It’s 2026 and the pendulum has swung too far. Server Components. Server Actions. Server State. Hydration. Partial Hydration. Resumability. Islands. The Edge. It feels like the entire industry collectively decided that the browser is just a dumb terminal. That the only way to build a fast website is to do everything on the metal, somewhere in a data center in Virginia, and ship HTML down the wire.

And for 99% of the web, they are right. If you are creating a blog? SSR. If you are launching an e-commerce site? SSR. If you are designing a marketing page? Static Site Generation. But we aren't doing those things. We are building Werkbank. We are crafting IDEs, video editors, and complex, stateful, long-lived applications that people keep open for eight hours a day. And for us, the Server is a distraction.

The Physics of Latency

The common argument is that moving logic to the server reduces latency because it's "closer to the database." That is true for the first fetch. But do you know what's even closer to the user for every subsequent interaction? The user's RAM.

When I click a button to open a modal, I don't want to wait for a roundtrip to Virginia. I don't care if it's 50ms. I want it to be 0ms. I want it to be instantaneous. I want the UI to react before my finger has even fully lifted off the mouse button.

This is about both actual and perceived performance. In a rich client-side application, the data should already be there. It should be in a local cache. It should be in a global store. It should be in indexedDB. We are building "Local-First" software. The network is an enhancement, not a requirement for interaction.

The Forgotten Promise of the PWA

Do you remember the dream? Around 2014, Jake Archibald published the first draft of the Service Worker. It was a watershed moment. For the first time, we had a programmable network proxy in the browser. We could intercept requests, cache responses, and build applications that worked truly offline.

It felt like the beginning of a new era. The era of the Progressive Web App (PWA). The promise was bold: Web apps that could rival native apps. Apps that could live on your home screen, access the File System, communicate with USB devices, and run in borderless windows. The ChromeOS team laid out a vision of High-Trust APIs and "capabilities" that would finally break the web out of the browser tab.

The technology is ready. It has been for years. But somewhere along the way, the mindset shifted. We stopped talking about Service Workers and started talking about Edge Functions. We stopped talking about "Offline First" and started talking about "Server First." We traded the raw power of the client device for the convenience of a unified backend. We let the PWA dream wither on the vine while we optimized First Contentful Paint for users who visit our site once and never come back.

The "App" vs. The "Site"

This abandonment of the PWA vision stems from a fundamental divide that we keep trying to paper over.

A Site is content. It's consumption. You go there, you read, you leave. The interaction model is "Click Link -> Load New Page". Sites should use SSR. It makes sense.

An App is a tool. It's creation. You go there, you stay. The interaction model is "Drag, Drop, Type, Resize, Toggle".

React was born to build Apps. It was a library for building user interfaces. It was about state management and DOM reconciliation. But lately, React has been optimizing for Sites.

And that's fine. The web is mostly Sites. But it leaves those of us building Apps feeling a bit... abandoned. We don't need SEO. Our app is behind a login. We don't need to reduce bundle size at all costs. Our users are on fiber connections and desktop computers. They can download 2MB of JS. It's fine.

Embracing the Client (Again)

So with Werkbank, we made a choice. We are picking up the torch that was dropped. No Next.js. No Remix. No Server Components. Just a good old-fashioned Single Page Application, supercharged with the technologies everyone else forgot.

We use Service Workers not just for caching assets, but for Background Sync. This means if you hit "Save" and close the tab immediately, the browser will wake up in the background and ensure that request completes. We use Web Workers to move heavy logic—parsing, image processing, database queries—off the main thread. We use WASM to bring native-grade performance to the browser.

To solve the data problem, we are building werkbank/db. It's a local-first database that runs right in your browser.

"But isn't IndexedDB slow and hard to use?" Yes. That's why we aren't using raw IndexedDB. We are using PGlite, a WASM build of Postgres. We are running a full SQL database in the browser. Not a reimplementation, but the actual Postgres codebase compiled to WebAssembly.

Why SQL? Because it removes abstractions. We don't need a custom query language. We don't need a proprietary ORM. We just write SQL. And with pgtyped, we get full type safety for those queries. No more guessing if user.name is a string or null. It brings the power and safety of backend development right into the frontend codebase.

useFindPersonById({ id: 1 }) isn't just a hook. It's a live subscription to a SQL query running in a Web Worker. The server is just a backup.

The Cost of Simplicity

Is it simpler? Yes and no. We have to manage loading states. We have to handle data synchronization.

Instead of just fetching data (hello tanstack-query), we are building a full sync engine with werkbank/db. It handles offline mutations, conflict resolution, and optimistic UI updates automatically. This is complex engineering, but it pays off in user experience.

The mental model becomes simpler. There is one runtime. The Browser. There is one state. The Memory. There is no "network waterfall" because we aren't cascading requests from a server component to a client component back to a server action.

Conclusion

I'm not saying SSR is bad. It's amazing technology. But it's not the only way. If you are building a tool—a real, heavy, complex tool—don't be afraid to embrace the Client. The browser is an incredibly powerful operating system. It has a file system. It has a database. It has threading.

We stopped fighting it. Use it. Build something that feels native. Build something that feels instant. The web is capable of more than just displaying text. Let's make the web powerful again.

function hello() {
  console.log("Hello from the client!");
}