DEV Community: Yasunori MAHATA

Initial Setup for a React + Hono Project

Yasunori MAHATA — Thu, 06 Mar 2025 07:38:59 +0000

What is this article about?

This is a memo about the initial setup when building a new web application using React (frontend) and Hono (backend). In this article, we will set up React using Vite.

By following this guide, you will get the following directory structure. The frontend/ directory contains the React application, while the backend/ directory contains the Hono application.

$ tree .
.
├── README.md
├── backend
│   ├──...
│   ...
└── frontend
    ├── ...
    ...

We assume that Node.js and pnpm are already installed. The setup was performed on macOS, but it should work in any modern shell environment.

As an appendix, this article also includes instructions on deploying the setup to Cloudflare Workers.

Creating `frontend/`

Create a frontend/ directory for the React project.

Generating a project template with Vite

$ pnpm create vite frontend --template react-swc-ts
$ cd frontend
$ pnpm i

The --template option can be react-ts as well. The difference is whether Babel or SWC (Speedy Web Compiler) is used for TypeScript transpilation. Since SWC is generally faster, we use react-swc-ts here.

Running tests with Vitest (Browser Mode)

Install Vitest and related packages:

$ pnpm install -D vitest @vitest/browser playwright vitest-browser-react @vitejs/plugin-react @testing-library/jest-dom

Add a "test" script to package.json:

"scripts": {
  "dev": "vite",
  "build": "tsc -b && vite build",
  "lint": "eslint .",
  "preview": "vite preview",
  "test": "vitest run --browser=chromium"   <-- Added
},

Create the Vitest configuration file frontend/vitest.config.ts with the following content:

/// <reference types="vitest" />
/// <reference types="@vitest/browser/providers/playwright" />

import react from "@vitejs/plugin-react";
import { defineConfig } from 'vitest/config'

export default defineConfig({
  plugins: [react()],
  test: {
    setupFiles: ['./src/setupTests.ts'],
    browser: {
      name: 'chromium',
      provider: 'playwright',
      enabled: true,
    },
  }
})

Create frontend/src/setupTests.ts and add the following content:

import "vitest-browser-react";
import "@testing-library/jest-dom/vitest";

Modify tsconfig.app.json by adding the following line under compilerOptions:

"types": ["@vitest/browser/providers/playwright", "vitest/globals"]

Now you can run pnpm test, and Vitest should start. Since no tests exist yet, it will fail.

Here is a sample test for the default "Vite + React" screen:

import { render } from 'vitest-browser-react'
import { expect, test } from 'vitest'
import App from './App'

test('loads and displays greeting', async () => {
  const screen = render(<App />)

  await expect.element(screen.getByText("Vite + React")).toBeInTheDocument()
})

Save this as frontend/src/App.test.tsx and run the test:

$ pnpm test

It should pass successfully.

Creating `backend/`

Navigate back to the project root and run the following commands:

$ pnpm create hono@latest ./backend --template cloudflare-workers --pm pnpm --install
$ cd backend
$ pnpm i  # Note: `pnpm i` might be required despite `--install`

Creating an API endpoint

Add the following endpoint to backend/src/index.ts:

app.get('/api/v1/books', (c) => {
  return c.json([
    { id: 1, title: 'The Great Gatsby', author: 'F. Scott Fitzgerald' },
    { id: 2, title: 'The Catcher in the Rye', author: 'J.D. Salinger' },
  ])
})

Writing tests

Install testing dependencies:

$ pnpm i -D vitest @cloudflare/vitest-pool-workers

Add the following script to backend/package.json:

"scripts": {
  "dev": "wrangler dev",
  "deploy": "wrangler deploy --minify",
  "test": "vitest --run"
},

Now, create a test file backend/src/index.test.ts:

import { expect, test } from 'vitest'
import app from './index'

test('should return JSON', async () => {
  const res = await app.request('http://localhost/api/v1/books');
  expect(res.status).toBe(200);

  const data = await res.json();
  expect(data).toEqual([
    { id: 1, title: 'The Great Gatsby', author: 'F. Scott Fitzgerald' },
    { id: 2, title: 'The Catcher in the Rye', author: 'J.D. Salinger' },
  ]);
})

Modify backend/src/index.ts::

import { cors } from 'hono/cors';

app.use('/api/*', cors({
  origin: 'http://localhost:5173',
}));

This is so that the development environment can receive API requests from React. Without this, due to CORS restrictions, HTTP requests will not go through.

(Appendix) Deploying to Cloudflare Workers

Hono apps can be easily deployed to Cloudflare Workers. Simply go to the backend/ directory and do pnpm run deploy. That's it. This will deploy your Hono app only to Cloudflare Workers.

But this article consists of a service with React and Hono, so how do we deploy React with it? Static Assets in Cloudflare Workers is an option. It uses Cloudflare Workers, but serves files under a specific directory statically. You can output the build results from frontend/ under backend/ and use it as Static Assets to deploy React and Hono together.

To deploy both React and Hono together, first modify frontend/package.json so that the build artifact is output under backend/dist:

"build": "tsc -b && vite build --outDir=../backend/dist",

Then add the following assets setting to backend/wrangler.jsonc:

"assets": {
  "directory": "./dist",
  "binding": "ASSETS"
},

Now, run:

$ pnpm build  # Run in frontend/
$ pnpm run deploy  # Run in backend/

Practically speaking, we do not want to move directories and run lots of commands every time, so it'd be better to prepare small scripts for them.

Other Options

Hono + JSX Middleware

Hono has a JSX middleware, which can be useful if you don't need full React.

Hono + HonoX

HonoX is another option for combining React and Hono, but it is in alpha at the time of writing.

A Tool to convert Bluesky posts to Pixela graph

Yasunori MAHATA — Thu, 06 Feb 2025 00:54:25 +0000

I created a tool that converts my daily Bluesky posts into a Pixela graph. The source code is available on GitHub.

For my account, it looks like this 📊 :

I’m aware that I tend to post on Bluesky only when I have free time. This tool helps visualize that pattern.

Implementation

The tool works by calling the Bluesky API, aggregating the number of posts per day, and then sending the data to Pixela via POST requests.

I won't go into details here because you can check the source code. It's small enough to take a look at. One thing I'd like to point out is that both the Bluesky and Pixela APIs are straightforward and easy to work with.

Appendix

The repository includes a GitHub Actions workflow that runs the script periodically:

name: Post to Pixela on a daily basis
on:
  schedule:
    - cron: '0 0 * * *' # Every day at 00:00 UTC
  workflow_dispatch:

jobs:
  slack:
    runs-on: ubuntu-24.04
    steps:
      - name: Check out repository code
        uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.13'
          cache: 'pip'

      - name: Install Dependencies
        run: pip install -r requirements.txt

      - name: Run the script
        run: python main.py
        env:
          BSKY_APP_PASSWORD: ${{ vars.BSKY_APP_PASSWORD }}
          BSKY_USERNAME: ${{ vars.BSKY_USERNAME }}
          PIXELA_GRAPH_ID: ${{ vars.PIXELA_GRAPH_ID }}
          PIXELA_USERNAME: ${{ vars.PIXELA_USERNAME }}
          PIXELA_USER_TOKEN: ${{ vars.PIXELA_USER_TOKEN }}

If you’re interested, you can clone the code, set up your Bluesky and Pixela environment variables, and have your graph updated automatically on a regular basis!

What's Test Doubles?

Yasunori MAHATA — Thu, 23 Jan 2025 02:56:16 +0000

Have you ever heard of test doubles? Even if you haven't, many software engineers use test doubles. For example, if you use Mockito in the Java world or Vitest/Jest in the JavaScript world, you are almost certainly using a test double.

Code that mimics a real implementation is called a test double.

There are several types of test doubles. The most commonly known name is the “mock”. Have you ever heard the expression “mocking a function” when talking about testing? In many cases, “mocking” means “making something behave differently from the real thing. But is it really “mocking”? What is the definition of “mock” in the first place? In this article, I will try to answer these questions.

Types of Test Doubles

There are several ways to classify test doubles, but following Martin Fowler, this article will classify them into the following five types

Dummy: A test double created to pass compilation (it will break if you try to use it).
Fake: A fake that actually works. Usually flawed in some way and not suitable for a production environment (e.g. in-memory database).
Stub: A test double that returns a predetermined value when called.
Spy: A test double that records how it is called.
Mock: A spy that asserts itself.

What do you think? Some of you may be thinking, “This doesn't make sense." I was also confused at first. Please read through the article without worrying about the details. After reading this article, you will be able to “get it”.

Motivation to classify test doubles

Why classify the test double? I believe it's for “clarify the intent of the test." I often develop by pair programming, and sometimes says to the pair, “Let's create a stub here to fix the behavior." If the partner also understands the classification of the test double, it is easier to convey the intent.

There is also a desire to be “professional” and use the correct terminology; writing JavaScript as JAVA SCRIPT undermines the trust of some people. You may suffer a similar disadvantage by calling a test double a miscellaneous name.

Test Double to Test the “Rocket Launch” System

Let's consider a test double in a program that controls a “rocket launch” system ¹. The example is in TypeScript, but it is written in such a way that it can be understood even if you do not have TypeScript-specific knowledge. If you understand the concepts of “interface” and “inheritance,” you can read it.

By the way, this program has a source: a blog post titled “The Test Double Rule of Thumb” published by VMware Tanzu Labs. The blog of Tanzu Labs has been closed for some time now, and it is no longer available. The original article was written in Java and was about controlling the launch of a missile, not a rocket. I pay great respect to the original article.

First State

There are two interfaces: Rocket and LaunchCode.

Let's start with Rocket.

export interface Rocket {
  // Launch the rocket
  launch(): void

  // Disable the rocket
  disable(): void
}

That's easy. Next is LaunchCode. This is the code required to launch the Rocket. We can't just launch the rocket without any thought.

export interface LaunchCode {
  // Returns whether the launch code has expired
  isExpired(): boolean

  // Returns whether the launch code is signed.
  isSigned(): boolean
}

We also created a Launcher as the main class and provided a method called launchRocket(). For now, this method simply launch() the Rocket object.

export class Launcher {
  launchRocket(rocket: Rocket, launchCode: LaunchCode) {
    this.rocket.launch()
  }
}

However, you don't want launchRocket() to launch a real rocket in the middle of the implementation. It would be disastrous. So let's consider dummy rockets.

Dummy

A valid launch code is required to launch a rocket. The launch code becomes invalid when it expires. How can we make sure in a test that an expired launch code will not launch a rocket?

Let's look at my proposal to use a dummy rocket.

export class DummyRocket implements Rocket {
  launch() {
    throw Error()
  }

  disable() {}
}

Dummy is a test double that “breaks when you actually try to use it”; the test that launchRocket() fails when it tries to use DummyRocket is as follows:

it("When expired launch code is given, rocket is not launched", () => {
  const launcher = new Launcher()
  launcher.launchRocket(new DummyRocket(), new ExpiredLaunchCodeStub())
})

ExpiredLaunchCodeStub is implemented as follows. This class is a test double called Stub. The definition of a stub is explained later.

export class ExpiredLaunchCodeStub implements LaunchCode {
  isSigned() {
    return true
  }

  isExpired() {
    return true
  }
}

This test fails, which is not surprising since dummyRocket throws an exception when launched().

We now have a “fails if rocket is used” test! Are you satisfied? No. This test has the following problems:

The absence of assertions in the test code makes it difficult to understand the intent of the test.
Catching the exception allows the test to pass even if launch() is used.

Let's assume that launchRocket() is implemented as follows:

  launchRocket() {
    try {
      this.rocket.launch()
    } catch (error) {}
  }

This passes the test even though it is launching the rocket. This means that the test is not driving the implementation, i.e., it is not functioning as TDD.

To remedy this, Let's introduce Spy.

Spy

The spy is a “test double that records how it was called." Let's quickly create a spy for Rocket.

export class RocketSpy implements Rocket {
  launchWasCalled = false

  launch() {
    this.launchWasCalled = true
  }

  wasLaunchCalled(): boolean {
    return this.launchWasCalled
  }

  disable() {}
}

This is a spy: launch() will set the launchWasCalled flag to true, and calling wasLaunchCalled() will get the value of the launchWasCalled flag. This implementation fulfills the request to record whether launch() is called or not.

Let's rewrite the test code using this. It should look something like this:

it("When expired launch code is given, rocket is not launched", () => {
  const rocket = new RocketSpy()

  const launcher = new Launcher()
  launcher.launchRocket(rocket, new ExpiredLaunchCodeStub())

  expect(rocket.wasLaunchCalled()).toBe(false)
})

rocket.wasLaunchCalled() returns true if the rocket passed to the launcher.launchRocket() method has been launched(). Now this test fails.

  launchRocket() {
    if (!this.launchCode.isExpired()) {
      this.rocket.launch()
    }
  }

It is probably easier to get the intent of the test with spies than with dummies. By using spies, we can write tests that follow the Given-When-Then syntax ². Let's add a comment to the code we just used with the spy.

it("When expired launch code is given, rocket is not launched", () => {
  // Given: When there's a rocket
  const rocket = new RocketSpy()

  // When: Launch the rocket with an expired launch code
  const launcher = new Launcher()
  launcher.launchRocket(rocket, new ExpiredLaunchCodeStub())

  // Then: Rocket is not launched
  expect(rocket.wasLaunchCalled()).toBe(false)
})

It's easy to understand. Also, with dummies, I could clench the exception and pass the test incorrectly, but not with spies. I could write a test to drive implementation. We could say that we could do test-driven development 😊

Next, let's look at mocks.

Mock

A new request came in from a product manager. When an invalid launch code is used, they want to disable the rocket itself as well. The Rocket interface had a disable() method. We could call this.

Let's modify the test code using the spy from earlier.

it("When expired launch code is given, rocket is not launched", () => {
  const rocket = new RocketSpy()

  const launcher = new Launcher()
  launcher.launchRocket(rocket, new ExpiredLaunchCodeStub())

  expect(rocket.wasLaunchCalled()).toBe(false)
  expect(rocket.wasDisableCalled()).toBe(true) // add this line
})

Added one assertion ³. Nothing too difficult. Let's update RocketSpy to make this test passed. It should look something like this:

export class RocketSpy implements Rocket {
  launchWasCalled = false
  disableWasCalled = false  // add this line

  launch() {
    this.launchWasCalled = true
  }

  wasLaunchCalled(): boolean {
    return this.launchWasCalled
  }

  disable() {
    this.disableWasCalled = true  // add this line
  }

  // add this method
  wasDisableCalled() {
    return this.disableWasCalled
  }
}

So far, it's clear.

The product manager says that not only can't we launch a rocket with expired launch code, we can't launch a rocket with unsigned launch code either. Then we need another test case.

it("When unsigned launch code is given, rocket is not launched", () => {
  const rocket = new RocketSpy()

  const launcher = new Launcher()
  launcher.launchRocket(rocket, new UnsignedLaunchCodeStub())

  expect(rocket.wasLaunchCalled()).toBe(false)
  expect(rocket.wasDisableCalled()).toBe(true)
})

UnsignedLaunchCodeStub looks like this, with isSigned() returning false.

export class UnsignedLaunchCodeStub implements LaunchCode {
  isSigned(): boolean {
    return false
  }

  isExpired() {
    return false
  }
}

Now consider an implementation that passes these tests. We could only launch() a rocket if the launch code is signed, not expired. So the implementation would look like this:

  launchRocket() {
    if (!this.launchCode.isExpired() && this.launchCode.isSigned()) {
      this.rocket.launch()
    } else {
      this.rocket.disable()
    }
  }

Now all tests pass. If all tests pass, it means it is time to refactor ⁴. Let's look again at the previous two test cases.

it("When expired launch code is given, rocket is not launched", () => {
  const rocket = new RocketSpy()

  const launcher = new Launcher()
  launcher.launchRocket(rocket, new ExpiredLaunchCodeStub())

  expect(rocket.wasLaunchCalled()).toBe(false)
  expect(rocket.wasDisableCalled()).toBe(true)
})

it("When unsigned launch code is given, rocket is not launched", () => {
  const rocket = new RocketSpy()

  const launcher = new Launcher()
  launcher.launchRocket(rocket, new UnsignedLaunchCodeStub())

  expect(rocket.wasLaunchCalled()).toBe(false)
  expect(rocket.wasDisableCalled()).toBe(true)
})

They are very similar. In particular, the next two lines are exactly the same:

  expect(rocket.wasLaunchCalled()).toBe(false)
  expect(rocket.wasDisableCalled()).toBe(true)

To clean up this duplication of assertions, let's make RocketSpy itself perform the assertion function by adding the following method to RocketSpy:

  verifyAbort() {
    expect(this.launchWasCalled).toBe(false)
    expect(this.disableWasCalled).toBe(true)
  }

This eliminates duplicate test code. It's clean. But is this really a spy? In fact, to this point, it is more appropriate to call this class a Mock. At the beginning of this article, I described a mock as a Spy that can assert itself. Exactly, the function to assert itself has been implemented.

Are there any disadvantages to using Mocks? Some may think that mocks are less readable than spies. Because explicit assertions fall out of the body of the test. We need to jump to verifyAbort() in the IDE to find out what we are asserting.

But if there are more conditions that don't fire rockets, their unrecognizability can't be ignored if the asserts are scattered throughout the test case. With mocks, the assert contents can be gathered in one place, reducing the need to write the same code all over the place.

Stub

Now let's talk about Stubs. Actually, though, stubs have already appeared: ExpiredLaunchCodeStub and UnsignedLaunchCodeStub. They fulfill the characteristics of stubs. That is, their methods "always return the same value."

Stubs are the basic test double, and it is almost impossible to write tests without them. That is why I wrote this article without any explanation at the first hand. It is a test double that is also easy to understand. So much so that I think I'll end the explanation here 😛

There is one thing I am dissatisfied with the stub implementation so far, so I will refactor it and conclude this section. The only complaint I have is that it is difficult to understand whether ExpiredLaunchCodeStub and UnsignedLaunchCodeStub are Expired or Signed, respectively. Let's solve this by introducing a base class.

export class ValidLaunchCode implements LaunchCode {
  isSigned() {
    return true
  }

  isExpired() {
    return false
  }
}

export class UnsignedLaunchCodeStub extends ValidLaunchCode {
  isSigned(): boolean {
    return false
  }
}

export class ExpiredLaunchCodeStub extends ValidLaunchCode {
  isExpired() {
    return true
  }
}

Introducing the base class ValidLaunchCode makes it easier to understand the intent of the derived class stub.

Fake

The product manager has informed us of another new requirement. He wants the launch code to be usable only once. Once someone has used the launch code, it is no longer available.

The test code would look like this:

it("When launch code is used already, rocket is not launched", () => {
  const rocket1 = new RocketMock()
  const rocket2 = new RocketMock()
  const launchCode = new ValidLaunchCode()

  const launcher = new Launcher()
  launcher.launchRocket(rocket1, launchCode)
  launcher.launchRocket(rocket2, launchCode)

  rocket2.verifyAbort()
})

What kind of implementation would allow this test to pass? Where should we store the used launchCode: RDBMS, KVS, or something else? Can it be stored in-memory? Do I need disk?

We prefer to make these decisions later. It is better to make these decisions when you have a clearer picture of your requirements. Focus on the interface to be implemented without thinking about the specific backend. Suppose the launchRocket() method accepts an argument called usedLaunchCodes. We use it as follows:

  Launcher.launchRocket(rocket1, launchCode, usedLaunchCodes);
  Launcher.launchRocket(rocket2, launchCode, usedLaunchCodes);

The requirements of the product manager should be satisfied if usedLaunchCodes can be used in the launchRocket() method as follows:

  launchRocket(rocket: Rocket, launchCode: LaunchCode, usedLaunchCodes: UsedLaunchCodes) {
    if (
      !usedLaunchCodes.contain(launchCode) &&
      !launchCode.isExpired() &&
      launchCode.isSigned()
    ) {
      rocket.launch()
      usedLaunchCodes.add(launchCode)
    } else {
      rocket.disable()
    }
  }

Yes, all we need is contains() and add() methods for usedLaunchCodes. At this point, the UsedLaunchCodes interface seems to be defined. And once the interface is defined, we can create a fake class that satisfies it. Yes, that fake is a Fake test double.

Fake is completely different from other test doubles. Other test doubles are easily distinguished from the real thing. Fakes, on the other hand, are made to be indistinguishable from the real thing. The fake imitates all the behaviors of the real thing. The fake is expected to be used in the same way as the real thing. But how do we make sure the fake behaves as expected? We can write tests 😉 When using a fake, we need to test the fake itself. This is another difference from other test-doubles.

Now, the interface of UsedLaunchCodes can be expressed in TypeScript code as follows

export interface UsedLaunchCodes {
  contain(launchCode: LaunchCode): boolean
  add(launchCode: LaunchCode): void
}

What would the test of this implementation class, FakeUsedLaunchCodes, look like? I think the test would be as follows:

it("contains() checks if a given launch code is already used", () => {
  const usedLaunchCodes = new FakeUsedLaunchCodes()
  const launchCode = new ValidLaunchCode()

  expect(usedLaunchCodes.contain(launchCode)).toBe(false)

  usedLaunchCodes.add(launchCode)

  expect(usedLaunchCodes.contain(launchCode)).toBe(true)
})

Now that we have come this far, it should not be too difficult to implement it; my implementation of FakeUsedlaunchCodes is as follows:

export class FakeUsedLaunchCodes implements UsedLaunchCodes {
  private launchCodes: Set<LaunchCode> = new Set()

  add(launchCode: LaunchCode): void {
    this.launchCodes.add(launchCode)
  }

  contain(launchCode: LaunchCode): boolean {
    return this.launchCodes.has(launchCode)
  }
}

Is this implementation acceptable? This way, if you restart the process, you lose the history of used launch codes. But the faking is "Ok with it." Implementing it this way allows us to put off making decisions about the real UsedLaunchCodes backend. Right now the in-memory Set<LaunchCode> is the history of the launch code, but a real implementation might be a Set of ValKeys, or it might be PostgreSQL. When you need them, just create a real class that implements UsedLaunchCodes.

Conclusion

This article has explained the test double. Be aware of the different types of test doubles and choose an appropriate test double to write your tests.

The code created in this article is up on GitHub. However, it is recommended that you actually try your hand at it while reading the article, as simply looking at the final form will not help you understand it.

The final code is available on GitHub. ↩
Martin Fowler has a blog post on Given When Then syntax. This syntax conveys the intent of the test by dividing the test code into three sections and writing "Given," "When," and “Then". ↩
There is an opinion that there should be only a single assertion for a single test method. I agree with that policy, but ignore it here for simplicity of explanation. ↩
Test-driven development is a “Red => Green => Refactor” cycle, where Red is the state where the test fails, Green is the state where the test passes, and Green is followed by Refactor because you can immediately notice if you accidentally break the implementation during refactoring. ↩

A Chrome extension for Startpage.com which adds search queries to the tab title

Yasunori MAHATA — Fri, 05 Jan 2024 01:33:04 +0000

The advent of ChatGPT has significantly reduced the use of conventional web searches. However, since ChatGPT doesn't possess new knowledge, I occasionally use search engines to obtain the latest information.

I use Startpage as my search engine. It is advertised as "The world's most private search engine." According to their own description, they return search results without retaining any user information. A similar service with higher recognition is DuckDuckGo.

I personally think that the search quality of DuckDuckGo is "not very good." DuckDuckGo uses Bing as its backend search engine, but I find Bing's search results somewhat inferior compared to Google, especially when searching for information in languages except English.

When using Startpage as it is, I encounter a problem: it's hard to distinguish between multiple search result pages. For instance, suppose you have three tabs open with searches for "Startpage," "DuckDuckGo," and "Google." In Google Chrome, they appear as follows:

Repeated searches can make it unclear which tab contains which search results.

I believe this is an intentional design by Startpage. Common search engines include the search query in the URL parameters, like ?q=search-query. Startpage receives search queries via POST requests, making it impossible to discern the search query from the URL. Similarly, not including the search query in the page title is likely a consideration to protect privacy even if someone peeks at your browser.

However, this compromises usability, which I personally find unbearable. To solve this, I created the Startpage Nicer Title Extension, a Chrome Extension. With this installed, the tabs look like this:

Can you see the difference? The search keywords are prefixed to the tabs. This makes it easier to distinguish between multiple search results in the browser.

The source code for this Chrome extension is available on GitHub. Speaking technically... there's not much to say. As of writing this article, the entirety of the code is the 5 lines in scripts/content.js:

const searchBox = document.getElementById('q');

if (searchBox && searchBox.value.trim() !== "") {
document.title = searchBox.value + " - StartPage";
}

The search box <input /> in Startpage has an id="q", so the code just retrieves its value and stuffs it into document.title. It's a short code, but I think it's amazing that something meaningful can be created with just this.

If you use a Chromium-based browser and are interested in Startpage, please try the Startpage Nicer Title Extension.