Forem: Viktor Lázár

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!

let vs const in JavaScript aka why don't you learn a bit of C?

Viktor Lázár — Wed, 08 May 2024 18:54:52 +0000

There's a raging war in the JavaScript community about when to use let or const and which one should not be used. Which is ridiculous. Some major JavaScript developers are blaming const as it’s not useful because you can still mutate the value in an object referenced by a const variable. Let’s get a deeper look on this and some background on from where we are coming from.

var

First, there was var. Before ES6 you used var only for variable declarations. But it was sometimes hard to understand what’s happening, because of hoisting. Hoisting means that basically all of your variable declarations are moved to the top of your scope, declaration position is ignored. So you can define your variable later in code and use your variable before declaration. Mind blowing, right? 🤯

x = 42;
console.log(x); // 42
var x;

The above example just works. Hoisting will move the var x; to the top and that’s how you can use the x variable anywhere in the scope. Although variable initialization is not working the same way, as only the variable declaration is hoisted, not the initialization. So the following will result in Nan.

x = x + 1;
console.log(x); // NaN
var x = 0;

This behaviour is surely hard to understand cognitively and hard to maintain. So we moved over with ES6 to use let and const.

let

The let keyword is easy to describe. You just need to forget about hoisting and it works the same way as var . You can re-assign any value to the variable at any point.

x = 42; // ReferenceError: Cannot access 'x' before initialization
console.log(x);
let x;

Because of let variable declarations are no longer hoisted, the above code will not work and will throw an error when you’re trying to use x before initialization.

let x = 0;
x = x + 1;
console.log(x); // 1

Here we re-assign a new value to x. Variable initialization set the value to x to be 0. Then we mutated the value of x and so we got 1 as a result on the console. Let’s continue to const!

const

ES6 also introduced the const keyword for variable declaration. This already seems to be off, as a constant is not a variable. But the definition of “variable” explains some parts already:

"A variable in programming languages is a named storage location in computer memory that holds a data value. It is characterized by an identifier, which uniquely identifies it within the program. Variables can represent various types of data, such as integers, floating-point numbers, characters, or complex data structures. The value stored in a variable can change during the execution of the program, hence the term 'variable.' Programmers use variables to store and manipulate data, enabling dynamic behavior and flexibility in their programs.”

So variables are basically just identifiers to a slot in memory. When you use var or let the JavaScript runtime engine will let you change the value of that slot in memory. But when you use const, you are instructing the JavaScript runtime engine to prevent any change of the variable, so you can’t update the memory identified by that variable.

const x = 0;
x = x + 1; // TypeError: Assignment to constant variable.
console.log(x);

You can only set the value to a const variable at initialization time. const variables are also not hoisted, the same way like let variables.

The “problem” with const…

is that if your const variable is a reference type, like an object, array or function, you can’t change the value of the variable, but you can mutate the value it’s referencing to.

const x = { a: 0 };
x.a = x.a + 1;
console.log(x.a); // 1

The above will perfectly work. But why? Is const not preventing mutation? It is! But only for the x variable. But why? Because x is a reference only to the object! With other maybe familiar words: it’s a pointer!

If we go back in time to the dark ages of programming, when developers used the “C” programming language to create awesome apps (most games of the ‘90s were developed by using C and Assembly), we can understand what’s happening here.

#include <stdio.h>

int main() {
    int num = 5;
    const int *ptr = &num; // Declaring a constant pointer to an integer

    printf("Initial value: %d\n", *ptr); // Output: Initial value: 5

    // Attempting to modify the value through the const pointer
    //*ptr = 10; // This line will result in a compilation error

    // However, we can still modify the underlying value using a non-const pointer
    int *mutablePtr = (int *)ptr;
    *mutablePtr = 10;

    printf("Modified value: %d\n", *ptr); // Output: Modified value: 10

    return 0;
}

In C, you need to cast the const pointer to be able to change it, but as the const variable is only an identifier to a slot in memory, when you convince the compiler you are allowed to change the memory identified by the variable, well, you can do it! It’s just memory!

#include <stdio.h>

// Define a struct
struct Point {
    int x;
    int y;
};

int main() {
    // Create an instance of struct Point
    struct Point point = {5, 10};

    // Declare a const pointer to a struct Point
    const struct Point *ptr = &point;

    printf("Initial values: (%d, %d)\n", ptr->x, ptr->y); // Output: Initial values: (5, 10)

    // Attempting to modify the values through the const pointer
    // ptr->x = 10; // This line will result in a compilation error

    // However, we can still modify the underlying values using a non-const pointer
    struct Point *mutablePtr = (struct Point *)ptr;
    mutablePtr->x = 10;
    mutablePtr->y = 20;

    printf("Modified values: (%d, %d)\n", ptr->x, ptr->y); // Output: Modified values: (10, 20)

    return 0;
}

This works for structs too, which is most close to what an object in JavaScript is. In JavaScript, your object represents a data structure in memory. As you are not specifying this object as non-mutable by using Object.freeze , you can mutate the values held in that object. Keep in mind, that nested objects are basically just pointers too and Object.freeze is only work for that single object you are freezing. For nested objects, you need to freeze every object used.

const x = Object.freeze({
    a: {
        b: 0
    }
});
x.a.b = 42;
console.log(x.a.b); // 42

The above will just work, but when you change the code to this:

const x = Object.freeze({
    a: Object.freeze({
        b: 0
    })
});
x.a.b = 42;
console.log(x.a.b); // 0

You will get back the same value as before, x.a.b will be 0. I admit, that this is still not the same as using a primitive const variable as the above will not throw an error, it just silently doesn't change the value of x.a.b.

So in case of a JavaScript const variable, you can’t change the pointer / reference, but you change the underlying memory. It is a false assumption, that the const specifier will affect the referenced object too. Why would it?

Cognitive load

What’s the role of let when you want immutability all the time? Marking and flagging all involved parties that you want to change the value of the variable at some point in your code! This doesn’t mean that it has to be another developer, it can be a static analysis tool or AI, anyone or anything that can understand code.

During code reviews let will help the reviewer to take special care about handling the variable. When I encounter such a case I instantly switch into questioning the authors code, why there’s a let variable. Is there any reason to use let? At any point is the value mutated? Why is it mutated?

Conclusion

As every language feature, let and const are just tools the developer can use. No one is forced to use const. It is not necessary to do so. But it provides values and by not using it, you miss those values.

What’s the value in saving 2 characters? Time? Code completion and any type of artificial help in typing in the variable definition makes this obsolete. Size of the bundle used? 2kb, maybe 20k in case of a very large library? While we are watching billions of videos online?

It would be better to review over-engineered and unnecessary architectures or tech stacks we use, than complaining about using const.

A new experimental meta-framework for React

Viktor Lázár — Thu, 28 Sep 2023 15:34:21 +0000

I was following the new React server-side rendering features for years now, since React 18. Everything started with using streaming and <Suspense> for rendering the document for the user. I had experiments in the past using React 18 streaming rendering using vite-plugin-ssr. Then came Next.js 13 and React Server Components were unleashed. But it didn't stop there. Server Actions! What awesome features these are from the React team!

A new and better PHP

It's fashionable to say that PHP is bad. But reality is that it's not and it will not die in the foreseeable future. But what's the issue with PHP? Switching language and context when you need something to work in the browser! There are a myriad of ways to handle the issue. But can you imagine a solution, where you get all the benefits of PHP AND you can create components which are running only in the browser in an instant? We are mostly talking about React Server Components, but the star of the show for me is mixing server and client components in the same React tree and it magically works!

Your BFF!

Another hot topic in web development is tRPC, which is a fantastic tool. But for a backend-for-frontend API, it's a bit of an overkill. Instead of creating the setup for tRPC and using its client, wouldn't be better to just use your functions as references and pass them to the browser, to be called as a <form>'s action or just programmatically from your client components? Deal done, this is Server Actions!

The first implementation of these React features were done by Next.js. Not surprising as these teams are working in close collaboration. But what to do if you're not fully satisfied with Next.js? What are your options?

In the past few months, I eagerly dived-in into this topic and the result is @lazarv/react-server, my own new experimental React meta-framework.

In search of flexibility

I very much like React's approach on how un-opinionated it is and supporting the "bring-your-own" mindset for your app. Next.js was always too rigid for me, so I wanted to see something configurable to the last bit possible.

I wanted to use the following 2 major tech with these new React features: ES modules and Vite.

For a long time now, I'm a huge advocate of ES modules. It's almost a shame that CommonJS is still here, despite the effort people are putting into using ES modules wherever possible. ES modules are supported by all browsers natively and fits for client components so well.

Vite is providing the best developer experience so much, that almost everyone is using it now. Astro, Nuxt, SolidStart, SvelteKit to mention just a few. Vite is highly customisable and extensible by using plugins. My first encounter with Vite was when I implemented my first streaming React SSR using vite-plugin-ssr and I always use it since then whenever possible. Vite and ES modules are best friends as Vite makes working with ES modules an ease.

Getting started

Do you ever dreamed about using a server-side rendering framework easy as a simple node.js script? With @lazarv/react-server, it's possible.

Let's setup the environment for our first app! We will use pnpm as it's the best and fastest package manager for node.js.

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

Now believe it or not, we're ready to implement our app. Just create a new entrypoint for the app in ./App.jsx or choose a name you like.

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

Now you're ready to start this app using @lazarv/react-server!

pnpm exec react-server ./App.jsx

This almost feels like using node ./App.jsx, doesn't it? The framework has so many features it would be hard to include everything right away, so stay tuned for more! Check out the repo in the meanwhile and try to run the examples in the repo. You can start the Photos example as simple as:

git clone https://github.com/lazarv/react-server
cd react-server
pnpm install
pnpm --filter ./examples/photos dev

Future of `@lazarv/react-server`

As this is only a personal experimental framework, I would only suggest to give it a go, but only use this for your own learning about the future of React. Which is still bright and awesome!

Please provide feedback on GitHub, here in dev.to or on Twitter/X. Every feedback is much appreciated and adds value to this project. Thanks!

I'll work on documentation and bug fixes for now, so please be patient and give the repo a star on GitHub to get notified on what's happening with this framework.

Maybe this will grow into something more.

Much more...

React Server Components without any frameworks

Viktor Lázár — Fri, 07 Jul 2023 15:21:00 +0000

Starting with Next.js 13 developers can access the power of React Server Components (let's just use RSC from now on). But if you don't want to use Next.js and you want to start to use RSC out of the box, then how should you start?

Dependencies

You need to use the experimental versions of react, react-dom and react-server-dom-webpack.

Let's start up a new project and install these. We will use pnpm, as it is now the best and most loved choice. Also for quick setup, we will use Vite for the client side and HatTip for our backend handler for more convenient readable stream handling.

mkdir hello-rsc
cd hello-rsc
pnpm init
pnpm add react@experimental react-dom@experimental react-server-dom-webpack@experimental vite @vitejs/plugin-react @hattip/core @hattip/adapter-node

Implementation

To start to work with SSR rendering with Vite, we need to create some files to get started with.

SSR

We will need an index.html file, which will be our SSR HTML template, which will load the client entry script. This is very-very minimal.

<script type="module" src="index.jsx"></script>
<div id="root"></div>

To start our SSR enabled Vite development server, let's create an index.mjs file, where we will instantiate a Vite development server in middleware mode and with "ssr" as application type.

import { createMiddleware } from "@hattip/adapter-node";
import { createServer as createViteDevServer } from "vite";
import react from "@vitejs/plugin-react";
import { readFile } from "node:fs/promises";

const viteDevServer = await createViteDevServer({
  server: {
    middlewareMode: true,
  },
  appType: "ssr",
  plugins: [react()],
});

We need to preload our index.html for later usage. So let's read up the file as it is.

const html = await readFile("./index.html", "utf-8");

The following HatTip handler will be our router to handle requests which accepts an RSC response. If the Accept header includes the text/x-component MIME type, then we know that the client needs the response in RSC format.

The RSC format is a JSON-like format which includes all the React elements the client will render.

0:"$L1"
1:[["$","h1",null,{"children":"Hello World!"}],["$","h2",null,{"children":["Darwin"," ","x64"," ","22.5.0"]}],"2023-07-07T12:40:30.880Z"]

Our implementation loads the rsc.jsx SSR module using Vite and uses the render function which will render the RSC into a readable stream. We also do some basic error handling.

const ssr = createMiddleware(async ({ request }) => {
  if (request.headers.get("accept").includes("text/x-component")) {
    try {
      const { render } = await viteDevServer.ssrLoadModule("./rsc.jsx");
      return new Response(await render(), {
        headers: {
          "content-type": "text/x-component",
        },
      });
    } catch (e) {
      return new Response(e.stack, {
        status: 500,
        headers: {
          "content-type": "text/plain",
        },
      });
    }
  }
  return new Response(
    await viteDevServer.transformIndexHtml(request.url, html),
    {
      headers: {
        "content-type": "text/html",
      },
    }
  );
});

At the end of this, we only need to start listening to requests using the Vite development server. As the

viteDevServer.middlewares.use(ssr);
viteDevServer.middlewares.listen(3000).on("listening", () => {
  console.log("Listening on http://localhost:3000");
});

React Server Component

How the rsc.jsx looks like? It's really very simple. The main imported module we need to watch out for is the react-server-dom-webpack/server.edge. Our <App /> component is an async function, so we can use await inside of it and at the end, just return JSX where we can also include server-side only functionality, so we give the client information about our OS and the current time. But first, we delay the response for a bit.

import { renderToReadableStream } from "react-server-dom-webpack/server.edge";
import * as OS from "node:os";

async function delay(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function App() {
  await delay(500);
  return (
    <>
      <h1>Hello World!</h1>
      <h2>
        {OS.type()} {OS.arch()} {OS.release()}
      </h2>
      {new Date().toISOString()}
    </>
  );
}

export async function render() {
  return renderToReadableStream(<App />);
}

The exported render function is the one we used in the index.mjs handler, loaded with Vite as an SSR module.

Client

The last part we need to implement is our client entry, where we create our React root to render the RSC response.

import { Suspense } from "react";
import { createRoot } from "react-dom/client";
import { createFromFetch } from "react-server-dom-webpack/client.browser";

let rsc = null;
function App() {
  if (!rsc) {
    rsc = createFromFetch(
      fetch("/app", {
        headers: {
          Accept: "text/x-component",
        },
      })
    );
  }

  return rsc;
}

const root = createRoot(document.getElementById("root"));
root.render(
  <Suspense fallback="Loading...">
    <App />
  </Suspense>
);

We need to add a Suspense around our <App /> component so it will show a fallback loading message while the client receives the RSC response.

We also need to "cache" the result of createFromFetch as we don't want this to be fired more than once and it always should be the same, so React can handle the <App /> component properly.

Future enhancement

Currently, our RSC rendering is not supporting client components ('use client'), only server-side rendered elements. We also don't support server actions in this implementation. These are much more advanced topics and you should use Next.js 13 for this or another meta-framework supporting these features.

Summary

Surely, this is only a "Hello World!" level implementation and could be enhanced, but maybe this is a good starting point when you want to start playing with some low-level implementation regarding React Server Components.

You can access the code at this repo

Thanks for reading, please click on follow and have a nice day!

Forem: Viktor Lázár

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

Creating a new MFE application with a counter

Integrate the Counter MFE Application into the Hosting Application

What is an Import Map?

Import map definition

Implementing Server Actions in a Micro-Frontend Architecture

Using Server Actions with @lazarv/react-server

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

Integrate the server action driven MFE into the Hosting Application

Using Static Site Generation in a Micro-Frontend Architecture

Update the react-server.config.mjs for SSG

Build the Micro-Frontend and Hosting Applications for production

Preparing the import map for production use

Execute the production build

Start the production server

Expanding Static Site Generation Beyond Micro-Frontends

Server Islands: loading MFE content using ReactServerComponent

Create a new MFE application with Suspense

Extend package.json scripts

Add the streaming MFE Application to the Hosting Application

Shared State Management in a Micro-Frontend Architecture

Backend State Management

Client-Side Cross-App State Management

Combining Backend and Client-Side State Management

Leveraging Native ES Modules with @lazarv/react-server

How Native ES Modules Simplify Micro-Frontend Architecture

Final thoughts

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

Introduction

The Power of Complexity in Technology

1. The Consultancy Boom: Turning Complexity into Profit

2. Education and Training: A Growing Industry

3. Content Creation: Complexity as a Content Goldmine

4. Job Market Dynamics: Complexity as a Career Booster

5. Corporate Strategy: Leveraging Complexity for Competitive Advantage

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

Conclusion

Migrating a Vite + React app to use React Server Components

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`

Future of `@lazarv/react-server`