DEV Community: Viktor Lázár

The "use client" Tax

Viktor Lázár — Tue, 28 Apr 2026 17:16:59 +0000

Why React Server Components force small interactive ideas into file-sized boundaries — and why that boundary should be lexical instead.

There is a moment that every developer who tries React Server Components hits, usually within their first hour. They write a server component. It fetches some data. It renders a list. Beautiful. Then they want a button that toggles a filter, and the compiler stops them: "you can't use useState here." So they cut the interactive piece out, paste it into a new file, sprinkle "use client" at the top, import it back into the parent, and move on.

A week later their components/ directory looks like this:

components/
├── product-list.tsx
├── product-list-filter.tsx
├── product-list-filter-input.tsx
├── product-list-sort.tsx
├── product-list-sort-dropdown.tsx
├── product-card.tsx
├── product-card-actions.tsx
├── product-card-favorite-button.tsx
└── product-card-quantity-stepper.tsx

Nine files for one product list. Each one a thin wrapper. Each one with two or three lines of real logic. Each one named with an increasingly desperate suffix because the original Filter already exists three directories up.

This is the "use client" tax, and it is real.

Where the tax comes from

The directive is not arbitrary. "use client" marks a module boundary that the bundler uses to split graphs: everything reachable from a "use client" entry becomes part of the client bundle; everything else stays on the server. The directive has to live at the top of a file because that is the granularity the bundler operates on. Modules in, modules out.

That works fine in theory. In practice it forces a one-to-one correspondence between interactive concerns and files on disk, and interactive concerns are not file-sized. They are paragraph-sized. A "favorite" button that toggles state is not a module — it is two lines inside the card that displays the product. But the runtime can't see those two lines unless you lift them into their own module, give them a name, export them, import them back, and pass props across the boundary.

The result is a particular kind of friction that compounds:

File sprawl. Trivial widgets become trivial files. Most of the file is the import header.

Naming fatigue. Every extracted leaf needs a name. Names that were unique in their lexical scope are no longer unique once they live in a flat directory. You end up with ProductCardFavoriteButtonInner.

Lost colocation. A server function that writes to the database and the form that calls it now live in two files. The relationship between them survives only as an import statement. To understand the feature you alt-tab.

Indirection without abstraction. Each extracted client component is a wrapper that accepts everything the parent had in scope, as props. You are manually performing closure conversion — by hand, every time, with no help from the compiler.

Compositions you can't write. The pattern that hurts most is the one you cannot express at all: a server function that computes some data and returns a small interactive component bound to that data. You cannot do this in standard RSC, because the client component has to be a separate module, which means it cannot close over server-side values. You always end up exporting the client component, exporting the data fetch, and re-assembling them at the call site. The expression you wanted to write — a factory — is not available to you.

The shape of the pain

Here is what a real fragment looks like under the current rules:

// product-card.tsx
import { FavoriteButton } from "./product-card-favorite-button";

export async function ProductCard({ id }) {
  const product = await db.product.find(id);
  return (
    <article>
      <h3>{product.name}</h3>
      <FavoriteButton productId={product.id} initial={product.isFavorite} />
    </article>
  );
}

// product-card-favorite-button.tsx
"use client";

import { useState } from "react";
import { toggleFavorite } from "./product-actions";

export function FavoriteButton({ productId, initial }) {
  const [favorite, setFavorite] = useState(initial);
  return (
    <button
      onClick={async () => {
        setFavorite(!favorite);
        await toggleFavorite(productId);
      }}
    >
      {favorite ? "★" : "☆"}
    </button>
  );
}

// product-actions.ts
"use server";

export async function toggleFavorite(productId: number) {
  // ...
}

Three files for a star button. Two of them exist purely as plumbing for the directive system. The actual interesting code — eight lines of state and a database write — is buried under thirty lines of imports, exports, and prop-passing.

This is what people mean when they say RSC is heavy. It is not the data fetching. It is not the streaming. It is this: the directive system asks you to manually re-architect every interactive idea into a multi-file module graph, and it does so for the smallest possible units of behavior.

Zoom out one level and the same pressure exists at the project boundary: modern frontend frameworks force entire micro-apps to be scaffolded across directory trees, config files, and node_modules for the same kind of mechanical reason — tooling that operates at a coarser unit than the developer's idea. I covered that version of the problem in The Forgotten Joy of node app.js. The fix is structurally the same as the one proposed below: stop letting the file system be the unit of expression.

The constraint is in the tool, not in the model

Here is the part that is worth saying out loud: the file-level restriction is a property of how bundlers were built, not a property of what the directive means. "use client" is asserting that a piece of code runs on the client and must be serialized across a runtime boundary. That assertion is perfectly meaningful at any function scope. It only has to live at the top of a file because that is what the bundler can see.

A compiler that knows about RSC directives can do better. Given a server module that contains a nested function marked "use client", it can:

Identify the nested function and the variables it captures from its lexical scope.
Lift the function into a synthetic module that the bundler treats exactly like a regular "use client" module.
Replace the original definition with a reference to the lifted module.
Inject the captured variables as props at the call site.

The developer wrote one file. The bundler sees the module graph it needs. Nothing about the underlying RSC contract changes — the same serialization rules apply, the same boundary is enforced — but the file system stops being the unit of expression. The function does.

What this should look like

Imagine writing the favorite button like this instead:

export async function ProductCard({ id }) {
  const product = await db.product.find(id);

  function FavoriteButton() {
    "use client";
    const [favorite, setFavorite] = useState(product.isFavorite);

    async function toggle() {
      "use server";
      await db.product.toggleFavorite(product.id);
    }

    return (
      <button onClick={async () => { setFavorite(!favorite); await toggle(); }}>
        {favorite ? "★" : "☆"}
      </button>
    );
  }

  return (
    <article>
      <h3>{product.name}</h3>
      <FavoriteButton />
    </article>
  );
}

One file. Server fetch, client interaction, server function — colocated, in the order you would read them, sharing a closure. The compiler does the lifting; the captured product becomes a prop on the synthesized client module; the inner "use server" function becomes a bound server function with the right scope. Server → client → server nesting works recursively because the same extraction pass runs until no nested directives remain.

This is what a real RSC ergonomic story looks like. Not a new mental model — the same one — just expressed at the granularity humans actually think in.

Why this should be a standard feature

The technique is not exotic. It is closure conversion, a transform compilers have been doing since the seventies. The hard part is wiring it into the RSC plugin chain so that virtual modules generated for inline directives flow through the same client/server graph the rest of the system already uses. That is engineering, not research.

There is no fundamental reason an RSC-capable runtime cannot support this. The directive system is already a contract between the developer and the compiler; expanding it to cover function scopes in addition to module scopes does not change serialization, bundling, streaming, or the security boundary. It only changes where the developer is allowed to write the directive.

If you are building an RSC runtime: pick this up. If you are using one that does not have it: ask for it. A "use client" file is not a feature. It is a workaround for a constraint we no longer need to accept.

The point of RSC was to let us put server logic and client logic next to each other. The directive system, taken at face value, does the opposite: it forces them apart, file by file, until your repository is ninety percent wrappers. We can fix this. It is time to make the fix standard.

The Forgotten Joy of `node app.js`

Viktor Lázár — Tue, 28 Apr 2026 17:16:40 +0000

There used to be a moment, ten years or so ago, when you could go from "I have an idea" to "I have a running web server" in about thirty seconds:

// app.js
const express = require('express')
const app = express()

app.get('/', (req, res) => res.send('hello'))

app.listen(3000)

node app.js

That was the whole thing. One file. One command. You could paste it into a Slack message. You could drop it in a Gist and someone could run it. A tiny webhook receiver, a debug dashboard, an internal tool, a stub API — the entire project lived in a single buffer in your editor.

Then frontend frameworks happened, and somewhere along the way we collectively decided that "starting a new project" meant something else entirely.

The scaffold tax

Today, the canonical first step in starting a new app is no longer writing code. It is running a command that writes code for you:

npx create-next-app@latest my-app
npx create-react-app my-app
npm create vite@latest
npx create-remix

What comes back is not a file. It is a tree. Configuration files for tooling you have not yet decided to use. A pages/ or app/ directory with conventions you must learn before you can write a single line. A tsconfig.json you did not write. ESLint rules. Prettier rules. A .gitignore. A README.md describing the scaffold itself. A package.json with twelve dependencies and four scripts you did not pick.

And, critically, there is no path back to a single file. The scaffold is the unit of starting. There is no framework dev ./App.jsx. There is only framework new my-project, which produces forty files, of which you will edit two.

This is fine when you are starting a real product. It is absurd when you are not.

What we lost

The single-file app is not a relic of a less mature ecosystem. It is a fundamentally different mode of working — one the modern frontend toolchain has quietly priced out of existence.

Specifically, we lost:

The throwaway. The five-minute hack to verify that an idea works. The "let me just see what this looks like rendered" experiment. With a scaffold, the cost of starting is high enough that you don't bother. You either pollute an existing big project, or you open the browser DevTools console.

The teaching artifact. A blog post used to be able to say here, run this file. Now it says clone this repo. The reader is no longer reading code; they are operating a project.

The micro-app. The three-route admin tool. The internal status page. The webhook that posts a Slack message. Things that should be one file are now twenty, because the framework demands it.

The shareable Gist. I cannot send you a single .jsx file and have you run it. I have to send you a repository — or a CodeSandbox URL, which is its own confession that the local toolchain has gotten too heavy.

The curl-and-run. Plain Node lets you stream a program straight from a URL into the runtime, no file on disk: curl https://gist.githubusercontent.com/.../app.js | node. No clone, no install, no project to set up. The source travels over the wire, lands in the interpreter, runs. The same pattern should work for a single-file frontend app — curl https://.../App.jsx | npx some-framework dev - — and the fact that this is unimaginable today is the most concrete possible measurement of how heavy "starting a frontend app" has become. We have a JavaScript-shaped hole in our shells that the language used to fit through.

There is a fractal version of this same pain one level down. Even inside a project, modern React's "use client" directive forces single features to be sharded across multiple files for purely mechanical reasons — the same disease, at smaller scale. I wrote about that version separately in The "use client" Tax. What follows here is the project-level shape of the same problem: even when the whole app should be one file, you are not allowed to write it that way.

The shape of the fix

Imagine, for a second, that this just worked:

npx next dev ./App.jsx

One file. One command. The framework picks it up, runs it, hot-reloads it, serves it. No next.config.js, no pages/, no app/, no package.json. If you decide later that you want a real project, you make the directory, add the config, split the file. The framework grows with you instead of demanding everything upfront.

The technology to do this is not hard. Frameworks already build on dev servers — Vite, esbuild, Turbopack — that can resolve and bundle a single entry point. The framework conventions (file-based routing, layouts, server components) are conventions over the bundler, not replacements for it. There is no fundamental reason a framework's CLI cannot accept a path to a .jsx file and Just Work, with the conventions kicking in only once you opt into a directory layout.

The reason it doesn't work is not technical. It's cultural. We have decided, somewhere along the way, that the project is the unit of frontend code, and the file is merely an implementation detail. Backend frameworks never made that mistake. You can still write a fifteen-line server.js and run it. You can still write a Flask app in one file. You can still put a Go HTTP handler in main.go and ship it. Scaffolds are offered as a convenience, not enforced as a precondition.

Frontend should be no different.

One file in, one file out

The single-file dev story is only half of the picture. The other half is what comes out when you build.

Today, building a frontend project produces another tree. A .next/ directory. A dist/ directory. A .output/ directory. Hundreds of chunked JavaScript files, manifests, server bundles, client bundles, route maps — and a node_modules you must ship alongside it, or carefully fold into the deployment artifact. Running the result usually means another framework-specific command (next start, node .output/server/index.mjs) that depends on the surrounding directory structure being intact.

It should be possible to do this:

some-framework build ./App.jsx -o app.js
node app.js

One file in. One file out. No node_modules, no config, no manifest, no dist/ to preserve. A single .js that boots an HTTP server, serves the assets it needs (inlined or referenced), and runs on any Node install with nothing else next to it.

Backend developers have had this for years, just under different names. Go produces a static binary. Deno compiles to a single executable. esbuild can bundle a Node program into one file. The pattern is universal: take everything the program needs, fold it into one artifact, ship that. Nothing about a React app — even a server-rendered, server-component-heavy React app — fundamentally prevents the same thing.

What this unlocks is bigger than convenience:

Trivial deployment. scp app.js server:/srv/ && node app.js. No CI artifact pipelines, no Docker images for a webhook receiver, no Kubernetes for a status page.
Reproducibility. The artifact is a file. You can hash it, version it, archive it, email it. Not a directory whose contents quietly differ depending on which npm install produced it.
Sandboxes. A single file is something a sandbox runtime — a serverless platform, a worker, a container — can swallow whole, with no need to mount a node_modules.
Distribution. Internal tools become as easy to share as a CLI binary. "Drop this on the server and run it" is a workflow we lost the moment frontends grew a build directory.

The deploy story for a small app should be as small as the app. Right now, even a thirty-line frontend deploys like a monorepo.

And then AI showed up

The scaffold tax used to be paid mostly by humans — a one-time annoyance you absorbed at project start, then forgot about. AI coding tools have quietly turned it into a recurring tax, paid on every interaction.

When you ask an AI to modify a single-file app, it can read the entire program in one shot, hold the whole behavior in its working memory, and reason about a change with confidence. The file is the project. There is nothing else to discover.

When you ask an AI to modify a scaffolded project, it has to do archaeology first. Where does routing live? Which tsconfig paths are aliased? Is that import resolved by a framework convention or by the bundler? Is app/ the routing root, or a coincidentally-named folder? What does the project's ESLint config forbid? Half the request gets spent loading context that wasn't actually relevant to the change.

This shows up as:

Worse answers, because the model is reasoning under a noisier prompt.
Slower answers, because more files have to be read before it can act.
More expensive answers, because tokens are not free, and a fresh agent re-discovers the same project structure on every session.
More fragile answers, because the model has more surface area on which to misread a convention.

A one-file app is, by accident, the ideal substrate for AI-assisted coding: the entire program fits in a single attention window, every symbol resolves locally, and the change you ask for can be made without crawling a directory tree first. The convention overhead we built up to make starting a project "easier" turns out to be overhead we now pay every time we ask a tool to help us edit one.

The same things that made the single-file app pleasant to write by hand — small surface, no hidden conventions, nothing to discover — make it the format AI tools handle best. We just stopped producing apps in that shape.

Why this matters

There is a subtle compounding effect to all of this. When the cost of starting is high, people start fewer things. When people start fewer things, the ecosystem gets less weird, less experimental, less playful. The thirty-line idea that would have become a beloved internal tool never gets written, because the scaffolding tax was higher than the energy budget for the experiment.

The modern frontend stack is extraordinarily capable. It can render server components, stream HTML, hydrate selectively, generate static pages, run on the edge, do incremental builds. None of that is at odds with also being able to do this:

some-framework dev ./App.jsx

It's a small surface area. It's enormously valuable. And it is, conspicuously, missing from almost every option you'd reach for today.

The good news is that almost. If you look around carefully, this capability is starting to reappear in the corners of the ecosystem — runtimes that treat the single file as a first-class entry point, not as a degenerate case of a project. It's worth keeping an eye on.

The thirty-second app deserves to come back.

The Two Joys of Coding Before AI

Viktor Lázár — Mon, 27 Apr 2026 19:51:28 +0000

There is a particular kind of grief floating around right now. You see it in blog posts, in conference talks, in late-night threads: a mourning for the joy of coding before AI. People describe it as if a forest has been paved over. Something they loved is gone, and something colder has taken its place.

I think most of these conversations talk past each other because they skip the only question that matters: what was the joy actually made of?

"Coding" is not one activity. It is at least two, braided together so tightly that for decades nobody had to separate them. AI pulls on one of those strands and not the other, and whether that feels like loss or liberation depends entirely on which strand you were holding.

Two kinds of joy

Strip a programming session down to its emotional core and you find two distinct rewards.

The first is the joy of materializing a vision. You see something in your head — a tool, an interface, a system, a small clever thing that does not exist yet — and you bring it into the world. The pleasure here is in the gap closing. The thing in your imagination and the thing on the screen converge until they are the same thing. The keyboard, the language, the build system: these are friction. Necessary friction, often beautiful friction, but friction. The joy lives at the moment of arrival.

The second is the joy of figuring something out. A problem resists you. You sit with it. You pull on threads, build mental models, get them wrong, refine them, and somewhere — sometimes in the shower, sometimes at 2 a.m., sometimes mid-sentence in a meeting — the shape of the answer clicks into place. The pleasure here is not in arrival but in the act of comprehension itself. You understand something now that you did not understand an hour ago, and your brain rewards you for it the way it rewards eating when you are hungry.

These are not the same feeling. They use different muscles. They satisfy different hungers. And — this is the important part — they leave behind different kinds of memory. A vision-materializer remembers what they built. A problem-solver remembers how the world bent into a new shape inside their head.

Most working programmers feel both, in different proportions, sometimes in the same hour. But if you ask honestly which one is the core — the thing that made you a programmer rather than something else — almost everyone has an answer.

What AI actually changes

AI coding assistants are extraordinary materializers. That is what they are built to be. You describe the thing, they produce the thing. The friction between vision and artifact collapses dramatically. What used to be an afternoon of plumbing is now a paragraph and a review pass.

If your joy was in the materialization — in seeing the thing exist — AI is not stealing anything from you. It is giving you more of what you loved. The gap closes faster, which means you can close more gaps, which means more visions per unit of life. The friction you tolerated was never the source of the joy; the arrival was. You can build the second thing now, and the third, and the weird side project you never had time for. The hands-on craft loss is real but it is a craft loss, not a joy loss. You can still write the loop by hand on a Saturday if you want to. Nothing stops you.

One thing has to be said clearly here, because it is the most common bad-faith reading of the materializer position: materialization is not "whatever shipped, shipped." A vision is not just a silhouette of a feature; it has internal coherence, a way it behaves under pressure, a quality it carries. A materializer who accepts slop because it superficially resembles the artifact in their head has not closed the gap — they have moved the goalposts to meet the output. That is not the joy of materializing a vision. That is the relief of being done. They are different feelings, and conflating them is how teams end up shipping confident-sounding garbage at unprecedented speed. The AI gives you a draft. The work — the actual materializer's work — is to keep pushing the draft until it matches the thing in your head, including the parts of the thing in your head that have to do with correctness, taste, performance, and how it will read to the next person. Acceleration is acceleration toward the right artifact, not toward any artifact. A materializer who forgets this is no longer practicing their craft; they are just hitting accept.

If your joy was in the figuring out, the picture is genuinely different — and the grief is genuinely earned. The AI is not just removing friction; it is removing the problem itself. The puzzle you would have sat with for three days, turning it over in your head on the train and in the shower, building the mental model that becomes part of how you think forever — the AI hands you an answer in twelve seconds. The answer is often correct. And the comprehension that would have grown in you while you struggled does not grow, because you did not struggle.

This is not a complaint about laziness or skill atrophy, though those are real concerns. It is something more specific: a category of human pleasure, the pleasure of understanding something hard, requires the hardness. Remove the hardness and you remove the pleasure, even if you keep the answer. You cannot have the satisfaction of a crossword without the crossword.

Why the debate is so confused

Once you see this split, the public conversation about AI and coding starts to make more sense. The two camps are not actually disagreeing about AI. They are reporting honestly on two different inner experiences.

The "AI is wonderful, I ship five times faster" camp is overwhelmingly populated by materializers. They are telling the truth. Their joy is intact and amplified.

The "AI is hollowing out my craft" camp is overwhelmingly populated by problem-solvers. They are also telling the truth. Their joy is, in fact, being eroded — not by malice or hype, but by the specific mechanism of having the puzzles solved before they get to play with them.

When these two groups argue, they sound like they are arguing about a tool. They are actually arguing about which of two pleasures is the real one. There is no answer to that question, because there are two answers, and they are both correct for the person giving them.

Notice how each camp uses the same phrase to dismiss the other's grief. To the materializer, the problem-solving was always an implementation detail — a means, a tax you paid on the way to the artifact, something a sufficiently advanced tool was supposed to absorb eventually. To the problem-solver, the shipped artifact was the implementation detail — the residue, the visible echo of an internal event that had already happened in their head. Each side, in good faith, treats the other side's joy as the boring scaffolding around their own. That is why the conversation goes nowhere: both sides are correctly identifying what is, for them, incidental.

What to do about it

If you are mourning, the first useful move is to ask yourself the honest version of the question. Not "do I miss coding," but: which kind of coding? When you replay the moments you would call joyful, are you watching yourself ship the thing, or are you watching yourself understand the thing? The answer tells you whether you are facing an opportunity or a loss.

For materializers, the path is mostly forward. Use the tools. Build more. The thing you loved is more available now, not less.

For problem-solvers, the answer is harder and more deliberate. The puzzles still exist; they have just stopped arriving on their own. Production code paths now route around them. To keep the joy, you have to choose the friction back in — pick problems the AI cannot solve cleanly, work in domains where the model is weak, build from scratch on weekends, read papers, do the leetcode-equivalent that is actually interesting to you, contribute to runtimes and compilers and other places where the problem space is still deep enough that no autocomplete can shortcut it. The protected hour where you do not ask the assistant is not a Luddite stance; it is a deliberate preservation of the conditions your joy requires.

Both responses are healthy. Both are grown-up. What is not healthy is conflating them — using a materializer's optimism to dismiss a problem-solver's grief, or using a problem-solver's grief to deny a materializer's genuine, earned acceleration.

The thing under the thing

The deeper claim hiding inside all of this is that coding was never one thing. It was a workbench where two very different human pleasures happened to use the same tools. The industry treated them as one because the workflow forced them to be one — you could not materialize a vision without solving a hundred small problems along the way, and you could not solve interesting problems without something to materialize them into.

AI is the first force strong enough to pull those two pleasures apart. It is doing so cleanly and without asking permission. What we are watching is not the death of the joy of coding. It is the unbundling of two joys that were always separate, finally being forced to admit it.

Which one was yours?

RSC as a serializer, not a model

Viktor Lázár — Mon, 27 Apr 2026 17:32:02 +0000

The most interesting thing about how TanStack Start integrates React Server Components is not what it does with them. It is the shape of the API.

You do not write a Server Component. You do not opt into a model. You opt into a function — a programmatic primitive that takes a component, runs it through the RSC renderer, and hands you back a payload you can store, transport, and rehydrate later. RSC is not the substrate of the application. It is a tool you reach for at specific call sites, when you want a specific thing.

That framing is worth pausing on, because it tells you something about the design intent that the marketing copy does not.

What the API is really for

The use case being served is narrow and clear: caching values that the rest of the JavaScript ecosystem cannot cache. A normal cache stores JSON. JSON cannot represent a React element. JSON cannot pass through a value that resolves later. JSON cannot carry the richer plain types — Map, Set, Date, typed arrays — that show up in a real component tree. RSC's wire format can. It was designed to. That is what the protocol is.

So if you take the RSC renderer, strip it of everything that makes it a composition model, and expose just the serializer, you get a primitive that turns "a tree containing UI and non-JSON props" into "a string you can put in Redis." That is a real capability. It is also, on reflection, a very small one.

This is the capability TanStack Start has surfaced. Not Server Components. A serializer for component-shaped values, exposed as a programmatic API.

If the goal is caching, name it caching

"use cache" is the design that already exists for this exact problem. It is a directive. It tells the runtime: this output is cacheable, key it on these inputs, store it for this long. The runtime handles serialization, deserialization, key derivation, invalidation, and storage. The developer writes a function and adds one line.

Concretely. Imagine a post card — a tree containing a server-rendered article and a client-rendered set of actions — produced once and reused across navigations. Under a directive:

async function PostCard({ postId }: { postId: string }) {
  "use cache"
  const post = await db.posts.findById(postId)
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.body}</p>
      <PostActions postId={post.id} authorId={post.authorId} />
    </article>
  )
}

The runtime knows what the cache key is (the inputs the function closes over), where the value lives, when it expires, and how to serialize it (the same wire format the rest of the system already speaks). One line of metadata and a function body. The developer writes a component.

Under TanStack Start's API, the same tree is produced by driving the protocol explicitly:

import { createServerFn } from "@tanstack/react-start"
import { createCompositeComponent } from "@tanstack/react-start/rsc"

const getPostCard = createServerFn()
  .validator(z.object({ postId: z.string() }))
  .handler(async ({ data }) => {
    const post = await db.posts.findById(data.postId)
    const src = await createCompositeComponent(
      (props: {
        renderActions?: (d: { postId: string; authorId: string }) => React.ReactNode
      }) => (
        <article>
          <h1>{post.title}</h1>
          <p>{post.body}</p>
          <footer>{props.renderActions?.({ postId: post.id, authorId: post.authorId })}</footer>
        </article>
      ),
    )
    return { src }
  })

export const Route = createFileRoute("/posts/$postId")({
  loader: ({ params }) => getPostCard({ data: { postId: params.postId } }),
  component: PostPage,
})

function PostPage() {
  const { src } = Route.useLoaderData()
  return (
    <CompositeComponent
      src={src}
      renderActions={({ postId, authorId }) => (
        <PostActions postId={postId} authorId={authorId} />
      )}
    />
  )
}

Six things have to agree across this code: the server function that produces the payload, the validator that gates its inputs, the createCompositeComponent call that names the seam, the loader entry on the route, the useLoaderData site that retrieves the payload, and the <CompositeComponent> site that rehydrates it — including the render-prop signature that has to match on both sides. Caching is implicit in the router's staleTime and loaderDeps. Invalidation is the router's responsibility and shaped by the route boundary, not the value boundary.

None of these decisions have a defensible non-canonical answer for the simple case. Every team using this will write the same wrapper around it, in slightly different shapes, and the bugs will all live in the relationships between the serialization site, the render-prop signature, and the rehydration site.

The case where this matters most is the one the framework does not address at all: caching a component-shaped value at request scope. The docs recommend React.cache for the request-scoped case, but React.cache deduplicates plain function results — it does not memoize trees that contain client component references and closures over server-only data. There is no primitive shaped for that. The same computation can run three times in one request because three parts of the tree need it, and the framework's answer is the route-level cache, which is route-scoped, or React.cache, which does not apply.

A directive-shaped API hides those decisions because most of them only have one correct answer. A library-shaped API exposes them because the framework refuses to commit to one.

Boundary wrappers, protocol wrappers

There is a more general problem under this. RSC, as a protocol, is a serialization format. RSC, as a model, is a composition story between two environments. When a framework lifts the protocol out of the model and exposes it as a programmable primitive, what it is really saying is: "the protocol is interesting to us, the model is not."

It would be easy to read this as a complaint about wrappers in general. It is not. A wrapper-shaped API is often the right answer, and in TanStack Start specifically it is the dominant idiom. Routes are wrappers. Loaders are wrappers. Server functions are wrappers. The whole framework is built around the pattern of pass your thing through this constructor, get back a richer thing the runtime now understands. A wrapper for RSC caching slots into that idiom cleanly.

The argument is about what a wrapper carries across the boundary it creates, because there are two kinds and they look almost identical until you start using them.

A boundary wrapper says: this is where the model changes shape. It takes a value, marks a seam the runtime will operate on, and hands the developer a richer reference back. The developer never touches the protocol underneath; they only see the seam, named and located. The wrapper carries the model with it — calling it is participating in the model.

A protocol wrapper says: here is the renderer, here is the payload, here is the deserializer. It hands the developer the wire format and asks them to drive it. The seam is gone. What is left is a set of operations on bytes that the developer has to compose themselves.

TanStack Start's other wrappers — the route, the loader, the server function — are boundary wrappers. The framework knows what the wrapped thing is, the runtime knows what to do with it, and the developer writes their code in the vocabulary of the model rather than the vocabulary of the protocol underneath. That is what makes those APIs feel coherent next to each other.

The RSC integration is the exception. The outer shape is the same — a function you call, a value you hand it, a value you get back — but there is no model on the other side. The developer is handed the renderer instead of being handed a richer reference.

The defensible version of the choice

The strongest case for what TanStack has shipped goes something like this. The framework's audience is router-driven and SPA-adjacent. Committing to the full RSC composition model would constrain the rest of the architecture in ways that conflict with how the framework already works. A library-shaped API leaves room for teams whose caching needs really do diverge. A directive forces a single shape on every caller, and that shape — "use cache" as it ships today — is itself not a settled design. Its key inference, its invalidation story, and its "what is safe to close over" semantics have known warts. Why commit to it?

The first half of that case is real. The second half is the one to push back on.

A directive does not have to mean "use cache" exactly as it ships today. The directive is a shape, not a specification. The shape is: a marker at the boundary, a runtime that infers the keying and storage, a developer who writes a function. The runtime gets to choose how aggressive the inference is, what scope the directive defaults to, and what the escape hatches look like. A request-scoped variant is easier than the application-cache variant "use cache" currently targets, not harder, because almost every decision has one canonical answer at the request scope.

The "we left it open because needs diverge" defense applies to primitives where they really do diverge. Application caches diverge — TTLs, tags, storage. Request-scoped caches do not. The needs are: dedupe within a render, survive into hydration, evaporate at request end. That is the specification. There is no second team whose answer to those questions is meaningfully different.

The honest version of the architectural choice is: "we don't want to commit to the model yet, and we don't want to ship a caching directive without committing to the model, so we shipped the renderer as a library and let users assemble what they need." That is a coherent position. It is just not the position the docs reflect.

What is actually being shipped

To make this caching primitive work, the framework has to bundle the RSC renderer, the RSC serializer, the matching deserializer, the streaming format reader, and enough of the React internals to drive all of it. That is the entire RSC machinery, intact — including the parts the framework will not let the developer use.

The framework does not have a "use client" boundary at all. Interactivity is injected through slots on <CompositeComponent> — children, render props, component props — not through client component references resolved at hydration. The reference-resolution machinery RSC was designed around, the matched identifiers across server and client builds, the client manifest, the hydration-time dispatch, all of it is bundled but inert. The framework has actively engineered an alternative path (the slot pattern) that routes around the very mechanism RSC exists to provide. The user experience of writing a TanStack Start application is the user experience of writing a router-driven app that occasionally summons the RSC serializer for caching.

So the framework pays the full cost of the protocol — every byte of the serializer, every transitive dependency, every line of React internals it has to remain compatible with — and uses it to power a feature that, on its own, could be expressed as a directive over a much smaller mechanism. The bundle includes the engine of a model the framework has chosen not to adopt.

There is a third option the design did not take: a fit-for-purpose serializer. The capability TanStack Start actually needs — turning a rendered component tree, slot placeholders and non-JSON values included, into bytes and back — is a small one. It is not the RSC protocol. RSC is that capability plus a streaming format with suspense boundaries, plus server reference dispatch, plus the entire client-resolution layer the framework has already chosen not to use. A protocol designed for the narrower job would be smaller, evolvable on the framework's own cadence, and decoupled from React's internals. That a project willing to ship its own router, its own loader system, its own server-function wrapper, and its own composite-component primitive nevertheless reached for the entire RSC implementation tells you the choice was not driven by what the feature needs.

The agent reading the code

There is one more lens worth applying, because in 2026 it is the lens that shapes a growing share of code: the AI coding agent.

The relevant claim is narrower than "agents will get directives right and wrappers wrong." It is structural: a directive compresses the model into the syntax; a protocol wrapper requires the model to be reconstructed at every call site, and that reconstruction is where coordination bugs compound.

An agent producing a directive-based caching feature emits a marker, a function body, and the inputs the developer already named. The keying, scope, invalidation, and lifetime are the runtime's contract — the agent does not produce them, so it cannot produce them wrong.

An agent producing a protocol-wrapper caching feature has to emit a serialization call, a storage decision, a key derivation, an invalidation hook, a deserialization call, a rehydration site, and the glue holding all of them in agreement. The shape of each piece is locally reasonable. The bug lives in the relationships — a stale key, a missed invalidation hook, a request-scoped value silently captured in the payload, a payload rehydrated at the wrong boundary. An agent reviewing its own output will not flag these, because each part on its own makes sense.

Less code is not only easier for humans. It is easier for agents — fewer tokens to generate, fewer relationships to track, fewer places to be subtly wrong. Boundary primitives compress an enormous amount of model into a tiny amount of syntax. Protocol APIs decompress the model back into surface area and ask the agent to operate it. Increasingly, an API surface that is hostile to agents is an API surface that is hostile to its own users.

What gets lost

A framework gets to choose the level of abstraction it commits to. If it commits to RSC as a model, the developer writes components and the runtime handles the seams. If it commits to caching as a model, the developer writes directives and the runtime handles serialization. If it commits to neither and exposes the protocol as a library, the developer writes glue.

Glue is the most expensive code in any application. It is the code that does not solve the problem; it only connects the things that do. It also ages worst, because every change to the surrounding ecosystem requires the glue to be rewritten while the parts on either side of it stay the same. The moment a request-scoped value becomes something the developer has to manually serialize, key, store, and revive, the framework has already lost the lifecycle it was supposed to protect.

A framework whose RSC story is a library call is asking every team that uses it to write and maintain that glue forever. The convenience is moved out of the runtime and into a thousand small repositories that all rediscover the same patterns and the same failure modes. The framework gets to ship a thinner runtime; the ecosystem absorbs the cost.

That trade is sometimes worth it — for a primitive that genuinely has no canonical shape. Caching component output is not that primitive. It has a canonical shape. The shape is a directive. The reason it is not the API is not that the shape is wrong. It is that adopting the shape would require committing to the surrounding model, and that commitment was the thing the framework was avoiding from the start.

The smaller point

Strip the protocol away and the design becomes legible. The team wanted a way to cache values that JSON could not represent. They had access to a serializer that could. They exposed the serializer. They called it RSC support.

It is RSC support in the sense that the renderer is in the bundle. It is not RSC support in the sense that the developer is asked to think in the RSC model, write in its idioms, or benefit from its composition story. The renderer is a load-bearing dependency for a feature that is not, itself, the model the renderer was designed to power.

When a framework treats a model as a primitive instead of as the model, it is telling you that it wanted something the model happened to make possible, not the model itself. There is nothing wrong with that as a product decision — but it should be named accurately. The honest version of this feature is a caching directive. The honest version of the framing is "we ship a serializer-backed cache." Everything else is a story told in the vocabulary of a model the framework chose not to adopt.

Project, Don't Embed: Introducing Virtual Frame

Viktor Lázár — Tue, 21 Apr 2026 08:48:43 +0000

A first-time introduction to Virtual Frame — what it is, why it exists, and how it composes independently deployed web apps into a single page without a shared build.

There's a problem every large frontend eventually runs into, and it goes something like this: you have five teams, five stacks, five deployment pipelines — and one page. The design system lives in team A's repo. The checkout widget belongs to team B. The dashboard you're trying to embed was last touched by a team that no longer exists. None of these things ship together. All of them need to render on the same page, at the same time, and feel like one product.

The industry has been trying to solve this for a decade. The solutions all have a tax.

Module federation is great when host and remote share a build pipeline, and useless the moment they don't. The first time you need a coordinated upgrade across three repos, the "independent teams" story evaporates. Iframes give you perfect isolation and zero composability — you get a rigid rectangle that doesn't flow with your layout, can't inherit your theme, and picks fights about scroll, focus, and accessibility. Edge-side includes and server fragments work beautifully for static markup and fall apart the moment the remote needs its own runtime. Ad-hoc SPA shells work until they don't; then you're debugging a shared React instance that sees two different versions of the same context.

Each of these is the right answer to a different question. None of them is the right answer to the question most teams are actually asking: how do I compose fully independent web applications — different repos, different frameworks, different deploys — into one page, with real layout flow and real interactivity, without coupling any of them at build time?

Virtual Frame is a bet that you can do that if you stop thinking about embedding remote applications and start thinking about projecting them.

The one-paragraph version

Picture a hidden iframe loading another team's page. The page runs normally in there — same as if you'd opened it in a new tab. Virtual Frame takes what that hidden page is drawing and paints it into a slot on your own page, live. When the remote updates, your slot updates. When your users click, scroll, or type inside the slot, Virtual Frame forwards those interactions back to the hidden page so its app keeps working like it's running in a real browser tab.

The result: the remote app's output is part of your page. It flows with your layout, picks up your theme, and behaves like any other piece of your UI — because, as far as the browser is concerned, it is any other piece of your UI. The remote keeps running in its own world; its output lives in yours.

That's the entire pitch.

Why this mental shift matters

The most important word in the previous section is projecting, and it's worth slowing down on.

When you embed something — an iframe, a web component, a third-party widget — you're accepting its frame. The embedded thing has a boundary, and things stop at that boundary. Layout stops there. Events stop there. Themes stop there. You're not composing, you're docking.

When you project, the boundary collapses. The remote application still runs in its own browsing context — that part is non-negotiable, it's how you keep the remote's runtime from tripping over yours — but its rendered output flows into your page the way a child component's output would. The execution is isolated; the presentation is composed.

This is a surprisingly slippery idea the first time you encounter it, because we've been trained by twenty years of iframe behavior to think of "other-origin content" and "rigid rectangle" as the same thing. They're not. The rigidity is an implementation detail of how browsers expose iframe contents, not a law of nature.

How it actually works

Three primitives, no magic.

A source iframe, hidden off-screen. The remote runs as a complete, standalone application inside it — its framework boots, its router runs, its effects fire, its fonts load. Virtual Frame doesn't re-execute your app; it observes it. That's the key constraint: nothing about your remote has to change to be projectable.

A host element, which is any element you put on the page — a <div>, a <section>, a component root. Virtual Frame optionally attaches a Shadow DOM to it (open or closed) and mirrors the remote's <body> subtree into that shadow root. Shadow DOM gives you CSS isolation without giving up custom-property inheritance, which is the sweet spot: the remote's styles can't bleed into your page, but your theme still crosses the boundary.

A sync layer. Same-origin, this is a MutationObserver on the source plus CSS rewriting and event re-dispatch. Cross-origin, a bridge script loaded once in the remote serializes the DOM and events over postMessage, and the host reconstructs them. The cross-origin story is worth dwelling on, because this is where iframes usually give up: there is no host-side configuration. Drop the bridge into the remote, and every host on every origin can project it.

Everything else — selector-based projection, canvas streaming, SSR with resumption, the shared reactive store — is built on top of these three primitives. But the primitives are simple, and that's on purpose. Simple primitives compose.

A taste of code

The shortest path is the custom element. This is a complete working projection:

<script type="module">
  import "virtual-frame/element";
</script>

<virtual-frame
  src="https://dashboard.example.com"
  isolate="open"
  style="width: 100%; height: 600px"
></virtual-frame>

That's it. No build plugin. No config file. No framework buy-in. When the element connects to the DOM, it creates a hidden iframe at src, attaches a shadow root to the custom element, and starts projecting. When the element is removed, everything tears down.

If you want to project only a piece of the remote — a chart, a panel, a sidebar — add a selector:

<virtual-frame
  src="https://dashboard.example.com"
  selector="#metrics-chart"
  isolate="open"
></virtual-frame>

The full remote still runs in the background, so the selected subtree behaves exactly as it would in its native page. Its event handlers work. Its data fetches work. Its animations work. You just pulled a widget out of another team's app without negotiating an API contract.

If you're in React, it's a component:

import { VirtualFrame, useVirtualFrame, useStore } from "@virtual-frame/react";
import { createStore } from "@virtual-frame/store";

const store = createStore();

function Dashboard() {
  const count = useStore(store, ["count"]);
  const frame = useVirtualFrame("https://remote.example.com", { store });

  return (
    <>
      <p>Count: {count ?? 0}</p>
      <VirtualFrame frame={frame} selector="#counter" />
    </>
  );
}

The store there is worth a second look. It's an event-sourced, proxy-based reactive object that synchronizes between host and remote automatically. Read and write it like a plain object on either side; mutations propagate over the same message channel the projection uses. It's the piece you reach for when "host and remote need to share state" comes up, and it means you don't have to invent a coordination protocol.

There are first-class bindings for Vue, Svelte, Solid, Angular, Next.js, Nuxt, SvelteKit, TanStack Start, SolidStart, Analog, React Router, and a few more. They all sit on the same core engine. Pick whichever is closest to how your page is built.

What you actually get

A few consequences of the projection model that are worth naming explicitly, because they're the things that tend to surprise people:

Layout flow just works. Projected content fills its host element's box and participates in flex and grid like any other child. No width="100%"-then-cry dance. No resize observer hacks. No scroll-inside-scroll confusion.

Theming crosses the boundary. CSS custom properties inherit into the shadow root, so your design tokens — colors, spacing, fonts, dark mode — reach the projection without any coordination with the remote team. They don't even need to know your tokens exist; they just need to use var() for things they want themeable.

Accessibility is inherited. The projected DOM is real DOM in your tree, so focus traversal, screen readers, and keyboard navigation see it as part of the page. You're not fighting the iframe a11y model.

SSR with resumption. The meta-framework integrations can server-fetch the remote, inline the projection inside declarative Shadow DOM, and resume on the client without a second round-trip. First paint is styled and interactive content arrives without the iframe flash.

Cross-origin without proxy gymnastics. No CORS negotiations. No server-side proxy. Ship the bridge once in the remote, and every host everywhere can project it.

What it isn't

Worth being honest about the non-goals, because they come up in design reviews and getting them wrong wastes everyone's time.

Virtual Frame is not an iframe replacement — it still uses one under the hood, because that's how you give the remote its own browsing context. What's different is that you don't see the iframe; its DOM is projected into your host.

It is not a trust boundary from the host's side. The iframe sandboxes the remote's script execution (same-origin policy still applies; the remote's JS can't touch host DOM or globals), but once you project the remote's DOM into your page, your code can read and manipulate that projected tree. If the remote is untrusted, keep the iframe visible and don't project.

It is not module federation. Nothing is shared at build time. No shared React instance, no shared bundle graph. If you need runtime coordination, use the shared store — a typed message channel, not a hidden dependency on a shared import.

It is not a hydration framework. The remote hydrates normally inside its own iframe. You don't rewrite your remote app to make it projectable; any web page will do.

When to reach for it

Virtual Frame fits well when you need to compose multiple independently deployed apps into one page without coordinating a build. When you want to embed UI from another team, tenant, or origin while keeping layout flow and interactivity native. When you want to retire a user-visible iframe that looks and feels like one. When you want to project only a slice of a remote app and let the rest keep running in the background.

Skip it when host and remote already share a build — module federation or a plain component export is lighter. Skip it when you need a hard security boundary against an untrusted remote — keep the iframe visible. Skip it when the remote doesn't need interactivity and doesn't change — a server-rendered fragment is simpler.

Where to go from here

The shortest possible next step: npm install virtual-frame, drop in the custom-element snippet above with a URL you own, and watch it work. Most of the mental model survives contact with five minutes of playing with it.

When you're ready for more:

What is Virtual Frame? — the conceptual overview in depth, including the parts of the mental model this article skipped.
Getting Started — installation, the three integration paths, and the first-projection checklist.
Framework guides — React, Vue, Svelte, Solid, Angular, Next.js, Nuxt, and the rest. Pick yours.
Cross-Origin — the bridge protocol, CSP requirements, and the proxy option for keeping first-party cookies.
Store — the reactive message channel for bidirectional state between host and remote.
API reference — every option, property, and method.

The thesis, one more time: stop embedding remote applications. Project them. The boundary you've been working around doesn't have to be there.

The Illusion of Language: What Directives Really Are

Viktor Lázár — Sun, 09 Nov 2025 11:35:27 +0000

Preface & Introduction — Why This Post Exists

This post is not a rebuttal.

It’s a reflection inspired by the great “Directives and the Platform Boundary” article by Tanner Linsley. I genuinely enjoyed the piece and agree with many of its points — especially around ownership, provenance, and the value of explicit APIs.
What I wanted to add is a slightly different lens: one that comes from building directive-driven tooling and from having lived through a very similar chapter in programming history, long before JavaScript had 'use client' or 'use server'.

Over the past year, I’ve watched countless developers treat directives in JavaScript as if they were actual language features — something built into the JavaScript spec or the runtime environment. And to be fair, at a glance, it does look that way. A string at the top of a file that magically changes how the code behaves feels authoritative.

If you haven’t been following the evolution of React Server Components and frameworks like Next.js: modern React apps now use file-level directives such as 'use client' and 'use server' to control where code runs. They look like simple string literals at the top of a file, but they decide whether a component executes on the server or the client — shaping bundling, rendering and data-flow. That’s where the confusion begins.

But here’s the tension:

Directives look like language features.
Directives feel like language features.
Yet directives are not language features.

They are tooling-level signals — consumed by bundlers, compilers, and build pipelines.

This misunderstanding is not a new phenomenon.
We’ve been here before.

A Personal Flashback

The first time I saw a #pragma once in a C++ codebase as a young developer, I thought:
“Wow, the language has a keyword for this! Why doesn’t JavaScript?”

Except… it wasn’t a language keyword.
It was a compiler instruction. A directive. A hint to the preprocessor, not to the language itself.

Just like 'use strict' wasn’t “JavaScript syntax” at first — and just like 'use client' isn’t “JavaScript syntax” today.

This post explores that parallel. Because understanding the C/C++ preprocessor era is a surprisingly powerful way to understand modern JS directives — why they confuse people, and what we could learn from the past to teach them better.

Why Do Directives Feel Like Language Features?

If you show a newcomer the following code:

'use client';

export function Button() {
  return <button>Click</button>;
}

and ask them what 'use client' is, most will confidently answer:

“It’s part of JavaScript.”

This isn’t ignorance. It’s pattern recognition.

Throughout their entire programming life, file-level “magic statements” have almost always been language semantics, not tooling semantics:

"use strict"
"use asm"

They look like syntax.
They live at the top of the file.
They change behavior.

So the brain does the obvious thing: it classifies them as language.

The TanStack article captures part of this well when it says:

“A directive at the top of a file looks authoritative. It gives the impression of being a language-level truth, not a framework hint.”

This is the crux of the confusion.

The Hidden Mechanism Makes It Worse

Directives blur boundaries because the code that reacts to them is:

invisible
non-local
not traceable through imports

If I write:

import { client } from 'somewhere';

→ I can follow the import. I see who owns it. I can version it. I know what documentation to search for.

But with directives:

there is no import
no namespace
no ownership reference
no callsite to inspect

The behavior “comes from nowhere”.

Which is exactly why they feel like language.

Add Build Tools… and the Illusion Solidifies

Unlike JavaScript keywords, directives do nothing by themselves.

A runtime engine won’t throw if you mistype 'use clinet'.
A bundler or transform plugin decides what to do with it. Some ignore it, some error, some treat it as a string literal.

This leads to the second major confusion:

“If it requires a bundler to work, isn’t it part of the ecosystem platform, not the language?”

From the developer’s perspective, if code changes behavior without explicit imports, the mind defaults to:

✅ language feature
❌ library feature

And that is the trap.

Because what we call “platform” today is actually a stack of tools — not a coherent language surface. Exactly like in the C/C++ era.

A Look Back: C/C++ Macros and the Preprocessor

Long before modern JavaScript build pipelines, the C and C++ world lived through a very similar confusion. And it all started with a layer that sat before compilation: the preprocessor.

To understand today’s directives, we need to briefly revisit three pillars of that era — because they map surprisingly well to what we see today.

The C Preprocessor Was Not the Language — But It Felt Like It

Consider this:

#define PI 3.14

Many beginners encountering this for the first time assume:
“Oh, C has a special language keyword for defining constants.”

Except… #define is not part of the C language grammar.
It’s an instruction to a separate tool that runs before the compiler.

It performs text substitution — not type checking, not syntax analysis, not semantic validation.

Yet, because it lived inside .c/.h files and looked like “code”, generations of developers perceived it as the language.

Sound familiar?

A directive in JS behaves the same way:

'use server';

The JavaScript engine doesn’t know what that means.
The bundler decides what to rewrite before execution.

Both are pre-language phases that masquerade as language.

Pragmas: The Original “Framework Directives”

If macros were like today’s codegen utilities, then #pragma was the closest ancestor to modern directives:

#pragma once

This line is not part of the C++ language spec.
It’s a compiler-specific “hint” — an instruction that affects how the build system treats this file.

No import
No namespace or provenance
No indication of ownership

Different compilers supported different pragmas. Some ignored them. Some produced warnings. Some behaved differently.

Replace “compiler” with “bundler” and you get 2025.

For example:

Next.js reacts to 'use client'
Vite might ignore it
A custom RSC bundler might interpret it differently

It’s the same fragmentation pattern seen 30 years ago.

Include Guards: The First “Invisible Build-Time Behavior”

Before #pragma once became common, C/C++ used include guards to prevent double inclusion:

#ifndef MY_HEADER_H
#define MY_HEADER_H

// header contents

#endif

This pattern:

altered program behavior
existed only for tooling
had no runtime meaning
required knowledge of the build model, not just the language

This is important:

C/C++ forced developers to learn that “code you write in a file” and “the language itself” are not the same thing.

This was a painful but transformative lesson.

We are now at the same educational moment in JavaScript.

Multi-Stage Compilation: A Familiar Pipeline

C/C++ had distinct layers:

Preprocessor → Compiler → Linker → Executable

Modern JS tooling has the same separation, just with cooler names:

Directive Scanner / Loader → AST Transforms → Bundler → Output Chunks

And just like beginners blamed “C++ the language” for preprocessor quirks, today developers blame:

“JavaScript”
“React”
“the platform”

…for behaviors that actually originate from build tooling.

History is repeating itself — almost line for line.

Modern Directives Through the Lens of the Preprocessor Era

Once you see the C/C++ parallels, modern JavaScript directives suddenly make a lot more sense. They are not an evolution of JavaScript syntax — they are an evolution of compiler hints.

Let’s make the mapping explicit:

Preprocessor Era Concept	Modern JS Equivalent
`#pragma`	`'use client'`, `'use server'`
`#define` macros	code transforms / auto-generated wrappers
`#include` guards	module boundary / hydration boundaries
compiler-specific behavior	bundler-specific behavior
multi-stage builds	loader → transform → bundle pipeline

Just like in the 90s, the surface looks deceptively simple — but the real action happens underneath.

Directives Don’t Execute — They Instruct a Tool

A key property of directives is this:

They don’t do anything themselves — they only change how something else behaves.

Here’s a breakdown of what typically happens in a directive-driven pipeline (simplified, but accurate enough):

Read file → Check for directives → Decide environment / boundary →
Run transforms → Generate client/server bundles → Output

Let’s compare that to the C pipeline:

Read file → Preprocessor expands macros + handles pragmas →
Compile → Link → Output

They are structurally identical concepts, just applied to different languages and eras.

Why the Illusion of a Language Feature Persists

Three psychological factors contribute to the confusion:

They look like syntax
Both #pragma once and 'use client' feel like reserved keywords.
They live at the top of the file
Anything that shapes the entire file is often assumed to be language.
They act globally and implicitly
They don’t require instantiation or import.

In other words, directives successfully exploit a linguistic illusion.
They act like a programming language — while not being one.

But Modern Directives Go Further Than C Pragmas

Here’s where things get more interesting:

C pragmas only affected compilation behavior.
Modern directives often affect execution model, code placement, bundling, and runtime boundaries.

For example, 'use server' might:

move code into a server-only chunk
replace calls with RPC stubs
add serialization wrappers
enforce data-flow constraints

This is already beyond what the C preprocessor did.

It’s closer to a macro system + compiler pass.

Which is exactly why understanding the distinction matters:

If something affects runtime execution and code placement, we should not treat it as “just a string at the top of the file”.

And yet, ironically, most misconceptions arise because that is exactly how it appears.

Build Tools Are the Real Interpreter of Directives

Just like different C compilers treated pragmas differently, modern JS tooling varies, too:

Next.js interprets 'use client' one way
Vite + RSC implementations another
Third-party bundlers a third way

If tomorrow another framework introduced:

'use streaming-server';

JavaScript engines wouldn’t care.
Tools would decide what it means.

And that is the mental shift we need developers to make:

Directive ≠ language
Directive = build instruction

They live in userland — not in the spec.

Before we move on, it’s worth pausing for a moment. The parallels with C and C++ are useful for understanding the shape of directives, but they can still feel abstract until you’ve seen them in practice. To bring the idea into clearer focus, let’s look at a concrete example from today’s ecosystem — one that makes the theory a bit more tangible, and shows how these compiler hints manifest in real, modern code.

📦 When Inline Server Functions Reveal the Need for Directives

I once ran into a case that perfectly exposed why some server behaviors cannot be left to runtime.

Consider an inline server function defined inside a Server Component, capturing variables from its local scope:
export default function Dashboard() {
  const rate = 0.27;

  async function save(value) {
    'use server';
    return value * rate; // ← captures "rate" from the component scope
  }

  return <button onClick={() => save(10)}>Save</button>;
}
At first glance, this feels like a normal function call. But for this to work, the bundler must do something subtle and non-negotiable:

detect that save is a server function,

hoist it into a server-only module,

perform AST-level closure analysis to capture rate,

and generate a stable, directly callable reference for the client — not a runtime-constructed wrapper.

A runtime helper cannot solve this.
By the time the code runs, the closure is gone and the intent is already lost.
The function must be transformed before the program exists, so that the client can call it as a direct function, not a proxy we stitched together too late.

This is why directives fit this space so well: they tell the build tools at the moment of definition what this function truly is, giving them time to shape it accordingly.

Some decisions must happen while the code is still being woven — not after it is already alive.

The Educational Gap — and What We Can Learn From History

If you step back and look at the confusion around directives today, you’ll notice something striking:

The problem is no longer technical — it’s educational.

We’ve repeated a historical pattern:

A tool-level construct looks like language
Developers assume it is language
The mental model becomes wrong
Confusion spreads faster than documentation can correct it

This happened with the C preprocessor.
It’s happening again with JavaScript directives.

We Need to Teach the Layering — Not Just the Feature

If we teach 'use server' as:

“This makes your function run on the server.”

…we’ve already lost.

Because that sentence hides 4 separate layers:

Layer	Responsible For
Syntax	writing a string literal
Loader	detecting the directive
Build tools	transforming / splitting code
Runtime	enforcing the boundary

If developers don’t understand which layer is responsible for what, they will blame “JavaScript” for a bundler problem — just like C developers once blamed “the language” for preprocessor bugs.

What the C/C++ Community Eventually Learned

Over time, C/C++ education evolved:

Early teaching:
“Here’s how to use #define and #pragma.”

Mature teaching:
“Here’s what the preprocessor is, and why it’s separate from the language.”

After that shift, confusion dropped dramatically. No serious C++ course today teaches macros without first teaching the mental model of the compilation stages.

We need the same shift for JS directives.

Directives Aren’t Bad — They’re Powerful, If Understood

This post is not an argument against directives. They serve a purpose:

Conveying intent declaratively
Reducing boilerplate
Helping tools optimize and separate code
Giving the developer a simple switch for complex behaviors

In fact, some of the most ergonomic server/serverless features would be far more cumbersome without them.

But the price of ergonomics is clarity debt.

If we don’t teach where the magic comes from, developers misattribute the source of truth — and debugging collapses.

A Simple Mental Model to Teach (Starting Tomorrow)

I like to explain directives with a single sentence:

“A directive is a note you leave for your build tools — not for JavaScript.”

That line alone fixes 70% of misunderstandings.

Add one analogy:

“If #pragma once was not C++ syntax, then 'use client' is not JavaScript syntax either.”

And suddenly, people get it.

This doesn’t require more docs — it requires better framing.

A Practical Step Toward Clarity: A TypeScript Plugin for Directives

Before wrapping up, I want to share one more concrete step I took to reduce this confusion in real-world codebases. If part of the problem comes from directives looking like language yet lacking any formal structure, then giving them type-level meaning is one way to bridge the gap.

I built a small TypeScript plugin called typescript-plugin-directives that brings type safety and IntelliSense awareness to directives. It allows teams to:

define their own directive vocabulary,
validate them at compile time,
get editor hints and autocomplete,
and avoid silent typos like 'use clinet'.

The goal isn’t to “standardize” directives, but to make their intent explicit and visible to both developers and tooling — without needing a bundler to interpret them first.

You can try it here:

npm: https://www.npmjs.com/package/typescript-plugin-directives
GitHub: https://github.com/lazarv/typescript-plugin-directives

It’s intentionally lightweight — just a small layer to help the mental model click earlier, and to give directives a more formal shape inside TypeScript projects.

There’s a common assumption that a TypeScript plugin could “enforce” directives — that if the plugin knows about them, the system becomes safe by default.
But a TS plugin lives in the Language Service. It can provide awareness, warnings, and guidance — yet it still doesn’t run where code is actually transformed. It doesn’t participate in compilation or bundling.

A plugin can help identify directive usage, but it cannot enforce their semantics.
For that, the compiler needs a signal of intent — something the type system can understand.

To enable this, I expose a global Directive type in my plugin. Authors can use satisfies not to inform the editor, but to inform the TypeScript compiler that a given string is intended to be a directive:
'use server' satisfies Directive;
This doesn’t change behavior or trigger any transformation.
What it does is far simpler and more fundamental:

It tells the type system:
“Treat this as a directive — and validate it as such.”

It aligns intent with the compiler, not with runtime, and not only with the IDE.

The actual separation of worlds — hoisting inline server functions out of a component, analyzing captured scope, generating a directly callable boundary — still belongs entirely to the build. The type system can acknowledge intent, but the bundler is the one who must act on it.

One practical caveat: today, some tooling — including Next.js — expects directives to appear as bare string literals. When written as 'use server' satisfies Directive, the directive may no longer be detected, since the literal is no longer in the exact form the framework scans for. Until this changes, this pattern won’t be picked up by Next.js.

There is one more subtlety worth mentioning. This type-level intent only matters if a type-checker is actually running. Many modern toolchains — esbuild, SWC, Oxc, Bun, even most Deno and Vite setups — do not type-check at all. They simply strip types and move on. In those environments, the Directive + satisfies expression becomes a silent note to the compiler that never had a chance to listen.

Closing Reflection

The article from Tanner raises a valuable conversation — one worth having early, before bad habits ossify. I don’t believe the goal should be to eliminate directives; they clearly solve real problems. But we can learn from history, and avoid the confusion that entire generations of C/C++ developers had to unlearn.

We’ve been here before.
We know how this story goes.
This time, we can skip the decade of confusion in the middle.

Teach the layers.
Teach the provenance.
Teach the mental model.

And directives will stop feeling like “secret language features” — and start feeling like the powerful, intentional compiler hints they actually are.

Exploring an experimental Micro-Frontend Architecture with Server-Side Rendering using React Server Components

Viktor Lázár — Sun, 25 Aug 2024 12:18:46 +0000

Introduction
What are Micro-Frontends?
Introduction to React Server Components (RSC)
The Experimental Architecture: Combining Micro-Frontends with RSC
Challenges and Considerations
The Future of Micro-Frontends with RSC
Introducing @lazarv/react-server with RSC Delegation
Implementing the Experimental Micro-Frontend Architecture with @lazarv/react-server
Supporting Client Components in a Micro-Frontend Architecture
Implementing Server Actions in a Micro-Frontend Architecture
Using Static Site Generation in a Micro-Frontend Architecture
Server Islands: loading MFE content using ReactServerComponent
Shared State Management in a Micro-Frontend Architecture
Leveraging Native ES Modules with @lazarv/react-server
Final Thoughts

In recent years, the micro-frontend architecture has gained significant traction, enabling teams to independently develop and deploy features within a larger application. This paradigm empowers organizations to scale development efforts by decentralizing codebases and fostering collaboration across teams. Coupled with server-side rendering (SSR), micro-frontends offer enhanced performance and SEO capabilities. In this blog post, we'll explore an experimental architecture that marries micro-frontends with React Server Components (RSC), pushing the boundaries of what's possible in modern web development.

What are Micro-Frontends?

Micro-frontends extend the concept of micro-services to the frontend, where a large application is broken down into smaller, independently deployable pieces. Each micro-frontend can be built and maintained by different teams, possibly using different technologies. This approach allows teams to work in parallel without stepping on each other's toes, thus accelerating the development process and making the codebase more maintainable over time.

However, this flexibility comes with its own set of challenges. Ensuring consistency in user experience, managing shared state, and optimizing performance across micro-frontends are some of the significant hurdles that developers face.

How Does This Stack Up?

When considering alternative approaches like traditional monolithic applications or Single Page Applications (SPAs), the micro-frontend architecture offers superior scalability and team autonomy. Unlike monoliths, which can become unwieldy as they grow, micro-frontends allow teams to iterate on specific features independently. Compared to SPAs, this architecture provides better initial load performance through SSR, which is crucial for applications with SEO requirements or those targeting low-bandwidth environments.

Introduction to React Server Components (RSC)

React Server Components (RSC) is a new feature of React that allows components to be rendered on the server. Unlike traditional SSR, where HTML is generated on the server, React Server Components can return lightweight "descriptions" of UI components, which the client can then render.

This approach has several advantages:

Improved Performance: By offloading some rendering logic to the server, the client-side workload is reduced, leading to faster interactions.
Code-Splitting at a Component Level: RSC facilitates finer-grained code-splitting, allowing for only the necessary components to be loaded and rendered.
Enhanced Developer Experience: The seamless integration of server and client components allows for a smoother development experience.

The Experimental Architecture: Combining Micro-Frontends with RSC

Our experimental architecture attempts to leverage the strengths of both micro-frontends and React Server Components. Here's an overview of the key components:

Independent Micro-Frontend Applications: Each micro-frontend is developed as a standalone application. These applications can be written in different frameworks or technologies but are integrated using a common interface or shared protocol.
Server-Side Rendering with React Server Components: The server takes responsibility for rendering React Server Components, returning lightweight component descriptions to the client. This reduces the initial load time and provides a smoother user experience.
Shared State Management: To ensure consistency across micro-frontends, a shared state management layer is introduced. This layer allows for state synchronization and communication between different micro-frontends, even if they are built using different technologies.
Lazy Loading and Code Splitting: RSC enables lazy loading of components at a granular level, ensuring that only the necessary code is sent to the client. This optimizes performance and reduces the time to interactive (TTI).

Challenges and Considerations

While this architecture offers significant benefits, it is not without its challenges:

Complexity: The integration of micro-frontends with React Server Components adds a layer of complexity. Teams must be diligent in managing dependencies, ensuring compatibility, and maintaining a consistent user experience across micro-frontends.
Performance Overhead: Although server-side rendering improves the initial load time, it can introduce performance overhead on the server. Proper load balancing and caching strategies are crucial to mitigate this issue.
SEO and Accessibility: While SSR improves SEO, developers need to ensure that all micro-frontends adhere to best practices for SEO and accessibility, particularly in a mixed technology environment.
Shared Dependencies: Managing shared dependencies across micro-frontends can be challenging. Ensuring that different versions of libraries or frameworks do not conflict is crucial to maintaining application stability.

The Future of Micro-Frontends with RSC

This experimental architecture is just one possible way to harness the power of micro-frontends and React Server Components. As these technologies evolve, we can expect to see more refined patterns and best practices emerge. For now, this approach represents an exciting frontier in web development, offering the potential for highly scalable, performant, and maintainable applications.

By combining micro-frontends with React Server Components, we can create applications that are not only modular and scalable but also optimized for performance and user experience. However, careful consideration must be given to the inherent complexity and potential pitfalls of this approach.

To illustrate a potential real-world use case, consider a large e-commerce platform that needs to scale while maintaining high performance. Using the micro-frontend architecture with React Server Components, each part of the application, such as the product catalog, user reviews, and checkout process, could be developed, deployed, and updated independently. This modular approach allows teams to work on different features simultaneously, reduces the risk of errors during deployment, and improves load times through server-side rendering, ultimately enhancing the user experience and streamlining maintenance.

As always, the best architecture is one that fits your specific use case. If you're considering adopting this experimental approach, weigh the pros and cons carefully and consider starting with a proof of concept to validate your ideas.

Introducing `@lazarv/react-server` with RSC Delegation

@lazarv/react-server is a cutting-edge framework designed to streamline the development of micro-frontends with robust server-side rendering capabilities. One of the standout features of this framework is its support for React Server Components (RSC), enabling developers to efficiently manage server-side logic while maintaining a seamless user experience. However, what truly sets @lazarv/react-server apart is its brand-new feature, RSC Delegation.

RSC Delegation is a powerful mechanism that allows developers to delegate specific React Server Components to different micro-frontends or even entirely separate servers. This feature ensures that complex or resource-intensive components can be processed on dedicated servers, optimizing performance and scalability. For instance, if one micro-frontend in your application requires heavy data processing, you can delegate that component's execution to a specialized server, leaving the rest of your application to run smoothly.

By using RSC Delegation, @lazarv/react-server enables a more modular and flexible architecture, where each micro-frontend can handle its own server-side rendering tasks independently or delegate them as needed. This not only improves the overall performance of your application but also simplifies the development process, as each component can be optimized for its specific environment without impacting the rest of the system. This feature makes @lazarv/react-server an even more powerful tool for building scalable, maintainable web applications.

Check out more about @lazarv/react-server at https://react-server.dev.

Implementing the Experimental Micro-Frontend Architecture with `@lazarv/react-server`

Now that we've discussed the theoretical aspects and potential benefits of combining micro-frontends with React Server Components, it's time to dive into a practical implementation. For this, we'll be using the @lazarv/react-server framework — a powerful tool designed specifically for server-side rendering with React Server Components.

This section will guide you through setting up and implementing this architecture using @lazarv/react-server.

Installing `@lazarv/react-server`

First, you'll need to install the @lazarv/react-server package. You can do this via pnpm, npm or even yarn. For this example project, we’ll be utilizing pnpm, a fast and efficient package manager that’s particularly well-suited for managing dependencies in complex, multi-project environments like micro-frontends.

mkdir my-app
cd my-app
pnpm init
pnpm add @lazarv/react-server

This command will add the @lazarv/react-server package to your project, leveraging pnpm's efficient dependency management system to ensure that your node_modules folder is optimized and free of duplicates.

Creating the Hosting Application

We’ll start by creating a hosting application that will serve as the main entry point for rendering and orchestrating different micro-frontends.

Create a simple React Server Component that will be rendered on the server:

// ./index.jsx
export default function HostingApplication() {
  return (
    <div>
      <h1>Welcome to the Hosting Application</h1>
      <p>This is a simple React Server Component.</p>
    </div>
  );
}

With everything set up, you can run the hosting application directly using the react-server command:

pnpm react-server ./index.jsx --open

This command will start the development server on http://localhost:3000 and automatically open the hosting application in your default web browser.

Creating a Simple Micro-Frontend (MFE) Application

Next, we’ll create a small micro-frontend application that can be loaded into the hosting application.

// ./remote.jsx
export default function MFE() {
  return (
    <div>
      <h2>This is the Micro-Frontend Component</h2>
      <p>Loaded from the MFE application.</p>
    </div>
  );
}

Start the MFE application server on port 3001 and open the RSC in the browser using:

pnpm react-server ./remote.jsx --port 3001 --open

Using `RemoteComponent` to integrate the MFE Application into the Hosting Application

Finally, we’ll integrate the MFE into the hosting application by using RemoteComponent from @lazarv/react-server/router to load the MFE dynamically.

Update the Hosting Application to use `RemoteComponent`

Modify the HostingApplication component to include the RemoteComponent pointing to http://localhost:3001:

// ./index.jsx
import { RemoteComponent } from '@lazarv/react-server/router';

export default function HostingApplication() {
  return (
    <div>
      <h1>Welcome to the Hosting Application</h1>
      <p>This is a simple React Server Component.</p>

      <RemoteComponent src="http://localhost:3001" />
    </div>
  );
}

With this setup, the RemoteComponent will fetch the RSC payload from the MFE application running on http://localhost:3001 and render it within the hosting application using server-side rendering.

With both the hosting and MFE applications running, you can now test how they work together. The hosting application will dynamically load and display components from the MFE application, allowing you to see how they integrate in real-time. This setup lets you check if everything is functioning correctly and ensure that the micro-frontends are interacting as expected.

Set up `package.json` scripts

Let's add run-p, a utility from npm-run-all that allows you to run multiple npm scripts in parallel. We will also add a script in the package.json file to start both the hosting and MFE applications simultaneously, while only opening the hosting application in the browser.

First, navigate to your project’s root directory and install the npm-run-all package, which includes the run-p command:

pnpm add -D npm-run-all

Next, you'll update the package.json file to include the scripts for starting both applications. Here’s how you can do it:

{
  "name": "my-app",
  "version": "1.0.0",
  "scripts": {
    "dev:host": "react-server ./index.jsx --name host --open",
    "dev:remote": "react-server ./remote.jsx --name remote --port 3001",
    "dev": "run-p dev:host dev:remote"
  },
  "dependencies": {
    "@lazarv/react-server": "0.0.0-experimental-a6c271a-20240825-5a3908ae"
  },
  "devDependencies": {
    "npm-run-all": "^4.1.5"
  }
}

In this setup:

dev:host: Starts the development server of the hosting application and opens it in the default browser. The --name host argument prefixes the server logs with "host" for easier identification in the terminal.
dev:remote: Starts the development server of the MFE application on port 3001. The --name remote argument prefixes the logs with "remote" for clarity.
dev: Uses run-p to run both dev:host and dev:remote in parallel, ensuring both servers start simultaneously but only the hosting application opens in the browser.

Running the applications

To start both the hosting and MFE applications with the appropriate logging prefixes, run:

pnpm dev

This command will start both servers concurrently. The hosting application will be accessible on http://localhost:3000, and the MFE application will be on http://localhost:3001. Only the hosting application will open automatically in the browser, while logs from both applications will be prefixed with "host" and "remote" respectively for clear identification.

Supporting Client Components in a Micro-Frontend Architecture

In a micro-frontend setup, client components play a crucial role in maintaining the balance between server-rendered content and client-side interactivity. With React's new "use client" directive, client components are still rendered on the server side, ensuring that the initial content is available as quickly as possible. Once the content is sent to the browser, these components are hydrated, which enables their interactivity, such as handling user input, managing state, and responding to events.

By incorporating client components into a micro-frontend architecture, you ensure that each micro-frontend not only contributes to the overall performance and SEO of the application but also provides a rich, interactive experience for users. This dual-rendering capability allows developers to choose the right balance of server-side rendering and client-side interactivity, depending on the needs of each component.

We will demonstrate how to integrate client components into a micro-frontend architecture using @lazarv/react-server. Specifically, we’ll create a new micro-frontend application that includes a client-side counter component, showing how it can be seamlessly integrated into an existing hosting application. This example will highlight the flexibility and power of combining server-rendered and client-rendered components within a unified architecture.

Creating a new MFE application with a counter

Next, we'll create a simple counter component that will be the MFE application.

// ./counter.jsx
"use client";

import { useState } from 'react';

export default function CounterComponent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h2>Counter Component</h2>
      <p>Current Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <button onClick={() => setCount(count - 1)}>Decrement</button>
    </div>
  );
}

This component uses React's useState hook to keep track of the count and provides two buttons to increment and decrement the count.

To differentiate from the previous MFE, we’ll run this new MFE on port 3002.

pnpm react-server ./counter.jsx --port 3002

Add a script to the package.json file to start this new MFE application and also update the dev script to concurrently run the MFE counter application too:

{
  "scripts": {
    "dev:counter": "react-server ./counter.jsx --port 3002 --name counter",
    "dev": "run-p dev:host dev:remote dev:counter"
  }
}

Now you can run the MFE counter application using the following command too:

pnpm dev:counter

Integrate the Counter MFE Application into the Hosting Application

Finally, let's integrate this new MFE into the existing hosting application.

Modify the HostingApplication component to include the new RemoteComponent for the counter MFE:

// ./index.jsx
import { RemoteComponent } from '@lazarv/react-server/router';

export default function HostingApplication() {
  return (
    <div>
      <h1>Welcome to the Hosting Application</h1>
      <p>This is a simple React Server Component.</p>

      <RemoteComponent src="http://localhost:3001" />
      <RemoteComponent src="http://localhost:3002" />
    </div>
  );
}

With this setup, the hosting application will load both the original MFE and the new counter MFE, displaying them on the same page.

Start the hosting application along with the counter MFE application:

pnpm dev

But this does not work yet! We need to add an import map to resolve the client-side issues.

What is an Import Map?

When working with native ES modules in modern browsers, an import map is a powerful tool that helps you control the way your JavaScript modules are resolved and loaded. By default, when you use the import statement in your code, the browser looks for modules based on their paths or URLs. However, this can become cumbersome when dealing with complex dependencies or when you want to use specific versions of a library without changing all your imports.

An import map allows you to define custom mappings for module specifiers, essentially telling the browser where to find specific modules. This is particularly useful when you're working with libraries or frameworks that are hosted on a CDN, or when you want to maintain control over the version of a module being used across your project.

Here's how an import map works:

Module Specifier Mapping: With an import map, you can map a module specifier (the string you use in the import statement) to a specific URL. This means you can use simple names like react or lodash in your imports, and the browser will know exactly where to find them based on your map.
Version Control: Import maps allow you to lock your dependencies to specific versions without needing to modify each import statement manually. For example, you can ensure that all references to a library like lodash point to the same version, which is crucial for maintaining consistency across your application.
Simplified Imports: Instead of dealing with long, complex URLs or paths, you can keep your import statements clean and easy to read. The import map handles the complexity under the hood.

In summary, import maps are a powerful way to manage module resolution in the browser, making it easier to handle dependencies, control versions, and keep your codebase clean and maintainable when using native ES modules.

Import map definition

To ensure that only a single instance of React is loaded in the browser when working with multiple micro-frontends, it's important to set up an import map. This prevents issues related to having multiple React instances, such as conflicts in state management or hooks not working correctly. Here's how you can add an import map to your project.

To properly support an import map and ensure that only a single instance of React is loaded across your micro-frontend architecture, you can configure the framework by using a react-server.config.mjs file. Below is an explanation and a step-by-step guide to implementing this configuration.

In your project, create a react-server.config.mjs file. This file will be used to define how modules are resolved and shared across different parts of your application.

Add the following content to react-server.config.mjs:

export default {
  importMap: {
    imports: {
      react: "https://esm.sh/react@0.0.0-experimental-58af67a8f8-20240628?dev",
      "react/jsx-dev-runtime": "https://esm.sh/react@0.0.0-experimental-58af67a8f8-20240628/jsx-dev-runtime?dev",
      "react-dom": "https://esm.sh/react-dom@0.0.0-experimental-58af67a8f8-20240628?dev",
      "react-dom/client": "https://esm.sh/react-dom@0.0.0-experimental-58af67a8f8-20240628/client?dev",
      "react-server-dom-webpack/client.browser": "https://esm.sh/react-server-dom-webpack@0.0.0-experimental-58af67a8f8-20240628/client.browser?dev",
      "http://localhost:3002/": "/",
    },
  },
  resolve: {
    shared: [
      "react",
      "react/jsx-dev-runtime",
      "react/jsx-runtime",
      "react-dom",
      "react-dom/client",
      "react-server-dom-webpack/client.browser",
    ],
  },
};

The import map is a JSON structure that tells the browser where to find specific modules. In this case, we're specifying that React and related packages should be loaded from esm.sh, a popular CDN for ES modules while it can also translate CommonJS packages to native ES modules.

By pointing to esm.sh, all micro-frontends and the hosting application will download and use the same instance of React and related modules directly from the CDN on the client-side. This avoids the common issue of having multiple versions of React in the same application, which can cause hooks to break and state to behave unexpectedly.

The resolve.shared section ensures that specific modules are shared across all components and micro-frontends, preventing multiple instances from being loaded. This guarantees that any part of your application that imports React, ReactDOM, or related libraries will use the same shared instance from esm.sh.

Now with the import map defined, we can retry running the apps by using pnpm dev and it should work now with the counter component working inside the hosting application!

Implementing Server Actions in a Micro-Frontend Architecture

Server actions in a micro-frontend architecture represent a powerful pattern for managing server-side logic in a modular and secure way. By defining server actions within individual micro-frontends, developers can keep the server-side operations close to the components that need them, maintaining a clean separation of concerns and enhancing scalability.

In a typical micro-frontend setup, different parts of the application are developed and deployed independently, each potentially containing its own server-side logic. Server actions enable each micro-frontend to manage its own server-side tasks, such as handling form submissions, interacting with databases, or processing data. These actions are executed entirely on the server, ensuring that sensitive logic is not exposed to the client, which greatly enhances security.

Moreover, by using server actions within micro-frontends, developers can optimize performance by offloading computationally expensive tasks to the server. This reduces the load on the client, resulting in a more responsive user interface. Since server actions are tied to specific components, they also contribute to a modular architecture where each micro-frontend can be developed, tested, and scaled independently of the others.

Overall, server actions in a micro-frontend architecture allow for a robust, scalable, and secure application structure. They empower each micro-frontend to independently handle its own server-side logic, while still contributing to a cohesive and unified user experience across the entire application.

Read more about server actions in the React documentation at https://react.dev/reference/rsc/server-actions.

Using Server Actions with `@lazarv/react-server`

Now we will implement another MFE application including a form and we will use a server action to handle form submission while staying in the context of the MFE application even when using the hosting application.

Creating a new MFE application with a form and a server action

Next, we'll create an RSC component including a form element and we will handle the form submit action using a server action.

// ./form.jsx
const state = { name: "" };
export default function ServerActionComponent() {
  return (
    <form action={async (formData) => {
        "use server";
        state.name = formData.get("name");
      }}>
      <h2>Welcome, {state.name || "Anonymous"}</h2>
      <input type="text" name="name" defaultValue={state.name} />
      <input type="submit" value="Submit" />
    </form>
  );
}

Similar to the previous counter MFE, we’ll run this new MFE on another a new port again, let's use port 3003 for this one.

pnpm react-server ./form.jsx --port 3003

Again, add a script to the package.json file to start this new MFE application and also update the dev script to concurrently run the MFE counter application too:

{
  "scripts": {
    "dev:form": "react-server ./form.jsx --port 3003 --cors --name form",
    "dev": "run-p dev:host dev:remote dev:counter dev:form"
  }
}

Now you can run the MFE application using a server action by running the following command:

pnpm dev:form

Integrate the server action driven MFE into the Hosting Application

Finally, let's integrate this new MFE using a server action into the existing hosting application.

Modify the HostingApplication to include the new RemoteComponent for the form MFE:

// ./index.jsx
import { RemoteComponent } from '@lazarv/react-server/router';

export default function HostingApplication() {
  return (
    <div>
      <h1>Welcome to the Hosting Application</h1>
      <p>This is a simple React Server Component.</p>

      <RemoteComponent src="http://localhost:3001" />
      <RemoteComponent src="http://localhost:3002" />
      <RemoteComponent src="http://localhost:3003" />
    </div>
  );
}

With this setup, the hosting application will load all of our MFE applications displaying them on the same page.

Start the hosting application along with the counter MFE application:

pnpm dev

Using a micro-frontend (MFE) application with a server action in the hosting application allows for a seamless and integrated approach to managing server-side logic across different parts of an application. In this setup, each micro-frontend can independently execute server actions, such as processing data or interacting with a database, while being part of a larger, cohesive system. The hosting application orchestrates these micro-frontends, ensuring they work together harmoniously, while the server actions keep sensitive logic secure and optimize performance by handling complex operations on the server. This approach enhances modularity, scalability, and maintainability, allowing the application to grow and evolve efficiently.

Using Static Site Generation in a Micro-Frontend Architecture

To incorporate Static Site Generation (SSG) into your micro-frontend (MFE) architecture using @lazarv/react-server, we can configure one of the micro-frontends to generate static content at build time. This content will then be served as part of the production build. By using the "remote" flag for the root path, we ensure that the MFE's content is statically generated and included in the hosting application.

Here’s how to extend the existing example to include SSG for one of the micro-frontends:

Update the `react-server.config.mjs` for SSG

To enable SSG, you'll need to update the react-server.config.mjs configuration to specify that the root path of the first MFE should be statically generated with the "remote" flag. This ensures that the content is pre-rendered at build time.

export default {
  importMap: {
    // ...
  },
  resolve: {
    shared: [
      // ...
    ],
  },
  export() {
    return [
      {
        path: "/", // Specify the root path
        remote: true, // Enable the "remote" flag for MFE SSG
      },
    ];
  },
};

Build the Micro-Frontend and Hosting Applications for production

Since SSG is only applicable in a production environment, you'll need to build your applications for production. Add the necessary build scripts in your package.json:

{
  "scripts": {
    "build:host": "react-server build ./index.jsx --outDir .react-server --no-export",
    "build:remote": "react-server build ./remote.jsx --outDir .react-server-remote",
    "build:counter": "react-server build ./counter.jsx --outDir .react-server-counter --no-export",
    "build:form": "react-server build ./form.jsx --outDir .react-server-form --no-export",
    "build": "run-s build:host build:remote build:counter build:form",
    "start:host": "react-server start --outDir .react-server --port 3000",
    "start:remote": "react-server start --outDir .react-server-remote --port 3001",
    "start:counter": "react-server start --outDir .react-server-counter --port 3002 --cors",
    "start:form": "react-server start --outDir .react-server-form --port 3003 --cors",
    "start": "run-p start:host start:remote start:counter start:form"
  }
}

We instruct each build to use it's own output directory so we don't use the same output directory for any of the MFE applications and the hosting application. Except the "remote" MFE application we also disable SSG as we don't need that for any other MFE application. We also enable CORS for each MFE application which will be called by the hosting application as the hosting application will send network requests to these MFE applications from http://localhost:3000 which is a different hostname than the MFE is listening on and would raise a CORS error in the browser.

Warning: Keep in mind that this is just an example and not the pattern you should follow for building for production. Simulating such a setup is way beyond the scope of this blogpost.

Preparing the import map for production use

We need to update the import map of the project to use production versions of dependencies when running the applications in production mode:

export default {
  importMap: {
    imports: {
      ...(process.env.NODE_ENV !== "production"
        ? {
            react:
              "https://esm.sh/react@0.0.0-experimental-58af67a8f8-20240628?dev",
            "react/jsx-dev-runtime":
              "https://esm.sh/react@0.0.0-experimental-58af67a8f8-20240628/jsx-dev-runtime?dev",
            "react-dom":
              "https://esm.sh/react-dom@0.0.0-experimental-58af67a8f8-20240628?dev",
            "react-dom/client":
              "https://esm.sh/react-dom@0.0.0-experimental-58af67a8f8-20240628/client?dev",
            "react-server-dom-webpack/client.browser":
              "https://esm.sh/react-server-dom-webpack@0.0.0-experimental-58af67a8f8-20240628/client.browser?dev",
            "http://localhost:3001/": "/",
            "http://localhost:3003/": "/",
          }
        : {
            react:
              "https://esm.sh/react@0.0.0-experimental-58af67a8f8-20240628",
            "react/jsx-runtime":
              "https://esm.sh/react@0.0.0-experimental-58af67a8f8-20240628/jsx-runtime",
            "react-dom":
              "https://esm.sh/react-dom@0.0.0-experimental-58af67a8f8-20240628",
            "react-dom/client":
              "https://esm.sh/react-dom@0.0.0-experimental-58af67a8f8-20240628/client",
            "react-server-dom-webpack/client.browser":
              "https://esm.sh/react-server-dom-webpack@0.0.0-experimental-58af67a8f8-20240628/client.browser",
          }),
    },
  },
  resolve: {
    shared: [
      "react",
      "react/jsx-dev-runtime",
      "react/jsx-runtime",
      "react-dom",
      "react-dom/client",
      "react-server-dom-webpack/client.browser",
    ],
  },
  export() {
    return [
      {
        path: "/",
        remote: true,
      },
    ];
  },
};

When we detect that NODE_ENV not equals "production" we will still use the development versions of the required dependencies. But when we use production mode, we need to use production builds of React and related packages too, so we need to remove the ?dev query param from the esm.sh URL of dependencies.

Execute the production build

pnpm build

This command will build all applications for production and pre-render the content for the root path of the first MFE and include it in the production build.

Start the production server

After building, you can start the applications in production mode:

pnpm start

This command will serve the statically generated content along with the dynamic content, providing an optimized and pre-rendered user experience.

By integrating Static Site Generation (SSG) into your micro-frontend architecture, you ensure that key parts of your application, such as the first MFE, are pre-rendered and optimized for performance. The use of the "remote" flag in the react-server.config.mjs ensures that these components are statically generated during the production build process. This approach not only improves load times but also enhances SEO and provides a better overall user experience by delivering fully rendered content as soon as possible.

Expanding Static Site Generation Beyond Micro-Frontends

Incorporating Static Site Generation (SSG) into your micro-frontend architecture significantly enhances performance by pre-rendering key parts of your application. While we focused on enabling SSG for a specific micro-frontend (MFE) in this example, it's important to note that SSG isn't limited to just the micro-frontend applications. You can also apply SSG to specific routes within the hosting application itself. By selectively pre-rendering routes in the hosting application, you can optimize the delivery of content that remains relatively static, improving load times and ensuring that your users receive fully rendered pages immediately upon request. This flexibility allows you to tailor your application’s performance and scalability precisely to the needs of your project, combining the benefits of dynamic rendering where needed with the speed of pre-rendered static content.

Server Islands: loading MFE content using `ReactServerComponent`

To demonstrate how you can load content from micro-frontend (MFE) applications in the hosting application using the ReactServerComponent with url and defer props (similar to Astro’s server islands), we’ll set up the architecture so that MFE content is loaded only on the client side, ensuring that it doesn't affect the initial server-side rendering.

This approach allows you to load micro-frontend content dynamically on the client side, deferring the load until the user interacts with the page or until after the initial server-side render. This method is useful for improving perceived performance and user experience by focusing on essential content first.

Create a new MFE application with Suspense

Let's create another MFE application, but this time let's use Suspense! By using Suspense the MFE application can use a streaming response, providing an initial loading content and then transform the initial MFE content to the content streamed to the client.

// ./streaming.jsx
import { Suspense } from 'react';

async function AsyncComponent() {
  await new Promise((resolve) => setTimeout(resolve, 1000));
  return (
    <p>
      This is a remote component that is loaded using Suspense. -{" "}
      <b>{new Date().toISOString()}</b>
    </p>
  );
}

export default function Streaming() {
  return (
    <Suspense fallback={<p>Loading...</p>}>
      <AsyncComponent />
    </Suspense>
  );
}

As usual by now, let's run this MFE using the following command:

pnpm react-server ./streaming.jsx --port 3004 --open

Extend `package.json` scripts

Add a script to the package.json file to start this new streaming MFE application and also update the dev script to concurrently run the streaming MFE application too:

{
  "scripts": {
    "dev:streaming": "react-server ./streaming.jsx --port 3004 --name streaming",
    "dev": "run-p dev:host dev:remote dev:counter dev:form dev:streaming",
    "build:streaming": "react-server build ./streaming.jsx --outDir .react-server-streaming --no-export",
    "start:streaming": "react-server start --outDir .react-server-streaming --port 3004 --cors",
    "start": "run-p start:host start:remote start:counter start:form start:streaming"
  }
}

Now you can run the MFE application using Suspense by running the following command:

pnpm dev:streaming

Add the streaming MFE Application to the Hosting Application

Modify the HostingApplication to include the new ReactServerComponent for the streaming MFE:

// ./index.jsx
import { RemoteComponent } from '@lazarv/react-server/router';
import { ReactServerComponent } from '@lazarv/react-server/navigation';

export default function HostingApplication() {
  return (
    <div>
      <h1>Welcome to the Hosting Application</h1>
      <p>This is a simple React Server Component.</p>

      <RemoteComponent src="http://localhost:3001" />
      <RemoteComponent src="http://localhost:3002" />
      <RemoteComponent src="http://localhost:3003" />
      <ReactServerComponent url="http://localhost:3004" defer />
    </div>
  );
}

With this setup we keep all of our previous MFE applications rendered using server-side rendering in the hosting application using RemoteComponent while rendering the streaming MFE only on the client by using the ReactServerComponent. As soon as the component renders on the client it starts fetching the streaming content from the streaming MFE we just created.

@lazarv/react-server uses the same ReactServerComponent for hydrating your app on the client side. Only the behavior of the component differs in this case and that the component will fetch it's content from an external source by specifying the url prop and that external source in this case is the streaming MFE.

Note: You can extend this by wrapping the ReactServerComponent into a component using a MutationObserver to render the ReactServerComponent only when it's container becomes visible on the page.

Now start the hosting application along with the streaming MFE application:

pnpm dev

By using ReactServerComponent with the url and defer props in the hosting application, you can dynamically load and render content from micro-frontends on the client side, similar to Astro's server islands. This approach allows you to optimize your application's performance by prioritizing critical content during the initial server-side render, while still leveraging the power of micro-frontends to deliver additional, modular functionality as needed.

Shared State Management in a Micro-Frontend Architecture

Managing shared state across multiple micro-frontends is one of the more challenging aspects of a micro-frontend architecture. When building modular applications with independent micro-frontends, ensuring consistent and efficient state management becomes critical. In this section, we’ll explore both backend state management and client-side cross-app state management strategies.

Backend State Management

Backend state management involves centralizing the application's state on the server. This approach ensures that all micro-frontends access a consistent state, regardless of which part of the application is being used. By keeping the state on the server, you reduce the risk of state divergence and improve synchronization across different parts of your application.

Server-Side State with APIs: In a typical setup, the server maintains the state and exposes it through RESTful or GraphQL APIs. Each micro-frontend can query the server to fetch the current state and update it as needed. For example, if one micro-frontend updates a user profile, that change is immediately reflected when another micro-frontend queries the user data.
Server Actions for State Management: Using server actions, as discussed earlier, is another powerful way to manage state. Server actions allow micro-frontends to interact with server-side logic directly. For instance, you might have a server action that updates a shared counter or user session, ensuring that all parts of your application stay in sync.
State Persistence: Persisting state on the backend can be handled through databases or in-memory data stores like Redis. These data stores allow you to maintain a global state that can be accessed and modified by any micro-frontend, providing a single source of truth for the application.

Client-Side Cross-App State Management

While backend state management ensures consistency, there are scenarios where sharing state directly on the client side is more efficient, especially for real-time interactions or when minimizing server calls is crucial.

Shared State Libraries: Libraries like Redux, Jotai or Zustand can be used to manage client-side state that needs to be shared across multiple micro-frontends. By configuring a shared store, different micro-frontends can read from and write to the same state, ensuring that all components reflect the current state of the application.

For example, you might have a shared Redux store that holds authentication information, and each micro-frontend can access this store to determine whether a user is logged in and what permissions they have.

Custom Event Systems: Implementing a custom event bus is another way to share state across micro-frontends on the client side. This approach involves creating a global event system where micro-frontends can emit and listen for events, allowing them to communicate and synchronize state changes without directly depending on each other.

For instance, when one micro-frontend updates a cart item, it emits an event that other micro-frontends listen for, allowing them to update the cart UI accordingly.

Web Storage: Web storage solutions like localStorage, sessionStorage or IndexedDB can be used for simpler cross-app state sharing. Micro-frontends can write to and read from these storage mechanisms, ensuring that state persists across page reloads or navigations.

This approach works well for non-sensitive data that doesn’t need to be immediately synchronized across micro-frontends but still needs to be accessible globally, like user preferences or temporary filters.

Combining Backend and Client-Side State Management

In practice, a robust micro-frontend architecture often uses a combination of backend and client-side state management. For critical state that requires consistency across all parts of the application, such as user sessions or permissions, backend state management is essential. However, for performance-sensitive operations or real-time interactions, client-side state management offers flexibility and speed.

By carefully choosing where and how state is managed, you can ensure that your micro-frontends are both independent and synchronized, providing a seamless user experience across your application. This balance allows for the efficient development and deployment of individual micro-frontends while maintaining the integrity of the overall application state.

Leveraging Native ES Modules with `@lazarv/react-server`

The fact that @lazarv/react-server natively supports ES modules through Vite and Rollup is a significant advantage for developers building micro-frontends. Vite’s use of native ES modules during development allows for faster builds and more efficient hot module replacement, making the development process smoother and more responsive. When it comes time to build for production, Rollup optimizes these ES modules, ensuring that your application is as performant as possible.

How Native ES Modules Simplify Micro-Frontend Architecture

Streamlined Development with Vite: Vite’s use of native ES modules means that during development, each micro-frontend can be built and tested independently with minimal configuration. The development server leverages the browser's native support for ES modules, loading dependencies directly as needed. This leads to faster development cycles, as changes are reflected almost instantly without the need for complex bundling steps.
Optimized Production Builds with Rollup: Rollup takes the ES module-based development environment created by Vite and produces optimized bundles for production. These bundles are smaller, more efficient, and easier to manage, which is especially important in a micro-frontend architecture where multiple independently developed frontends need to come together seamlessly.
Simplified Dependency Management: Since @lazarv/react-server uses native ES modules, managing dependencies across different micro-frontends becomes much simpler. Each micro-frontend can specify and import only the dependencies it needs without worrying about global conflicts or redundant code. This also enables you to take advantage of tree-shaking, where unused code is automatically removed during the build process, further optimizing your application.
Enhanced Modularity and Flexibility: With native ES modules, the architecture of your micro-frontends becomes more modular. Each micro-frontend is essentially a self-contained unit that can be developed, tested, and deployed independently. This modularity is enhanced by the fact that Vite and Rollup are designed to work seamlessly with ES modules, allowing for easy integration of new features and components without disrupting the overall application.
Faster Builds and Deployments: The combination of Vite and Rollup enables quicker build times and more efficient deployments. Vite's instant server start and hot module replacement make development faster, while Rollup's tree-shaking and code-splitting capabilities ensure that the final production bundles are as lean as possible. This is particularly beneficial in a micro-frontend environment, where minimizing build and deployment times is crucial for maintaining agility.

The built-in use of native ES modules in @lazarv/react-server, facilitated by Vite and Rollup, significantly enhances the development and deployment process for micro-frontends. This approach not only simplifies dependency management and module bundling but also ensures that each micro-frontend can operate independently while still contributing to a cohesive and performant overall application. By leveraging these tools, @lazarv/react-server offers a streamlined, modular, and efficient architecture that is well-suited to the demands of modern web development.

Final thoughts

Working with @lazarv/react-server to build a micro-frontend architecture has been an exciting journey, showcasing the framework's potential to revolutionize how we approach modular web development. This framework offers a unique blend of server-side rendering, dynamic content loading, and modular front-end development, making it a powerful tool for creating scalable and maintainable applications.

However, it's important to acknowledge that @lazarv/react-server is still in an experimental phase. While the current capabilities are impressive, there are numerous opportunities for refinement and enhancement. For instance, simplifying the API and improving tooling support could make the framework even more accessible to developers. Additionally, as more developers start using it, we can expect the community to drive innovations that further optimize performance and streamline the development process.

One of the most exciting aspects of @lazarv/react-server is its extendability. The architecture is designed to adapt and grow alongside your application’s needs. Whether you’re looking to incorporate advanced caching strategies, integrate with modern deployment pipelines, or explore new rendering techniques, the framework is flexible enough to accommodate these ambitions.

In summary, while @lazarv/react-server is a powerful tool with a promising future, it’s also a work in progress. As the framework evolves, it will undoubtedly continue to push the boundaries of what’s possible in web development, offering new ways to build fast, scalable, and maintainable applications. The journey with @lazarv/react-server is just beginning, and there’s a lot to look forward to as it matures and expands its capabilities.

The Hidden Economy of Technology: How Tech's Most Difficult Tools Fuel an Industry

Viktor Lázár — Wed, 14 Aug 2024 20:03:37 +0000

Introduction

In the fast-paced world of technology, complexity is often seen as a necessary evil—a byproduct of sophisticated systems designed to solve challenging problems. But what if complexity isn't just an unintended consequence? What if, in some cases, it drives a broader ecosystem that benefits more than just the engineers who master it? From consultants and content creators to corporate strategies and niche specializations, the intricate dance with complexity has created a thriving economy all its own.

The Power of Complexity in Technology

At first glance, complexity in technology might seem like an obstacle—something to be overcome or simplified. But a deeper look reveals that this complexity often fuels an entire industry, creating opportunities for economic gain, educational advancement, and career specialization.

1. The Consultancy Boom: Turning Complexity into Profit

Complex technologies demand expertise. This need has given rise to a robust consultancy market, where businesses and organizations seek out specialists who can navigate these intricate systems. Whether it’s implementing a new enterprise resource planning (ERP) system, optimizing a cloud infrastructure, or managing a complex cybersecurity framework, consultants are in high demand. The more complex the technology, the higher the demand—and the higher the fees.

Consultants don't just solve problems; they offer peace of mind. Companies are willing to pay a premium for the assurance that their complex systems are in capable hands, making consultancy a lucrative field for those who have mastered the intricacies of these technologies.

2. Education and Training: A Growing Industry

The complexity of modern tools and systems has also spurred a booming market in education and training. Companies, universities, and independent platforms like Udemy and Coursera offer specialized courses aimed at demystifying these technologies. Certifications have become badges of honor in the tech world, validating one's ability to navigate and master complex systems.

For those looking to enter the tech industry or advance their careers, these training programs are invaluable. But they’re also big business. The more difficult the subject, the more willing individuals and companies are to invest in education. This has led to a proliferation of training programs, boot camps, and online courses designed to make complexity more manageable—while also turning a profit.

3. Content Creation: Complexity as a Content Goldmine

In the age of digital content, complexity is a goldmine for creators. YouTube channels, blogs, and podcasts that focus on teaching complex technologies attract dedicated audiences eager to learn. These platforms provide tutorials, tips, and deep dives into the nuances of difficult tools, all while generating income through ads, sponsorships, and paid subscriptions.

For content creators, the appeal is clear: the more complex the subject matter, the more valuable their content becomes. A niche audience of dedicated learners often means higher engagement, more views, and a steady stream of income. Platforms like Patreon have further enabled creators to monetize their expertise, offering exclusive content and one-on-one mentoring for a fee.

4. Job Market Dynamics: Complexity as a Career Booster

Mastering complex technologies can be a significant career booster. The scarcity of experts in a particular field means that those who do possess the necessary skills are highly sought after. This demand often translates into higher salaries, better job security, and more opportunities for advancement.

In some cases, entire careers are built around niche specializations in complex technologies. These specialists become indispensable within their organizations, offering expertise that few others possess. The more intricate the technology, the more valuable the specialist, creating a virtuous cycle where complexity drives career growth.

5. Corporate Strategy: Leveraging Complexity for Competitive Advantage

Corporations are not blind to the power of complexity. In some cases, companies might intentionally design their systems or technologies to be complex as a form of competitive advantage. This can lead to vendor lock-in, where the difficulty of switching to a different system ensures long-term contracts and ongoing revenue streams.

Furthermore, the development of complex systems often results in the creation of intellectual property (IP) and patents. These assets can give companies a significant edge in the market, creating barriers to entry for competitors and establishing the company as a leader in a particular technology.

6. The Perpetuation of Complexity: A Self-Sustaining Cycle

Over time, complex technologies often become entrenched as legacy systems, further perpetuating their complexity. As these systems evolve, they accumulate additional layers of features and requirements, making them even more difficult to master. This perpetuation creates a continuous need for education, training, and consultancy, sustaining the ecosystem that has grown around the technology.

Ironically, the complexity itself can drive demand for tools and services that simplify or abstract away that complexity. This has led to the rise of frameworks, platforms, and services that aim to make complex technologies more accessible—yet often become complex themselves as they grow.

Conclusion

Complexity in technology is not just a challenge to be overcome; it’s a driver of economic opportunity and industry growth. From consultancy and education to content creation and corporate strategy, the intricate nature of modern tools fuels a multi-faceted ecosystem that benefits a wide range of stakeholders. While this complexity may frustrate users, it also creates a thriving market for those who are willing to embrace it.

In the end, the relationship between complexity and opportunity is symbiotic. As technology continues to advance, this hidden economy of complexity is likely to grow, offering new avenues for innovation, specialization, and economic gain. Whether you’re a consultant, a content creator, or a tech professional, understanding and navigating this complexity can be your key to success in the ever-evolving world of technology.

Disclaimer: This blog post was generated with the assistance of ChatGPT, an AI language model developed by OpenAI. This post is part of a test to gauge viewership and engagement. The content reflects a combination of AI-generated ideas and human curation. We appreciate your feedback and interest in this experiment!

Migrating a Vite + React app to use React Server Components

Viktor Lázár — Sun, 11 Aug 2024 12:25:11 +0000

Vite has the best developer experience a web developer could wish for. When you want to create a single page application using React then Vite is your default choice. It's incomparable how much better it is than using create-react-app just a few years ago. Who really misses Webpack? Who misses complex configurations?

Getting started

Starting a new Vite + React app is easy:

pnpm create vite my-react-app --template react

Then you just need to change directory, install dependencies and start your app:

cd my-react-app
pnpm install
pnpm dev

It just works!

You can achieve great things working only on the client side, what Kent C. Dodds is presenting in this great video is awesome and perfectly viable in a lot of use cases:

But is it really enough? Probably it is most of the time, but everyone wants server-side rendering nowadays, the hype is real and we want it too, so let's continue...

React Server Components

The hype around RSCs are still rising! More and more frameworks are starting to support the new server-side rendering features of the upcoming new major release of React.

Surely Next.js was the first to jump on the train (they built it for themselves) and Vercel started to teach developers around the world about the benefits of using RSCs, including how to work with client components and server actions too.

Other major React based frameworks are picking up RSCs a bit slower though. Remix just demonstrated using RSCs in the loader, while not missing working client components:

Astro is more likely a bit off here as while it supports React, it's implementing it's own similar solutions, like Astro Actions:

RedwoodJS also works on RSC support and Waku supports the new features already.

You can also start building your own framework from scratch or using vinxi. But how many developers are up to do this? It's not even really documented how to do it! What about web developers who are not experienced enough or don't have the time to go down this road? Surely there are some, like Hiroshi implementing an RSC supprting framework using both the current Vite API at https://github.com/hi-ogawa/vite-plugins/tree/main/packages/react-server and using the incoming Vite 6 Environment API at https://github.com/hi-ogawa/vite-environment-examples/tree/main/examples/react-server. Also there's a great article from Daniel Nagy about building your own framework using Vite and RSC support at https://danielnagy.me/posts/Post_usaivhdu3j5d.

But we are drifting too far away from the original simplicity and easy start we had. How to enhance your simple Vite + React single page application with modern server-side rendering?

A bit controversial tutorial you can find is from Vercel, presented by Lee Robinson:

But surely a lot of us were very disappointed when the starting Vite client-side app became a heavy Next.js app, removing all traces of Vite in the end. But we adore Vite here right? We love how simple it is, how fast it is, how easy it is to extend it using plugins, especially compared to custom Webpack plugins.

Almost all other frameworks are using Vite now, especially non-React frameworks, like SvelteKit. When you stick with React, Remix is closest to what we wish for and it will be even more when there will be proper RSC support in Remix. You can already use Remix with Vite and it's great! But it's not supporting RSCs yet and you will get some magic files which will be mostly just deleted as it's not likely you want to modify these. Maybe in a couple months, but expect refactoring!

Is there another choice? A new alternative? Which framework to choose when you want to modify the starting Vite + React app the least and be able to use everything new from React 19?

Vite Forever

So let's correct what Lee did and don't go into the wrong direction by migrating over to Next.js and Webpack, let's stick with Vite at least for a few years, maybe even a decade (or more)!

As we want to use RSCs, let's move everything from the index.html into src/main.jsx and instead of rendering App on the client-side, just use it as a component in this RSC layout:

import App from "./App.jsx";
import "./index.css";

export default function Html() {
  return (
    <html lang="en">
      <head>
        <meta charSet="UTF-8" />
        <link rel="icon" type="image/svg+xml" href="/vite.svg" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Vite + React</title>
      </head>
      <body>
        <div id="root">
          <App />
        </div>
      </body>
    </html>
  );
}

Beware that you need to fix charSet as it has a different casing when used in JSX than in HTML!

For now, just add a "use client"; directive to App.jsx to make it work instantly as the App component includes a useState React hook.

Now let's uninstall react and react-dom as we will not need them, both were just React 18. Now what? How we will run our app?

pnpm add @lazarv/react-server@latest

Yes, I'm installing my own React meta-framework to solve the problem I have here. Is it a better choice than Remix? If you want to use the latest React features, then yes. As it supports RSCs, client components and server actions already, while using Vite, ES modules and keeping everything stupid simple. It's probably best for quick prototyping and for indie devs loving to work with bleeding edge experimental tech. The fact that it was already good enough to implement its own documentation site, using its static-site generation capability, shows great potential. With time, it will become even better and more mature, offering an even wider feature set to work with. You can read more about the framework at https://react-server.dev. Get back to our app now!

Just make some more changes on how to start our app:

"scripts": {
  "dev": "react-server ./src/main.jsx",
  "build": "react-server build ./src/main.jsx",
  "lint": "eslint .",
  "start": "react-server start"
}

If you think this is very familiar to how you would use Node.js to run a script, you're right! react-server ./src/main.tsx is the same as executing node server.js, just for React RSCs. If it would be enough, we could just run a single RSC component using npx with this framework, even without installing anything! Just like with Node.js!

Let's start our app using pnpm dev --open!

It just works! Awesome! But can we fix the loading glitch that we can see on refreshing the page? What causes this?

Optimizing client components

In the current state of our app, the whole App component is a client component. This is not ideal, as only the counter part is interactive in it. We also attached some CSS to this client component which will only be loaded when the client component loads in the browser at runtime. This is causing a glitch for a blink of an eye at page load.

Let's create a new Counter component in a new file at src/Counter.jsx and move the counter button into this new component:

"use client";

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount((count) => count + 1)}>
      count is {count}
    </button>
  );
}

export default Counter;

Now let's get back to the App component, remove the "use client"; directive, remove the App.css import and the code which was only part of the Counter component, but import it instead:

import reactLogo from "./assets/react.svg";
import viteLogo from "/vite.svg";
import Counter from "./Counter.jsx";

function App() {
  return (
    <>
      <div>
        <a href="https://vitejs.dev" target="_blank">
          <img src={viteLogo} className="logo" alt="Vite logo" />
        </a>
        <a href="https://react.dev" target="_blank">
          <img src={reactLogo} className="logo react" alt="React logo" />
        </a>
      </div>
      <h1>Vite + React</h1>
      <div className="card">
        <Counter />
        <p>
          Edit <code>src/App.jsx</code> and save to test HMR
        </p>
      </div>
      <p className="read-the-docs">
        Click on the Vite and React logos to learn more
      </p>
    </>
  );
}

export default App;

The easiest resolution of the CSS issue is to import App.css in main.jsx:

import App from "./App.jsx";
import "./index.css";
import "./App.css";

export default function Html() {
  // we don't need to do any change here
}

Now both CSS files will be loaded instantly on page load and there will be no flickering. The counter button will still work as before as we refactored it to be a new client component. Every other part of the App component was static, which is best to be included in RSCs. You can also combine the 2 CSS files as there's no reason why we have two, just fix the CSS imports in the main.jsx after that.

Where to go?

Now we have the same Vite + React app working with server-side rendering. But how to evolve from this state further?

You can start implementing a form using server actions, just as described at https://react.dev/reference/rsc/server-actions.

You can add a router, maybe a file-system based routing solution supporting RSCs, like @lazarv/react-server-router. It's very flexible!

You can export your app as static as there might be no reason to use dynamic server-side rendering and it's enough for you to render your app at build time.

You can add any Vite plugin and remain in this wonderful ecosystem, extending your app at any time.

You can eagerly wait for a version of Vite using Rolldown, to have an even more blazing-fast developer experience!

Conclusion

While RSCs are with us for quite some time now, we are still learning how to use them properly. It's a super-power to have and it will certainly evolve further. But it's more like a beast to tame than an easy to understand feature. We are holding endless possibilities in our hands, but most of us don't know what to do with it. With great power comes great responsibility! But even when we tend to over-engineer even extremely simple problems, we like to work with simple technologies. That's how Vite won and how PHP is still with us. It's easy to use. A lot of us are not god-like developers implementing anything from scratch in a day. We are just mere humans trying hard to make some silly things work. And we fail a lot. But we win in the end with persistence, like long-distance runners.

We should stick to what we already learned in the past. We should not forget, that we already knew how to make things efficiently. We had worse tools, worse tech, worse machines, but it was possible because of creativity and endurance to create wonderful things. Now we should use our new tools, new tech, new machines and we should still use our creativity and imagination to create even more fascinating experiences. We are responsible for making people happy to use our products. Even as software engineers.

@lazarv/react-server vs Next.js

Viktor Lázár — Sun, 07 Jul 2024 17:12:26 +0000

In this article we will compare @lazarv/react-server to Next.js as these React meta-frameworks are very close because both are based on the new React 19 server-side rendering features.

We will investigate both frameworks on their approach and architectural choices.

What is a meta-framework?

We can consider a solution to be a meta-framework when the following features are supported and the framework is using a specific library as it's base. Which is React in our case.

File-based routing
Static generation
Hybrid rendering
Data fetching
Isomorphic component trees

The React team suggests to use a framework for future React development. Next.js, Remix, Gatsby and Expo are their suggestion, while mentioning Next.js App Router as the bleeding-edge framework. If you really want to use React without a framework, you can still use a bundler like Vite or Parcel.

Next.js

Originally released in 2016 and nowadays it's the go-to meta-framework for React. There are some developers from the Next.js team who are also involved in the development of React itself. This means that Next.js is following the architectural choices the React team considers the best for React. This could be true for certain use cases, but still it's debatable. One major issue with Next.js is that it's optimized for the Vercel platform in every single way. While you can run your Next.js app in every environment which supports node.js, making this choice removes or at least diminishes a lot of nice and valuable features from your Next.js app, which could use Vercel platform features to implement these app features in the most optimal way. You can think of image optimalization, ISR, caching, etc.

Next.js is using Webpack under the hood to bundle your app. While there's experimental support for Turbopack and support for using SWC and Lightning CSS as the compiler. Next.js is still using CommonJS (with some support for ES modules), while the node.js community is mostly trying to switch over to native ES modules and CommonJS is considered legacy now, with some exceptions. Support will remain for years for sure, but there are already npm packages which only support ES modules since a specific version.

@lazarv/react-server

In contrast to Next.js, @lazarv/react-server is using Vite for it's development server and as using Vite, it's bundling for production using Rollup. With this choice it's fully supporting native ES modules. This framework is not favoring any cloud providers like Vercel, but supports deployment to Vercel. As the framework is more of a wrapper around React 19 server-side rendering features without any strict choices on how to implement specific features, it's easier to shape your app the way you want it to work and behave. The only exception is that it will use Vite. Based on that, it's also easier to run apps literally anywhere where you can run a node.js service. The framework also supports cluster mode, which creates a node.js cluster for your app which is beneficial if you run your app in an environment where you want to fully utilize the available resources.

Shared features

As both @lazarv/react-server and Next.js is using React at it's core, both share a lot of features which are provided by React and are not Next.js nor @lazarv/react-server features directly.

React Server Components is a hot topic in the community and it's a very versatile tool. It's surely is the next most different new feature in React 19 since hooks. RSCs are rendered only on the server-side and have no client code so you can't re-render these on the client.

To open a door from RSCs into the client code, you need to create client components. This type of components are basically the same as you already used to in a React server-side rendered app. These are also rendered on the server, but getting hydrated on the client and these are able to re-render on the client based on their state. You can mix RSCs and client components in every way. RSCs can contain client components and client components can also contain RSCs. It's absolutely up to the developer how the app is structured and which part of the app is using RSCs and which part is created using client components and are also running in the browser.

Using RSCs you are able to load initial data into your client components. To use mutation, you can use server actions. This feature is like a built-in RPC into React and the React meta-frameworks. You can call a server action using HTML form or button elements or by passing the server action as a reference to the client component and calling it like a normal async JavaScript function.

While with Next.js you have to use it's built-in file-based router named the App Router, when you're using @lazarv/react-server it's only up to you if you want to use the optional file-based router or you want to implement your application using another solution. If you still need the file-based router, both framework's solution for the router is very similar and if you used Next.js App Router, it will be easy to do the same using @lazarv/react-server-router. It's just optional. Both framework's routing solution supports middlewares and API routes.

Getting started

All frameworks provide a project creation command line tool for developers to help getting started with it. Next.js has npx create-next-app, Remix has npx create-remix, etc. All of these CLI tools create a new project, initializing files required to run your app using that framework and it's also installing required dependencies. These are mostly marketed as a 5min task. Which is fair. These tools are easy to use and it's really just a few minutes.

@lazarv/react-server is different. You don't need any tools to initialize your app. You just need @lazarv/react-server. After installing it as a dependency or just using npx to run the framework's CLI, you're done. It brings back the most simple developer experience ever: node server.js. You already have a JSX file with a component? Just run npx @lazarv/react-server ./App.jsx. You don't need to install React. It would be pointless and Next.js is also including it's own specific version of React as for all React 19 and experimental React features to work properly, you need a specific version of React. @lazarv/react-server installs it's own React too. So running your first app with @lazarv/react-server takes a few seconds. Nothing more. But infinitely expandable.

Some numbers

Next.js can be slow. This might not feels that much until you experienced something better and @lazarv/react-server wins by a lot in this. You can experience the same when you migrated your old Create React App project to Vite.

Our benchmark app might feel weak as it's only the most simple React app possible, but measuring the difference even in this most minimal use case means that Next.js will always lag behind because it's heavy-weight architecture. This is not achieved by using a faster bundler, only with a more suiting architecture.

Our tiny app looks like this:

export default function Page() {
  return (
    <html lang="en">
      <body>
        <h1>Hello World!</h1>
      </body>
    </html>
  );
}

For Next.js a mock layout file also needs to be created, just rendering children and doing nothing else.

The results seem devastating:

	Next.js	`@lazarv/react-server`
startup	~800ms	~150ms
compiling	~600ms	N/A
page load	~150ms	~30ms
build	~3.5s	~200ms
start	~100ms	~100ms
rps	~9k	~21k

Using the cluster mode available for the production runtime of @lazarv/react-server you can achieve even more blazing-fast performance even without caching. Using an 8 core M3 Macbook Air it's hitting a whopping ~50k requests per second using all the available CPU cores, so running 8 workers!

Results

Let's get a look on each type of result and the reason behind the numbers!

startup

This is the startup time for the development server. Next.js startup is more than 4x. Next.js is much more heavy and core codebase of Next.js is way too much for an app like this, while @lazarv/react-server is a light-weight server with being a wrapper around Vite and React where no unnecessary code is run on startup.

compiling

Next.js needs to create a bundle for your app. But using Vite, @lazarv/react-server eliminates this part by not creating any bundle during development. The underlying bundler in case of Vite doesn't need to collect and compile a bundle before you could use your app. This is an essential architectural choice with Vite. Learn more about this at Why Vite?.

page load

Next.js loads roughly twice as much client side code when running your app and the client-side router is much more complex. Performance for page load is about 5x with @lazarv/react-server.

build

When you are finished implementing your app and ready to deploy it to somewhere, you need to build your app for production use. Again, Next.js is lagging behind. Even when using a powerhouse developer machine, it takes seconds to build your Next.js app for production! While the Rollup based build in @lazarv/react-server is just a blink of an eye compared to the Next.js build. The difference is most prominent in this case between the two frameworks. @lazarv/react-server wins by a whopping 18x performance gain!

start

This is the startup time for the production server of the framework and also the only category which the frameworks are getting a tie.

Conclusion

Do you really need to work with Next.js all the time and in all use case? Surely not. Next.js might be still excellent and awesome for a ton of apps. But there are also way to many apps that are using Next.js even when they should not. By using @lazarv/react-server developers don't need to use a heavier framework like Next.js when the app is not needing all features or you will run your app on your own. When you would use Vite for a single page application, but might be a bit jealous on the SSR niceties React 19 provides.

My story creating a new React meta-framework

Viktor Lázár — Mon, 10 Jun 2024 22:20:51 +0000

I have a great idea for a new hobby project! As I am a React developer, I'll use it again for implementing this project, that's an easy choice. I use Next.js at work. It's fine, but there are some pain points in using it, so I don't want to go with it for my own project. I struggle with it during work, so why should I struggle in my spare time. I want to have some fun!

I love Vite! When I used Vite for a React SPA app, with React Router and react-query, I liked it a lot! It was blazing-fast! No need to wait for any Webpack bundling, just using ES modules, it was heavenly. I started to use Vite when I started experimenting with streaming server-side rendering using React Suspense. I also created a micro-frontend system based on Vite and a self-hosted fork of esm.sh instead of Module Federation, but that's another story.

But this Vite setup I had for an SPA didn't work for server-side rendering as I wanted it to. Should I use Remix then? Remix now supports Vite! Though choice. I like some parts of Next.js since Next.js 13. More precisely, I like the new React server-side rendering features a lot. React Server Components are awesome! To have complete control over the React hydration and which parts of the rendering is server vs client is great. Using server actions with Next.js is also fantastic! I like how much this new way is close to traditional web development. I like that links and forms are driving navigation, mutation and that state management is shared between the client and the server using standard solutions, like search params and RESTish routing, even some cookies if needed. Web development is again so much easier and fun this way. But I don't want to have all the caching problems of Next.js. I don't want bundles and waiting. So what should I use again? Remix is not supporting these. What about Astro? I like Astro, I would possibly use it for a more content driven project, but this time, it's not my best choice. I only want to use pure React. I heard there's a new minimal React framework, Waku. I want to have even less setup than that!

To summarize, what will I need or want to use for this project?

Vite
server-side rendering
React Server Components
client components
server actions
full access to the HTTP context
a minimal setup, no boilerplate
fast dev server, build and deploy

Is there a framework like that? No. I worked on some libraries and frameworks in the past, like JayData or odata-v4-server, so if I would create a new React framework with the requirements I have, how should it be done? That's a though question as there's no documentation for these React features yet, just some tests in the React repo and while Next.js is open source, the codebase is huge! I love to experiment with un-documented tech, I loved when I learned the intricacies of the unknown and then tweaking it to the max to create an awesome, jaw-dropping experience, like porting Wolfenstein 3D to the web from scratch, directly porting some C/C++ code to JavaScript while learning a lot or using WebAssembly to create a DOOM web runtime environment to play any WAD files from DOOM I or II, even other DOOM-engine games like Heretic. I loved re-engineering these retro games to make them playable in the browser or on my phone or tablet. I also started to make a dive and started messing around with the Elder Scrolls series to remake it in the browser! It was so much fun! So, without any hesitance, I started to create some proof of concepts.

RSC is easy. You just need to call renderToReadableStream and send it to the browser. But what about hydration and client components? Now that's a challenge! You need to render your React tree to the RSC payload in a thread with "react-server" module resolution conditions. This payload will include all the static HTML nodes and references to client components and server actions. To render client components properly, you need to have a snapshot. That's the RSC payload, with the static HTML nodes. Then, you need to get a new React tree from this. To get that, you need to use createFromReadbaleStream to transform your RSC stream to a React tree, then use a different type of renderToReadableStream, but this time not using the react-server-dom-webpack package, but react-dom. While doing this, you need to send your RSC payload in parallel with the HTML content to hydrate your React application on the client as you stream the server-side rendered content. You also need to have all the references ready to tag client components with the react.client.reference symbol and if you also want server actions, then with the react.server.reference symbol. So you need to transform your files differently for multiple environments during rendering and you also need to manage all the module resolution for these. Take this with all the workarounds you need to do to make this work with Vite. So after creating some Vite transform plugins and dealing with the complex rendering (not just a simple renderToString like in the old days), you're good to go, right?

A framework is much more, than making some proof of concept work. It's much more, than achieving something in a sandbox. It's very similar to game development or it's very similar to me, to my own game development experience as I always worked on some rendering engine for games and not as a game designer or creating content for a new game (with some tiny exceptions). After you finish with the gameplay, you need to start building all the other parts, like menus, configuration management, etc. A framework is not just a rendering engine and some core functionality. It has to provide some great developer experience. I had this partially because of Vite. If I would not have Vite, my job would have been much harder. But I had an idea. A vision.

When I experienced node.js the first time, I was amazed. I already worked as a frontend engineer, so node.js for me was a gate to another world, to another dimension. I was able to use all my expertise with JavaScript on the backend. I worked a little bit at this point with other backend solutions, like PHP or ASP.NET. But despite it's quirks, I loved JavaScript (I know, I know...). So node.js was the best thing to continue with. What made node.js awesome? node server.js. If you had a JavaScript file with any size, be it a tiny script or a large backend for a complex architecture, in the end it's just running a simple node command to start your server.

react-server ./App.jsx. I wanted to have this. So badly! All the frameworks are handling your entrypoint differently. Next.js is enforcing it's own file-based routing. It's so much more opinionated compared to React. Remix has a long setup to follow. I just wanted an App.jsx and a CLI tool to run it as my entrypoint, taking away all the project setup work that every project needs at the start.

I imagined this "Get started" (I also love pnpm btw):

pnpm add @lazarv/react-server
pnpm exec react-server ./App.jsx

No need for anything else. Simple as that. Not even a configuration file. Not even installing React directly! Just running the Vite development server, like I would do it for an SPA using npx vite with an index.html in place. I was amazed by a Vite demo Evan You did more than 2 years ago. It was minimal. It was elegant. It was awesome! I wanted to have the simplicity of node.js and Vite, just for React.

I also have to mention a very important presentation. It changed how I look on RSCs and the new way of React server-side rendering. It was Dan Abramov’s RemixConf 2023 presentation titled: “React from Another Dimension”. If you haven’t watched it yet, do it. RSC clicked for me watching it! Also the title was great as I listen to Liquid Tension Experiment a lot! :)

My hobby project grew out of it’s cooking pot. Maybe it’s some sort of megalomania. But I always lose some scope as I dream big. In all my works, I have a much larger target in the end than at the start of that project. But if I’m committed to that project, I will finish and achieve my vision no matter what.

If you share the same view on frameworks like me, you can get my experience. Just head over to https://github.com/lazarv/react-server and give as much feedback as possible. I also sort of completed my hobby project. But not the original one. I used my own framework to create the documentation site for it. Check it out at https://react-server.dev. I hope you will also have fun trying it out!

Todo app with no client-side JavaScript using @lazarv/react-server

Viktor Lázár — Mon, 27 May 2024 17:02:41 +0000

Everyone starts with a simple Todo app when evaluating a new framework. So let’s do it this time using @lazarv/react-server, a new minimalist React meta-framework using Vite!

Our goal with this example is to use no client-side JavaScript and no React hydration. We only want to use React Server Components and Server Actions. Is this possible? Absolutely!

Project setup

Let’s create a new project, by creating a new folder, initializing pnpm and installing all the required dependencies.

mkdir todo
cd todo
pnpm init
pnpm config set auto-install-peers true --location project
pnpm add @lazarv/react-server better-sqlite3 zod
pnpm add -D @types/better-sqlite3 @types/react @types/react-dom autoprefixer postcss tailwindcss typescript
pnpx tailwindcss init -p

To store our Todo items, we will use a local Sqlite database. For validation, we will use Zod and for styling we will use Tailwind CSS. To include all our source code as Tailwind content, change the tailwind.config.js to this:

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./src/**/*.tsx"],
  theme: {
    extend: {},
  },
  plugins: [],
};

As we will not do any exciting Tailwind styling, put the usual 3-liner Tailwind setup into src/index.css:

@tailwind base;
@tailwind components;
@tailwind utilities;

Hello World!

Well it’s nothing better than a good old “Hello World!” app, so let’s create an entrypoint for our Todo app! Put the following code into src/index.tsx:

export default function Index() {
  return (
      <h1>Hello World!</h1>
  );
}

To run this micro-app, you can just use pnpm exec react-server ./src/index.tsx . To make our life easier, let’s add some npm scripts to package.json:

"scripts": {
  "dev": "react-server ./src/index.tsx",
  "build": "react-server build ./src/index.tsx",
  "start": "react-server start"
},

After doing this, use pnpm dev to start the development server. After our development server is running, open http://localhost:3000 and be proud of our Hello World! app. You can also use pnpm dev --open to do so.

Layout

Our Todo app needs a layout, so let’s create src/Layout.tsx:

export default function Layout({ children }: React.PropsWithChildren) {
  return (
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Todo</title>
      </head>
      <body>
        <div className="p-4">
          <h1 className="text-4xl font-bold mb-4">
            <a href="/">Todo</a>
          </h1>
          {children}
        </div>
      </body>
    </html>
  );
}

Nothing fancy here, just a usual HTML document template. We will use this Layout component as a wrapper for our app.

Page

Our main page will be the Todo app, where we will use all of the building blocks to create our app. Let’s say goodbye to Hello World! and change the component to this:

import "./index.css";

import { allTodos } from "./actions";
import AddTodo from "./AddTodo";
import Item from "./Item";
import Layout from "./Layout";

export default function Index() {
  const todos = allTodos();

  return (
    <Layout>
      <AddTodo />
      {todos.length === 0 && <p className="text-gray-500">No todos yet!</p>}
      {todos.map((todo) => (
        <Item key={todo.id} title={todo.title} id={todo.id} />
      ))}
    </Layout>
  );
}

In this React Server Component, we collect all the stored Todo items by calling allTodos() and use the result to render JSX. We use the Layout component to wrap our content into a HTML document.

Item

To render our items, let’s create an Item component in src/Item.tsx:

import { deleteTodo } from "./actions";

type Props = {
  id: number;
  title: string;
};
export default function Item({ id, title }: Props) {
  return (
    <div className="flex row items-center justify-between py-1 px-4 my-1 rounded-lg text-lg border bg-gray-100 text-gray-600 mb-2">
      <p className="flex-1">{title}</p>
      <form action={deleteTodo}>
        <input type="hidden" name="id" value={id} />
        <button className="font-medium">Delete</button>
      </form>
    </div>
  );
}

The Item component will render our Todo item using an id and title prop. But what about that <form action={deleteTodo}>? It’s a server action! When the user will submit the form by clicking on the “Delete” button, the browser will call our server action. This is possible without any JavaScript on the frontend, as React supports progressive enhancement for server actions and the initial form action will call the server action by including a hidden input field in the form:

<input type="hidden" name="$ACTION_ID_/Users/lazarv/Projects/tutorials/todo/src/actions.ts#deleteTodo">

The framework will resolve this $ACTION_ID_ prefixed path to the server action and it will call our server action function!

Server actions

We will use server actions to implement all functionality of our Todo app. This is the most complex part of the app, but don’t shy away, it’s still really very simple, let’s create src/actions.ts:

"use server";

import { redirect } from "@lazarv/react-server";
import Database from "better-sqlite3";
import * as zod from "zod";

const db = new Database("db.sqlite");
db.exec(
  "CREATE TABLE IF NOT EXISTS todos (id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT)"
);

type Todo = {
  id: number;
  title: string;
};

const addTodoSchema = zod.object({
  title: zod
    .string()
    .min(3, "Title must be at least 3 characters")
    .max(100, "Title must be at most 100 characters")
    .refine((value) => value.length > 0, "Title is required")
    .transform((value) => value.trim()),
});

const deleteTodoSchema = zod.object({
  id: zod.string().transform((value) => parseInt(value.trim(), 10)),
});

export async function addTodo(formData: FormData) {
  const result = addTodoSchema.safeParse(Object.fromEntries(formData));

  if (!result.success) {
    throw result.error.issues;
  }

  const { title } = result.data;
  db.prepare("INSERT INTO todos(title) VALUES (?)").run(title);
  redirect("/");
}

export function allTodos() {
  return db.prepare("SELECT * FROM todos").all() as Todo[];
}

export async function deleteTodo(formData: FormData) {
  const result = deleteTodoSchema.safeParse(Object.fromEntries(formData));

  if (!result.success) {
    throw result.error.issues;
  }

  const { id } = result.data;
  db.prepare("DELETE FROM todos WHERE id = ?").run(id);
  redirect("/");
}

In the first line of this file, we instrument the framework to treat this file as a server action module using the “use server”; directive. All exported async functions will be available for us to use as server actions.

We initialize the Sqlite database on module import and create Zod schemas for item add and delete operations.

In all server actions, you will receive a FormData instance, including all the fields we define in the forms. We safeParse these after converting to JavaScript objects using Object.fromEntries.

If Zod validation fails, we throw the validation issues as an error.

On success, we run a database command to INSERT or DELETE the Todo item.

At the end, we are using redirect to navigate the user back from the server action call. This is needed as we don’t want the user to use a browser page refresh to create or delete the Todo item again, reusing the form submit.

We also implemented the allTodos function here, to have all the storage related code in a single file.

Add new item

To implement the AddTodo component, create an src/AddTodo.tsx file with the following content:

import { useActionState } from "@lazarv/react-server/router";
import type { ZodIssue } from "zod";

import { addTodo } from "./actions";

export default function AddTodo() {
  const { formData, error } = useActionState<
    typeof addTodo,
    string & Error & ZodIssue[]
  >(addTodo);

  return (
    <form action={addTodo} className="mb-4">
      <div className="mb-2">
        <input
          name="title"
          type="text"
          className="bg-gray-50 border border-gray-300 text-gray-900 rounded-lg p-2.5"
          defaultValue={formData?.get?.("title") as string}
          autoFocus
        />
      </div>
      <button
        className="text-white bg-blue-700 hover:bg-blue-800 rounded-lg px-5 py-2 mb-2 text-center"
        type="submit"
      >
        Submit
      </button>
      {error?.map?.(({ message }, i) => (
        <p
          key={i}
          className="bg-red-50 border rounded-lg border-red-500 text-red-500 p-2.5 mb-2"
        >
          {message}
        </p>
      )) ??
        (error && (
          <p className="bg-red-50 border rounded-lg border-red-500 text-red-500 p-2.5">
            {error}
          </p>
        ))}
    </form>
  );
}

We already know, how to use server actions from a <form>. But what about the result of our server action call? useActionState to the rescue!

By passing the addTodo server action function reference to useActionState , we can get the result of the server action call when this specific server action was called, so we can collect the error result. This will be the Zod error issues we thrown in the add server action. So we can iterate on all Zod validation issues here and render validation error messages on the server side.

Production build

During using the development server, you can notice that the page loaded some JavaScript modules in the browser. This is only used for Hot Module Replacement. In a production build, only the document and a CSS asset will be loaded in the browser.

To build for production, run pnpm build and then you can start the production server using pnpm start .

Final words

That’s it! We have a working small Todo example. You can also find the example on GitHub. By using the above approach, it will be easy for you to add a Todo item update feature, marking an item as completed. I hope you had fun and you will like the developer experience the @lazarv/react-server framework provides! There are a lot of other exciting features provided by React and the framework itself! We don’t used any client components here, that will be in another tutorial. The documentation site of @lazarv/react-server was created using the framework and it’s build and deployment to Vercel takes about 5s! Because the framework uses Vite, the developer experience is blazing-fast!

DEV Community: Viktor Lázár

The "use client" Tax

Where the tax comes from

The shape of the pain

The constraint is in the tool, not in the model

What this should look like

Why this should be a standard feature

The Forgotten Joy of `node app.js`

The scaffold tax

What we lost

The shape of the fix

One file in, one file out

And then AI showed up

Why this matters

The Two Joys of Coding Before AI

Two kinds of joy

What AI actually changes

Why the debate is so confused

What to do about it

The thing under the thing

RSC as a serializer, not a model

What the API is really for

If the goal is caching, name it caching

Boundary wrappers, protocol wrappers

The defensible version of the choice

What is actually being shipped

The agent reading the code

What gets lost

The smaller point

Project, Don't Embed: Introducing Virtual Frame

The one-paragraph version

Why this mental shift matters

How it actually works

A taste of code

What you actually get

What it isn't

When to reach for it

Where to go from here

The Illusion of Language: What Directives Really Are

Preface & Introduction — Why This Post Exists

A Personal Flashback

Why Do Directives Feel Like Language Features?

The Hidden Mechanism Makes It Worse

Add Build Tools… and the Illusion Solidifies

A Look Back: C/C++ Macros and the Preprocessor

The C Preprocessor Was Not the Language — But It Felt Like It

Pragmas: The Original “Framework Directives”

Include Guards: The First “Invisible Build-Time Behavior”

Multi-Stage Compilation: A Familiar Pipeline

Modern Directives Through the Lens of the Preprocessor Era

Directives Don’t Execute — They Instruct a Tool

Why the Illusion of a Language Feature Persists

But Modern Directives Go Further Than C Pragmas

Build Tools Are the Real Interpreter of Directives

The Educational Gap — and What We Can Learn From History

We Need to Teach the Layering — Not Just the Feature

What the C/C++ Community Eventually Learned

Directives Aren’t Bad — They’re Powerful, If Understood

A Simple Mental Model to Teach (Starting Tomorrow)

A Practical Step Toward Clarity: A TypeScript Plugin for Directives

Closing Reflection

Exploring an experimental Micro-Frontend Architecture with Server-Side Rendering using React Server Components

Table of Contents

What are Micro-Frontends?

How Does This Stack Up?

Introduction to React Server Components (RSC)

The Experimental Architecture: Combining Micro-Frontends with RSC

Challenges and Considerations

The Future of Micro-Frontends with RSC

Introducing @lazarv/react-server with RSC Delegation

Implementing the Experimental Micro-Frontend Architecture with @lazarv/react-server

Installing @lazarv/react-server

Creating the Hosting Application

Creating a Simple Micro-Frontend (MFE) Application

Using RemoteComponent to integrate the MFE Application into the Hosting Application

Update the Hosting Application to use RemoteComponent

Set up package.json scripts

In this setup:

Running the applications

Supporting Client Components in a Micro-Frontend Architecture

Introducing `@lazarv/react-server` with RSC Delegation

Implementing the Experimental Micro-Frontend Architecture with `@lazarv/react-server`

Installing `@lazarv/react-server`

Using `RemoteComponent` to integrate the MFE Application into the Hosting Application

Update the Hosting Application to use `RemoteComponent`

Set up `package.json` scripts

Using Server Actions with `@lazarv/react-server`

Update the `react-server.config.mjs` for SSG

Server Islands: loading MFE content using `ReactServerComponent`

Extend `package.json` scripts

Leveraging Native ES Modules with `@lazarv/react-server`