TL;DR: Last week I argued Gemma 4 Dense regressed on a grounded-retrieval scenario under tightened prompts — and called the MoE-vs-Dense divergence architecture-mediated. The comment thread, led by Robin Converse on her sovereign Ollama stack, proposed an alternative: my max_tokens: 400 cap was starving Gemma’s reasoning layer before the visible reply completed. I re-ran the same six scenarios with one variable changed — budget raised from 400 to 4096. Dense recovered on every scenario, including the false-refusal headline that anchored the original article. MoE did too. The original MoE-vs-Dense divergence largely disappears when reasoning has room to finish. The cap was doing the work. Walking it back publicly.

Why I Re-Ran It

Last week I published I Added Three Rules to Gemma 4. The MoE Searched. The Dense Model Refused.. Quick recap: I ran Gemma 4 26B MoE and Gemma 4 31B Dense through my Arabic e-commerce chat router with three prompt rules — an Arabic-first system frame, temperature capped at 0.3, max_tokens floored at 400. The 26B MoE flipped from stalling to grounded answers. The 31B Dense flipped from working correctly to false-negative refusals on a scenario where the white shirts the customer asked about were sitting in its context. I called the divergence architecture-mediated and shipped the article.

The comment thread reframed it.

Robin Converse (Triava Labs, running the same model family on self-hosted Ollama) ran her own uncapped sweep on her sovereign stack — same scenarios, three temperatures, max_tokens unrestricted. Her MoE handled every case correctly. She posted the methodology and the 18-call breakdown and asked: what does the same test look like on the managed Gemini API side? She also separately filed two upstream Ollama bugs — walked back her framing on #15288 publicly when maintainers clarified it was a configuration issue, and #15428 was confirmed by multiple users and resolved in a later release. That kind of fair-witness practice is what made me trust the hypothesis enough to test it.

The hypothesis itself, sharp: my max_tokens: 400 cap was starving Gemma 4’s reasoning layer before the visible reply completed. Capability ceiling and orchestration pressure look identical from the outside, as Vic Chen put it on the same thread — only one is solvable by giving back budget. Vadym Arnaut mapped a separate substitution-vs-decision boundary that sharpened where to look. Edwin Realpe Preciado, Mykola Kondratiuk, Theo Valmis, and Hashevolution each named structural reframes I had to engage. The collective shape of the thread was: the cap is one variable, the architecture is a category, and you’ve been calling the result by the wrong name.

The cap was the part I could test fastest. One variable. Re-run the same six scenarios on the same two architectures with the only change being the budget.

The Experiment

Single-variable change against the original v2 conditions:

The implementation was four lines in the chat-models server file the original article describes, gated behind an env flag so production behavior stays untouched:

// before
max_tokens: Math.max(params.max_tokens ?? 0, 400),
// after
const uncapped = process.env.GEMMA_UNCAPPED === "1";
max_tokens: uncapped ? 4096 : Math.max(params.max_tokens ?? 0, 400),

Dev server restarted with GEMMA_UNCAPPED=1. Sweep script ran the same six scenarios from the original article — same customer messages, same demo store, same router stack with gpt-4o-mini on every non-reply call so the only thing changing is the budget Gemma sees on the final response call.

No prompt edits. No router changes. No temperature changes. No new model rules. Just the budget.

The Results

12 of 12 calls succeeded. Both architectures handled every scenario correctly.

HTTP 500 rate: v2 Dense was 2 of 6. Uncapped Dense was 0 of 6. Uncapped MoE was 0 of 6. The reliability gap disappears.

Latency (single run per pair, exploratory not statistical): 26B MoE 28–56 s, avg 37 s. 31B Dense 19–38 s, avg 27 s. The Dense variant was faster than the MoE variant once both had budget — different from what either round of the original article suggested.

Scenario 2 — the load-bearing test

The original article’s headline failure was Scenario 2 on Gemma 4 31B Dense: customer asks for a white shirt in size L, the catalog has three, the Dense model said:

​v2 capped: “والله ما عندنا قميص أبيض مقاس L حالياً. اعذرني، ما في شي متوفر من هاد الموديل حالياً.”

Translation: “We don’t currently have a white shirt in size L. My apologies, nothing of that model is available right now.”

Same model, same context, same prompt, same temperature, budget raised from 400 to 4096:

​Uncapped: “من عيوني! عندنا Urban Cool Striped Shirt بـ $65، وBordeaux Heritage Shirt بـ $80، وUrban Stripes Classic Shirt بـ $95، وكلهم متوفرين باللون الأبيض ومقاس L. بنصحك تنسق القميص مع Chinos عشان تطلع الطلة مرتبة وفخمة!”

Translation: “My pleasure! We have Urban Cool Striped Shirt for $65, Bordeaux Heritage Shirt for $80, and Urban Stripes Classic Shirt for $95, all available in white in size L. I recommend pairing the shirt with Chinos for a clean, polished look!”

False refusal → three real SKUs with real prices and a styling cross-sell. One variable changed.

What This Means

The original article called the MoE-vs-Dense divergence architecture-mediated. The honest read of the re-run is sharper than that:

1. The cap was doing most of the work. Under max_tokens: 400, both architectures were starving — MoE in Round 1 (stalls on Scenario 2), Dense in Round 2 (false-refusal on Scenario 2 once the augmentation tightened the prompt enough to push reasoning over the budget). When both have room, both behave grounded.
2. The architectural difference is real but quantitative, not qualitative. Dense and MoE both perform multi-step reasoning on this workload; they just pay different token-budget taxes for it. Calling the v2 result “architecture-mediated failure” over-claimed. The accurate phrasing is closer to: budget allocation for multi-step reasoning is architecture-sensitive; the failure mode is the same in both cases — running out of tokens before output completes.
3. The “Dense is unfit for grounded chat” subtext that some readers took from the original is wrong. Dense recovered on every scenario when given the budget. The article’s matrix table was misleading on that point and I should have flagged it harder.

Robin called it from her stack on Tuesday. The cross-validation now exists: same architecture, two deployment contexts (sovereign Ollama, managed Gemini API), one finding — uncap the budget and the failure mode evaporates.

What still partially holds from the original article:

• Reluctance, not hallucination, as the dominant failure mode for grounded Arabic chat on open models when the budget is too tight to complete reasoning.
• Variant-specific prompt tuning is real — but the variant-specific thing isn’t an architectural slot; it’s a token budget shaped to the variant’s reasoning footprint.
• Latency on the Google API is still a chasm for interactive chat — that part wasn’t a cap artifact.

What I retract:

• The “architecture has slots for sequential sub-behavior that dense doesn’t” hypothesis was too strong. Dense plus budget gets the same grounded behavior.
• The matrix’s “31B Dense regression” reads now as “31B Dense under-budgeted regression.”
• The closing line — “I think I was tuning architecture, not size” — should have been “I think I was tuning budget, mediated by architecture.”

What’s Still Open

• Temperature dimension untested in this run. I held temperature at 0.3 to keep this one-variable. Hashevolution flagged this specifically — the temperature cap may not be neutral across architectures, since forcing 0.3 on an MoE might suppress the routing entropy that lets it resolve sequencing in the first place. The next sweep varies temperature (0.3 / 0.7 / default) on top of uncapped budget to separate “architecture matters” from “thermostat + architecture matters.”
• Cross-validation with Robin’s data still pending as a single artifact. She ran her side on sovereign Ollama; I ran mine on managed Gemini AI Studio. Two stacks, one architecture, one combined finding. That’s the version worth co-publishing — and the version where the headline becomes “what holds across deployment contexts.”
• Instruction-order ablation / typed retrieval. Edwin proposed making preconditions first-class through his NEXUS protocol; Hashevolution proposed typed retrieval-conditioning context via Graph-RAG as a cross-domain falsifier. Both bypass the model’s ambiguity resolution by removing the decision from the model. The Graph-RAG cross-experiment is in motion — provider-contract landed early on Hashevolution’s side, swap targeted for mid-June.
• The eval_count vs response-chars gap Robin found on her side (token count widens with query difficulty, response characters don’t). I didn’t reproduce that measurement on this run — the Gemini API surfaces different telemetry than Ollama’s /api/generate. Worth a follow-up that adds per-call token accounting on the managed side so the cross-validation is symmetric.
• Third deployment context queued. Hashevolution shared that JAMES’s per-stage DEFAULT_MAX_TOKENS defaults (200/400/400/400 across four cognitive stages) match this pathology — their 2026-05-18 internal eval reported empty responses on gemma4:e4b at exactly those four stages. Uncapped replication is queued this week. If it reproduces, that’s three independent deployment contexts (sovereign Ollama, managed Gemini API, JAMES production) on the same cap pathology before any cross-experiment swap runs.

The Lesson

The community ran my falsifier for me. The cap is one variable; architecture is a category. If your model is failing under a tight token budget, raise the budget before you reach for architectural explanations — and if a thoughtful commenter offers you a single-variable test against your strongest claim, run it.

The article you can write a week later, with the comment thread folded in, is stronger than the one you ship alone. Robin Converse is the right person to share the next round with.

A Next.js app migrated from Pages Router to App Router. RSC throughout, use client pushed to the leaves. Lighthouse score went up. LCP in production got worse by 800ms.

The component tree was fetching data. Each server component called its own database query. They ran sequentially — one couldn’t start until its parent finished. What was previously one getServerSideProps call became eight round trips before the page could render.

RSC reduces client JavaScript. That part works exactly as advertised. What it doesn’t do is make data fetching faster, or eliminate the server-side work that now determines when your HTML actually arrives.

What RSC actually changes

Server components stay on the server. Their code never ships to the browser, they don’t get hydrated, and anything they import doesn’t touch the client bundle. For components that are genuinely static — content that renders from data and never responds to user interaction — this is a real win. The JavaScript savings from the previous article compound here: pushing use client to the leaves is how you maximize the RSC benefit.

Bundle size reduction is real. But LCP is determined by when the HTML arrives, not by how much JavaScript the client downloads afterward. If server components are slow, TTFB is slow, and LCP is slow — regardless of how small the client bundle is.

The waterfall that App Router makes easy to create

Pages Router’s data fetching model had a structural advantage it rarely got credit for: getServerSideProps ran once, in one place, before the page rendered. Everything the page needed came from one function.

With RSC, each component can fetch its own data. This sounds cleaner — components are self-contained, colocated with their data requirements. The problem is that React renders the component tree top to bottom, and a child component’s data fetch can’t start until its parent has rendered and the child has mounted on the server.

// ParentComponent fetches its data first
async function ParentComponent() {
  const parent = await db.query('SELECT * FROM parent WHERE id = ?', [id]);
  return <ChildComponent parentId={parent.id} />;
}

// ChildComponent can't start until ParentComponent finishes
async function ChildComponent({ parentId }) {
  const children = await db.query('SELECT * FROM children WHERE parent_id = ?', [parentId]);
  return <>{/* render */}</>;
}

Two queries, sequential. If each takes 40ms, that’s 80ms added to TTFB before the waterfall. Nest three or four levels of components that each need data, and you’re looking at 200–400ms of sequential database round trips added to every page render.

This is the App Router waterfall. It’s easy to create, easy to miss in development where database latency is near zero, and immediately visible in production.

Fetching in parallel

The fix is to hoist data fetching to the component that needs all the data, or to run independent queries in parallel:

async function ProductPage({ productId }: { productId: string }) {
  // These run in parallel — Promise.all starts both immediately
  const [product, reviews, inventory] = await Promise.all([
    db.products.findById(productId),
    db.reviews.findByProduct(productId),
    db.inventory.getStock(productId),
  ]);

  return (
    <>
      <ProductHeader product={product} />
      <InventoryStatus inventory={inventory} />
      <ReviewList reviews={reviews} />
    </>
  );
}

Three queries, one round trip’s worth of latency. The child components receive data as props and render without fetching anything themselves.

This trades component colocation for speed. Sometimes that’s the right tradeoff. For a page where TTFB matters — which is most pages — it usually is.

For queries that genuinely can’t be parallelized because they depend on each other’s results, React.cache at least prevents duplicate fetches across a single render when multiple components request the same data:

import { cache } from 'react';

const getUser = cache(async (userId: string) => {
  return db.users.findById(userId);
});

// Both components call getUser — only one database query executes
async function Header({ userId }) {
  const user = await getUser(userId);
  return <nav>{user.name}</nav>;
}

async function Sidebar({ userId }) {
  const user = await getUser(userId);
  return <aside>{user.role}</aside>;
}

cache deduplicates within a single request. It doesn’t cache across requests — that’s what unstable_cache or a proper caching layer handles.

TTFB is the new LCP bottleneck

With Pages Router, slow getServerSideProps was obviously the bottleneck because it was the one place data fetching happened. With App Router, the bottleneck is distributed across the component tree and harder to trace.

The signal to look for: LCP correlates with server response time in your field data, not with client-side metrics. If p75 LCP improves when you filter to users with fast connections, that’s a client-side problem. If it’s high regardless of connection speed, the server is slow.

Measuring TTFB separately from LCP in your RUM data makes this visible. If TTFB is 600ms and LCP is 650ms, the client is fine — the server is the problem.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === 'navigation') {
      sendMetric({
        ttfb: entry.responseStart - entry.requestStart,
        page: location.pathname,
      });
    }
  }
}).observe({ type: 'navigation', buffered: true });

Tracking TTFB per page in production shows which routes have server-side performance problems. A product listing page with high TTFB is a data fetching problem. A marketing page with high TTFB is a different problem — probably server cold starts or lack of caching.

Where RSC genuinely helps

RSC is the right model for components that render server-side data without needing client interactivity. Static product descriptions, server-rendered markdown, navigation built from a CMS — these belong on the server. Moving them there reduces the client bundle and eliminates hydration cost, and that’s a real performance improvement.

What RSC doesn’t do is make database queries faster, fix slow APIs, or reduce TTFB if your data fetching is sequential. The performance benefit of RSC is realized at the component boundary — it removes cost on the client. Everything upstream of that boundary is still your problem.

The next article in this series covers streaming SSR — the actual mechanism that lets Next.js send HTML before all the server-side data is ready, and where it genuinely helps LCP versus where it creates new problems to manage.

Next.js apps are heavy. A standard Docker build often exceeds 1 GB, wasting bandwidth, disk space, and deployment time.

The fix? Multi-stage builds. With a simple Dockerfile change, you can shrink that image by 70% or more.

Why is the default image so big?
A typical single-stage Dockerfile:

Installs node_modules (including devDependencies like TypeScript, ESLint, testing tools).

Keeps build caches and source maps.

Includes the entire build toolchain inside the final image.

You don’t need any of that in production.

The multi-stage approach
Split the build into three stages:

Dependencies – Install everything.

Builder – Run next build.

Production – Copy only the bare essentials.

Example Dockerfile
dockerfile

Stage 1: Dependencies

FROM node:18-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci –only=production

Stage 2: Builder

FROM node:18-alpine AS builder
WORKDIR /app
COPY –from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

Stage 3: Production

FROM node:18-alpine AS runner
WORKDIR /app

Copy standalone output (Next.js 12+)

COPY –from=builder /app/.next/standalone ./
COPY –from=builder /app/.next/static ./.next/static
COPY –from=builder /app/public ./public

EXPOSE 3000
CMD [“node”, “server.js”]
Key line:
COPY –from=builder /app/.next/standalone ./ — This is the magic. It grabs only the compiled production output.

Results
Metric Single-stage Multi-stage Reduction
Image size 1.2 GB 280 MB 77%
Node modules Full (300 MB) None in final 100%
Build artifacts Kept Removed –
Pro tips for even smaller images
Enable standalone output – In next.config.js:

js
module.exports = {
output: ‘standalone’,
}
This creates a self-contained server.js with minimal dependencies.

Use Alpine Linux – node:18-alpine is ~50 MB vs node:18 (~1 GB).

Add .dockerignore – Exclude .git, .next, node_modules, Dockerfile.

Run as non-root – Add RUN addgroup –system –gid 1001 nodejs + USER nodejs for security.

What about caching?
Multi-stage still caches well. Docker caches each stage independently. Your CI will rebuild only changed layers.

The bottom line
Switching to multi-stage builds is 15 minutes of work for a 70%+ size reduction. Smaller images mean:

Faster deployments

Lower storage costs

Quicker container pulls (especially on Kubernetes)

Try it on your next Next.js project. Your DevOps team will thank you.

Need a working example? Check out the official Next.js Docker example in their GitHub repo.

I’ve been writing React for a long time, and I want to tell you a story about a round trip. It starts with me being a true believer in Next.js, runs through the era when the App Router and Server Components moved into my house and rearranged the furniture, passes through a couple of genuinely scary security incidents, and ends with me happily back on a boring, well-understood architecture: a single-page app and a separate backend that talk over a plain HTTP boundary.

This isn’t a “framework X is dead” hot take. It’s a description of how my own thinking changed, and why the thing I reach for in 2026 looks a lot like the thing I would have reached for in 2018… except smarter about the parts that actually matter.

When Next.js was genuinely great

I want to be fair to Next.js, because for a long stretch it earned its reputation.

The Pages Router era was a sweet spot. You had file-based routing that you could explain to a new hire in five minutes. You had getStaticProps and getServerSideProps – two functions, clearly named, with an obvious mental model: one runs at build time, the other runs per request, and everything else is just React. You got code splitting, image optimization, and a dev server that mostly worked. Deploying was a non-event.

The thing I appreciated most was that the boundary between server and client was legible. Data fetching happened in named lifecycle-ish functions at the top of a route. The component tree below them was ordinary client React. I could point at any line of code and tell you which machine it ran on. That legibility is worth more than people realized at the time, and we mostly only noticed it once it was gone.

So when I say I left, understand that I left something I used to love.

Then the App Router and Server Components moved in

The App Router and React Server Components were pitched as the next evolution, and on paper the pitch is seductive: render components on the server, ship less JavaScript, colocate data fetching with the component that needs it, stream HTML to the browser as it becomes ready. Who doesn’t want less JS and faster paint?

In practice, here is what I actually experienced.

The mental model fractured. Suddenly every file was either a Server Component or a Client Component, the distinction was load-bearing, and the boundary was declared with a "use client" string at the top of a file. That directive is viral in one direction and silent about it. A component that was fine yesterday breaks today because something three levels up crossed the boundary, and the error you get is rarely “you crossed a boundary”; it’s a serialization complaint, or a hydration mismatch, or a hook being called somewhere it can’t be.

“It works in dev” stopped meaning anything. Caching behavior between next dev, next build && next start, and the production edge deployment diverged enough that I stopped trusting local results. I had bugs that only existed in the production cache. I had stale data that no revalidate value seemed to fix. I learned more about the Next.js caching layers than I ever wanted to, and the reward for that knowledge was a permanent low-grade anxiety about whether any given page was actually fresh.

The server/client boundary stopped being legible. This is the one that really got me. The thing I loved most about the Pages era, being able to look at code and know where it ran, was exactly the thing RSC took away. Data fetching is now scattered through the tree. async components look like normal components but aren’t. The boundary is real and consequential but invisible at the call site.

None of these are unfixable in isolation. Together they meant I was spending a large fraction of my time fighting the framework’s model instead of building the product. That’s the signal I should have read sooner.

Then the security incidents made it concrete

Architectural friction is a judgment call. Security incidents are not, and a run of them turned my vague unease into a decision.

It started with CVE-2025-29927, the middleware authorization bypass disclosed in March 2025 at CVSS 9.1. The mechanism was almost embarrassingly simple: Next.js used the internal header x-middleware-subrequest to mark subrequests and prevent infinite middleware loops, but the header was never meant to be client-controlled, and by spoofing it, attackers could skip middleware entirely, auth and authorization included, and reach protected routes with one crafted curl.

If that had been a one-off, I’d have shrugged it off; every framework has bugs. But it wasn’t a one-off. The back half of 2025 and the start of 2026 brought a steady drumbeat, and the pattern is what mattered:

• CVE-2025-55182 (December 2025) – a React Server Components flaw rated CVSS 10.0, the maximum. It sat in the react-server-dom-* packages and therefore affected every framework built on RSC & Next.js, React Router’s RSC APIs, Waku, Parcel’s RSC plugin, and the Vite RSC plugin. A perfect score is rare, and this one lived in the RSC machinery itself.
• CVE-2026-23864 (January 2026, CVSS 7.5) – a denial-of-service flaw in React Server Components: a malicious payload sent to a Server Function endpoint triggers memory exhaustion or runaway CPU. Patched alongside two more medium-severity Next.js CVEs in the same release.
• CVE-2026-23869 and CVE-2026-23870 (early 2026) – more DoS issues in Server Components, triggered by specially crafted HTTP requests to App Router Server Function endpoints that blow up CPU on deserialization. Affected Next.js 13.x through 16.x on the App Router.
• CVE-2026-44578 (May 2026, CVSS 7.8) – a server-side request forgery in the self-hosted Next.js Node server: crafted WebSocket upgrade requests let an attacker proxy requests to arbitrary internal destinations, including cloud metadata endpoints.

Look at where these clusters are. A middleware bypass, then a string of Server Component and Server Function flaws, several of them triggered specifically on deserialization of a crafted request. This isn’t bad luck distributed randomly across a codebase. The vulnerable surface is the server-rendering and server-function machinery, the exact part of the stack that the App Router and RSC made central. The more your framework does on the server on every request, the more attack surface you have signed up for, and a 10.0 in the shared RSC packages means a single bug ripples across every framework that adopted the model.

What unsettled me wasn’t any single CVE… it was what the cluster implied about the architecture. Teams like mine had been quietly nudged to treat middleware as the authorization layer, because in the App Router model, auth-in-middleware is the path of least resistance. The level-headed takeaway in every writeup was the one that stung: middleware should supplement, not replace, security enforced closer to the data. So, I sat with a question: how much of my security posture do I want coupled to a rendering framework’s internal request plumbing? My answer was “as little as possible.”

The TanStack route – also not a free lunch

When developers get fed up with Next.js, a common next stop is the TanStack ecosystem – TanStack Router and TanStack Start. And I’ll be honest: TanStack Router is a genuinely nice piece of engineering. The type-safe routing is best-in-class, the search-param handling is thoughtful, and the data loading is well-considered. If you’d asked me purely about developer experience, I’d have said good things.

But “switch to TanStack” is not the escape hatch some people think it is, and recent history makes that point sharply.

In May 2026, the TanStack npm packages were hit by a supply chain attack. On 11 May 2026, a threat group ran a coordinated supply chain attack against the npm and PyPI ecosystems, compromising packages across multiple namespaces, including the @tanstack namespace, which contains @tanstack/react-router, one of the most widely-used routing libraries in the React ecosystem, with roughly 12 million weekly downloads. Between 19:20 and 19:26 UTC on a single Monday, the attacker published 84 malicious versions across 42 TanStack packages.

The payload was not subtle. It targeted CI/CD tokens, cloud credentials across AWS, GCP, and Azure, Kubernetes service accounts, Vault, and registry tokens, and it used stolen npm and GitHub Actions tokens to publish poisoned versions of more packages, functioning as a worm spreading through the npm ecosystem. It also installed a persistent daemon that polled GitHub every 60 seconds, and on detecting token revocation would attempt to run rm -rf on the user’s home directory. One detail makes this especially grim: the compromised packages carried valid SLSA Build Level 3 provenance attestations, making it the first documented npm worm to produce validly attested malicious packages because the malicious versions were published through the project’s own GitHub Actions release pipeline using hijacked OIDC tokens.

I want to be careful and fair here. This was not a flaw in TanStack Router’s code. The attackers got in by forking a TanStack repository on GitHub and submitting a malicious commit under a fabricated identity. The TanStack maintainers responded quickly and communicated well. This could have happened, and has happened, to almost anyone – 2025 saw significant growth in supply chain attacks, and the npm ecosystem, because of its popularity, absorbed a large share of them. The September 2025 Shai-Hulud worm was the first self-propagating worm in the npm ecosystem and affected over 500 packages.

So the lesson I drew from the TanStack incident isn’t “TanStack is unsafe.” It’s the opposite of tribal. The lesson is: no framework choice immunizes you from supply chain risk, and the more of your stack you concentrate into one heavyweight meta-framework, the larger and more attractive a single compromise becomes. Switching framework brand doesn’t fix that. Reducing surface area and dependency count does.

The deeper reason full-stack RSC was always going to be hard: serialization

Set the CVEs aside for a moment, because I think there’s a more fundamental issue, and it’s the one that finally settled my thinking.

The whole promise of Server Components, server actions, and streaming is that the server/client boundary should feel seamless… You just write components and call functions, and the framework figures out what runs where. But a function call across a network is not a function call. The boundary is real, and it is made of serialization.

Everything that crosses from server to client has to be serialized into the RSC payload, streamed, and deserialized. That constraint quietly shapes everything:

• You can’t pass a function to a Client Component from a Server Component unless it’s a server action, because functions don’t serialize. So “just pass a callback”, the most ordinary thing in React, becomes a boundary decision.
• Class instances, Date semantics, Map/Set, anything with methods or identity, all of it has to be flattened to plain data, or it doesn’t make the trip cleanly.
• Errors that originate on the server are serialized before you see them on the client, so the stack trace you get is often a translation of the real problem rather than the problem itself.
• Streaming adds time as a dimension. Components resolve out of order, Suspense boundaries flush independently, and now you’re reasoning about the partial states of a tree mid-stream, which is a genuinely harder mental model than “fetch, then render.”

This isn’t a bug anyone can patch. It’s intrinsic. The instant you let a UI tree straddle a network boundary, you have signed up for a distributed-systems problem dressed in component clothing, and serialization is where that problem leaks through. RSC’s seamlessness is, to a real degree, a leaky abstraction over an inherently unseamless thing. You can build impressive demos on it. Holding it stable across a large app, a team, and a year of changes is a different sport.

And notice the connection back to that CVE cluster. Several of those 2026 flaws, the Server Function DoS bugs, trigger on deserialization of a crafted request. That is not a coincidence. Deserializing untrusted input into a live program is one of the oldest, most dangerous operations in computing, and the RSC model puts a deserialization boundary on the hot path of ordinary feature work. The architecture didn’t just make my app harder to reason about; it made the framework itself a richer target. Serialization is both the ergonomic tax and the security surface, the same seam, charged twice.

Once I framed it that way, my decision basically made itself. I don’t want my UI framework and my data boundary fused. I want the network boundary to be explicit, visible, and boring, a place I deliberately walk up to, not a seam hidden inside my component tree.

The stack I actually use now

So here’s where I landed. None of it is exotic. That’s the point.

Frontend: React Router in framework mode, on Vite, mostly SPA

I use React Router in its framework mode with Vite. Framework mode gives me the things I genuinely missed from Next.js file-based-ish routing conventions, loaders and actions, nested layouts, type-safe params without forcing a server-rendering model on me.

The crucial part: I don’t run SSR. A handful of pages that are truly static marketing, docs, and the landing page get prerendered at build time, so they ship as fast static HTML and are friendly to crawlers. Everything else is a plain client-rendered SPA.

People will say, “But SPAs are slow/bad for SEO / out of fashion.” For an authenticated application, a dashboard, a tool, or a product behind a login, almost none of that critique applies. There’s nothing for Google to index behind the login wall. The first paint is a thin shell, the bundle is code-split per route, and from then on, navigation is instant because it’s all client-side. I get a build artifact that is just static files. I can put it on any CDN or object store. There is no server-rendering process to keep alive, patch, scale, or get a CVE in. The deployment story is “upload a folder,” and the security surface of the frontend collapses to almost nothing.

And critically: there is no serialization boundary inside my UI. The component tree runs entirely in the browser. It talks to the backend through fetch, against an API I designed on purpose. The boundary is visible in the code, at exactly the lines where it exists.

Here’s what that looks like in practice. A route loads its data in a clientLoader which, despite living in a framework-mode route file, runs entirely in the browser and just calls my API:

// app/routes/projects.tsx
import type { Route } from "./+types/projects";
import { api } from "~/lib/api-client";

export async function clientLoader({ params }: Route.ClientLoaderArgs) {
  // Runs in the browser. No server. Just an HTTP call to my backend.
  const projects = await api.projects.$get();
  if (!projects.ok) throw new Response("Failed to load", { status: 502 });
  return { projects: await projects.json() };
}

export default function Projects({ loaderData }: Route.ComponentProps) {
  return (
    <ul>
      {loaderData.projects.map((p) => (
        <li key={p.id}>{p.name}</li>
      ))}
    </ul>
  );
}

There’s no loader (server) here at all, only clientLoader. The seam is the api.projects.$get() call, and I can point at it. Auth is enforced the same way, with a clientMiddleware that runs before the loaders on protected routes:

// app/routes/dashboard.tsx - a protected layout route
import { redirect } from "react-router";
import type { Route } from "./+types/dashboard";
import { api } from "~/lib/api-client";

export const clientMiddleware: Route.ClientMiddlewareFunction[] = [
  async ({ context }) => {
    const res = await api.auth.me.$get();
    if (!res.ok) throw redirect("/login");
    context.set(userContext, await res.json());
  },
];

But notice what this middleware is not: it is not my security boundary. It’s a UX convenience; it bounces an unauthenticated user to the login screen so they don’t stare at a broken page. If someone skips it entirely, they gain nothing, because every API endpoint enforces auth itself, server-side, on every request. This is the whole lesson of CVE-2025-29927 applied: client-side middleware is for experience, never for enforcement. The frontend can’t bypass a check that the backend owns.

The backend side of that contract, in Hono, is explicit and inspectable:

// server/index.ts
import { Hono } from "hono";
import { cors } from "hono/cors";
import { csrf } from "hono/csrf";
import { authMiddleware } from "./auth";

const app = new Hono();

app.use("*", cors({ origin: ["https://app.example.com"], credentials: true }));
app.use("*", csrf({ origin: ["https://app.example.com"] }));

// Real enforcement: the API itself rejects unauthenticated requests.
const projects = new Hono()
  .use("*", authMiddleware)
  .get("/", async (c) => {
    const user = c.get("user"); // set by authMiddleware, trusted here
    return c.json(await db.projectsForUser(user.id));
  });

const routes = app.route("/projects", projects).route("/auth", authRoutes);
export type AppType = typeof routes; // <- exported for the frontend

That last line is the only reason I reach for Hono specifically. Exporting AppType lets the frontend build a fully typed client with no codegen step and no shared runtime:

// app/lib/api-client.ts
import { hc } from "hono/client";
import type { AppType } from "../../server";

// `api` is end-to-end typed against the backend routes.
export const api = hc<AppType>("/api", { init: { credentials: "include" } });

If the backend changes a route’s shape, the frontend stops compiling. That’s the type safety people credit good Next.js setups with, and I keep it without fusing the two halves into one runtime. Swap Hono for Go or Python, and I lose only this typed-client convenience; the architecture is unchanged, because the contract is just HTTP.

For data that loads after the initial render, a slow widget on an otherwise-ready page, I reach for Suspense and the use hook. This is the one genuinely good idea from the streaming era, and the nice part is it works perfectly well in a plain SPA, with no server rendering involved:

import { Suspense, use } from "react";
import { api } from "~/lib/api-client";

// Kick off the request; do NOT await it. `use` will suspend on the promise.
function ActivityFeed({ feedPromise }: { feedPromise: Promise<Activity[]> }) {
  const activity = use(feedPromise); // suspends until resolved
  return <Feed items={activity} />;
}

export default function Dashboard() {
  // Promise created during render, in the browser. No RSC payload.
  const feedPromise = useMemo(() => api.activity.$get().then((r) => r.json()), []);
  return (
    <>
      <Header />
      <Suspense fallback={<FeedSkeleton />}>
        <ActivityFeed feedPromise={feedPromise} />
      </Suspense>
    </>
  );
}

Same Suspense, same use, same streaming-feel UX of content arriving progressively, but the promise is an ordinary fetch resolving in the browser, not a chunk of a serialized server tree. There’s no out-of-order flush to reason about, no hydration boundary, no payload format. I got the ergonomic win of the streaming era and left behind the serialized-tree machinery that came bundled with it.

Backend: a separate service – Hono if I want TypeScript

The backend is its own thing, deployed, scaled, and reasoned about independently. Right now, I mostly reach for Hono, because it’s small, fast, runs anywhere from Node to workers to Bun, and lets me keep TypeScript end to end. With Hono, I can share types between client and server and even get a typed client, so I lose none of the type safety that good Next.js setups gave me.

But, and this matters the backend doesn’t have to be JavaScript at all. It could just as easily be Go or Python. The reason that’s now a free choice is precisely the serialization point from earlier: when your frontend is an SPA talking to an API over plain HTTP and JSON, there is no RSC payload, no server-action boundary, no shared-component-tree contract that forces both sides to be the same language. The contract is just HTTP. Go is fantastic for a backend. Python is fantastic for a backend. I use Hono specifically and only when I want the TypeScript type-sharing convenience; it’s a preference, not a requirement. The architecture itself is language-agnostic, and that flexibility is a feature I gave myself by removing the fused boundary.

Security lives in the backend, on purpose

This is the part I care about most, and it’s the direct lesson of CVE-2025-29927. Authorization and security are the backend’s job, enforced at the API layer, every request, no exceptions. Not in framework middleware. Not coupled to a renderer’s internal request plumbing. In the service that owns the data.

Concretely, on the backend, I run:

• Authentication as a real, deliberate layer of sessions or tokens, validated server-side on every protected request. The server, which owns the database, decides what you can see. The frontend is never trusted to enforce this; it only reflects it.
• CORS configured tightly – an explicit allowlist of origins, not a wildcard, so the browser only lets my actual frontend talk to the API.
• CSRF protection – since a SPA-plus-API setup often uses cookies, I use proper anti-CSRF tokens and/or SameSite cookie attributes so a malicious site can’t ride a logged-in user’s session.
• CAPTCHA on the abuse-prone endpoints, signup, login, password reset, public form submissions to keep bots and credential-stuffing out.
• Plus the usual unglamorous hygiene: rate limiting, strict input validation at the API edge, security headers, secrets kept out of the client bundle, and least-privilege everywhere.

Every one of these is something I configure and can point at. There’s no invisible header that flips my auth off, because my auth was never a header; it’s a checked condition in the request handler that sits between the attacker and the database. If someone bypasses a routing layer, they hit the API, and the API still says no.

What I actually gained

Stepping back, here’s the trade I made and why I’m happy with it.

I gave up: server-rendered dynamic pages out of the box, and the “it’s all one project” convenience of a meta-framework.

I got back, in exchange:

• A legible architecture. I can point at any line and say which machine it runs on. The network boundary is one explicit place where the API, instead of being smeared invisibly through a component tree.
• No serialization tax. The UI tree lives entirely in the browser. No RSC payload, no server-action plumbing, no streaming-order puzzles.
• A tiny frontend attack surface. Static files on a CDN. Nothing to keep running, nothing to patch, no Server Functions to send crafted payloads at, nothing to catch the next 10.0 in the RSC packages.
• Security I can see. Auth, CORS, CSRF, CAPTCHA, and rate limiting all live in one service, enforced per request, decoupled from any renderer.
• Backend freedom. Hono today for the TypeScript ergonomics; Go or Python tomorrow if a project wants them. The HTTP contract doesn’t care.
• Smaller blast radius. Two modest, separately-updated pieces with fewer heavyweight dependencies, instead of one large meta-framework whose single compromise is a very attractive target.

So, is Next.js bad? Is TanStack bad?

No. I want to end honestly, because tribal blog posts age badly.

Next.js and TanStack are both serious, well-engineered projects built by talented people. The CVEs and the supply chain attack I described are real and worth knowing about, but the CVEs got patched, and the TanStack incident was an account-and-pipeline compromise that could have hit almost any popular package. If your product genuinely needs server rendering for SEO on dynamic content, or you have a content-heavy site where streaming pays for itself, a meta-framework can absolutely be the right call. Plenty of teams ship great things on exactly the stack I walked away from.

My point is narrower and more personal. For the apps I build, authenticated products where the UI is interactive and the data is the crown jewels, the full-stack RSC model added a serialization-shaped boundary I didn’t want, hid the seam I most needed to see, and nudged my security toward the framework’s plumbing instead of my own backend. A SPA plus a separate, well-secured backend gave me a smaller, more legible, more boring system. And in software, boring is usually a compliment.

That’s the round trip. I left, I looked around, and I came back to a plain SPA and a real backend, older ideas, held with sharper reasons.

Problem Statement

The Intersection Observer API lets you efficiently detect when an element enters or leaves the viewport (or another parent element). You need this because the old way—listening to scroll events and manually calculating positions—is slow, janky, and wastes battery life on mobile devices. Every time you’ve built an infinite scroll, lazy-loaded images, or a “when do I animate this?” feature, you’ve probably either suffered scroll-performance pain or written hacky throttled code. The Intersection Observer gives you a clean, performant, browser-native solution.

Core Explanation

Think of it as a surveillance camera for your webpage. You give the camera (the observer) a target element and say, “Tell me the moment this box enters or leaves the screen (or any other container).” The browser handles the math for you—no manual scroll listeners, no getBoundingClientRect() in a loop.

Here’s how the core pieces fit together:

• Observer: You create one instance of IntersectionObserver. It’s your watchtower.
• Callback: You pass a function that fires every time the visibility of any observed element changes. The callback receives an array of IntersectionObserverEntry objects—one per observed element that changed.
• Thresholds: You tell the observer how much of the element must be visible before it triggers. A single number like 0.5 means “fire when at least 50% of the element is visible.” You can also pass an array like [0, 0.25, 0.5, 0.75, 1] for multiple checkpoints.
• Root: By default, the observer checks against the browser viewport. But you can set a custom root—any scrollable container—so you can track visibility inside a scrollable div.
• Root Margin: Think of it as a buffer zone around the root. Use rootMargin: "100px" to trigger the callback when the element is 100 pixels outside the viewport—useful for pre-loading content before the user scrolls to it.

The magic? The browser runs this in a separate, optimized thread. No blocking main-thread work. Your callback fires only when the intersection state actually changes, not on every pixel scroll.

Practical Context

When to use the Intersection Observer API:

• Lazy-loading images or iframes: Only fetch the resource when the element is close to entering the viewport. Combine with rootMargin to start loading early.
• Infinite scrolling: Detect when a sentinel element (a small invisible div at the bottom of a list) becomes visible, then append more items. Much cleaner than scroll-event hacks.
• Ads or analytics: Track how long an element was visible or when a user first saw an ad unit.
• Animations on scroll: Trigger a CSS transition or class change when an element enters the viewport. Great for “scroll-triggered fade-ins.”
• Sticky or fixed positioning: Know exactly when an element stops being visible and swap to a fixed position.

When NOT to use it:

• If you need to know the element’s exact X/Y position (use getBoundingClientRect() or ResizeObserver). Intersection Observer only tells you “it’s intersecting” or “it’s not.”
• If you’re building a parallax effect that needs pixel-level scroll offsets. The callback doesn’t fire continuously—only at threshold crossings. For smooth parallax, a scroll-based approach is still better (but use requestAnimationFrame to throttle).
• If you need real-time tracking of visibility percentage (e.g., a progress bar showing how much of an article is read). You can approximate it with many thresholds, but it’s not a continuous stream.

Why should you care? Because it turns a notoriously expensive, error-prone task into a handful of lines that run in low overhead. Your users get smoother scrolling, your app uses less CPU, and your code becomes more declarative.

Quick Example

Here’s how to lazy-load an image when it enters the viewport:

const observer = new IntersectionObserver(
  (entries) => {
    entries.forEach((entry) => {
      if (entry.isIntersecting) {
        const img = entry.target;
        img.src = img.dataset.src;   // swap placeholder for real URL
        observer.unobserve(img);     // stop watching after load
      }
    });
  },
  { rootMargin: "200px" }           // start loading 200px before visible
);

document.querySelectorAll(".lazy-image").forEach((img) => observer.observe(img));

What’s happening? We create an observer that fires when a watched element intersects. Inside the callback, we check entry.isIntersecting. If true, we set the real src (stored in a data-src attribute) and then stop observing that element so we don’t re-trigger. The rootMargin gives us a head start so images load just before the user scrolls to them. No scroll listener, no getBoundingClientRect()—the browser does the heavy lifting.

Key Takeaway

Stop listening to scroll events for visibility checks—let the browser do it for you. The Intersection Observer API is the standard, performant way to know when an element appears or disappears from a container. For a deeper dive, read the MDN documentation on Intersection Observer.