For a decade the web moved everything to the client. Rendering, routing, data fetching, state, all shipped as JavaScript and reassembled in the browser. The current generation of tools is quietly walking a lot of that back, and the results are faster sites with less code. Here is the shape of the new stack.
The pendulum swings back to the server
The single-page application solved a real problem, rich interactivity, and created a new one: enormous JavaScript bundles that block the main thread and punish anyone without a flagship phone. The insight driving the new stack is simple.
Islands: interactivity as the exception
The islands architecture inverts the SPA default. Instead of a JavaScript app that renders some static content, you have a static HTML page with small islands of interactivity embedded in a sea of inert, fast HTML.
Each island hydrates independently and lazily. A search box at the top of the page does not block a comment widget at the bottom, and a page with zero interactive elements ships zero JavaScript.
---
// This runs at build time on the server, never shipped to the browser.
const posts = await getPosts();
---
<article>
<!-- Static HTML: zero client JS -->
{posts.map((p) => <PostCard post={p} />)}
<!-- Only this component ships JavaScript, and only when visible -->
<SearchBox client:visible />
</article>The client:visible directive is the whole philosophy in one line: hydrate this, and only this, and only when it scrolls into view.
Streaming and the edge
The second shift is where and when rendering happens. Instead of rendering a whole page in one region and then sending it, the new stack streams HTML as it is produced, from servers positioned close to the user.
| Strategy | Time to first byte | JS shipped | Best for |
|---|---|---|---|
| Client-rendered SPA | Fast, blank | High | App-like, auth-walled UIs |
| Server-rendered (SSR) | Medium | Medium | Dynamic, personalized pages |
| Static (SSG) | Fastest | Minimal | Content, marketing, blogs |
| Streaming + islands | Fast, useful | Low | Most content-driven sites |
Less JavaScript is a feature
The uncomfortable truth is that the biggest performance win available to most sites is not a faster framework; it is simply shipping less JavaScript. Every kilobyte has to be downloaded, parsed, and executed on the main thread, and that thread is also the one drawing the page.
Where it is heading
The direction is clear: HTML-first by default, interactivity opted into deliberately, rendering pushed to the edge and streamed. Frameworks are converging on this from different starting points, but the destination is the same: a web that is fast because it stopped doing so much work in the browser.
The fastest JavaScript is the JavaScript you never shipped.
None of this means the SPA is dead; genuinely app-like products still want it. But for the enormous category of sites that are mostly content with some interactivity, the new stack is a strictly better deal: less code, less complexity, and pages that are fast for everyone, not just the people holding the newest phone.
