DEV Community: Michael Lin

React Compiler and Beyond: Capability Boundaries of Compiler-Driven UI Frameworks

Michael Lin — Wed, 04 Mar 2026 18:01:09 +0000

Bottom line first: React Compiler is a major step forward, but it optimizes React's expression and render costs within React's runtime contract.

Compiler-first fine-grained frameworks like Fict pursue a different objective: move more update routing to compile time, then execute updates through dependency propagation at runtime.

This is not a winner-takes-all debate. It is an engineering trade-off across different objective functions.

Fict Repo: https://github.com/fictjs/fict

0. Scope and Rigor

To avoid slogan-level comparisons, this article uses strict boundaries:

It compares two technical routes:
- React + React Compiler (preserving React semantics)
- Compiler-first fine-grained (using Fict as the concrete example)
It separates three layers:
- Developer experience (mental overhead and ergonomics)
- Performance model (update path and cost structure)
- Semantic constraints (effects, lifecycle, error handling, consistency)
Claims about Fict are grounded in this repository's implementation and docs, not idealized marketing descriptions.

1. What React Compiler Actually Solves

React Compiler does not "replace React." It improves React's default performance posture by:

Inferring dependency boundaries so developers write less manual useMemo and useCallback.
Reusing expressions and JSX subtrees more aggressively.
Raising performance floor while preserving the React programming model.

A conceptual sketch:

function ProductList({ products, filter, onSelect }) {
  const cache = getCompilerCache()

  const filtered = cache.memo('filtered', [products, filter], () =>
    products.filter(p => p.category === filter),
  )

  const handleClick = cache.memo('handleClick', [onSelect], () => id => onSelect(id))

  return cache.memo('listJSX', [filtered, handleClick], () => (
    <ul>
      {filtered.map(p => (
        <ProductItem key={p.id} product={p} onClick={handleClick} />
      ))}
    </ul>
  ))
}

Key point: this is stronger automatic memoization inside React semantics, not a replacement of Fiber/Hook contracts.

2. What React Compiler Does Not Redefine

A precise statement:

React Compiler can remove substantial redundant compute and subtree work.
It does not redefine React into a signal-driven DOM execution engine.

Why:

React's core abstraction is still component-tree scheduling and commit semantics.
Compiler optimizations must remain inside React boundaries: hook ordering, effect timing, concurrent scheduling, error boundary behavior.
Therefore it optimizes "how much work React does," not "what React fundamentally is."

Practical implications:

React updates are not always full-tree reruns due to bailouts and memoized outputs.
But the dominant scheduling unit remains component/subtree semantics, not explicit signal graph nodes.
React.memo with children is not inherently useless:
- It often fails if children are recreated each render.
- It can work when references are stabilized by caller patterns or compiler transforms.

3. What Fict Changes (Based on Current Repository)

Fict's route is compiler-first fine-grained reactivity: compile dependency relationships, then propagate updates through runtime graph nodes.

This is visible in the current codebase:

Macro contract:
- $state and $effect are compile-time macros and throw if executed at runtime (packages/fict/src/index.ts).
Compile-time placement constraints:
- Macro placement is validated; loops/conditionals/nested contexts are restricted according to compiler rules (packages/compiler/src/index.ts, docs/compiler-spec.md).
IR and lowering pipeline:
- HIR build, optimization, and lowering stages exist in packages/compiler/src/ir/*.
Runtime graph model:
- Signal/computed/effect propagation is implemented in packages/runtime/src/signal.ts.
Local list reconciliation still exists:
- Fict avoids whole-tree VDOM diffing, but keyed local reconciliation is implemented (packages/runtime/src/reconcile.ts, packages/runtime/src/list-helpers.ts).
Fail-closed guarantee mode is explicit:
- FICT_STRICT_GUARANTEE=1 enforces strict diagnostics in CI (docs/reactivity-guarantee-matrix.md).

This corrects two frequent misconceptions:

"Fict has no reconciliation at all." Not true. It avoids whole-tree VDOM diffing; it still reconciles local keyed list paths.
"Fict is only syntax sugar over existing runtimes." Not true. It has a dedicated compile-time dataflow and lowering pipeline with a distinct runtime execution model.

4. Cost Model: Same Interaction, Different Work Units

Use a searchable list as an example:

// React + Compiler (conceptual)
function SearchList({ items }) {
  const [query, setQuery] = useState('')
  const [sortBy, setSortBy] = useState('name')

  const filtered = items.filter(item => item.name.toLowerCase().includes(query.toLowerCase()))
  const sorted = [...filtered].sort((a, b) => a[sortBy].localeCompare(b[sortBy]))

  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      <select value={sortBy} onChange={e => setSortBy(e.target.value)}>
        <option value="name">Name</option>
        <option value="date">Date</option>
      </select>
      <p>{sorted.length} results</p>
      <ul>
        {sorted.map(item => (
          <li key={item.id}>{item.name}</li>
        ))}
      </ul>
    </div>
  )
}

// Fict (conceptual)
function SearchList({ items }) {
  let query = $state('')
  let sortBy = $state('name')

  const filtered = items.filter(item => item.name.toLowerCase().includes(query.toLowerCase()))
  const sorted = [...filtered].sort((a, b) => a[sortBy].localeCompare(b[sortBy]))

  return (
    <div>
      <input value={query} onInput={e => (query = e.target.value)} />
      <select value={sortBy} onChange={e => (sortBy = e.target.value)}>
        <option value="name">Name</option>
        <option value="date">Date</option>
      </select>
      <p>{sorted.length} results</p>
      <ul>
        {sorted.map(item => (
          <li key={item.id}>{item.name}</li>
        ))}
      </ul>
    </div>
  )
}

Conceptual complexity comparison:

React path:
- O(rendered-subtree + diff-subtree + patch), reduced by compiler/bailouts.
Fict path:
- O(changed-sources + affected-computed/effects + affected-bindings + local-list-reconcile).

The correct conclusion is not "always faster/slower":

Fine-grained tends to win when changes are local, dependency graph is sparse, and list size is large.
React Compiler is often sufficient when bottlenecks are I/O dominated or UI compute is moderate.

5. Semantic Trade-offs (The Part People Skip)

Performance-only comparisons are incomplete. Semantic behavior determines production risk.

5.1 Effects Are Not Mechanical One-to-One Replacements

useEffect and $effect are not drop-in equivalents:

Fict $effect is compiler-constrained and analyzed in a macro-based model.
Dependency collection semantics differ from React dependency-array workflows.
Less manual dependency bookkeeping reduces a class of developer mistakes, but correctness partially shifts toward compiler analyzability and guarantee coverage.

5.2 Control Flow and Dynamic Shapes Need Explicit Validation

High-risk migration areas:

Effect cleanup timing under control-flow branch switching.
Closure reads in event chains and async callbacks.
Cancellation/race handling in async flows.
List identity behavior under unstable key quality.

5.3 "No Free Ecosystem Inheritance"

React's long-lived advantages are structural:

Ecosystem breadth and battle-tested framework integrations.
Mature concurrent scheduling and tooling culture.
Broad operational knowledge in teams.

Compiler-first routes must independently harden:

DevTools observability
SSR/Hydration/Resume stability
Error boundary and suspense consistency
Third-party integration contracts

6. Side-by-Side Decision Matrix

Dimension	React + Compiler	Fict / Compiler-First Fine-Grained
Primary objective	Reduce React performance tuning overhead	Lower runtime update upper bound
Core mechanism	Automatic memoization + bailouts	Compile-time dependency graph + runtime propagation
Dominant update unit	Component/subtree scheduling	Source/computed/binding-level propagation
List behavior	Reconciliation in React tree semantics	Local keyed reconciliation
Migration cost	Low to medium (keep React mental model)	Medium to high (compiler constraints + semantic verification)
Main risk	Performance predictability tied to component structure	Semantic edge cases and compiler coverage boundaries

Important framing: this is objective-function selection, not a "modernity contest."

7. What a Defensible Technical Article Must Include

If the goal is engineering evidence rather than opinion, include at least:

Public benchmark method:
- Dataset, warm/cold separation, hardware/software baselines.
Metric decomposition:
- Render/commit timing, DOM mutations, GC, memory peak.
Counterexample sets:
- Cases where React is better; cases where fine-grained is better.
Semantic equivalence tests:
- Cleanup, error boundaries, async races, fallback paths.
Migration cost quantification:
- Changed LOC, defect categories, regression count, fix lead time.

Without this, conclusions remain high-quality perspective, not reproducible engineering claims.

8. Reproducible Evaluation Appendix

Use repository-native commands only.

Environment baseline:
- Node >=20
- pnpm >=9
- OS/CPU/RAM
- Browser version (for benchmark runs)
Repository health:

pnpm install
pnpm build
pnpm test
pnpm typecheck
pnpm lint

Strict guarantee gate:

FICT_STRICT_GUARANTEE=1 pnpm build

Framework benchmark flow:

pnpm perf:data
pnpm perf:results

Runtime stress:

pnpm stress:runtime
pnpm stress:runtime:long

Compiler optimization regression guard:

pnpm bench:optimizer:guard

Reporting minimums:
- Scenario and data scale (N, update rate, list size)
- Median + IQR from at least 5 runs
- Error logs and failure sample links

9. Migration Readiness Checklist

Before adopting a compiler-first route, verify:

You are solving a front-end CPU update bottleneck, not primarily network/back-end latency.
You can run strict guarantee mode in CI (FICT_STRICT_GUARANTEE=1).
You have semantic regression coverage for effects, async races, and error boundaries.
Team conventions can absorb macro constraints and compile-time diagnostics.
You have a rollback strategy for fallback-path regressions.

When to prefer React + Compiler first:

Large existing React codebase with narrow migration window.
Heavy dependency on mainstream React ecosystem/runtime assumptions.
Performance gains needed are incremental, not architectural.

When Fict-like route is justified:

CPU update path is a top product bottleneck.
Large/interactive local updates dominate user experience.
Team is willing to trade some migration complexity for lower runtime update ceiling.

10. Final Conclusion

React Compiler matters because it turns performance tuning expertise into compiler defaults inside React semantics.

Fict-like compiler-first systems matter because they can replace rerun-and-compare execution with dependency-driven propagation for many update paths.

Both are valid. They optimize different costs:

React Compiler answers:
- How far can we push automatic performance within React's existing contract?
Compiler-first fine-grained answers:
- If dataflow is known at compile time, how much runtime tree-level comparison can we avoid?

A serious engineering decision should not declare a universal winner.

It should define boundaries, publish evidence, and make trade-offs explicit.

Renderify: A Runtime Engine for Rendering LLM-Generated UI Instantly in the Browser

Michael Lin — Thu, 26 Feb 2026 18:34:56 +0000

Repo: github.com/webllm/renderify

Introduction

As large language models (LLMs) advance rapidly, AI can now generate structurally complete and logically sound UI code. Yet a key engineering question remains open: how do you safely and efficiently render LLM-generated UI directly in the browser — without any backend compilation or deployment pipeline?

Existing approaches each have limitations: v0/Bolt.new rely on a full Next.js compilation backend; Streamlit/Gradio are Python-based and server-rendered; Anthropic Artifacts is closed-source and non-embeddable; JSON Schema renderers can only express a predefined component set; Sandpack/WebContainers are powerful but heavyweight.

Renderify was built to fill this gap. It is a runtime-first dynamic rendering engine that transpiles, sandboxes, and renders LLM-generated JSX/TSX (or structured JSON plans) directly in the browser as interactive UI — with zero build steps, zero server-side compilation, and zero deployment pipeline.

LLM Output (JSX/TSX or Structured Plan)
  → Code Generator (parse + normalize)
    → Security Policy Check (intercept before execution)
      → Runtime Execution (Babel transpilation + JSPM module resolution)
        → Interactive UI rendered in the browser

Industry Landscape (as of 2026-02-16)

Before discussing Renderify's differentiation, it helps to establish a common framework. The diagram below breaks the "LLM → UI" path into six stages:

User Intent
  -> [A] LLM generates code / description
    -> [B] Code parsing / transformation / orchestration
      -> [C] Security checks + sandboxing
        -> [D] Browser module resolution (bare import -> URL)
          -> [E] Runtime execution + DOM rendering
            -> [F] State management + interaction

Definitions:

Open Source: Whether the core SDK/runtime has public source code (the platform service itself may be closed-source).
Embeddable: Whether it can be integrated as a capability into your own application, rather than used only within the vendor's hosted product.
Stages Covered: Represents the typical primary path, not the full capability boundary.

Solution	Stages Covered (typical)	Core Path	Open Source	Embeddable
v0 (Vercel)	A→E (backend build path)	LLM → Next.js compile/deploy	Platform closed-source, SDK open-source	✅ (Platform API/SDK)
Bolt.new (StackBlitz)	A→E (WebContainers path)	LLM → WebContainers → full Node.js	Partial (frontend open-source, WebContainers engine closed-source)	Limited (primarily a product)
Anthropic Artifacts	A→E (private sandbox)	LLM → private render sandbox	❌	❌
Vercel AI SDK	A + E (+ experimental RSC)	LLM orchestration → framework UI	✅	✅ (multiple frameworks)
AI.JSX	A→B	LLM selects/orchestrates predefined components	✅	✅
llm-ui	E	LLM text → Markdown/JSON components	✅	✅
Gen-UI-Lang	A→B	LLM → DSL → multi-target output	✅	✅
Thesys GenUI	A→E	LLM → structured DSL/API → React render layer	Partial (SDK/examples open-source)	✅ (primarily React SDK)
Sandpack	D→E	Predefined code → iframe bundler execution	✅	✅
WebContainers	D→E	In-browser Node.js/WASM environment	Partial	✅ (provides embed API)
E2B	C→E	Code → remote micro VM execution	Partial (SDK open-source)	✅ (typically requires server)
Renderify	B→F (core) + A (optional)	LLM/external input → IR → security policy → Babel/JSPM → render	✅	✅

From this perspective, Renderify's positioning is more precisely described as:

A browser-runtime-centric, locally embeddable execution chain covering stages B→F.
Stage A is optional — you can plug in @renderify/llm, or supply a RuntimePlan from any external system.

Core Architecture

Monorepo Package Topology

Renderify is organized as a monorepo using pnpm workspaces + Turborepo, consisting of seven packages with clearly separated responsibilities:

Package	Responsibility
`@renderify/ir`	Intermediate representation — RuntimePlan/Node/State/Action type contracts
`@renderify/security`	Security policy engine — profile configuration, static analysis, module allowlists
`@renderify/runtime`	Runtime execution engine — transpilation, module loading, sandboxed execution, UI rendering
`@renderify/core`	Orchestration layer — RenderifyApp full pipeline, streaming, plugin system
`@renderify/llm`	LLM provider abstraction — OpenAI/Anthropic/Google/Ollama/LMStudio
`renderify`	Top-level SDK facade — the recommended application entry point
`@renderify/cli`	CLI tooling + browser Playground

Package dependencies form a clean directed acyclic graph (DAG). @renderify/ir is a leaf node with no internal dependencies; all other packages build upon it layer by layer.

Five-Stage Pipeline

The rendering pipeline consists of five strictly ordered stages:

┌──────────────────┐     ┌──────────────────┐     ┌──────────────────┐
│  LLM Interpreter │────▶│  Code Generator  │────▶│   RuntimePlan    │
│  (OpenAI/Claude/ │     │  (JSON or TSX    │     │   (IR)           │
│   Gemini)        │     │   extraction)    │     │                  │
└──────────────────┘     └──────────────────┘     └────────┬─────────┘
                                                           │
                                                           ▼
                                                  ┌──────────────────┐
                                                  │  Security Policy │
                                                  │  Checker         │
                                                  └────────┬─────────┘
                                                           │
                                                           ▼
                                                 ┌───────────────────┐
                                                 │  Runtime Manager  │
                                                 │  (execute plan,   │
                                                 │   resolve modules,│
                                                 │   transpile)      │
                                                 └─────────┬─────────┘
                                                           │
                                                           ▼
                                                 ┌───────────────────┐
                                                 │  UI Renderer      │
                                                 │  (HTML generation,│
                                                 │   DOM reconcile)  │
                                                 └───────────────────┘

RuntimePlan: The Unified Intermediate Representation

RuntimePlan is the core contract of the entire system, serving as a stable interface between all pipeline stages. Regardless of the LLM's output format, everything is normalized into a RuntimePlan before flowing through security checks, runtime execution, and UI rendering.

Type Structure

// Three node types compose the UI tree
type RuntimeNode =
  | RuntimeTextNode // Text node: { type: "text", value: string }
  | RuntimeElementNode // Element node: { type: "element", tag: string, props?, children? }
  | RuntimeComponentNode; // Component node: { type: "component", module: string, props?, children? }

// Complete RuntimePlan structure
interface RuntimePlan {
  specVersion?: "runtime-plan/v1";
  id: string;
  version: number;
  root: RuntimeNode; // Declarative UI tree (required)
  source?: RuntimeSourceModule; // JSX/TSX source code module
  imports?: string[]; // npm dependency declarations
  state?: RuntimeStateModel; // State model
  capabilities?: RuntimeCapabilities; // Capability declarations
  moduleManifest?: RuntimeModuleManifest; // Module resolution manifest
}

Dual Input Paths

Renderify supports two fundamentally different input formats, both of which converge at the same security check and execution pipeline:

Path A: Structured RuntimePlan JSON

The LLM generates a structured RuntimePlan directly via JSON Schema constraints. This path offers maximum control and deterministic behavior, making it ideal for production systems.

{
  "specVersion": "runtime-plan/v1",
  "id": "dashboard-v1",
  "version": 1,
  "root": {
    "type": "element",
    "tag": "div",
    "children": [{ "type": "text", "value": "Hello World" }]
  },
  "capabilities": { "domWrite": true }
}

Path B: TSX/JSX Source Code

The LLM generates free-form text containing code blocks. The code generation stage extracts the source code and wraps it as a RuntimePlan with a source field; the runtime then transpiles and executes it.

import { useState } from "preact/hooks";
import { LineChart, Line } from "recharts";

export default function Dashboard() {
  const [metric, setMetric] = useState("revenue");
  return <div>...</div>;
}

This dual-path design maximizes flexibility — structured JSON suits scenarios that demand precise control, while TSX/JSX code blocks feel more natural for LLMs and can express richer interactive logic.

Security: Defense in Depth

When LLMs generate code, security is paramount. An LLM may produce <script> tags, eval() calls, or unsafe network requests. Renderify employs multiple independent defense layers, enforcing strict security policies before any code executes.

Three Security Profiles

Policy	Strict	Balanced (default)	Relaxed
Max tree depth	8	12	24
Max node count	250	500	2,000
Max source size	20KB	80KB	200KB
Max imports	80	200	1,000
Max execution time	5s	15s	60s
Manifest required	Yes	Yes	No
Module integrity	Required	No	No
Dynamic imports	Blocked	Blocked	Allowed

Seven Defense Layers

Static pattern analysis: Regex-based detection of dangerous source patterns (eval(, new Function(, fetch(, document.cookie, localStorage, child_process, etc.), plus path-traversal detection on module specifiers (including encoded variants).
Structural limits: Tree depth, node count, source byte size.
Tag blocklist: Blocks script, iframe, object, embed, and other dangerous tags.
Module allowlist: Only pre-approved modules may be imported.
Manifest integrity: In strict mode, all imports must have exact URL mappings.
Execution budgets: Wall-clock timeouts, import count limits, and component invocation limits, enforced via Promise.race().
Sandbox isolation: Three sandbox modes — Worker/iframe/ShadowRealm — with automatic fallback chains.

The overall strategy is fail-closed by default: tags, modules, hosts, and execution profiles not explicitly permitted by the policy are rejected. In strict/balanced mode, uncovered bare specifiers are also rejected. The relaxed profile selectively loosens these constraints.

Browser ESM Module Graph Materialization

A key engineering capability of Renderify is how it resolves and loads npm packages entirely in the browser — without any server-side bundler.

Background

Browsers natively support ES Modules, but with one critical limitation: bare specifiers are not supported. You cannot directly import { format } from "date-fns" in the browser. Traditional solutions require bundlers like webpack or Vite to resolve these specifiers on the server, which contradicts Renderify's zero-build-step design goal.

Solution: The fetch → rewrite → blob URL Pipeline

Source code
  → es-module-lexer extracts import declarations
    → JSPM CDN resolves bare specifiers
      → Recursively materialize child dependency imports
        → Rewrite import statements to resolved URLs
          → Create blob: URL
            → dynamic import() to load

The detailed flow:

Lexical extraction: Use es-module-lexer to extract all import declarations from the source code.
Specifier resolution: Resolve bare specifiers (e.g., recharts) to exact CDN URLs via the JSPM CDN.
Recursive materialization: Fetch remote module source, parse its child imports, and recursively repeat the same process.
Rewriting: Replace all import specifiers with materialized blob/data URLs.
Packaging: Create a blob URL from the rewritten source.
Loading: Load the blob URL via dynamic import().

Asset Proxy Modules

For non-JavaScript assets, Renderify handles them transparently through proxy modules:

CSS imports: Converted to <style> injection proxy modules (deduplicated by FNV-1a hash — created on first encounter, reused on subsequent ones).
JSON imports: Wrapped as export default <parsed-json> ESM modules.
Binary assets: Converted to proxy modules that export the CDN URL.

Auto-Pin-Latest Strategy

renderPlanInBrowser enables auto-pin-latest mode by default:

Developers use bare imports in source code (e.g., import { format } from "date-fns/format").
On first run, Renderify resolves the bare specifier to an exact versioned URL via JSPM.
The resolution result is immediately injected into the moduleManifest; subsequent executions use the pinned version.

For production, use manifest-only mode (autoPinLatestModuleManifest: false) to ensure fully pre-pinned, auditable dependency mappings.

React Ecosystem Compatibility Bridge

LLM-generated code typically uses the React API — it is the most common frontend framework in model training data.

Renderify transparently redirects common React imports to the Preact compat layer via built-in compatibility mappings (Preact is approximately 3–4KB gzipped, significantly smaller than the React runtime; exact figures vary by version), reducing runtime overhead and improving cold-start performance:

const DEFAULT_JSPM_SPECIFIER_OVERRIDES = {
  react: "preact/compat",
  "react-dom": "preact/compat",
  "react-dom/client": "preact/compat",
  "react/jsx-runtime": "preact/jsx-runtime",
  recharts: "recharts@3.3.0",
  // ...
};

This means LLMs can freely generate standard React code, and it will execute on the smaller, faster Preact runtime. React ecosystem libraries such as Recharts and MUI work as expected.

Streaming Rendering Architecture

In Chat UI scenarios, users expect real-time feedback. Renderify's streaming pipeline delivers progressive preview updates while the LLM is still generating code:

LLM tokens ──▶ llm-delta chunks ──▶ preview renders ──▶ final render

llm-delta: Each token from the LLM is emitted as a chunk.
preview: At configurable intervals, the accumulated text is parsed and rendered as a preview.
final: After LLM completion, the full pipeline executes and emits the final result.
error: If any stage fails, an error chunk is emitted before the exception propagates.

Efficient Change Detection

The streaming code generation stage uses FNV-1a 64-bit hashing for efficient change detection. As the LLM continuously outputs tokens, the system computes a hash signature over the accumulated text — only re-parsing and re-rendering when the signature changes. This avoids redundant computation during streaming while maintaining responsive incremental previews.

Plugin System

The CustomizationEngine provides 10 hook points covering every pipeline stage:

beforeLLM → [LLM] → afterLLM
  → beforeCodeGen → [CodeGen] → afterCodeGen
    → beforePolicyCheck → [Security] → afterPolicyCheck
      → beforeRuntime → [Runtime] → afterRuntime
        → beforeRender → [UI] → afterRender

Each hook receives the current stage's payload and can transform it before passing it to the next stage. Multiple plugins execute in registration order. This design lets developers inject custom logic without forking the core — from modifying the LLM prompt to post-processing render output.

Sandbox Execution Model

For scenarios requiring stronger isolation, Renderify offers three browser sandbox modes:

Mode	Mechanism	Characteristics
`sandbox-worker`	Web Worker + blob URL + `postMessage`	Separate-thread execution with timeout and abort support
`sandbox-iframe`	`sandbox="allow-scripts"` iframe + MessageChannel	Isolated document context
`sandbox-shadowrealm`	ShadowRealm API + blob URL bridge	Same-thread isolated realm

The three modes support automatic fallback chains — if the preferred mode is unavailable, execution automatically falls back to the next one. Each mode supports configurable timeouts and fail-closed behavior (fail-closed by default; can be disabled via browserSourceSandboxFailClosed to fall back to non-sandboxed execution on failure).

DOM Reconciliation and UI Rendering

DefaultUIRenderer is not a simple innerHTML replacement — it implements a full DOM reconciliation algorithm:

Keyed + positional child matching: Prioritizes key-based matching, then falls back to positional matching.
Differential attribute updates: Only updates attributes that have actually changed.
Text node updates: Directly modifies textContent rather than replacing the node.
Interactive state preservation: Preserves scroll positions during reconciliation and avoids overwriting value/checked on focused input elements.
Event delegation: Implements event handling via data-renderify-event-* attributes and CustomEvent dispatch.
XSS protection: Blocks dangerous tags/attributes and sanitizes inline styles (blocking expression(), url(), javascript:, etc.).

One-Line Embed API

Renderify provides a minimal embed API — a single call completes the entire flow from Plan to rendered UI:

import { renderPlanInBrowser } from "renderify";

await renderPlanInBrowser(plan, { target: "#mount" });

Internally, this call automatically creates all required infrastructure — module loader, security checker, runtime manager, UI renderer — and uses a WeakMap-backed render lock to ensure concurrent renders to the same DOM target are properly serialized.

A complete 30-second example:

import { renderPlanInBrowser } from "renderify";

renderPlanInBrowser(
  {
    id: "hello_jsx_runtime",
    version: 1,
    root: { type: "text", value: "Loading..." },
    source: {
      language: "tsx",
      code: `
        import { format } from "date-fns/format";

        export default function App() {
          return <section>Today: {format(new Date(), "yyyy-MM-dd")}</section>;
        }
      `,
    },
  },
  { target: "#mount" },
);

The code above does three things: (1) executes JSX/TSX directly at browser runtime; (2) auto-resolves the date-fns bare import via JSPM; (3) pins the resolved URL into moduleManifest before execution.

Performance Optimization Strategies

Transpilation Cache

The runtime transpiler uses an LRU cache (256 entries) with cache keys composed from language/runtime/filename/code, avoiding redundant transpilation of unchanged source code.

Request Deduplication

Both JspmModuleLoader and RuntimeSourceModuleLoader implement request deduplication — when multiple components request the same module concurrently, only a single network request is made.

Multi-CDN Fault Tolerance

Module fetching supports multi-CDN fallback using Promise.any for hedged requests. The default source is the JSPM GA CDN, with fallback to esm.sh and other alternative CDNs on failure.

Budget Racing

Execution budgets constrain async paths via remaining-time calculation + Promise.race(). For synchronously blocking code, sandboxed execution (such as browser sandbox or isolated-vm) is still required to mitigate the risk of main-thread stalls.

Blob URL Cleanup

The runtime manager tracks all created blob URLs and revokes them in bulk during cleanup to prevent memory leaks.

Tuning Parameters

Parameter	Default	Impact
`enableDependencyPreflight`	`true`	Better safety and earlier failure signals
`remoteFetchTimeoutMs`	`12000`	Prevents long hangs
`remoteFetchRetries`	`2`	Better resilience
`browserSourceSandboxMode`	`worker` in browser (`none` outside browser)	Isolation for untrusted source code
`autoPinLatestModuleManifest`	`true`	Developer experience for bare imports

Use Cases

Renderify is well-suited for the following scenarios:

LLM Chat / Agent platforms: Render dynamic UI from model output — dashboards, forms, cards, data visualizations.
AI Agent toolchains: An Agent analyzes user data and dynamically generates interactive dashboards or operation interfaces, rather than just returning text.
Low-Code / No-Code AI backends: Users describe intent in natural language; the LLM generates a runnable UI component on the fly.
Dynamic forms and approval workflows: Generate context-aware forms at runtime, more flexible than JSON Schema renderers.
Rapid prototyping: Go from prompt to rendered UI in seconds, not minutes.
Safe rendering of untrusted UI: Any application that needs to securely render dynamically generated UI in the browser.

Getting Started

SDK Embedding (Recommended)

pnpm add renderify

import { renderPlanInBrowser } from "renderify";

await renderPlanInBrowser(
  {
    id: "quickstart",
    version: 1,
    root: { type: "text", value: "Loading..." },
    source: {
      language: "tsx",
      code: `export default () => <section>Hello from Renderify</section>;`,
    },
  },
  { target: "#mount" },
);

CLI Playground

# Start the browser Playground
pnpm playground

# Render from a prompt
pnpm cli -- run "Build a welcome card"

# Output RuntimePlan JSON
pnpm cli -- plan "Build a welcome card"

# Probe plan compatibility (security policy + runtime preflight)
pnpm cli -- probe-plan examples/runtime/recharts-dashboard-plan.json

# Configure LLM provider
RENDERIFY_LLM_PROVIDER=openai RENDERIFY_LLM_API_KEY=<key> pnpm playground
RENDERIFY_LLM_PROVIDER=anthropic RENDERIFY_LLM_API_KEY=<key> pnpm playground
RENDERIFY_LLM_PROVIDER=google RENDERIFY_LLM_API_KEY=<key> pnpm playground

Renderer-Only Mode (No LLM)

From a capability standpoint, Renderify's LLM integration is optional. You can supply a RuntimePlan from any source — your backend API, another SDK, or a different model provider.

Note that the top-level renderify package includes @renderify/llm as a dependency for out-of-the-box convenience. If you want to minimize the runtime entry point, use @renderify/runtime + @renderify/ir directly:

import { renderPlanInBrowser } from "@renderify/runtime";
import type { RuntimePlan } from "@renderify/ir";

const plan: RuntimePlan = {
  specVersion: "runtime-plan/v1",
  id: "renderer_only",
  version: 1,
  root: {
    type: "element",
    tag: "div",
    children: [{ type: "text", value: "Hello from BYO plan" }],
  },
  capabilities: { domWrite: true },
};

await renderPlanInBrowser(plan, { target: "#mount" });

Design Philosophy and Technical Highlights

1. IR as a Stable Contract

The RuntimePlan intermediate representation fully decouples LLM output format from execution and rendering. Even outside of Renderify, this IR design provides a reusable schema for any system that needs to describe "LLM-generated interactive UI."

2. Reusable Security Policy Framework

A systematic approach to executing untrusted dynamic code — tag blocklists, module allowlists, execution budgets, source pattern analysis — this policy model can be extracted and applied to any browser-side dynamic code execution scenario.

3. Browser ESM Module Graph Materialization

The fetch → rewrite imports → blob URL pipeline solves a problem that browser standards have not yet natively addressed — bare specifiers are not usable in browsers. This module loading strategy can be extracted as a standalone utility.

4. Strategy over Convention

Key components throughout the system employ the Strategy pattern — transpilers (Babel/esbuild), sandbox modes (Worker/iframe/ShadowRealm), LLM providers (five built-in implementations), module loaders — all are swappable implementations behind interfaces.

5. Zero-Configuration React Compatibility

LLMs generate standard React code that transparently executes on the Preact compat runtime — no additional configuration or special handling required.

Conclusion

Renderify represents an important infrastructure layer in LLM application development — it solves the last-mile problem between "an LLM can generate code" and "users can see and interact with that UI." Its value stems from a set of composable engineering capabilities:

Zero-build runtime rendering: Fully browser-side transpilation and module resolution via Babel Standalone + JSPM CDN.
Defense-in-depth security: Seven independent defense layers ensuring LLM-generated untrusted code is executed safely.
Browser ESM module graph materialization: The fetch → rewrite → blob URL pipeline, constructing module dependency graphs in the browser.
Streaming rendering: Efficient change detection based on FNV-1a hashing, delivering real-time incremental UI previews.
Minimal API: A single line of code from RuntimePlan to fully rendered interactive UI.

Renderify provides a solid technical foundation for building the next generation of AI-driven dynamic UI applications. Whether it's rich interactive components in chat interfaces, AI Agent-generated data dashboards, or natural-language-driven low-code platforms, Renderify turns LLM UI generation capabilities into tangible, interactive product experiences.

A note on comparisons: cross-product size and performance claims should be substantiated with benchmarks under fixed versions, fixed scenarios, and fixed network conditions before drawing conclusions.

Fict – A compiler that makes JavaScript variables automatically reactive

Michael Lin — Wed, 31 Dec 2025 15:50:09 +0000

Fict Repo - https://github.com/fictjs/fict

Opening: A Starting Point for Technical Exploration

When developing with React, we often write code like this:

const [count, setCount] = useState(0)
const doubled = useMemo(() => count * 2, [count])
const handleClick = useCallback(() => setCount(c => c + 1), [])

The meaning expressed by these three lines is actually quite simple: count is a number, and doubled is twice its value.

This raises a question: Is it possible for a compiler to automatically infer these dependencies?

Modern compilers are already capable of analyzing control flow, performing type inference, and eliminating dead code—theoretically, automatically tracking variable dependencies seems feasible as well.

Fict is a technical exploration based precisely on this idea.

Part 1: Core Design Philosophy

What if variables just... worked?

The core hypothesis of Fict is:

If the compiler can see your code, it can know which variables depend on which other variables.

Let's look at an example:

function Counter() {
  let count = $state(0) // Marker: This is mutable state (reactive source)
  const doubled = count * 2 // Compiler inference: Depends on count
  const message = `Value: ${doubled}` // Compiler inference: Depends on doubled → Depends on count

  return <button onClick={() => count++}>{message}</button>
}

Notice what is missing here:

No setCount (direct assignment)
No useMemo (automatic inference)
No dependency arrays (compiler analysis)
No .value or explicit getter calls (just plain variables)

$state(0) is the only marker. Everything else is inferred by the compiler itself.

Technical Feasibility Analysis

This isn't magic; it's based on mature static analysis technology.

The compiler constructs a High-Level Intermediate Representation (HIR, a high-level IR) and performs data flow analysis; with the right representation, dependency tracking turns into a "traversing the dependency graph" problem.

In a simplified SSA (Static Single Assignment) perspective, you would see a dependency chain like this:

count_1    = $state(0)                 // Reactive source
doubled_1  = count_1 * 2               // Uses count_1 → Depends on count
message_1  = `Value: ${doubled_1}`     // Uses doubled_1 → Transitive dependency on count

The compiler knows message depends on count without you telling it.

The above is an overview of Fict's core design philosophy and technical route. Subsequent chapters will detail the specific implementation methods.

Part 2: Comparison with Other Frameworks

2.1 Syntax Comparison

Let's look at how different frameworks handle the same problem:

┌─────────────────────────────────────────────────────────────┐
│ React                                                       │
├─────────────────────────────────────────────────────────────┤
│ const [count, setCount] = useState(0)                       │
│ const doubled = useMemo(() => count * 2, [count])           │
│ // Problem: Manual dependency arrays are error-prone;       │
│ // React Compiler automates memoization.                    │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ Solid                                                       │
├─────────────────────────────────────────────────────────────┤
│ const [count, setCount] = createSignal(0)                   │
│ const doubled = createMemo(() => count() * 2)               │
│ // Mental model: count vs count();                          │
│ // Destructuring props might lose reactivity (use splitProps)│
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ Svelte 5                                                    │
├─────────────────────────────────────────────────────────────┤
│ let count = $state(0)                                       │
│ let doubled = $derived(count * 2)                           │
│ // Better, but derived intent still needs explicit $derived │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ Fict                                                        │
├─────────────────────────────────────────────────────────────┤
│ let count = $state(0)                                       │
│ const doubled = count * 2                                   │
│ // No $derived: Compiler automatically infers within static │
│ // analysis scope.                                          │
└─────────────────────────────────────────────────────────────┘

2.2 Compiler Comparison

Syntax is just the surface difference. A more essential distinction lies in: What responsibilities do the compilers (or runtimes) of each framework assume?

React Compiler: Automatic Memoization (Does not change React Model)

The goal of React Compiler is clear: Automatic memoization.

Its output often "looks like" it automatically added React.memo / useMemo / useCallback for you, but implementation-wise, it doesn't necessarily generate these Hook calls; in public discussions, React Compiler explicitly stated it directly inlines dependency checks and caches values, avoiding the overhead of closures and dependency arrays associated with handwritten useMemo/useCallback.

// Input
function Component({ items }) {
  const sorted = items.toSorted()
  return <List data={sorted} />
}

You can understand the compiler's "conceptual" output as:

// Conceptual equivalent (for understanding, not necessarily actual output)
function Component({ items }) {
  const sorted = useMemo(() => items.toSorted(), [items])
  return <List data={sorted} />
}

What it does:

✅ Automatic memoization: Caches calculation results, stabilizes references, reduces unnecessary re-computations and re-renders.
✅ Skips as many updates as possible without changing React's render + reconciliation model.
✅ Still allows developers to use useMemo/useCallback as escape hatches (e.g., for stable effect dependencies).
✅ Provides "use no memo" as a temporary escape hatch: lets a specific function completely skip compiler optimization for troubleshooting incompatible code.

What it doesn't do:

❌ Does not turn React into a "compile to fine-grained DOM instructions" framework: React is still render + reconciliation (colloquially "VDOM + diff").
❌ Does not replace the hooks system: You still write useState/useEffect/.... The compiler just tries to automate "caching work" like memoization.

React Compiler's design positioning is: Improve performance through automatic memoization without changing the logical model of React.

Svelte 5: Template Compilation + Explicit Runes (Derivations/Side Effects capture dependencies at evaluation)

Svelte's typical path is: Compile templates to DOM update code (no VDOM), and use runes ($state/$derived/$effect) to explicitly write out the intent of "this is state/derived/side-effect".

The key point: Svelte 5's $derived documentation clearly states dependency rules—any value read synchronously inside a $derived expression (or $derived.by function body) becomes a dependency; when dependencies change, it is marked dirty and re-calculated on next read.
$effect similarly drives re-execution based on dependency changes.

<script>
  let count = $state(0)
  let doubled = $derived(count * 2)
</script>

<button on:click={() => count++}>
  {doubled}
</button>

What it does:

✅ Template → DOM update code (no VDOM)
✅ Runes provide explicit semantics: $derived for derivations, $effect for side effects, dependencies captured at evaluation and schedule updates.

What it doesn't do:

❌ Does not do global SSA-level automatic derivation inference for "arbitrary JS blocks" to let you skip $derived: In Svelte, derivation intent still needs to be expressed via $derived.
❌ UI components are still organized around .svelte files (this is its ecosystem & DX choice).

Solid: Compile-time JSX lowering / JSX compilation + Runtime Fine-grained Dependency Tracking (No VDOM)

Solid's route is more like: Compiler is responsible for turning JSX into efficient DOM creation/binding, while dependency tracking and update scheduling mainly happen at runtime (signals/memos/effects).

Solid official documentation clearly warns: Direct destructuring of props is not recommended, as it may break reactivity; need to use props.xxx, wrapper functions, or splitProps.
Meanwhile, Solid's homepage explicitly emphasizes: No Virtual DOM / no extensive diffing, updates can be precise to the DOM binding layer.

function Counter() {
  const [count, setCount] = createSignal(0)
  const doubled = createMemo(() => count() * 2)
  return <button onClick={() => setCount(c => c + 1)}>{doubled()}</button>
}

What it does:

✅ JSX → DOM templates/bindings (static optimization at compile time)
✅ Runtime fine-grained dependency tracking: Whoever uses the signal subscribes to it; only updates relevant DOM bindings when changed (no VDOM).
✅ Provides tools (like splitProps) to safely handle props (avoiding loss of reactivity on destructuring).
What it doesn't do:
❌ No "automatic derivation inference": Derived values usually need explicit createMemo.
❌ Runtime model is "signals driven", not "compiler globally infers everything".

Vue Vapor: A "No VDOM" Exploration Direction (Still Evolving)

In Vue's official documentation, Vapor Mode is described as a new compilation strategy being explored: inspired by Solid, not relying on Virtual DOM, and making stricter use of Vue's built-in reactivity system.
Meanwhile, the vue-vapor repository itself is in an archived (read-only) state, so it should be treated as experimental / in flux.

Compiler Comparison Table (Stricter Version)

Note: ✅ = Officially clearly described and presented as a stable capability; 🧪 = Officially defined as exploration/experimental direction; — = Not the main narrative of the framework/hard to draw a hard conclusion.

Dimension	React + React Compiler	Svelte 5	Solid	Vue Vapor	Fict
Automatic memoization (reduce manual memo)	✅ Automatic memoization, `useMemo/useCallback` as escape hatch; supports `"use no memo"` to skip optimization.	❌ Derivations need explicit `$derived`.	❌ Derivations usually need `createMemo` (explicit).	—	✅
Still render + reconciliation?	✅ Yes.	❌ (Template compiled to DOM updates)	❌ (No VDOM/No diffing)	🧪 Official exploration of "No VDOM" strategy.	❌
Are Derived/Side-effect intents explicit?	✅ Hooks explicit; memoization can be automated by compiler.	✅ `$derived/$effect` explicit; dependencies are captured from synchronous reads during evaluation.	✅ Explicit memo/effect; dependency tracking at runtime.	✅ (Vue default: computed/watch etc.; Vapor's commitment to not changing intent expression is not set in stone)	✅
DX Form	JS/JSX + Compiler	`.svelte` + runes	JS/JSX + signals	SFC/Template-centric (Vapor is exploration)	Pure JSX/JS

2.3 Execution Model Comparison

The compiler is only half the story; the other half is the execution model.

Framework	Does Component Code Re-execute?	Update Granularity	Control Flow Expression
React (with Compiler)	React still re-renders; the compiler memoizes values/functions to reduce work and stabilize props.	Component/Subtree dominant (determined by reconciliation)	Native JS (if/for)
Solid	Executes once on init; subsequent fine-grained updates driven by signal subscriptions (no VDOM/diff).	DOM Binding Level	Commonly uses `<Show>/<For>` control flow components
Svelte 5	Executes once on init; `$derived/$effect` scheduled on dependency change.	DOM update code + runes scheduling	Template blocks (`{#if}/{#each}`)
Vue Vapor	🧪 Exploring: Goal is rendering path not dependent on VDOM.	🧪	Template/Directives centric
Fict	On-demand (Mixed)	Fine-grained DOM update	Native JS (if/for)

An Intuitive Example: Re-execution Strategy and Slot Reuse

function Demo() {
  console.log('mount once') // First run
  let count = $state(0)
  console.log('re-run with', count) // Re-runs when count changes
  return <button onClick={() => count++}>{count}</button>
}

After clicking the button, the console will only append re-run with 1/2/.... mount once will not repeat, indicating that only the region reading the state is re-executed. The compiler achieves this by hoisting static parts outside the reactive region, or splitting the function into multiple regions.
DOM will not be recreated: Signal slot reuse + binding updates ensure the button node, events, and refs remain in place, only the text node updates.

Part 3: Fict's "Full-Link Analysis" (Design Goal)

One thing Fict attempts to do is: Analyze the entire JS function, not just the template part.

function Counter() {
  let count = $state(0)
  const doubled = count * 2
  const message = `Value: ${doubled}`

  if (count > 10) {
    return <Special value={message} />
  }
  return <button onClick={() => count++}>{message}</button>
}

Main processing stages of the Fict compiler:

Build HIR (High-Level Intermediate Representation): Function body → Basic Blocks + CFG (including if/for/while/switch)
Convert to SSA: Make assignment versions unique, facilitating explicit dependency edges
Analyze Reactive Scopes: Automatically turn expression regions dependent on $state into memo/effect/bindings
Detect Control Flow Reads: When reactive values appear in branch tests etc., choose paths that "need re-execution"
Generate Fine-grained DOM: JSX → DOM instructions; Bindings → Precise effects

Part 4: Fict's Mixed Execution Model

The execution model designed by Fict:

If state is only read in JSX → Component does not re-execute, only relevant DOM nodes update
If state is read in control flow (e.g., branch conditions in if/switch/loop) → Component needs re-execution

The compiler analyzes and decides which update strategy to adopt at compile time. Developers don't need to rewrite code into special syntax like <Show>/<For> or {#if}; native if/for works directly.

Part 5: How the Compiler Works

The Fict compiler transforms source code into efficient runtime code through several core stages.

Inside the compiler

Fict compiler's core is a multi-stage pipeline:

Plain JS/TS + JSX/TSX (compiled)
     ↓
  ┌─────────┐
  │  HIR    │  CFG (Basic Blocks + Control Flow Graph)
  └────┬────┘
       ↓
  ┌─────────┐
  │  SSA    │  Versioned Assignments + Dependency Analysis
  └────┬────┘
       ↓
  ┌─────────────────┐
  │ Reactive Scopes │  Reactive Scope Analysis + Region Grouping
  └────────┬────────┘
       ↓
  ┌─────────┐
  │ Codegen │  Fine-grained DOM Operations + bindings
  └─────────┘

The compiler performs Reactive Scope Analysis to determine memoization boundaries, automatically identifying which expressions should be wrapped as memos, and their dependencies.

HIR Construction (Schematic)

if (count > 10) {
  return <Special />
}
return <Normal />

// HIR (Schematic)
Block 0:
  $0 = LoadLocal count
  $1 = BinaryExpr(>) $0, 10
  Branch $1 -> Block1, Block2

Block 1:
  $2 = JSXElement(Special)
  Return $2

Block 2:
  $3 = JSXElement(Normal)
  Return $3

SSA Conversion & Dependency Tracking (Schematic)

let x = count
if (cond) {
  x = count + 1
}
return x

// SSA (Schematic)
x_1 = count_1
Branch cond -> Block1, Block2

Block1:
  x_2 = count_1 + 1
  Jump -> Block3

Block2:
  Jump -> Block3

Block3:
  x_3 = Phi(Block1: x_2, Block2: x_1)
  Return x_3

Now the dependency relationship is very clear: x_3 ultimately depends on count_1.

Part 6: Compilation Output Example (Simplified)

// Input
function Counter() {
  let count = $state(0)
  const doubled = count * 2
  return <button onClick={() => count++}>{doubled}</button>
}

// Output (Simplified Schematic)
// User code stays ‘plain variables’; the generated code may use accessor calls internally.
function Counter() {
  const __ctx = __fictUseContext()

  // $state -> signal
  const count = __fictUseSignal(__ctx, 0, 0)

  // Derived value -> memo (Compiler inferred)
  const doubled = __fictUseMemo(__ctx, () => count() * 2, 1)

  // DOM Creation
  const button = document.createElement('button')
  const text = document.createTextNode('')
  button.appendChild(text)

  // Binding Update (Using fine-grained effect)
  bindText(text, () => doubled())

  // Event
  button.onclick = () => count(count() + 1)

  return button
}

The characteristics of this compilation output are:

No VDOM
No diffing
Only precise DOM operations
doubled automatically memoized

Example with Control Flow

// Input
function App() {
  let show = $state(true)
  if (show) return <Panel />
  return <Fallback />
}

// Output (Simplified)
function App() {
  const __ctx = __fictUseContext()

  return __fictRender(__ctx, () => {
    const show = __fictUseSignal(__ctx, true, 0)

    // Control flow triggers re-execution, so the whole render function logic runs again
    // But signals are reused via slots, not recreated

    return createConditional(
      () => show(),
      () => /* Panel's fine-grained DOM */,
      createElement,
      () => /* Fallback's fine-grained DOM */
    )
  })
}

__fictRender re-executes the internal function when show changes, but __fictUseSignal reuses state via slots, so state is not lost.

Reactivity of Props

Fict automatically maintains the reactivity of props, even after destructuring:

// Input
function Child({ count, update }) {
  const doubled = count * 2
  return <div>{doubled}</div>
}

// Output (Simplified)
function Child(__props) {
  const __ctx = __fictUseContext()

  // Destructured props automatically wrapped as getters
  const count = useProp(() => __props.count)
  const update = __props.update // Function type not wrapped

  // Derived values automatically become memos
  const doubled = __fictUseMemo(__ctx, () => count() * 2, 0)

  // ...
}

This solves a common pain point in Solid: Destructuring props breaks reactivity. In Fict, you can destructure freely.

Part 7: Compiler Safety Rails

DX Protection Mechanisms

The Fict compiler detects common error patterns and issues warnings:

┌─────────────────────────────────────────────────────────────┐
│ Code       │ Issue                   │ Severity             │
├─────────────────────────────────────────────────────────────┤
│ FICT-C003  │ Nested Component Def    │ Warning              │
│ FICT-M003  │ Memo with Side Effects  │ Warning              │
│ FICT-S002  │ State passed as arg     │ Warning              │
│ FICT-J002  │ List missing key        │ Warning              │
│ FICT-E001  │ Effect no deps          │ Warning              │
│ FICT-C004  │ Component no return     │ Warning              │
├─────────────────────────────────────────────────────────────┤
│ $state inside condition | Not Allowed | Compile Error       │
│ $state inside loop      | Not Allowed | Compile Error       │
│ Destructuring $state    | Not Allowed | Compile Error       │
└─────────────────────────────────────────────────────────────┘

For example, defining nested components is a common anti-pattern:

function Parent() {
  // ⚠️ FICT-C003: Components should not be defined inside another component
  function Child() {
    return <div>Child</div>
  }
  return <Child />
}

The compiler will warn you to move Child to module scope.

Part 8: Trade-offs

What Fict can't do (yet)

I want to be honest about Fict's limitations:

1. Dependency tracking inside black-box functions may be incomplete

const result = someExternalLib.compute(() => count)
// Compiler cannot see inside compute callback, dependency tracking might be incomplete

Solution: The compiler issues a warning (FICT-S002), you can use explicit getters or let the component take the re-execution path.

2. Dynamic property access is limited

const key = getDynamicKey()
const value = obj[key] // Compiler doesn't know what key is

Solution: Degrade to object-level subscription + warning.

3. No Ecosystem

This is common for new frameworks. No UI library, no complete SSR framework, no mature router. If you need to go to production today, Fict might not be the right choice.

4. Execution Model needs learning

Fict's execution model differs from React (see Section 2.3):

console.log('A') // Executes once
let count = $state(0)
console.log('B', count) // Executes every time count changes

Developers from a React background might be confused: "Why doesn't A execute every time?" This requires understanding Fict's concept of reactive regions.

We will provide Fict DevTools to visualize these regions to aid debugging.

5. Compiler Complexity

Fict's compiler is much more complex than Solid's. More code means more potential bugs.

Known Escape Hatches / Mitigation

Explicit $memo / $effect: When automatic inference doesn't meet expectations, manually declare derivation or side-effect boundaries.
useProp/mergeProps helpers: Manually maintain reactivity when props access patterns are special.
Control Flow Degradation: Scenarios that cannot be statically analyzed are handed over to the re-execution model, prioritizing correctness.

Why I still think it's worth it

Despite all these trade-offs, I believe what we get in return is worth it:

The amount of code developers write every day is reduced.
Mental burden is reduced.
Beginners don't need to understand "why do I have to write useMemo".

React Compiler proved that "letting the compiler take more responsibility" is the right direction. Fict just pushes this idea a bit further.

Part 9: Extended APIs

Fict also provides some extended APIs to handle scenarios that automatic inference cannot cover:

$store: For fine-grained reactivity of nested objects. $store is the recommended choice when path-level update tracking for deep objects is needed.
$memo: Escape hatch for explicitly creating memos. Although the compiler automatically infers derived values, developers can also manually control memoization.
$effect: Explicitly declare side effects.
ErrorBoundary / Suspense / Transitions: For error handling, async loading, and priority scheduling.

Fict's design philosophy is "reduce boilerplate + compiler automatic inference", these APIs serve as supplementary tools for advanced scenarios.

Part 10: Why Now

The frontend framework field is undergoing some interesting changes:

React Compiler achieved automatic memoization: Reduces the need for manual memo without changing the React model.
Signals proposal is advancing in TC39: Although still in early stages, it reflects the community's focus on reactive primitives.
Svelte 5 makes derivation/side-effect intent more explicit via runes, with clear dependency rules (sync read equals dependency).
Vue is officially exploring Vapor Mode: A compilation strategy that doesn't rely on VDOM and utilizes built-in reactivity more.

In this context:

Fict does not attempt to replace these excellent frameworks, but is a technical exploration: If we start from scratch based on these excellent frameworks, taking "compiler automatic dependency inference" as the core design principle, how far can we go?

Conclusion: Welcome to Try

Fict is currently under active development.

npm install fict

The core compiler and runtime functions are basically stable, but the ecosystem is still under construction. If you are interested in trying it out, we look forward to your feedback:

Bug reports (edge cases are especially valuable)
Suggestions for improving compiler output
Usage patterns you think should be supported but are not yet

Thank you for reading, and looking forward to communicating with you.

Rethinking Undo/Redo - Why We Need Travels

Michael Lin — Sun, 05 Oct 2025 13:44:56 +0000

TL;DR: If your app state is large (>10KB), needs persistence, or you care about memory usage and performance with long histories, Travels’ JSON Patch approach is worth considering. For simple scenarios, the default snapshot modes in Redux-undo or Zundo are actually simpler and more efficient.

Where the Problem Starts

Implementing usable undo/redo sounds easy: store a full snapshot for every state change and restore it on undo. The problem is that when the state object is large and changes are small (the usual case), snapshot memory = object size × history length. That linear growth is unacceptable for big objects. Worse, repeatedly deep-copying/patch-diffing complex structures pushes the main thread toward jank—this isn’t something you “optimize a bit” to fix; it’s a category error.

Travels starts by making JSON Patch (RFC 6902) a first-class citizen: generate patches/inversePatches incrementally as changes happen, trading compute for storage and serialization efficiency—preserving full reversibility while drastically shrinking history size.

Travels was created to resolve a fundamental tension: how to retain a complete history while minimizing memory and performance overhead.

How Mainstream Approaches Work

Let’s first look at how two popular community solutions work in practice.

Redux-undo: Reference-Based Snapshot Storage

Redux-undo is the classic solution in the Redux ecosystem. Its core logic looks like:

// redux-undo/src/reducer.js
function insert(history, state, limit, group) {
  const newPast = [...pastSliced, _latestUnfiltered];
  return newHistory(newPast, state, [], group);
}

Its strategy: store references to each state object.

{
  past: [state1, state2, state3],    // array of object references
  present: state4,
  future: [state5, state6]
}

There’s no deep copy here; it relies on Redux’s immutable update pattern:

Reducers return new objects each time
Structural sharing reduces memory copying
past only holds references

Pros:

Simple, straightforward implementation
Efficient enough for small state
Supports fine-grained controls like filter and groupBy

Limitations:

With Redux-undo plus Immer or immutable updates, unmodified subtrees share references. But each change still creates new objects for the changed node and all of its ancestors. For deep structures, even a single-field change can rebuild an entire parent chain.
Each history entry is effectively a full state snapshot
Tightly coupled to Redux; not usable elsewhere

For a simple counter, this is perfectly fine. But for a complex document object, 100 history entries imply 100 state references plus each one’s memory footprint.

Zundo: Optional Diff Optimization

Zundo is a tiny (<700B) and flexible undo/redo middleware for Zustand.

Core code:

// zundo/src/temporal.ts
_handleSet: (pastState, replace, currentState, deltaState) => {
  set({
    pastStates: get().pastStates.concat(deltaState || pastState),
    futureStates: [],
  });
};

Note deltaState || pastState:

Default stores the full state (pastState)
Optionally stores a diff (deltaState, computed via user-provided diff)

Although Zundo exposes a diff option, you must pick and configure a diff library and translate results yourself. For many developers, that adds learning cost. More importantly, diffing a large state tree frequently can itself become a performance bottleneck.

It’s a clever design:

Zero-cost abstraction: don’t opt in to diffs, pay no cost
Flexibility: choose any diff algorithm (microdiff, fast-json-patch, etc.) or roll your own
Control: pair with partialize to track only part of the state

Pros:

Supports diff-based storage; can optimize memory
Elegant API
Deep integration with Zustand

Limitations:

You must implement the diff logic yourself—not trivial
Zustand-only
Default behavior still stores full snapshots

The catch: building a reliable diff is non-trivial. You must:

Pick the right diff library
Write transformation code (like the example)
Handle edge cases (null, undefined, cycles, etc.)
Ensure reversibility (correct undo/redo)

And for very large trees, the diff stage itself can be expensive.

Travels: JSON Patch as a First-Class Citizen

This is where Travels comes in. Its core idea: use JSON Patch as the built-in, default storage format.

import { createTravels } from 'travels';

const travels = createTravels({
  title: 'My Doc',
  content: '...',
  // ... potentially a very large object
});

travels.setState((draft) => {
  draft.title = 'New Title';
});

// Internally, Travels stores:
// {
//   patches: [{ op: "replace", path: ["title"], value: "New Title" }],
//   inversePatches: [{ op: "replace", path: ["title"], value: "My Doc" }]
// }

// You can set { patchesOptions: { pathAsArray: true } } to make `path` a JSON path string.

No configuration required—JSON Patch is default.

Why Mutative?

Travels is built on Mutative. That choice matters:

// Mutative core capability
import { create } from 'mutative';

const [nextState, patches, inversePatches] = create(
  { count: 0 },
  (draft) => {
    draft.count++;
  },
  { enablePatches: true }
);

// patches: [{ op: "replace", path: ["count"], value: 1 }]
// inversePatches: [{ op: "replace", path: ["count"], value: 0 }]

Mutative provides:

Draft API – identical ergonomics to Immer
Native JSON Patch generation – no extra diff library
High performance – official benchmarks show up to 10× over Immer
Zero configuration – patch generation is built-in, not optional

This lets Travels leverage Mutative’s strengths directly, without forcing users to implement diffs like Zundo.

Real Memory Differences

A test with a 100KB complex object and 100 tiny edits (2 fields per edit):

Redux-undo:

// Stores full-state references
pastStates: [
  { /* 100KB object */ },
  { /* 100KB object */ },
  // ...
];
// 100 history entries: ~11.8 MB growth

Zundo (no diff):

// Default stores full state
pastStates: [
  { /* 100KB object */ },
  { /* 100KB object */ },
  // ...
];
// 100 history entries: ~11.8 MB growth

Travels:

// Automatically stores JSON Patches
patches: [
  [{ op: 'replace', path: ['field1'], value: 'new' }],   // ~50 bytes
  [{ op: 'replace', path: ['field2'], value: 'newer' }], // ~50 bytes
  // ...
];
// 100 histories: ~0.32 MB growth (≈97.3% saved)
// After serialization only ~20.6 KB (≈99.8% smaller than snapshots)

The gap is stark. For large objects with small edits, Travels can deliver ~40× memory savings, and 500×+ on serialized size.

Framework-Agnostic by Design

Another advantage: Travels is framework-agnostic. The core is a plain state manager:

// React
import { useSyncExternalStore } from 'react';

function useTravel(travels) {
  const state = useSyncExternalStore(
    travels.subscribe.bind(travels),
    travels.getState.bind(travels),
    travels.getState.bind(travels) // for SSR
  );
  return [state, travels.setState.bind(travels), travels.getControls()];
}

// Vue
import { ref } from 'vue';

function useTravel(travels) {
  const state = ref(travels.getState());
  travels.subscribe((newState) => {
    state.value = newState;
  });
  return { state, travels };
}

// Plain JS
travels.subscribe((state) => {
  document.querySelector('#app').innerHTML = render(state);
});

Use it anywhere: React, Vue, Svelte, Angular, or vanilla JS.

Side-by-Side Comparison

Dimension	Redux-undo	Zundo	Travels
Storage model	Snapshot references	Snapshot by default, diff	Built-in JSON Patch
Config complexity	Low	Medium (you write the diff)	Low
Memory efficiency	Medium (sharing helps)	Low→High (depends on diff)	High (out of the box)
Persistence fit	Poor (large data)	Poor (large data)	Excellent (compact + standard)
Frameworks	Redux only	Zustand only	Framework-agnostic
Highlights	filter, groupBy	partialize, custom diff	Auto/manual archive, mutable mode
Core LOC (approx.)	~440	~250	~640

A Few Neat Designs in Travels

1) Auto/Manual Archive Modes

// Auto: each setState becomes a history entry
const travels = createTravels({ count: 0 });
travels.setState({ count: 1 }); // +1 history
travels.setState({ count: 2 }); // +1 history

// Manual: batch multiple changes into one entry
const travels = createTravels({ count: 0 }, { autoArchive: false });
travels.setState({ count: 1 });
travels.setState({ count: 2 });
travels.setState({ count: 3 });
travels.archive(); // record only 0→3 as one history entry

Manual mode is ideal for complex interactions. E.g., a drag operation might trigger dozens of updates, but you want it to undo as one unit.

2) Mutable Mode for Reactive Frameworks

In Vue/MobX (Proxy-based reactivity), replacing object references breaks reactivity. Travels offers mutable mode:

// Vue example
import { reactive } from 'vue';

const travels = createTravels(reactive({ count: 0 }), { mutable: true });

// Travels mutates in place, keeping the Proxy reference
travels.setState((draft) => {
  draft.count++;
});
// Vue reactivity stays intact

Implementation sketch:

if (this.mutable) {
  apply(this.state as object, patches, { mutable: true });
  this.pendingState = this.state; // keep the reference stable
} else {
  this.state = apply(this.state as object, patches) as S;
}

This allows seamless use in reactive frameworks.

3) Sliding Window via `maxHistory`

const travels = createTravels({ count: 0 }, { maxHistory: 3 });

// 5 consecutive ops
increment(); // 1
increment(); // 2
increment(); // 3
increment(); // 4
increment(); // 5

// History window: [2, 3, 4, 5]
// You can undo back to 2, but not to 0 or 1 due to the window size
// however, reset() can return to the initial state 0.

Great for memory-constrained environments.

Hands-On Experience

I refactored a collaborative editor with Travels. Based on benchmark projections for a 100KB doc over 100 edits:

Memory: ~11.8MB (snapshots) → ~0.32MB (−97%)
Persistence size: ~11.7MB → ~116KB (−99%)
Serialization speed: ~12ms → ~0.06ms (≈200× faster)
Code volume: ~40% less (no custom diff code)
Undo/redo: still sub-millisecond (≈0.69ms undo / 0.27ms redo in the real-library test)

And the API is intuitive:

const travels = createTravels(initialState);

// Update
travels.setState((draft) => {
  draft.title = 'New';
  draft.sections[0].content = 'Updated';
});

// Time travel
travels.back();     // undo
travels.forward();  // redo
travels.go(5);      // jump to position 5
travels.reset();    // back to initial

// History info
travels.getHistory();
travels.getPosition();
travels.canBack();
travels.canForward();

If you’ve used Immer or Mutative, there’s essentially no learning curve.

Benchmarks

To validate the analysis, I wrote comprehensive benchmarks. Setup:

Object size: ~100KB (nested objects/arrays)
Ops: 100 tiny edits (2 fields per op)
Env: Node.js v22.21.1
Memory: measured precisely with --expose-gc

Full code: ./benchmarks/

Results

The latest runs (Node v22.21.1) come from executing yarn test:all, which runs both benchmark scripts with node --expose-gc.

Simulated implementations (`memory-performance-test.js`)

Metric	Redux-undo	Zundo	Travels
Memory (MB)	11.8	11.8	0.32
setState (ms)	42.74	41.27	88.16
Undo (ms)	0.08	0.07	18.65
Redo (ms)	0.12	0.02	20.34
Serialized size (KB)	11,626.66	11,626.46	20.6
Serialize (ms)	12.86	11.88	0.06
Deserialize (ms)	23.6	23.55	0.14

Travels keeps simulated history sizes tiny (20.6 KB vs ~11 MB snapshots) and serializes >200× faster, while snapshot stores remain unbeatable for undo/redo latency.
The Travels simulated setState cost (88 ms for 100 updates) is roughly 2× the snapshot stores, which matches expectations for generating JSON Patch.

Real libraries (`real-library-benchmark.js`)

Metric	Redux-undo	Zundo	Travels
Memory (MB)	0.05	0.04	0.16
setState (ms)	0.35	0.3	1.81
Undo (ms)	0.25	0.12	0.69
Redo (ms)	0.07	0.15	0.27
Serialized size (KB)	11,742.03	11,510.59	116.26
Serialize (ms)	12.63	11.59	0.61
Deserialize (ms)	28.87	22.66	0.42

Even with real packages, Travels shrinks serialized history by roughly 100× and finishes (de)serialization well under a millisecond.
Snapshot-based stacks still win hot-path operations (setState/undo/redo), so workloads that prioritize raw speed over persistence will continue to prefer Redux-undo/Zundo.

Performance Conclusion

Snapshot approaches (Redux-undo / default Zundo):

✅ Fastest setState
✅ Fastest undo/redo
❌ Huge memory
❌ Large serialized payloads
❌ Poor fit for persistence

Travels (built-in JSON Patch):

⚠️ Slower setState (patch generation)
⚠️ Slower undo/redo (patch application)
✅ Low memory
✅ Extremely small persistence ⭐
✅ Zero-config, out of the box
✅ Standard format, great for storage/analytics

Recommendation:

Simple apps, unconcerned with memory → Redux-undo/Zundo default
Need persistence, cross-framework, plug-and-play → Travels

When to Use It

Travels isn’t a silver bullet; it shines when:

✅ Good fit:

State objects are large (>10KB)
You need cross-framework reuse
Memory-sensitive environments (mobile, embedded)
You want fine-grained history control (manual archive, custom windows)

❌ Less ideal:

Very simple state (a few fields—Redux-undo is simpler)
Deeply invested in Zustand (Zundo is lighter)
You don’t care about memory

Comparison Summary

Redux-undo is a dependable standard in the Redux ecosystem but is Redux-bound.

Zundo is elegantly designed and supports diff optimization, but pushes diff complexity onto users.

Travels treats JSON Patch as a first-class citizen—out-of-the-box memory savings, framework-agnostic, and high-performance where it matters for persistence.

If you’re building:

Rich text editors
Graphics/design tools
Collaborative editing apps
Complex form systems

—i.e., anything with frequent undo/redo—Travels is worth a try.

Technical Details

JSON Patch Reversibility

Travels stores both patches and inversePatches:

// Change: count: 0 -> 1
patches: [{ op: 'replace', path: ['count'], value: 1 }];
inversePatches: [{ op: 'replace', path: ['count'], value: 0 }];

// Redo: apply patches
// Undo: apply inversePatches

This guarantees reliable time travel.

Why Mutative Is Fast

Mutative’s performance comes from:

Copy-on-write – only copy what changes
Shallow copy – shallow by default; deep when needed
Incremental patch generation – not a post-hoc diff

This is typically faster than Immer and far more efficient than JSON.parse(JSON.stringify()).

Why JSON Patch Excels at Persistence

Another key advantage: JSON Patch is extremely well suited to persistence.

Suppose you want “save the entire edit history locally and resume it on next launch”:

Redux-undo / Zundo (full snapshots):

// Data to persist
const dataToSave = {
  past: [
    { title: "Doc", content: "...", metadata: {...} },        // 100KB
    { title: "Doc v2", content: "...", metadata: {...} },     // 100KB
    // ... 100 histories
  ],
  present: { /* current state */ },
  future: []
};

// Write to localStorage/IndexedDB
localStorage.setItem('history', JSON.stringify(dataToSave));
// Problem: 10MB+ of serialized JSON

Travels (JSON Patch):

// Data to persist
const dataToSave = {
  state: travels.getState(),        // current state
  patches: travels.getPatches(),    // only patches, just a few KB
  position: travels.getPosition(),  // index
};

localStorage.setItem('travels-state', JSON.stringify(dataToSave.state));
localStorage.setItem('travels-patches', JSON.stringify(dataToSave.patches));
localStorage.setItem('travels-position', String(dataToSave.position));

// Restore
const travels = createTravels(
  JSON.parse(localStorage.getItem('travels-state')),
  {
    initialPatches: JSON.parse(localStorage.getItem('travels-patches')),
    initialPosition: Number(localStorage.getItem('travels-position')),
  }
);

Practical comparison (100 histories, from the benchmark):

Scenario	Redux-undo	Zundo	Travels
localStorage usage	~11.7 MB	~11.5 MB	~116 KB
`JSON.stringify` time	~12.6 ms	~11.6 ms	~0.61 ms (×20 faster) ⭐
`JSON.parse` time	~28.9 ms	~22.7 ms	~0.42 ms (×55 faster) ⭐
Storage savings	–	–	99% ⭐
IndexedDB write speed	Slow	Slow	Fast (100×+ less data)

Why such a gap?

Size: Patches are inherently compact
(De)serialization: tiny payloads make JSON faster
Quotas: localStorage caps at 5–10MB; Travels stores far more history

Real-World Patterns

This matters in many cases:

1) Offline-first apps

// Save to local storage on every change
travels.subscribe(() => {
  // Always-on autosave is feasible because data is tiny
  saveToLocalStorage({
    state: travels.getState(),
    patches: travels.getPatches(),
    position: travels.getPosition(),
  });
});

// Next launch resumes with full undo/redo history

2) Collaborative editing operation logs

// Sync patches to server
travels.subscribe((state, patches, position) => {
  // patches are standard JSON Patch (RFC 6902)
  // Send for:
  // - Operational history
  // - Conflict resolution
  // - Playback/replay
  api.syncPatches(patches);
});

3) Versioning & audit

// JSON Patch doubles as an operation log
const auditLog = travels.getPatches().patches.map((patch, index) => ({
  timestamp: Date.now(),
  user: currentUser,
  changes: patch, // standard, easy to review
  position: index,
}));

// Can export to human-friendly formats:
/*
2024-01-01 10:00:00 - User A:
  - Changed /title from "Draft" to "Final"
  - Added /tags/0 = "published"

2024-01-01 10:05:00 - User B:
  - Replaced /content/paragraphs/3
*/

4) Product analytics

// Analyze editing patterns
const stats = analyzePatches(travels.getPatches());
/*
{
  totalOperations: 150,
  avgPatchSize: 45,  // bytes
  mostEditedFields: ["/title", "/content/section[0]"],
  undoRate: 0.15
}
*/

Here, JSON Patch’s standardized, compact format is a huge win. Snapshot-based Redux-undo/Zundo are simple, but become unwieldy once persistence enters the picture.

Resources

Travels: https://github.com/mutativejs/travels
use-travel: https://github.com/mutativejs/use-travel (React hook)
zustand-travel: https://github.com/mutativejs/zustand-travel (Zustand middleware)
Mutative: https://github.com/unadlib/mutative

Final Thoughts

Before writing this post, I read the source code of all three libraries carefully. Redux-undo and Zundo are both excellent and have their places.

Travels isn’t a silver bullet; it targets a specific problem: when you need long histories, how do you minimize memory usage, reduce performance overhead, and stay as general and feature-complete as possible? Its philosophy is to trade compute for memory, which pays off the most when state is large, changes are small, and histories are long. No need to pick a diff library, write conversion logic, or wrangle edge cases—those are built in.

If you’re implementing or optimizing undo/redo—especially for collaborative editors, visual design tools, game editors, or any app that needs long operation histories and hits memory/perf ceilings—Travels is worth a try. It may not be the only answer, but it’s certainly one to consider.

This article is based on source reviews of redux-undo v1.1.0, zundo v2.3.0, and travels v0.9.0. If anything is inaccurate, corrections are welcome.

Unlocking Multithreading for Smoother Web Applications

Michael Lin — Mon, 16 Dec 2024 17:36:02 +0000

Coaction - An efficient and flexible state management library for building high-performance, multithreading web applications.

Repo: https://github.com/unadlib/coaction

Motivation

Modern web applications are becoming increasingly complex, pushing the boundaries of what's possible in the browser. Single-threaded JavaScript, while powerful, often struggles to keep up with the demands of sophisticated UIs, real-time interactions, and data-intensive computations. This bottleneck leads to performance issues, laggy or unresponsive interfaces, limitations in request connections, and ultimately, a compromised user experience.

While Web Workers (or SharedWorker) offer a path towards parallelism and improved performance, they introduce a new set of challenges. Managing state across threads, synchronizing data efficiently, and maintaining coherent application logic can quickly become a daunting task. Existing state management solutions often fall short in addressing these specific needs, either by being too tightly coupled to the worker thread or by introducing complex abstractions that hinder developer productivity.

Coaction was created out of the need for a state management solution that truly embraces the multithreading nature of modern web applications. It recognizes that performance and developer experience shouldn't be mutually exclusive. By leveraging the power of Web Workers and Shared Workers, Coaction allows developers to offload computationally intensive tasks and state management logic from the worker thread, resulting in a more responsive and fluid user interface.

More than just performance, Coaction is about enabling a more scalable and maintainable architecture for complex applications. The library's intuitive API, inspired by Zustand, ensures a smooth learning curve and a productive development workflow. Its support for Slices, namespaces, and computed properties promotes modularity and code organization, making it easier to manage large and evolving codebases.

Coaction's integration with data-transport unlocks a new level of flexibility in state synchronization. By supporting generic transport protocols, it opens up possibilities for various communication patterns and architectures, catering to the unique needs of different applications.

In essence, Coaction empowers developers to build the next generation of web applications without sacrificing performance, developer experience, or architectural integrity. It bridges the gap between the increasing complexity of web applications and the need for efficient, maintainable, and performant state management across threads. It's a tool designed for developers who strive to create exceptional user experiences in a world where parallelism and responsiveness are no longer optional, but essential. It also supports remote synchronization, making it suitable for building any CRDTs application as well.

Concepts and Features

Coaction aims to provide a secure and efficient solution for sharing and synchronizing state in multithreading environments (such as Web Workers, Shared Workers, or even across processes and devices) in web applications.

Key features include:

Multithreading Sync: Supports sharing state between webpage thread and the worker thread. With data-transport for generic communication, developers can avoid the complexities of message passing and serialization logic.
Immutable State with Optional Mutability: Powered by the Mutative library, the core provides an immutable state transition process while allowing performance optimization with mutable instances when needed.
Patch-Based Updates: Enables efficient incremental state changes through patch-based synchronization, simplifying its use in CRDTs applications.
Built-in Computed: Supports derived properties based on state dependencies, making it easier to manage and retrieve computed data from core states.
Slices Pattern: Easily combine multiple slices into a store with namespace.
Extensible Middleware: Allows for middleware to enhance the store's behavior, such as logging, time-travel debugging, or integration with third-party tools.
Integration with 3rd-Party Libraries: Supports popular frameworks like React, Angular, Vue, Svelte, and Solid, as well as state management libraries such as Redux, Zustand, and MobX.

Operating Modes and Fundamentals

This library operates in two primary modes:

Standard Mode
- In a standard webpage environment, the store is managed entirely within the webpage thread. Patch updates are disabled by default to ensure optimal performance in standard mode.
Shared Mode
- The worker thread serves as the primary source of the shared state, utilizing transport for synchronization.
- Webpage thread act as clients, accessing and manipulating the state asynchronously through a store.

In shared mode, the library automatically determines the execution context based on the transport parameters, handling the synchronization thread seamlessly.

You can easily use Coaction in your application to support multiple tabs, multithreading, or multiprocessing.

For example, for a 3D scene shared across several tabs, you can effortlessly handle their state management using Coaction.

https://github.com/user-attachments/assets/9eb9f4f8-8d47-433a-8eb2-85f044d6d8fa

Shared Mode - Sequence Diagram

Performance

Measure(ops/sec) to update 50K arrays and 1K objects, bigger is better(view source). [Coaction v0.1.5 vs Zustand v5.0.2]

Coaction x 5,272 ops/sec ±3.08% (63 runs sampled)
Coaction with Mutative x 4,626 ops/sec ±2.26% (83 runs sampled)
Zustand x 5,233 ops/sec ±2.68% (79 runs sampled)
Zustand with Immer x 253 ops/sec ±0.26% (93 runs sampled)

The fastest method is Coaction,Zustand

According to the provided performance data, Coaction's performance is comparable to Zustand's performance. However, Coaction with Mutative demonstrates a significant performance advantage compared to Zustand with Immer.

While standard Coaction achieves approximately 5,272 (ops/sec) and standard Zustand reaches around 5,233 (ops/sec), the most striking difference is observed with Zustand with Immer, which drastically drops to a mere 253 (ops/sec). Furthermore, Coaction with Mutative achieves around 4,626 (ops/sec). This means Coaction with Mutative is approximately 18.3X faster than Zustand with Immer (4626 / 253 ≈ 18.3). The data clearly indicates that Coaction offers superior performance characteristics compared to Zustand, and this advantage is especially pronounced when contrasted with Zustand's Immer implementation.

We will also provide more complete benchmarking.

Difference between Coaction and Zustand

Coaction's design philosophy is to provide a necessary and sufficiently simple API, making it easy for developers to use. Therefore, Coaction inherits the advantages of Zustand's API design and includes built-in support for features that Zustand does not offer.

	`coaction`	Zustand
Built-in multithreading	✅	❌
Support getter accessor	✅	❌
Built-in computed properties	✅	❌
Built-in namespace Slice	✅	❌
Built-in auto selector for state	✅	❌
Built-in multiple stores selector	✅	❌
Easy to implement middleware	✅	❌
Support `this` in getter/action	✅	❌

Installation

You can install @coaction/react for React application via npm, yarn, or pnpm.

npm install coaction @coaction/react

If you want to use the core library without any framework, you can install coaction via npm, yarn, or pnpm.

npm install coaction

Usage

Standard Mode Store

import { create } from '@coaction/react';

const useStore = create((set, get) => ({
  count: 0,
  increment: () => set((state) => state.count++)
}));

const CounterComponent = () => {
  const store = useStore();
  return (
    <div>
      <p>Count: {store.count}</p>
      <button onClick={store.increment}>Increment</button>
    </div>
  );
};

Shared Mode Store

counter.js:

import { create } from '@coaction/react';

export const counter = (set) => ({
  count: 0,
  increment: () => set((state) => state.count++)
});

worker.js:

import { create } from '@coaction/react';
import { counter } from './counter';

const useStore = create(counter);

import { create } from '@coaction/react';

const worker = new Worker(new URL('./worker.js', import.meta.url));
const useStore = create(counter, { worker });

const CounterComponent = () => {
  const store = useStore();
  return (
    <div>
      <p>Count in Worker: {store.count}</p>
      <button onClick={store.increment}>Increment</button>
    </div>
  );
};

Slices Pattern And Derived Data

import { create } from '@coaction/react';

const counter = (set) => ({
  count: 0,
  // derived data without cache
  get tripleCount() {
    return this.count * 3;
  },
  // derived data with cache
  doubleCount: get(
    (state) => [state.counter.count],
    (count) => count * 2
  ),
  increment() {
    set(() => {
      // you can use `this` to access the slice state
      this.count += 1;
    });
  }
});

const useStore = create({
  counter
});

Conclusion

Repo: https://github.com/unadlib/coaction

How to Build High-Performance Front-End Applications Based on Multithreading

Michael Lin — Fri, 19 Jan 2024 15:31:57 +0000

Motivation

As modern front-end applications become larger, leveraging the device's CPU multi-cores to improve performance is becoming an important trend.

Front-end applications often run in a single browser window, where JavaScript executes on a single thread. This means that common web applications cannot fully utilize a CPU's multiple cores. As applications become larger and more complex, this can lead to performance problems and a poor user experience.

However, there is good news: modern browsers widely support various types of workers, including Shared Workers, as IE and Safari v16 are gradually being phased out (regarding Shared Worker support). Shared Workers are a mature technology allowing multiple threads of JavaScript code to share data and communicate with each other. This makes them ideal for building multithreaded front-end applications.

Multithreaded front-end applications offer several benefits. They can better handle computation-intensive and slow-running JavaScript, which can improve performance and responsiveness. They can also increase the number of concurrent requests that can be processed, which can further improve the application's responsiveness.

Therefore, we aim to explore a web application framework that leverages multithreading.

Web application with Multithreading

In a multithreaded web architecture, we can leverage the Shared Web Apps concept of reactant-share to expand upon general multithreading programming.

Shared Web Apps allows web applications to run in multiple browser windows or workers. It uses a unique front-end server (such as a Shared Worker) to facilitate sharing across web apps, including code, local storage, state, and more. Regardless of the number of browser windows opened, there is always only one server application instance shared among multiple client applications in Shared Web Apps. This enables web tabs to focus solely on rendering, thereby better utilizing the device's multi-cores and ensuring the smooth operation of the web application.

Shared Web Apps offers the following benefits:

Reduces the mental burden of multithreading programming by implementing Isomorphism through a universal modular model. Isomorphism refers to the ability to execute the same code on the server thread, client thread, or other threads, simplifying multithreading programming.
Ensures the smooth operation of the front-end server thread by transferring compute-intensive tasks to another thread. This frees up the front-end server thread to focus on business logic and the client thread on rendering, improving performance and responsiveness.
Improves request concurrency through a more efficient multithreading model.

Coworker based on reactant-share

Building upon reactant-share, we have implemented the Coworker model, which facilitates state sharing across multiple threads, synchronizes state, and minimizes state changes using patches to ensure optimal performance in multithreaded execution.

The Coworker model comprises three types of threads:

client thread: The rendering thread, responsible for accepting shared state and solely rendering the web UI. Its lightweight nature ensures smooth rendering.
server thread: The main thread, responsible for executing the majority of the application's business logic. Smooth operation is also crucial for this thread.
Coworker thread: This thread handles compute-intensive business logic or request-intensive logic. This frees the server thread to focus on business logic. This allows the server thread to reduce blocking caused by JavaScript and makes it less susceptible to the impact of request-intensive logic.

In 'Base' mode, Reactant Shared Apps has only two threads: the Tab thread and the Coworker thread. By default, the Coworker thread utilizes a Web Worker.

Implementation of Coworker

For details on the underlying principles of Reactant-Share, please refer to the following link: https://reactant.js.org/blog/2021/10/03/how-to-make-web-application-support-multiple-browser-windows

Coworker comprises two modules:

CoworkerAdapter: Provides a communication channel between the server thread and the coworker thread.
CoworkerExecutor: Manages the synchronization of shared state between threads and custom Coworker type modules (used for proxy execution of coworkers). Coworker state is synchronously sent to the main thread in one direction. Each time a Coworker synchronizes its state, it includes a sequence tag. If the sequence is out of order, a complete Coworker state synchronization is automatically triggered to ensure the consistency of the shared state between the Coworker and the main thread.

Core Concepts and Advantages of Coworker

Isomorphism: The ability for all threads to execute the same code enhances the maintainability of multithreading programming in JavaScript.
Thread Interaction based on the Actor Model: By leveraging the Actor model, this approach reduces the cognitive load associated with multithreading programming in JavaScript.
Generic Transport Model: Coworker supports any transport mechanism based on data-transport (https://github.com/unadlib/data-transport), enabling it to run in any container that supports transport, including SharedWorker. The following is a list of supported transports:
- iframe
- Broadcast
- Web Worker
- Service Worker
- Shared Worker
- Browser Extension
- Node.js
- WebRTC
- Electron
- Any other port based on data-transport
High Performance Based on Mutative: Mutative offers high performance, being faster than a naive handcrafted reducer and 10 times faster than Immer. Mutative also maintains good performance when updating immutable data. Patches generated from shared state updates are used for state synchronization.
High Performance: Because Coworker handles a large number of requests and compute-intensive tasks, the main thread and rendering thread can maintain extremely high performance and a superior user experience.
Support for Large Applications: Reactant offers a complete module model design, including dependency injection and a class-first approach, along with various modular design patterns and dynamic module injection capabilities.
Separation of Service and Rendering View Modules: Service modules, primarily focused on business logic, can execute independently from view modules. This not only achieves separation of concerns but also allows each thread to have its own containerization.
Graceful Degradation: If the JavaScript host environment does not support SharedWorker, Coworker gracefully degrades to a regular SPA. This does not affect the behavior of existing applications.

API

delegate() - This function forwards execution to the specified module and function proxies within the Coworker, drawing inspiration from the Actor model.

Examples

We will create a Counter application using Coworker based on the 'Base' pattern.

First, create app.tsx, which contains the ProxyCounter module that will be executed in the Coworker.

Its calling method, delegate(this.proxyCounter, 'increase', []), is identical to that used in general Shared Web Apps. Whether it is executed with a proxy in the Coworker depends on the configuration of createApp.

import React from "react";
import {
  ViewModule,
  injectable,
  useConnector,
  action,
  state,
  delegate,
} from "reactant-share";

@injectable({
  name: "ProxyCounter",
})
export class ProxyCounter {
  @state
  count = 0;

  @action
  increase() {
    this.count += 1;
  }
}

@injectable({
  name: "AppView",
})
export class AppView extends ViewModule {
  constructor(public proxyCounter: ProxyCounter) {
    super();
  }

  @state
  count = 0;

  @action
  increase() {
    this.count += 1;
  }

  component(this: AppView) {
    const [count, proxyCount] = useConnector(() => [
      this.count,
      this.proxyCounter.count,
    ]);

    return (
      <>
        <div>{count}</div>
        <button type="button" onClick={() => delegate(this, "increase", [])}>
          +
        </button>
        <p>proxy in coworker</p>
        <div>{proxyCount}</div>
        <button
          type="button"
          onClick={() => delegate(this.proxyCounter, "increase", [])}
        >
          +
        </button>
      </>
    );
  }
}

Create the main file, index.ts. Here, we configure ProxyCounter as a module of Coworker and set isCoworker to false.

import { render } from 'reactant-web';
import {
  createSharedApp,
  Coworker,
  CoworkerOptions,
  ICoworkerOptions,
} from 'reactant-share';
import { AppView, ProxyCounter } from './app';

createSharedApp({
  modules: [
    Coworker,
    {
      provide: CoworkerOptions,
      useValue: {
        useModules: [ProxyCounter],
        worker: new Worker(new URL('./coworker.ts', import.meta.url)),
        isCoworker: false,
      } as ICoworkerOptions,
    },
  ],
  main: AppView,
  render,
  share: {
    name: 'SharedWorkerApp',
    type: 'Base',
  },
}).then((app) => {
  app.bootstrap(document.getElementById('app'));
  window.app = app;
});

Create the Coworker file, coworker.ts. Here, we also configure ProxyCounter as a module of Coworker, but this time set isCoworker to true.

import {
  createSharedApp,
  Coworker,
  CoworkerOptions,
  ICoworkerOptions,
} from 'reactant-share';
import { AppView, ProxyCounter } from './app';

createSharedApp({
  modules: [
    Coworker,
    {
      provide: CoworkerOptions,
      useValue: {
        useModules: [ProxyCounter],
        isCoworker: true,
      } as ICoworkerOptions,
    },
  ],
  main: AppView,
  render: () => {},
  share: {
    name: 'SharedWorkerApp',
    type: 'Base',
  },
}).then((app) => {
  self.app = app;
});

Thus far, we have created a basic application using a Coworker. Users trigger the delegate(this.proxyCounter, 'increase', []) function in the main thread via the UI. This action is forwarded to the coworker to execute the increase function of proxyCounter, and the shared state automatically synchronizes back to the main thread. The rendering update is handled by the useConnector() Hook.

Q&A

1. What are the challenges of multithreaded programming with Coworker based on reactant-share?

State sharing and synchronization among threads in multithreaded programming are inherently complex. Fortunately, Reactant-share ensures robustness through a consistent shared state design. The dependencies between isomorphic modules within Coworker should also be considered. During development, adopting concepts like Domain-Driven Design is recommended to prevent improper module design.

2. What are the potential use cases for Coworker?

Request Queue: Coworker is particularly well-suited for modules handling a high volume of requests. Running these within Coworker prevents them from occupying the main thread's request queue, allowing other main thread requests to execute unimpeded.
Large Task Execution Blocking: To avoid blocking the application's main thread during the execution of computationally intensive tasks, such tasks are ideal for asynchronous execution within Coworker.
Isolatable Modules: Coworker can also serve as a sandbox to isolate the execution of specific modules.

3. Are there specific examples demonstrating how Coworker can improve application performance?

In production, we have implemented Coworker in specific scenarios for modules involving text matching with large data volumes. This resulted in a substantial performance improvement, in some cases up to 10x, significantly enhancing the user experience. Previously, such computationally intensive text matching would require users to wait over 1 second, during which the webpage would be completely blocked. However, after implementing Coworker, the webpage blockage was reduced to less than 100ms (the actual degree of improvement varies depending on data size).

4. Is Coworker usable across different browsers, or is its support limited to within browser tabs? Can Coworker be used across tabs in different domains?

Coworker is a multithreaded model built upon reactant-share, which in turn is based on data-transport. Therefore, utilizing the WebRTC transport from data-transport within Coworker's CoworkerAdapter is sufficient to achieve cross-browser support. Additionally, to enable usage across tabs in different domains, we can implement Coworker under cross-domain tabs using an iframe and shared worker approach.

Conclusion

Front-end development is at a turning point, driven by advancements in front-end technology and browser capabilities. Multi-core CPUs and multithreading tools like Shared Workers and other Workers are now being utilized effectively in front-end development. The emergence of Shared Web Apps with Coworker introduces a novel multithreading model for front-end applications, significantly improving application performance, user experience, and code maintainability. For developers, this signifies more technical choices and challenges, but also greater opportunities and potential.

Multithreaded programming for front-end applications is likely to become a key solution for enhancing front-end performance. This will result in a smoother, more efficient, and more responsive user experience.

reactant-share Document：https://reactant.js.org/docs/shared-app
reactant-share Repo: https://github.com/unadlib/reactant/tree/master/packages/reactant-share

Announcing Mutative 1.0 - A New Era in Efficient Immutable Updates

Michael Lin — Fri, 15 Dec 2023 19:57:50 +0000

In the world of JavaScript development, managing immutable state efficiently is a cornerstone for high-performance applications. Today, we are excited to introduce Mutative 1.0, a JavaScript library that redefines the way we handle immutable updates. With performance that is 2-6x faster than naive handcrafted reducers and over 10x faster than Immer, Mutative 1.0 is set to transform our approach to immutable state management and make it more efficient.

Repository: https://github.com/unadlib/mutative

Key Features and Benefits

Mutative brings a suite of features designed to optimize performance and flexibility:

High Performance: At its core, Mutative is engineered for speed. It excels in scenarios involving large data structures, making it an ideal choice for complex applications.
Immutable Updates with Ease: Supporting a range of data structures including objects, arrays, Sets, Maps, and more customizable types, Mutative ensures that immutable updates are not just efficient but also straightforward to implement.
Flexible Configuration: The library offers optional freezing of immutable data, strict mode and supports the JSON Patch standard, providing developers with the flexibility to tailor it to their specific needs.

Performance

Reducer by object

Naive handcrafted reducer

// baseState type: Record<string, { value: number }>
const state = {
  ...baseState,
  key0: {
    ...baseState.key0,
    value: i,
  },
};

Mutative

const state = create(baseState, (draft) => {
  draft.key0.value = i;
});

Measure(seconds) to update the 1K-100K items object, lower is better(view source).

Mutative is up to 2x faster than naive handcrafted reducer for updating immutable objects.

Reducer by array

Naive handcrafted reducer

// baseState type: { value: number }[]
const state = [
  { ...baseState[0], value: i },
  ...baseState.slice(1, baseState.length),
];

Mutative

const state = create(baseState, (draft) => {
  draft[0].value = i;
});

Measure(seconds) to update the 1K-100K items array, lower is better(view source).

Mutative is up to 6x faster than naive handcrafted reducer for updating immutable arrays.

Mutative vs Immer Performance

Mutative passed all of Immer's test cases.

Measure(ops/sec) to update 50K arrays and 1K objects, bigger is better(view source). [Mutative v1.0.0 vs Immer v10.0.3]

Naive handcrafted reducer - No Freeze x 4,361 ops/sec ±0.99% (90 runs sampled)
Mutative - No Freeze x 6,178 ops/sec ±1.41% (95 runs sampled)
Immer - No Freeze x 5.79 ops/sec ±0.33% (19 runs sampled)

Mutative - Freeze x 849 ops/sec ±0.19% (96 runs sampled)
Immer - Freeze x 383 ops/sec ±0.77% (94 runs sampled)

Mutative - Patches and No Freeze x 764 ops/sec ±0.20% (96 runs sampled)
Immer - Patches and No Freeze x 5.72 ops/sec ±0.34% (19 runs sampled)

Mutative - Patches and Freeze x 418 ops/sec ±1.23% (94 runs sampled)
Immer - Patches and Freeze x 279 ops/sec ±0.54% (90 runs sampled)

The fastest method is Mutative - No Freeze

Run yarn benchmark to measure performance.

OS: macOS 12.6, CPU: Apple M1 Max, Node.js: 16.14.2

Immer relies on auto-freeze to be enabled, if auto-freeze is disabled, Immer will have a huge performance drop and Mutative will have a huge performance lead, especially with large data structures it will have a performance lead of more than 50x.

So if you are using Immer, you will have to enable auto-freeze for performance. Mutative is disabled auto-freeze by default. With the default configuration of both, we can see the 16x performance gap between Mutative (6,178 ops/sec) and Immer (383 ops/sec).

Overall, Mutative has a huge performance lead over Immer in more performance testing scenarios.

Comparison with Immer

While Immer has been a popular choice for handling immutable data, Mutative 1.0 takes it a step further, and Mutative is over 10x faster than Immer. It not only matches all of Immer's test cases but also introduces additional features such as custom shallow copy, strict mode, and a default setting that does not freeze data. These enhancements make Mutative more efficient, especially in handling large-scale applications. Here’s a quick comparison of the two libraries:

	Mutative	Immer
Custom shallow copy	✅	❌
Strict mode	✅	❌
No data freeze by default	✅	❌
Non-invasive marking	✅	❌
Complete freeze data	✅	❌
Non-global config	✅	❌
async draft function	✅	❌
Fully compatible with JSON Patch spec	✅	❌

Mutative has fewer bugs such as accidental draft escapes than Immer, view details.

Getting Started

Integrating Mutative into your JavaScript projects is straightforward. You can install it using Yarn or NPM, and its API is intuitive and easy to grasp. Here’s a quick start example:

Install Mutative using Yarn or NPM:

yarn add mutative

Import the create function from Mutative and use it to create a new immutable state:

import { create } from 'mutative';

const baseState = {
  foo: 'bar',
  list: [{ text: 'coding' }],
};

const state = create(baseState, (draft) => {
  draft.list.push({ text: 'learning' });
});

expect(state).not.toBe(baseState);
expect(state.list).not.toBe(baseState.list);

This simple code snippet demonstrates the ease with which you can manage immutable state using Mutative.

Conclusion

As we unveil Mutative 1.0, we're not just releasing a new library; we're inviting JavaScript developers to step into a future where state management is no longer a bottleneck but a catalyst for performance and innovation. Mutative 1.0 stands as a testament to what modern JavaScript can achieve - a blend of speed, efficiency, and ease of use that elevates coding from a task to an art.

This library is more than a tool; it's a paradigm shift in how we approach immutable updates. With its unparalleled performance, Mutative 1.0 is poised to redefine best practices in JavaScript development, making cumbersome state management a thing of the past. It's an invitation to developers to push the boundaries of what's possible, to build applications that are not just functional but phenomenally fast and responsive.

As the JavaScript landscape continues to evolve, Mutative 1.0 will undoubtedly play a pivotal role in shaping the future of state management. We encourage the community to explore its potential, to integrate it into their projects, and to contribute to its growth. Together, we can drive the evolution of JavaScript development, making our applications not just faster, but smarter, and more intuitive than ever before.

Join us in embracing the future with Mutative 1.0 - where efficiency meets innovation, and where every line of code brings us closer to the zenith of JavaScript potential.

Mutative - 10x faster than Immer

Michael Lin — Sat, 31 Dec 2022 15:22:48 +0000

Mutative - A JavaScript library for efficient immutable updates, 10x faster than Immer by default, even faster than naive handcrafted reducer.

Motivation

Writing immutable updates by hand is usually difficult, prone to errors, and cumbersome. Immer helps us write simpler immutable updates with "mutative" logic.

But its performance issue causes a runtime performance overhead. Immer must have auto-freeze enabled by default(Performance will be worse if auto-freeze is disabled), such immutable state with Immer are not common. In scenarios such as cross-processing, remote data transfer, etc., we have to constantly freeze these immutable data.

There are more parts that could be improved, such as better type inference, non-intrusive markup, support for more types of immutability, Safer immutability, and so on.

This is why Mutative was created.

Repo: https://github.com/unadlib/mutative

Mutative vs Immer Performance

Measure(ops/sec) to update 50K arrays and 1K objects, bigger is better(view source).[Mutative v0.3.2 vs Immer v9.0.18]



Naive handcrafted reducer - No Freeze x 3,713 ops/sec ±0.86% (89 runs sampled)
Mutative - No Freeze x 5,323 ops/sec ±1.69% (93 runs sampled)
Immer - No Freeze x 8 ops/sec ±0.88% (23 runs sampled)

Mutative - Freeze x 875 ops/sec ±1.20% (95 runs sampled)
Immer - Freeze x 320 ops/sec ±0.45% (92 runs sampled)

Mutative - Patches and No Freeze x 752 ops/sec ±0.16% (96 runs sampled)
Immer - Patches and No Freeze x 7 ops/sec ±1.32% (23 runs sampled)

Mutative - Patches and Freeze x 425 ops/sec ±0.33% (95 runs sampled)
Immer - Patches and Freeze x 239 ops/sec ±0.99% (89 runs sampled)

The fastest method is Mutative - No Freeze

Run yarn benchmark to reproduce them locally.

OS: macOS 12.6, CPU: Apple M1 Max, Node.js: 16.14.2

So if you are using Immer, you will have to enable auto-freeze for performance. Mutative is disabled auto-freeze by default. With the default configuration of both, we can see the performance gap between Mutative (5,323 ops/sec) and Immer (320 ops/sec).

Overall, Mutative has a huge performance lead over Immer in more performance testing scenarios. Run yarn performance to get all the performance results locally.

Features and Benefits

Mutation makes immutable updates
Support apply patches
Optional freezing state
Custom shallow copy
Immutable and mutable data markable
Strict mode for safer mutable data access
Support for JSON patches
Support for reducer

Difference between Mutative and Immer

-	Mutative	Immer
Custom shallow copy	✅	❌
Strict mode	✅	❌
No data freeze by default	✅	❌
Non-invasive marking	✅	❌
Complete freeze data	✅	❌
Non-global config	✅	❌
Support IE browser	❌	✅

Mutative has fewer bugs such as accidental draft escapes than Immer, view details.

Mutative size is 4.16KB with minified and gzipped. Immer size with same features is 4.67 KB.

Installation



yarn install mutative # npm install mutative

Usage



import { create } from 'mutative';

const baseState = {
  foo: 'bar',
  list: [{ text: 'coding' }],
};

const state = create(baseState, (draft) => {
  draft.foo = 'foobar';
  draft.list.push({ text: 'learning' });
});

create(baseState, (draft) => void, options?: Options): newState

The first argument of create() is the base state. Mutative drafts it and passes it to the arguments of the draft function, and performs the draft mutation until the draft function finishes, then Mutative will finalize it and produce the new state.

Use create() for more advanced functions by setting options, which also supports currying.

strict - boolean, the default is false.

Forbid accessing non-draftable values in strict mode.

enablePatches - boolean, the default is false.

Enable patch, and return the patches and inversePatches.

enableAutoFreeze - boolean, the default is false.

Enable autoFreeze, and return frozen state.

mark - () => ('mutable'|'immutable'|function)

Set a mark to determine if the object is mutable or if an instance is an immutable, and it can also return a shallow copy function(AutoFreeze and Patches should both be disabled).

FAQs

Why doesn't Mutative support IE?

Mutative is a library that relies heavily on the use of the Proxy object, which is a feature of modern web browsers that allows the interception of various operations on objects. As such, Mutative may not be fully compatible with older browsers that do not support the Proxy object, such as Internet Explorer. However, these older browsers make up a very small percentage of the overall browser market, so the impact on compatibility is likely minimal.

Why does Mutative have such good performance?

Mutative optimization focus is on shallow copy optimization, more complete lazy drafts, finalization process optimization, and more.

I'm already using Immer, can I migrate smoothly to Mutative?

Yes. Unless you have to be compatible with Internet Explorer, Mutative supports almost all of Immer features, and you can easily migrate from Immer to Mutative.

Migration is also not possible for React Native that does not support Proxy.

Conclusion

Mutative is inspired by Immer.

Mutative aims at efficient immutable updates, focusing on performance improvements and better APIs to bring better development experience. If you think Mutative is good, feel free to give it a star!

Repo: https://github.com/unadlib/mutative

How to make Web application support multiple browser windows

Michael Lin — Sun, 03 Oct 2021 04:57:19 +0000

Motivation

When we develop a Single-Page Application, we usually only define its behavior in a single browser window, and even if the same application is opened on multiple browser windows, in most cases it is only synchronized with the local storage, and the state of each application in each window is not synchronized in real time (unless the server synchronizes), they run in isolation and are relatively independent.

However, this means that more browser windows will generate more and more independent application instances, which may have different UI states and often inevitably have the same network requests or WebSocket connections, which may also mean a bad user experience (as users may have become accustomed to) and excessive usage of server resources.

So what does it mean to have applications that supports multiple browser windows?

Application instance sharing: code sharing, local storage sharing, state sharing, and more
Lower server resource usage
Better user consistency experience
Smoother web applications

But it's not easy to keep large Web applications running smoothly.

Web applications are still primarily built in JavaScript, which is a single-threaded programming language, and slow JavaScript code can prevent the browser’s rendering. The good news is that mainstream browsers are gradually supporting more different types of workers, especially Service Workers, which are used to implement PWAs (Progressive Web Apps) that greatly enhance the user experience. And the latest modern browsers also provide Web Worker, Shared Worker. With IE becoming deprecated this year, there is good support for these workers. Currently, only Safari lacks support for Shared Worker among modern browsers.

So what does it mean for Web applications to be "multi-threaded" with Worker?

"The State Of Web Workers In 2021" post covers a number of unpredictable performance issues. With these browser workers we will likely be better able to deal with computationally complex and slow-running JS code to keep web applications smooth.

It's time to rethink why we can't make web applications support multiple browser windows and improve the performance of web applications. New architectural requirements bring new framework requirements, and such applications we call it Shared Web Apps.

Shared Web Apps

Even though we want users to open as few application windows as possible, the fact remains that many users will open the same application in multiple browser windows.

Shared Web Apps supports running web applications in multiple browser windows.

It has a unique Server thread to share the Shared Web Apps, whether it's code sharing, local storage sharing, state sharing, and so on. No matter how many browser windows are opened, Shared Web Apps always has only one server app instance for multiple client apps sharing. We all know that DOM operations are expensive. In Shared Web Apps, the client app instance is only responsible for rendering, and except for state sync the client app will become very lightweight and almost all business logic will run in the server app.

The client app only renders UI, making better use of the device's multiple cores to ensure that the client app is smooth
Solve the problems caused by multiple browser windows
Better separation of concerns

reactant-share - A framework for building Shared Web Apps

reactant-share Repo: reactant

To build such Shared Web Apps, reactant-share was created. reactant-share is based on the reactant framework and react library, which supports the following features.

Dependency injection
Immutable state management
View module
Redux plug-in module
Test bed for unit testing and integration testing
Routing module
Persistence module
Module dynamics
Shared web app support multiple browser windows
- Shared tab
- SharedWorker
- ServiceWorker
- Browser extension
- Detached window
- iframe

reactant-share is very easy to use, you can use it to quickly build a Shared Web Apps. it greatly reduces the complexity of supporting multi-browser window application architecture.

How it works

When reactant-share starts, it creates a server app instance and multiple client app instances (one per browser window) in the browser, but the only instance that is really running in full is the server app instance, which is responsible for almost all of the application's logic, and multiple client app instances simply synchronize state and render. The state model of reactant-share uses immutable state, and reactant is based on Redux, so we trigger state sync from server app to client app via Redux's dispatch.

The user triggers the client app proxy method through DOM events
This proxy method is executed on the server app.
The server app state is synchronized back to the client app.

Example

The overall workflow of the reactant-share is shown in the figure below. Here is an example of a shared-worker type counter app.

First, we define a counter app module and view module in app.view.tsx

import React from "react";
import {
  ViewModule,
  createApp,
  injectable,
  useConnector,
  action,
  state,
  spawn,
} from "reactant-share";

@injectable({ name: "counter" })
class Counter {
  @state
  count = 0;

  @action
  increase() {
    this.count += 1;
  }
}

@injectable()
export class AppView extends ViewModule {
  constructor(public counter: Counter) {
    super();
  }

  component() {
    const count = useConnector(() => this.counter.count);
    return (
      <button type="button" onClick={() => spawn(this.counter, "increase", [])}>
        {count}
      </button>
    );
  }
}

Next, we use createSharedApp() to create the client app, whose options must contain workerURL, the worker url that will create a shared worker (if it hasn't been created yet).

import { render } from "reactant-web";
import { createSharedApp } from "reactant-share";
import { AppView } from "./app.view";

createSharedApp({
  modules: [],
  main: AppView,
  render,
  share: {
    name: "SharedWorkerApp",
    port: "client",
    type: "SharedWorker",
    workerURL: "worker.bundle.js",
  },
}).then((app) => {
  // render only
  app.bootstrap(document.getElementById("app"));
});

Finally, we just create the worker file worker.tsx and build it as worker.bundle.js for the workerURL option.

import { createSharedApp } from "reactant-share";
import { AppView } from "./app.view";

createSharedApp({
  modules: [],
  main: AppView,
  render: () => {
    //
  },
  share: {
    name: "SharedWorkerApp",
    port: "server",
    type: "SharedWorker",
  },
}).then((app) => {
  // render less
});

The specific workflow of increase looks like this.

The user clicks the button in client app.
spawn(this.counter, "increase", []) will be executed, which passes the parameters about the proxy execution to the server app.
The server app will execute this.counter.increase(), and sync the updated state back to each client apps.

spawn() in reactant-share is inspired by the actor model.

reactant-share Framework

Multiple modes

Shared tab - It is suitable for running in browsers that do not support SharedWorker/ServiceWorker. The server app is an instance with rendering that also runs in a browser window. In multiple browser windows, there is also only one server app, and after it is closed or refreshed, one instance of the other client apps will be converted to a server app.
SharedWorker - If there is no browser compatibility requirement, reactant-share is highly recommended to use this mode, and reactant-share also does a graceful degradation, so if the browser does not support SharedWorker then the app will run in Shared-Tab mode.
ServiceWorker - If Shared Web Apps are intended to be PWA (Progressive Web Apps), then using this mode would be ideal, and it also supports the automatic graceful degradation to Shared-Tab mode.
Browser extension - The browser extension allows a background thread, the server app of reactant-share can run in this background thread, and the UI can run in the client app.
Detached window - reactant-share allows sub-applications to run as Detached windows or to be quickly merged into a more complete application.
iframe - reactant-share allows each child application to run on an iframe.

Example repo: SharedWorker/Detached window/iframe

User Experience

Since reactant-share's multiple instances are logic-sharing and state-sharing, when a user opens the same reactant-share application in multiple browser windows, the only instance that is actually running in full is the server app.

The rendering-only client app will be so smooth that it will almost never freeze due to JS code, and the consistent application state will allow users to switch between multiple browser windows without any worries.

Development Experience

reactant-share provides CLI and full support for Typescript, as well as support for Shared-Tab, SharedWorker, ServiceWorker and Browser extension, and other different types of runtime modes out of the box. Built-in testbed for module testing, Routing and Persistence modules, and module dynamics support for lazy loading of reactant-share applications.

Service Discovery / Communications

Since reactant-share uses data-transport, reactant-share supports almost all the transports supported by data-transport.The client app and the server app, whichever is loaded first, the client app will wait for the server app to finish starting and get all the initial application state from it.

Using the actor model in the client app to design spawn(), we can do spawn(counterModule, 'increase', []) to let the server app proxy the execution of the module method and respond and sync both the state and the result back to the client app.

But if we need direct communication between the client app and the server app, then we need to use the PortDetector module.

class Counter {
  constructor(public portDetector: PortDetector) {
    this.portDetector.onServer(async (transport) => {
      const result = await transport.emit("test", 42);
      // result should be `hello, 42`
    });
    this.portDetector.onClient((transport) => {
      transport.listen("test", (num) => `hello, ${num}`);
    });
  }
}

Tracking/Debugging

Since reactant-share is based on Redux, it fully supports Redux DevTools, and the immutable time travel that Redux brings will make debugging easy.

Fault Tolerance / Data Consistency

Since state synchronization after the client app uses spawn() to get the server app proxy to execute each time may cause it to be out of order in edge cases for various reasons, reactant-share integrates reactant-last-action, which provides sequence markers to keep If the client app receives a synchronized action that checks for an exception in the sequence, the client app will launch a full state synchronization to correct the action sequence.

In addition, when the browser does not support the Worker API, reactant-share will perform a graceful degradation (e.g. SharedWorker mode -> Shared-Tab mode -> SPA mode).

Isolation

Regardless of modes such as Shared-Tab, SharedWorker or ServiceWorker, each application instance runs in isolation and their basic interactions can only be triggered by spawn() to synchronize state.

Configuration

reactant-share provides CLI, you just need to run npx reactant-cli init shared-worker-example -t shared-worker to get a project of reactant-share with SharedWorker mode. If you want to change its mode, you just need to change the configuration of createSharedApp().

createSharedApp({
  modules: [],
  main: AppView,
  render,
  share: {
    name: 'ReactantExampleApp',
    port: 'client',
-   type: 'SharedWorker',
+   type: 'ServiceWorker',
    workerURL: 'worker.bundle.js',
  },
}).then((app) => {
  app.bootstrap(document.getElementById('app'));
});

With that, we can quickly turn SharedWorker mode into ServiceWorker mode.

Transport/Performance

Since the client app only renders and receives synchronized state. So the client app keeps running smoothly when the size of each dispatch update state does not exceed 50M. reactant uses Immer patch to update, usually this patch will be very small and reactant also does DEV checking for patch minimization updates. In fact, in most scenarios, the patch will not be that large.

Update state size	Volume of data	Deserialization
30 Array * 1,000 items	1.4 M	14 ms
30 Array * 1,0000 items	14 M	130 ms
1000 Array * 1,000 items	46 M	380 ms

Notebook: 1 GHz Intel Core M / 8 GB 1600 MHz DDR3

benchmarking of the reactant-share module with derived data cache

Number of modules and states	Total number of states	Each state update
100 modules * 20 states	2,000	3 ms
200 modules * 30 states	6,000	9 ms
300 modules * 100 states	30,000	44 ms

Notebook: 1 GHz Intel Core M / 8 GB 1600 MHz DDR3

Therefore, reactant-share still performs well in large projects.

Complexity

Whether it's practicing clean architecture, DDD, OOP or even FP, reactant-share has more openness to architect highly complex projects at will. reactant-share provides a few optional features, but the only one that shouldn't be missed is DI. reactant-share's DI is inspired by Angular, and it is very similar to Angular's DI. The complexity of coding that comes with architectural design is often determined by the final specification of the practice, but reactant-share hopes to help with such complex architectural design at the framework level.

Security

For reactant-share applications, the communication between server/client only serializes and deserializes state and parameters, so it is almost impossible to cause framework-level security issues. Of course, enabling https and usingSubresource Integrity are both necessary for any project that values front-end security, and we should also be concerned about XSS security in React documentation.

Testing

reactant-share provides testBed() to facilitate module testing. For example,

const { instance } = testBed({
  main: Counter,
  modules: [],
});

For integration testing of server app/client app interactions, reactant-share also provides mockPairTransports() for mock transport.

const transports = mockPairTransports();

createSharedApp({
  modules: [],
  main: AppView,
  render,
  share: {
    name: "SharedWorkerApp",
    port: "client",
    type: "SharedWorker",
    transports: {
      client: transports[0],
    },
  },
}).then((app) => {
  const clientApp = app;
  // render only
  app.bootstrap(document.getElementById("app"));
});

createSharedApp({
  modules: [],
  main: AppView,
  render: () => {
    //
  },
  share: {
    name: "SharedWorkerApp",
    port: "server",
    type: "SharedWorker",
    transports: {
      client: transports[1],
    },
  },
}).then((app) => {
  const serverApp = app;
  // render less
});

After mocking transport like this, clientApp and serverApp can be easily tested for integration.

APIs

@injectable()

You can use @injectable() to decorate a module that can be injected and then use the emitDecoratorMetadata using TypeScript, or @inject() to inject the dependency.

@state

@state is used to decorate a class property that will create a reducer for Redux.

@action

It updates the redux state with mutations via the class method.

class Todo {
  @state
  list: { text: string }[] = [];

  @action
  addTodo(text: string) {
    this.list.push({ text });
  }
}

ViewModule/useConnector()

ViewModule is a view module with a component, which is completely different from React class component. The component of ViewModule is a function component that is used for the state connection between the module and the UI (using useConnector()) and for the application view bootstrap.

spawn()

spawn() transfers class methods execution from the client app to the server app and synchronizes the state to all client apps. It is inspired by the Actor model, but unlike other actor models, reactant-share's spawn() does not create new threads.

createSharedApp()

reactant-share supports multiple modes, and you can use createSharedApp() to create multiple different Shared Web Apps that interact with each other via transport APIs.

Q&A

Can reactant-share completely solve the complexity of the architecture?

Although reactant-share tries to reduce some complexity at the framework level, the complexity of large applications does not depend entirely on the framework itself, so even using reactant-share to architect a large project does not completely guarantee that it is absolutely clean, efficient, and maintainable. It involves testing strategy, code specification, CI/CD, development process, module design, and many other point.

But in terms of module model and shared model, reactant-share already provides as clean a design as possible. If you are interested in reactant-share, you can try it quickly.

Does reactant-share have no cons at all? Are there any limitations to using it?

reactant-share is a framework for building Shared Web Apps. But such a model is not free, and it will face performance issues with data transfer (The high maintenance cost of the SharedArrayBuffer has forced us to abandon it for now as well. In fact this is a problem caused by the fact that JS "multithreading" does not share memory efficiently).

Although Shared Web Apps lets the client App run in a render-only client thread, it introduces the additional overhead of synchronous state transfer. We must ensure that it is lightweight and efficient enough. While reactant-share does state patch based on Immer, it is always difficult to ensure that each patch is minimally updated.

reactant-share provides a development option enablePatchesChecker. In development mode, it is enabled by default. Any mutation operation that is not a valid mutation will be alerted, usually eliminating the alert, and reactant-share will try to keep the update size as minimal as possible.

Conclusion

Front-end frameworks and architectures are always evolving. With full Worker support in modern browsers and an increasing number of multi-core CPU devices, we have reached a mature stage in our exploration of some multi-threaded running Web Apps. We have reasons to believe that the future Web App will be designed with lower complexity and run smoothly with multiple threads. It can fully utilize the user's device resources and give the user a good experience, and the developer does not need to have too many multi-threaded programming burden.

This is what reactant-share wants to try and work on.

If you think reactant-share is interesting, feel free to give it a star.

Repo: reactant

A progressive micro frontends framework - Fronts

Michael Lin — Sat, 03 Jul 2021 02:31:41 +0000

Micro Frontends

An architectural style where independently deliverable frontend applications are composed into a greater whole.

As front-end development becomes increasingly complex, traditional large front-end projects should likely end up being difficult to maintain due to over-coupling, and therefore Micro Frontends is also gaining attention in front-end architectures.

Front-end application modules dynamic will become one of the new trends in front-end development, and it will be possible to solve the problem of code base maintainability and delivery efficiency more thoroughly.

Benefits and Value of Micro Frontends

Independence and Autonomy

Only if the overall process of application development can be developed, deployed and managed independently of the code base, etc., then the front-end project can have true independence guaranteed. And this possibility of team autonomy is also in line with Conway's Law, which states that "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure", thus bringing about a possible new form of organizational management.

Technology Agnostic

Technology agnostic facilitates the collaboration of multiple teams with different technology stacks. The smooth migration of technology stacks also brings greater convenience to the continuous iteration and technology upgrade of the older business system.

Runtime Integration

In modern front-end development processes, we most often see build-time integration. Whereas before, runtime integration happened to separate modules more independently. Micro frontends also happen to integrate well with such micro module concepts and keep such modules independent and dependency sharing.

Decoupled Modularity & Composable

In large front-end projects, we have high requirements for modular decoupling, often based on different types of divisions, such as business type modularity, technical service type modularity, and so on. The composable of individual micro frontends particles in turn allows for good module consistency and overall customization differentiation across multiple deliverable families, and can greatly reduce business duplication.

In general, the proper practice of micro frontends architecture will bring far-reaching value to the long-term maintenance of some large front-end projects.

Motivation

Among the many micro frontends solutions, single-spa and Module Federation are the best of them.

single-spa is a micro frontends framework based on router configuration. The centralization of configuration brings some limitations, such as it is difficult to granulate nestable micro frontends, module granularity control, module sharing, and so on.

In 2019, Zack Jackson proposed and implemented Module Federation. Module Federation is a completely different concept from single-spa, and allows a JavaScript application to dynamically load code from another application. It completely solves the problem of code dependency sharing and runtime modularity. The idea is true - A game-changer in JavaScript architecture as mentioned in Zack Jackson's article. And it's currently supported by Webpack, Next.js, and Rollup.

Although the Module Federation concept is so amazing, it has not yet gone further to provide a more complete and fully targeted micro frontends framework implementation, and this is what Fronts is trying to do.

Hotspots of Micro Frontends Framework

Based on the current mainstream micro frontends frameworks or concepts, the following is a compilation of the main hotspots involved.

Should the granularity level be application level or module level

Module level is obviously more advantageous in terms of flexibility and granularity, but there is clearly an advantage to supporting application level in order to be compatible with some not so modern front-end projects, so we need a framework that supports both. If application-level runtime integration is required, it is clear that just using Module Federation's Webpack is not enough, we also need a runtime application-level granular entry point loader.

Whether the entry point file is HTML or JavaScript

From a modern engineering perspective, most front-end application entry points are JS-based, and some previous front-end projects have used HTML alone as the entry point. The trade-off is that building a micro frontends system for applications where HTML is the main entry point is bound to be a longer and more complex of processes. Such a library would be better suited as a standalone sub-package, while the overall framework should take JS files as the entry point.

Is it necessary to support perfect module sharing

Module sharing is a problem that must be solved by micro frontends frameworks, otherwise the duplication of resources at runtime will make micro frontends less valuable. Currently, only Webpack with Module Federation allows such module sharing to be handled at build time, with dynamic dependency sharing at runtime. No better solution than Module Federation has yet emerged.

CSS/JS isolation trade-off

Isolation of CSS is almost required and is supported by many micro frontends frameworks. We may have to do all kinds of hijacking to ensure the security, performance and stability, and also consider the compatibility of different browsers. However, JS isolation is relatively expensive to implement, and the fact that such isolation is required for modern front-end engineering depends on the actual situation of each micro frontend.

Generic micro frontend and support multiple containers with multiple modes (Or SSR, etc.)

In large front-end projects, it is often not just about building a single web application, but possibly multiple web applications, or even more front-end application types, such as Electron applications, browser extensions, native applications, etc. So a good micro frontends framework should be able to run more kinds of containers and build a variety of application types, but also preferably compatible with building traditional SPA and micro frontends applications. Module Federation also initially implemented in the next.js implementation of SSR support.

Version control and dependency management

With rapid iteration and business growth, various module management becomes very important, so when a large front-end project practices micro frontends architecture at a later stage, version control and dependency management will become especially important, which will determine the delivery efficiency and maintainability.

To solve these problems, Fronts was created.

What's Fronts

Fronts is a progressive micro frontends framework for building Web applications, and it's based on the module federation of Webpack.

Repo: https://github.com/unadlib/fronts

Non-module-federation - Although Fronts is based on the concept of module federation, it also supports non-module-federation mode.
Decentralized configuration - Configure site.json for dependency management in each Fronts app, support for nested micro frontends.
Cross frameworks - No framework or technology stack is restricted.
Code splitting & lazy loading - Support code splitting within the Fronts app as a module, it can be lazy loaded by other Fronts app as a dependent module.
CSS isolation - Optional CSS isolation solution.
Lifecycle - Fronts provide concise lifecycle for Fronts app entry.
Web Components & iFrame - Support for multiple frontend containers.
Multiple patterns - Support for building micro-frontends app and non-micro-frontends app.
Monorepo & TypeScript - Friendly support for Monorepo and TypeScript, which are mutually appropriate technology stack.
Version control - It's used for efficient and dynamic delivery apps such as canary release.
Zero hijacking - Fronts didn't do any hijacking, maintaining originality and possible loss of performance and security.
Generic Communication - Fronts provides concise and generic communication APIs, which supports almost all frontend environments.

Benefits of Fronts

Fronts is a concise and easy to understand micro frontends framework.

Set site.json to define a micro frontend, similar to a package.json in Node.js.

{
  "name": "app1",
  "exports": ["./src/bootstrap"],
  "dependencies": {
    // If version control is enabled,
    // here it looks like: `"app2": "1.0.0"`
    "app2": "http://localhost:3002/remoteEntry.js"
  },
  "shared": {
    "react": { "singleton": true },
    "react-dom": { "singleton": true }
  }
}

Fronts is progressive.

If every front-end application does not support Module Federation, it will still work well as a micro frontend, with on-demand runtime modes, and as projects are upgraded, they can gradually be made to support Module Federation and eventually version control can be enabled. With support for multiple granularity levels, build types, module types, shared types, runtime types, and communication types, Fronts can almost meet all kinds of micro frontends architectures.

Fronts APIs are clean and simple.

Fronts provides three sets of loaders useApp(), useWebComponents() and useIframe(). It also provides an micro frontend launcher boot() and a Webpack configuration generator createWebpackConfig(). With these APIs, you will be able to do micro frontends development quickly and efficiently.

Example

We will build a micro frontends project based on Fronts, where app1 is the main entry point and it will depend on app2.

You can follow this article(React without create-react-app Webpack 5) to quickly create app1 and app2 React projects.

Assuming you've completed these steps, let's get started with a quick taste of the wonderful micro frontends development of Fronts.

Install fronts-react and fronts-bundler in the projects.

# with NPM
npm install fronts-react fronts-bundler

# or with Yarn
yarn add fronts-react fronts-bundler

Set up site.json and webpack.config.js in the projects

We define app1 as a parent micro frontend and it depends on app2.

app1/site.json:

{
  "name": "app1",
  "exports": [],
  "dependencies": {
    "app2": "http://localhost:3002/remoteEntry.js"
  }
}

app2 doesn't have any dependencies, it acts as a micro frontend and we define it to export ./src/bootstrap as a micro frontends entry, this entry of app2 end will be used by app1.

app2/site.json:

{
  "name": "app2",
  "exports": ["./src/bootstrap"],
  "dependencies": {}
}

Wrap the Webpack config with createWebpackConfig() in config/webpack.config.js in the projects.

const { createWebpackConfig } = require('fronts-bundler');

module.exports = createWebpackConfig(originalWebpackConfig);

Define the default exported bootstrap function in app2/src/bootstrap.jsx and use boot() to get it booted.

import React from 'react';
import ReactDOM from 'react-dom';
import { boot } from 'fronts-react';
import App from './App';

export default function render(element) {
  ReactDOM.render(<App />, element);
  return () => {
    ReactDOM.unmountComponentAtNode(element);
  };
}

boot(render, document.getElementById('root'));

Load app1/src/App.jsx with useApp() to import app2.

import React from 'react';
import { useApp } from 'fronts-react';

export const App = () => {
  const App2 = useApp({
    name: 'app2',
    loader: () => import('app2/src/bootstrap'),
  });
  return <App2 />;
};

Run yarn start, and app2 is rendered as a micro frontend on app1.

Example repo：https://github.com/unadlib/fronts-example

Notes

Built-in packages

The mainstream front-end frameworks are still React, Vue and Angular. When a micro frontend uses one of them, it is recommended to use Fronts' built-in packages, such as fronts-react, fronts-vue and fronts-ng, and when it comes to other frameworks not supported by the built-in packages or no framework, then please use fronts.

Built-in Package API

Each built-in package contains three sets of loaders useApp(), useWebComponents(), useIframe(). useApp() provides loose CSS isolation, useWebComponents() provides strict CSS isolation, and useIframe() provides native strict CSS isolation and JS isolation.

Version Control

Fronts does not have full version control suite support and currently only supports self-built registry server.

Monorepo & TypeScript

Large front-end projects often mean a high level of complexity, so Fronts are well suited for use in a combination of technology stacks like Monorepo and TypeScript. You get a great development experience in type safety, code management and runtime integration. when each micro frontend is used as a Monorepo sub-package, you just run SPA=true yarn start and switch the micro frontends development mode to the traditional SPA development mode.

Conclusion

The front-end architecture based on Fronts, Monorepo, and TypeScript will significantly improve codebase management, type safety, business development and delivery efficiency, and enable multiple combination of product business capabilities, high reuse and consistency of business code, and diversity of application types.

Every large front-end project that tries to implement micro frontends architecture has different or similar requirements, so by analyzing the demands and needs of their own large front-end projects and using them to build or choose their own micro front-end architecture, they can really solve their own main engineering problems.

With a general module concept based on Module Federation, Fronts tries to solve the main problems of micro frontends in a more targeted and systematic way, such as cross-framework, dependency sharing, dependency management, version control, compatibility with multiple runtime containers and patterns, etc.

Fronts wants to evolve from more micro frontends architecture requirements to an efficient micro frontends framework.

Repo: https://github.com/unadlib/fronts