DEV Community: Md. Zahirul Haque

Onefold + Hono + Cloudflare: Building a Fast SSR App on the Edge

Md. Zahirul Haque — Sun, 06 Sep 2026 04:27:49 +0000

Server-side rendering usually comes with baggage: a big framework, a heavy runtime, and a hosting bill to match. It doesn't have to. Pair three small, TypeScript-first tools and you get real SSR that ships tiny bundles and runs at the edge for pennies:

Onefold for the UI
Hono for the server
Cloudflare Workers for hosting

This is a great fit for content-heavy apps where the first paint has to be fast and the budget has to stay small. This walkthrough builds a real (if small) server-rendered app end to end and ships it to Cloudflare. By the last section you'll have HTML rendering on a Worker and coming alive in the browser.

One promise up front: every snippet here uses the actual Onefold API and actually compiles. No invented method names, no hand-wavy pseudocode.

Why this stack

Each piece earns its place:

Piece	What it brings
Onefold	Fine-grained reactivity, real DOM rendering, core under 6kb gzipped, SSR built in
Hono	A tiny, fast web framework with a clean API and first-class Workers support
Cloudflare Workers	Global edge deployment, generous free tier, one-command deploys with Wrangler

The combination is a good fit for job boards, blogs, documentation sites, dashboards — anything that benefits from fast initial loads and doesn't need the weight of a larger framework. Onefold renders to a plain HTML string on the server, which is exactly what a Worker wants to return, and its client core is small enough that hydration is cheap.

How the pieces fit together

Before any code, here's the request flow:

Browser request
      ↓
Cloudflare Worker (Hono routes it)
      ↓
renderHTML(() => Home())     ← Onefold renders the page to an HTML string
      ↓
Hono returns a full HTML document (fast first paint, no JS needed)
      ↓
client.js loads → mounts interactive bits into placeholders → interactive

Three things are worth calling out up front, because they shape the whole design:

Onefold's SSR is a snapshot. renderHTML runs your component with a server version of the html tag that produces a string. Reactive expressions are evaluated once, and event handlers are stripped — they can't run in static HTML anyway.
Routing lives on the server, in Hono — not in Onefold. Onefold ships a client-side Router, but it builds DOM nodes directly (document.createElement), so it can't run inside renderHTML on a Worker where there's no DOM. That's fine: Hono is a web framework, routing is its job. Each Hono route renders the matching page. Navigation between pages uses plain <a href> links.
Hydration is selective. Instead of re-rendering the whole page on the client, we mark the interactive parts with a container (#interactive) and mount just those in the browser. Fully static pages ship no JavaScript logic at all. This is the same pattern Onefold's own SSR example uses.

Project setup

Start with a Hono project targeting Cloudflare Workers:

npm create hono@latest onefold-ssr-app

When prompted for a template, choose cloudflare-workers. Then move in and add Onefold:

cd onefold-ssr-app
npm install onefold

Onefold has zero runtime dependencies, so this adds one small package and nothing else.

Project structure

Here's the layout we'll build:

onefold-ssr-app/
├── src/
│   ├── index.ts          # Hono server + routes (runs on the Worker)
│   ├── shell.ts          # HTML document wrapper
│   ├── client.ts         # Client entry — selective hydration
│   ├── pages/
│   │   ├── Home.ts        # SSR page: dynamic data + interactive placeholder
│   │   ├── About.ts       # Fully static SSR page
│   │   └── NotFound.ts    # 404 page
│   ├── server/
│   │   └── data.ts        # Server-only data (DB/KV/API stand-in)
│   └── shared/
│       ├── Nav.ts         # Server-rendered nav (plain <a> links)
│       └── Counter.ts     # Interactive component (client-only)
├── public/               # Static assets (client.js lands here)
├── wrangler.toml
└── package.json

The pages/ are Onefold components built from the html tag, which is SSR-safe. Counter.ts is the one interactive piece that runs in the browser.

1. The pages

`src/shared/Nav.ts`

Navigation is a plain server-rendered list of links. We use real <a href> elements rather than Onefold's client-only Link component, so the nav renders fine through renderHTML.

import { html } from 'onefold';

const LINKS: [string, string][] = [
  ['/', 'Home'],
  ['/about', 'About'],
];

export function Nav(activePath: string): unknown {
  return html`
    <nav>
      ${LINKS.map(
        ([href, label]) => html`
          <a href=${href} class=${activePath === href ? 'active' : ''}>${label}</a>
        `
      )}
    </nav>
  `;
}

`src/server/data.ts`

Here's the part that makes SSR feel like SSR: data that only exists on the server, baked into the HTML before it ships. In a real app this is your database, KV, D1, or an upstream API. For the demo it's a static list plus a little request-time metadata — enough to prove the page is rendered fresh on every request, not cached at build time.

export interface Post {
  id: number;
  title: string;
  author: string;
  minutesAgo: number;
}

const POSTS: Post[] = [
  { id: 1, title: 'Shipping SSR to the edge with Onefold', author: 'Ada', minutesAgo: 8 },
  { id: 2, title: 'Why fine-grained reactivity beats diffing', author: 'Lin', minutesAgo: 42 },
  { id: 3, title: 'Zero-egress uploads with R2', author: 'Sam', minutesAgo: 121 },
  { id: 4, title: 'A tiny router that stays out of your way', author: 'Noor', minutesAgo: 300 },
];

/** Pretend this is an async DB/KV read — it's async on purpose. */
export async function getLatestPosts(limit = 3): Promise<Post[]> {
  return POSTS.slice(0, limit);
}

export interface RenderInfo {
  renderedAt: string; // ISO timestamp, computed per request
  colo: string;       // Cloudflare edge location (data center code)
  country: string;
}

export function getRenderInfo(req: Request): RenderInfo {
  // Cloudflare attaches request metadata on `request.cf` (plus some headers).
  const cf = (req as Request & { cf?: IncomingRequestCfProperties }).cf;
  return {
    renderedAt: new Date().toISOString(),
    colo: cf?.colo ?? req.headers.get('cf-ray')?.split('-')[1] ?? 'local',
    country: (cf?.country as string) ?? req.headers.get('cf-ipcountry') ?? 'local',
  };
}

The getRenderInfo bit is a nice touch for a demo — it pulls the actual Cloudflare data center that served the request off request.cf, so once deployed you can literally see which edge location rendered your page.

`src/pages/Home.ts`

Now the Home page takes that data as props and renders it into the markup: a posts list and a "rendered in {colo} at {timestamp}" line. All of it lands in the HTML on the server. The only client-side piece is still the counter, which mounts into the #interactive placeholder.

import { html } from 'onefold';
import { Nav } from '../shared/Nav';
import type { Post, RenderInfo } from '../server/data';

interface HomeProps {
  posts: Post[];
  info: RenderInfo;
}

function ago(minutes: number): string {
  if (minutes < 60) return `${minutes}m ago`;
  const h = Math.floor(minutes / 60);
  return h < 24 ? `${h}h ago` : `${Math.floor(h / 24)}d ago`;
}

export function Home({ posts, info }: HomeProps): unknown {
  return html`
    <div class="app">
      ${Nav('/')}
      <h1>Onefold on the edge</h1>
      <p>
        This page was rendered to HTML on a Cloudflare Worker in
        <strong>${info.colo}</strong> (${info.country}) at
        <time datetime=${info.renderedAt}>${info.renderedAt}</time>.
        Refresh and the timestamp changes — proof it's rendered per request.
      </p>

      <h2>Latest posts</h2>
      <ul class="posts">
        ${posts.map(
          (post) => html`
            <li>
              <span class="post-title">${post.title}</span>
              <span class="post-meta">by ${post.author} · ${ago(post.minutesAgo)}</span>
            </li>
          `
        )}
      </ul>

      <h2>Interactive bit</h2>
      <div id="interactive">
        <p class="loading">Loading counter…</p>
      </div>
    </div>
  `;
}

Notice there's no () => wrapper around info.colo or the post fields. That's deliberate — this data is fixed for the life of the request, so a one-time interpolation is exactly right. The reactive () => wrapper is for values that change after render, which on the server never happens. Save it for the client.

`src/shared/Counter.ts`

The interactive bit. This runs in the browser during hydration, so it uses signals and event handlers normally.

import { html, createSignal } from 'onefold';

export function Counter(): Node {
  const count = createSignal(0);

  return html`
    <button onclick=${() => count.set(n => n + 1)}>
      Clicked ${() => count()} times
    </button>
  ` as Node;
}

Two Onefold rules are in play here, and they matter:

The click handler is a function, not a string, and the attribute starts with on.
The count read is wrapped in () =>. That closure is what makes it reactive — without it the value renders once and never updates. This is the single most common Onefold mistake, so it's worth burning into memory.

`src/pages/About.ts`

A fully static page. No #interactive container, so it ships zero JavaScript logic.

import { html } from 'onefold';
import { Nav } from '../shared/Nav';

export function About(): unknown {
  return html`
    <div class="app">
      ${Nav('/about')}
      <h1>About</h1>
      <p>
        A small but complete SSR example using
        <strong>Onefold</strong>, <strong>Hono</strong>, and
        Cloudflare Workers.
      </p>
    </div>
  `;
}

`src/pages/NotFound.ts`

import { html } from 'onefold';
import { Nav } from '../shared/Nav';

export function NotFound(): unknown {
  return html`
    <div class="app">
      ${Nav('')}
      <h1>404 — Not found</h1>
      <p>That page doesn't exist. Head back <a href="/">home</a>.</p>
    </div>
  `;
}

2. The HTML shell

A small helper wraps a page's rendered body in a full HTML document, including the global styles and the <script> that loads the client bundle.

`src/shell.ts`

export function shell(title: string, body: string): string {
  return `<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>${title} — Onefold + Hono SSR</title>
  <style>
    body {
      font-family: system-ui, -apple-system, sans-serif;
      max-width: 720px; margin: 48px auto; padding: 0 20px; line-height: 1.6;
    }
    nav { margin-bottom: 2rem; padding-bottom: 1rem;
      border-bottom: 1px solid #e5e5e5; display: flex; gap: 1rem; }
    nav a { color: #4338ca; text-decoration: none; }
    nav a.active { font-weight: 600; }
    .loading { color: #94a3b8; }
    time { color: #4338ca; font-variant-numeric: tabular-nums; }
    .posts { list-style: none; padding: 0; }
    .posts li { display: flex; flex-direction: column; gap: 2px;
      padding: 10px 0; border-bottom: 1px solid #f0f0f0; }
    .post-title { font-weight: 600; }
    .post-meta { color: #94a3b8; font-size: 0.85rem; }
    button { padding: 0.6rem 1.2rem; font-size: 1rem; cursor: pointer;
      border-radius: 6px; border: 1px solid #ccc; background: #f8f8f8; }
    button:hover { background: #eee; }
  </style>
</head>
<body>
  <div id="app">${body}</div>
  <script type="module" src="/client.js"></script>
</body>
</html>`;
}

3. The Hono server

Here's where routing happens, and where the dynamic data comes together. The / route gathers its data on the server — getLatestPosts() and getRenderInfo() — then hands it to the page inside renderHTML. renderHTML is available from onefold and from the dedicated onefold/ssr subpath; the explicit subpath keeps the intent obvious. It accepts a component function and can be sync or async, so await is the safe default — exactly what you want when a page fetches data first.

`src/index.ts`

import { Hono } from 'hono';
import { renderHTML } from 'onefold/ssr';
import { shell } from './shell';
import { Home } from './pages/Home';
import { About } from './pages/About';
import { NotFound } from './pages/NotFound';
import { getLatestPosts, getRenderInfo } from './server/data';

const app = new Hono();

app.get('/', async (c) => {
  // Gather request-time data on the server, then render it into the HTML.
  const posts = await getLatestPosts(3);
  const info = getRenderInfo(c.req.raw);

  const body = await renderHTML(() => Home({ posts, info }));
  return c.html(shell('Home', body));
});

app.get('/about', async (c) => {
  const body = await renderHTML(() => About());
  return c.html(shell('About', body));
});

app.notFound(async (c) => {
  const body = await renderHTML(() => NotFound());
  return c.html(shell('404', body), 404);
});

export default app;

If a page needs data, fetch it inside the render function and pass it to the page component:

app.get('/posts', async (c) => {
  const body = await renderHTML(async () => {
    const posts = await c.env.DB.getPosts();
    return PostsPage(posts);
  });
  return c.html(shell('Posts', body));
});

4. The client entry — selective hydration

The client's only job is to bring the interactive parts to life. We look for the #interactive container; if it's there (Home has one, About doesn't), we mount the Counter into it. Static pages load this script, find no container, and do nothing.

`src/client.ts`

import { mount } from 'onefold';
import { Counter } from './shared/Counter';

const root = document.getElementById('interactive');
if (root) {
  mount(Counter(), root);
}

mount replaces the container's contents (the "Loading…" placeholder) with the live counter. The server gave the browser a fully-formed page for instant paint; this swaps in the interactive piece once JS arrives.

5. Build configuration

The Worker code (src/index.ts) is bundled by Wrangler. The client code (src/client.ts) is a separate browser bundle we build ourselves and serve as a static asset. esbuild handles that in one line.

Add esbuild:

npm install -D esbuild

Then update the scripts in package.json:

{
  "scripts": {
    "build:client": "esbuild src/client.ts --bundle --format=esm --minify --outfile=public/client.js",
    "build": "npm run build:client",
    "dev": "npm run build && wrangler dev",
    "deploy": "npm run build && wrangler deploy"
  }
}

The client bundle lands in public/client.js, which Cloudflare serves as a static asset at /client.js — matching the <script src="/client.js"> in the document.

6. Cloudflare configuration

Point Wrangler at the Worker entry and the static assets directory.

`wrangler.toml`

name = "onefold-ssr-app"
main = "src/index.ts"
compatibility_date = "2025-07-18"

[assets]
directory = "./public"
binding = "ASSETS"

Use a compatibility_date your installed Wrangler runtime supports — if you set one in the future, Wrangler falls back to its latest supported date with a warning. The [assets] block tells Cloudflare to serve files from public/ directly from its edge cache. Static asset requests (like /client.js) are handled before your Worker runs, so serving the client bundle costs you nothing in Worker execution time.

7. Run it locally

npm run dev

Open http://localhost:8787 (Wrangler prints the exact port). View source: the posts list and the "rendered at" line are right there in the HTML, no JavaScript required to see them. Hit refresh a few times and watch the timestamp change on each load — that's the page being rendered fresh per request, not served from a cache. Once client.js loads, the counter starts working. Visit /about and notice it's fully static: it renders on the server and ships no interactive JavaScript at all.

Once you deploy, that rendered in ... line will show the real Cloudflare data center that served you — a fun, tangible reminder that your HTML is being built at the edge, close to the visitor.

8. Deploy

npm run deploy

Wrangler builds the client bundle, uploads your Worker and static assets, and puts the app on Cloudflare's global network. First deploy will prompt you to log in if you haven't already.

Optional: storing files with R2

If your app grows to handle uploads — resumes on a job board, images on a blog — Cloudflare R2 is a natural fit because it has no egress fees. Add a bucket binding:

[[r2_buckets]]
binding = "MY_BUCKET"
bucket_name = "my-app-uploads"

Then reach it from any Hono route through c.env.MY_BUCKET, using the standard R2 API (put, get, delete). No extra client library needed.

A few honest caveats

This is SSR plus selective hydration, not resumability. The server sends real HTML for a fast first paint; the client then mounts the interactive pieces into their placeholders. The #interactive container briefly shows its fallback before JS swaps in the live component. For content-driven pages that's exactly what you want. If you need above-the-fold widgets interactive with zero visible swap, render their initial state into the placeholder so the fallback already looks right.
Route on the server, not with Onefold's Router. Onefold's Router and Link build DOM directly, so they can't run inside renderHTML on a Worker. Let Hono handle routing and use plain <a href> links between pages. Onefold's client Router is great for a pure SPA — just not in the SSR path.
Keep server components DOM-free. Anything that only exists in the browser — window, document, localStorage, or Onefold's mount/Router — will throw during SSR. Keep those in client.ts and the components it imports.
Onefold is young. It's capable and the API is stable enough to build on, but it's a newer project than the big frameworks. Weigh that against the small bundles and zero-config toolkit.

Wrapping up

That's the whole stack: a server-rendered app that's small on the wire, quick to paint, and cheap to run anywhere in the world.

Onefold renders pages to HTML on the Worker, then hydrates just the interactive pieces in the browser.
Hono routes requests and returns the document with almost no overhead.
Cloudflare serves it from the edge and hosts your client bundle for free.

It's a solid foundation to grow into a real product — a blog, a job board, a dashboard, a small SaaS. Add routes, pull in data, and the shape stays the same.

Code
Demo

Links:

Happy building.

Microfrontends Without the Complexity: How Onefold Handles Multi-Team Frontend Architecture

Md. Zahirul Haque — Fri, 21 Aug 2026 14:16:05 +0000

Microfrontends solve a real problem: letting multiple teams ship frontend code independently without stepping on each other. But the implementation usually involves a week of webpack config, Module Federation plugins, custom shell apps, and fragile runtime contracts.

What if it was just... an import?

import { loadRemote, configureSecurity } from 'onefold/remote';

Onefold is a reactive UI framework that ships microfrontend support as a first-class feature. No plugins, no extra packages, no build tool gymnastics. In this article, I'll walk through how it works and build a working multi-team dashboard from scratch.

The Problem With Traditional Microfrontend Setups

If you've tried microfrontends before, you've probably dealt with:

Module Federation — powerful but deeply coupled to webpack, complex config, version mismatches between shared dependencies
iframe-based isolation — simple but terrible UX (no shared styling, no proper resizing, navigation is painful)
Custom loaders — hand-rolled <script> injection with no security model, no integrity checks, no CSS isolation
Runtime CSS conflicts — Team A's .card class stomps Team B's .card class
No security model — anyone who controls a CDN can inject arbitrary code into your app

Onefold addresses all of these with a small, focused API that handles the hard parts: security, isolation, loading, and error handling.

The Architecture

The mental model is simple:

Host Shell (your main app)
 │
 ├── loadRemote('https://billing.cdn.com/widget.js')
 │   └── Team: Payments (deployed independently)
 │
 └── loadRemote('https://analytics.cdn.com/widget.js')
     └── Team: Data (deployed independently)

Each remote is a standard ES module that exports a function returning a DOM Node. The host loads these modules dynamically, verifies their integrity, and mounts them with CSS isolation.

No special bundler plugin. No runtime registry. Just ES modules over HTTP.

Security First: configureSecurity

Before loading any remote code into your app, you establish a security perimeter. Call this once at app startup — before any loadRemote calls:

import { configureSecurity } from 'onefold/remote';

configureSecurity({
  trustedOrigins: [
    'https://billing.cdn.com',
    'https://analytics.cdn.com',
  ],
  requireIntegrity: true,
  timeout: 10000,
  blockAll: false,
});

Any loadRemote() call that targets an origin not in the trusted list will be blocked immediately — the module never loads, the code never executes.

The 7 Security Layers

Onefold's remote loader enforces multiple layers of protection:

Origin Allowlist — Only modules from trustedOrigins can load. All other origins are rejected before any network request.
SRI Integrity — When requireIntegrity is true, fetched content is verified against a SHA hash before execution. A compromised CDN can't serve malicious code.
Timeout — Modules taking longer than the timeout are aborted. Prevents slow-loris attacks.
Isolation — Shadow DOM or iframe sandboxing prevents DOM/CSS leaks between host and remote.
CSP Compatible — No eval(), no Function(), no inline scripts. Works with strict Content-Security-Policy headers.
Credential Isolation — Remote fetches use credentials: 'omit' — cookies are never sent to remote origins.
Kill Switch — Set blockAll: true to instantly disable all remote loading in production.

Configuration Options

Option	Type	Default	Description
`trustedOrigins`	string[]	`[]`	Allowed origins (protocol + host + port). No wildcards.
`requireIntegrity`	boolean	`false`	Require SRI hash for every remote load
`blockAll`	boolean	`false`	Emergency kill switch — blocks all remotes instantly
`timeout`	number	`10000`	Maximum load time in ms before failing

Loading a Remote: loadRemote

Here's the core API:

import { html } from 'onefold';
import { loadRemote } from 'onefold/remote';

const BillingWidget = loadRemote({
  url: 'https://billing.cdn.com/widget.js',
  integrity: 'sha384-oqVuAfXRKap7fdgcCY5uykM6...',
  isolate: 'shadow',
  permissions: ['dom'],
  fallback: () => html`<div class="spinner">Loading billing...</div>`,
  onError: (err) => html`<div class="error">Billing unavailable: ${err.message}</div>`,
});

// Use it like any other component
function Dashboard(): Node {
  return html`
    <div>
      <h1>Dashboard</h1>
      ${BillingWidget({ accountId: 'ACCT-7291' })}
    </div>
  `;
}

loadRemote returns a component function. You call it with props, and it returns a Node — just like any other Onefold component. The loading, verification, and mounting happen transparently.

loadRemote Options

Option	Type	Default	Description
`url`	string	required	URL to the remote ES module
`exportName`	string	`'default'`	Which export to use as the component factory
`isolate`	`'none' \	'shadow' \	'iframe'`
`integrity`	string	—	SRI hash (required when `requireIntegrity` is on)
`permissions`	array	`['dom']`	What the remote can access
`fallback`	`() => Node`	—	UI shown while loading
`onError`	`(err: Error) => Node`	—	UI shown on failure
`props`	object	—	Static props (can also pass dynamically at call time)
`timeout`	number	—	Override global timeout for this specific remote

Isolation Modes

You get three levels of isolation depending on your trust model:

`'none'` — Direct Mount

The remote's DOM is inserted directly into the host page. Fastest rendering, but CSS can conflict. Use only for code you fully trust and control (same team, same design system).

const InternalWidget = loadRemote({
  url: 'https://internal.cdn.com/header.js',
  isolate: 'none',
});

`'shadow'` — Shadow DOM Encapsulation

The remote is mounted inside a closed Shadow DOM. Its CSS cannot affect the host, and the host's CSS cannot bleed in. This is the sweet spot for most multi-team setups:

const TeamWidget = loadRemote({
  url: 'https://widgets.company.com/billing.js',
  isolate: 'shadow',
});

The Shadow DOM uses mode: 'closed' — external JavaScript cannot pierce into the remote's internals.

`'iframe'` — Full Sandbox

Complete JS + CSS + DOM isolation. The remote runs in a sandboxed iframe with restricted permissions. It cannot access the host's cookies, localStorage, or DOM:

const UntrustedWidget = loadRemote({
  url: 'https://third-party-vendor.com/widget.js',
  isolate: 'iframe',
  permissions: ['dom'],  // no 'storage', no 'navigation'
});

The iframe auto-resizes to content height via ResizeObserver + postMessage. No fixed-height hacks needed.

When to Use Which

Scenario	Isolation	Why
Same team, shared design system	`'none'`	No CSS conflicts, maximum performance
Different teams, same company	`'shadow'`	CSS isolation without JS overhead
Third-party vendor code	`'iframe'`	Full sandbox, zero trust

Writing a Remote Widget

A remote is just an ES module that exports a default function. Here's a complete billing widget:

// billing-widget.ts — deployed to https://billing.cdn.com/widget.js
import { createSignal, html, css } from 'onefold';

interface BillingProps {
  accountId?: string;
}

const styles = css`
  .billing-widget { font-family: -apple-system, sans-serif; }
  .billing-header {
    display: flex;
    align-items: center;
    justify-content: space-between;
    margin-bottom: 16px;
  }
  .billing-header h3 { margin: 0; font-size: 16px; }
  .badge {
    font-size: 11px;
    padding: 3px 8px;
    border-radius: 12px;
    background: rgba(34,197,94,0.1);
    color: #16a34a;
    font-weight: 600;
  }
  .plan-card {
    background: linear-gradient(135deg, #6366f1, #8b5cf6);
    border-radius: 12px;
    padding: 20px;
    color: white;
    margin-bottom: 16px;
  }
  .plan-name { font-size: 20px; font-weight: 700; margin-bottom: 4px; }
  .plan-price { font-size: 14px; opacity: 0.8; }
  .usage-bar {
    height: 6px;
    background: rgba(255,255,255,0.3);
    border-radius: 3px;
    margin-top: 12px;
    overflow: hidden;
  }
  .usage-fill {
    height: 100%;
    background: white;
    border-radius: 3px;
    transition: width 0.3s;
  }
  .invoices { list-style: none; padding: 0; margin: 0; }
  .invoices li {
    display: flex;
    justify-content: space-between;
    padding: 10px 0;
    border-bottom: 1px solid #f3f4f6;
    font-size: 13px;
  }
  .invoices li:last-child { border-bottom: none; }
  .amount { font-weight: 600; }
  button {
    width: 100%;
    padding: 10px;
    background: #4f46e5;
    color: white;
    border: none;
    border-radius: 8px;
    cursor: pointer;
    font-size: 14px;
    margin-top: 12px;
  }
  button:hover { background: #4338ca; }
`;

export default function BillingWidget(props: BillingProps): Node {
  const usage = createSignal(67);

  const invoices = [
    { date: 'Jul 2026', amount: '$49.00', status: 'Paid' },
    { date: 'Jun 2026', amount: '$49.00', status: 'Paid' },
    { date: 'May 2026', amount: '$39.00', status: 'Paid' },
  ];

  return html`
    <div class=${styles.scope}>
      <div class="billing-widget">
        <div class="billing-header">
          <h3>Billing — ${props.accountId ?? 'Default'}</h3>
          <span class="badge">Active</span>
        </div>

        <div class="plan-card">
          <div class="plan-name">Pro Plan</div>
          <div class="plan-price">$49/month · Renews Aug 1</div>
          <div class="usage-bar">
            <div class="usage-fill" style=${() => ({ width: `${usage()}%` })}></div>
          </div>
        </div>

        <h4 style=${{ fontSize: '14px', margin: '0 0 8px' }}>Recent Invoices</h4>
        <ul class="invoices">
          ${invoices.map(inv => html`
            <li>
              <span>${inv.date}</span>
              <span class="amount">${inv.amount}</span>
              <span>${inv.status}</span>
            </li>
          `)}
        </ul>

        <button onclick=${() => usage.set(Math.min(100, Math.floor(Math.random() * 40) + 60))}>
          Simulate API Usage
        </button>
      </div>
    </div>
  `;
}

Key points about remotes:

Imports from onefold like any normal component
Uses css scoped styles (won't leak even without Shadow DOM — double protection)
Exports a default function that accepts props and returns a Node
Gets bundled into a single JS file and deployed to a CDN
Has its own reactive state (createSignal) — fully self-contained

Building a Complete Host Shell

Here's a full host application that loads two remote widgets from different teams:

// host/main.ts
import { createSignal, html, css, mount } from 'onefold';
import { loadRemote, configureSecurity, preloadRemote } from 'onefold/remote';

// Step 1: Lock down which origins can load code into this app
configureSecurity({
  trustedOrigins: ['http://localhost:3001'],
  timeout: 10000,
});

// Remote URLs (in production: different CDNs per team)
const REMOTES = {
  billing: 'http://localhost:3001/billing.js',
  analytics: 'http://localhost:3001/analytics.js',
};

// Step 2: Define fallback/error UI
function LoadingFallback(): Node {
  return html`<div class="spinner">Loading widget...</div>`;
}

function ErrorFallback(err: Error): Node {
  return html`<div class="error">Failed: ${err.message}</div>`;
}

// Step 3: Create remote component loaders
const BillingWidget = loadRemote({
  url: REMOTES.billing,
  isolate: 'shadow',
  fallback: LoadingFallback,
  onError: ErrorFallback,
});

const AnalyticsWidget = loadRemote({
  url: REMOTES.analytics,
  isolate: 'shadow',
  fallback: LoadingFallback,
  onError: ErrorFallback,
});

// Step 4: Build the shell UI
const shell = css`
  .shell { max-width: 1100px; margin: 0 auto; padding: 32px 20px; }
  .shell-header { text-align: center; margin-bottom: 32px; }
  .shell-header h1 { font-size: 28px; margin-bottom: 8px; }
  .shell-header p { color: #6b7280; font-size: 14px; }
  .widgets {
    display: grid;
    grid-template-columns: 1fr 1fr;
    gap: 20px;
  }
  @media (max-width: 768px) {
    .widgets { grid-template-columns: 1fr; }
  }
  .widget-frame {
    background: #ffffff;
    border: 1px solid #e5e7eb;
    border-radius: 12px;
    overflow: hidden;
  }
  .widget-toolbar {
    display: flex;
    align-items: center;
    justify-content: space-between;
    padding: 10px 16px;
    background: #f9fafb;
    border-bottom: 1px solid #e5e7eb;
  }
  .widget-toolbar span {
    font-size: 12px;
    font-weight: 600;
    color: #6b7280;
    text-transform: uppercase;
    letter-spacing: 0.5px;
  }
  .team-badge {
    font-size: 11px;
    padding: 2px 8px;
    border-radius: 10px;
    background: #eef2ff;
    color: #4f46e5;
  }
  .widget-content { padding: 20px; }
`;

function App(): Node {
  return html`
    <div class=${shell.scope}>
      <div class="shell">
        <div class="shell-header">
          <h1>Platform Dashboard</h1>
          <p>Host shell loading remote widgets from independent teams</p>
        </div>

        <div class="widgets">
          <div class="widget-frame"
            onmouseenter=${() => preloadRemote(REMOTES.billing)}>
            <div class="widget-toolbar">
              <span>Billing Widget</span>
              <span class="team-badge">Team: Payments</span>
            </div>
            <div class="widget-content">
              ${BillingWidget({ accountId: 'ACCT-7291' })}
            </div>
          </div>

          <div class="widget-frame"
            onmouseenter=${() => preloadRemote(REMOTES.analytics)}>
            <div class="widget-toolbar">
              <span>Analytics Widget</span>
              <span class="team-badge">Team: Data</span>
            </div>
            <div class="widget-content">
              ${AnalyticsWidget({ dashboardId: 'main' })}
            </div>
          </div>
        </div>
      </div>
    </div>
  `;
}

mount(App(), document.getElementById('app')!);

Notice preloadRemote() on mouseenter — it prefetches the remote module when the user hovers over the widget frame, so subsequent loads are instant from cache.

Prefetching & Caching

Onefold caches loaded modules by URL + integrity hash. You can manage this cache:

import { preloadRemote, clearRemoteCache } from 'onefold/remote';

// Prefetch on route anticipation or hover
preloadRemote('https://billing.cdn.com/widget.js');

// Clear cache for a specific remote (force re-fetch)
clearRemoteCache('https://billing.cdn.com/widget.js');

// Clear all cached remotes
clearRemoteCache();

Use clearRemoteCache when:

You detect a compromised remote and need to force a fresh load after updating the SRI hash
A remote has been updated and you want to bust the cache
You're running integration tests and need clean state

Scaffolding a Full Project

The create-onefold CLI has a dedicated microfrontend template that sets up the entire architecture:

npm create onefold@latest my-platform --template microfrontend
cd my-platform
npm install
npm run dev

This generates:

my-platform/
├── src/
│   ├── host/
│   │   └── main.ts              # Shell app — loads remote widgets
│   ├── remotes/
│   │   ├── billing/
│   │   │   └── index.ts         # Self-contained billing widget
│   │   └── analytics/
│   │       └── index.ts         # Self-contained analytics widget
│   └── shared/
│       └── types.ts             # Shared type contracts
├── index.html
├── style.css                    # Host global styles
├── build.mjs                    # Builds host + remotes (supports --target)
├── dev.mjs                      # Dev: host on :3000, remotes on :3001
├── preview.mjs                  # Serve production build
└── package.json

The dev server runs two ports simultaneously:

:3000 — Host shell (with livereload)
:3001 — Remote widget server (CORS enabled)

This simulates cross-origin deployment during development.

Independent Builds & Deployment

Each piece can be built and deployed separately:

npm run build              # Build everything → dist/
npm run build:host         # Build only the host shell
npm run build:billing      # Build only the billing widget
npm run build:analytics    # Build only the analytics widget

In production, each team deploys their remote to their own CDN:

# Team: Payments
npm run build:billing
# Deploy dist/billing.js → https://billing.cdn.com/widget.js

# Team: Data
npm run build:analytics
# Deploy dist/analytics.js → https://analytics.cdn.com/widget.js

Then update the host's configuration for production URLs:

configureSecurity({
  trustedOrigins: [
    'https://billing.cdn.com',
    'https://analytics.cdn.com',
  ],
  requireIntegrity: true,
});

const BillingWidget = loadRemote({
  url: 'https://billing.cdn.com/widget.js',
  integrity: 'sha384-oqVuAfXRKap7fdgcCY5uykM6...',
  isolate: 'shadow',
  fallback: LoadingFallback,
  onError: ErrorFallback,
});

The host doesn't need to rebuild when a remote updates — as long as the export contract (function signature and props interface) stays the same. Update the integrity hash in the host when remotes publish new versions.

The Remote Contract

Every remote must follow a simple contract:

// The remote exports a default function
export default function WidgetName(props: SomeProps): Node {
  // ... build UI using onefold
  return html`...`;
}

That's it. The function:

Receives props from the host
Returns a DOM Node
Can use any Onefold API internally (signals, css, effects, etc.)
Is fully self-contained — no implicit dependencies on the host

You can share type definitions between host and remotes via a shared package:

// shared/types.ts
export type RemoteWidget<P = Record<string, unknown>> = (props: P) => Node;

export interface BillingProps {
  accountId: string;
  plan?: string;
}

export interface AnalyticsProps {
  dashboardId: string;
}

Live Data in Remotes

Remotes are full Onefold components — they can have their own reactive state, effects, and even live-updating data:

// analytics-widget.ts
import { createSignal, html, css } from 'onefold';

export default function AnalyticsWidget(props: { dashboardId?: string }): Node {
  const visitors = createSignal(1247);
  const pageViews = createSignal(3891);
  const chartData = createSignal([35, 52, 41, 67, 45, 78, 62, 55, 71, 48, 83, 59]);

  // Simulate live data updates
  setInterval(() => {
    visitors.set(v => v + Math.floor(Math.random() * 10) - 3);
    pageViews.set(v => v + Math.floor(Math.random() * 15));
    chartData.set(prev => [...prev.slice(1), Math.floor(Math.random() * 60) + 30]);
  }, 2000);

  const styles = css`
    .stats { display: grid; grid-template-columns: 1fr 1fr; gap: 10px; margin-bottom: 16px; }
    .stat { background: #f9fafb; border-radius: 10px; padding: 14px; text-align: center; }
    .stat-value { font-size: 22px; font-weight: 700; }
    .stat-label { font-size: 12px; color: #6b7280; }
    .chart { display: flex; align-items: flex-end; gap: 3px; height: 60px; }
    .bar {
      flex: 1;
      background: #6366f1;
      border-radius: 3px 3px 0 0;
      transition: height 0.3s;
      min-height: 4px;
    }
  `;

  return html`
    <div class=${styles.scope}>
      <h3>Analytics${props.dashboardId ? ` — ${props.dashboardId}` : ''}</h3>
      <div class="stats">
        <div class="stat">
          <div class="stat-value">${() => visitors().toLocaleString()}</div>
          <div class="stat-label">Visitors</div>
        </div>
        <div class="stat">
          <div class="stat-value">${() => pageViews().toLocaleString()}</div>
          <div class="stat-label">Page Views</div>
        </div>
      </div>
      <div class="chart">
        ${() => chartData().map(v => html`<div class="bar" style=${{ height: `${v}%` }}></div>`)}
      </div>
    </div>
  `;
}

Each remote manages its own state. The host doesn't know or care about the remote's internals — it just passes props and renders the returned Node.

Compared to Module Federation

	Onefold loadRemote	Webpack Module Federation
Setup	One import, zero config	Plugin config in both host and remote
Bundler dependency	None (works with any bundler)	Webpack 5+ only
Shared dependencies	Import Maps (declarative) or bundle per remote	Runtime shared scope config
Security	Built-in origin allowlist, SRI, sandboxing	None built-in
CSS isolation	Shadow DOM or iframe	Manual (CSS Modules, etc.)
Runtime overhead	ES module `import()`	Webpack runtime chunk
Hot reload	Built into dev server	Requires additional setup
Type safety	Shared type packages	Requires extra tooling

The trade-off: Module Federation handles shared dependency negotiation at runtime (multiple versions can coexist with fallback logic). Onefold's approach is simpler — use Import Maps for shared deps, or let each remote bundle independently. No runtime negotiation, no version mismatch surprises. You decide at build time.

Shared Dependencies: Marking Onefold as External

Here's a practical concern that comes up quickly: if your host and five remote widgets all bundle their own copy of onefold, you're shipping ~6kb × 6 = 36kb of the same framework code. That's wasteful, and it also means each remote has its own signal system — signals can't cross boundaries between host and remotes.

The fix is straightforward. Mark onefold as external in your remote build config, and let the browser resolve it from a single shared source via an Import Map.

Step 1: Build the remote with onefold as external

In your remote's esbuild config (or whichever bundler you use), tell it not to bundle onefold:

// build-remote.mjs
import { build } from 'esbuild';

await build({
  entryPoints: ['src/remotes/billing/index.ts'],
  bundle: true,
  format: 'esm',
  external: ['onefold'],  // Don't bundle — resolved at runtime
  outfile: 'dist/billing.js',
  minify: true,
});

The output billing.js will still have import { html, createSignal } from 'onefold' — but as a bare import that the browser resolves at runtime, not bundled code.

Step 2: Add an Import Map to the host HTML

In your host's index.html, declare where the browser should find onefold:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8" />
  <script type="importmap">
  {
    "imports": {
      "onefold": "https://cdn.example.com/onefold@0.1.5/index.js"
    }
  }
  </script>
</head>
<body>
  <div id="app"></div>
  <script type="module" src="./host.js"></script>
</body>
</html>

Now every remote that does import { ... } from 'onefold' gets the same instance from the CDN. One download, one signal system, shared across host and all remotes.

Step 3: The remote code stays clean

Your remote widget doesn't change at all — it uses normal imports:

// billing-widget.ts — bare import, resolved by the host's import map
import { html, createSignal, css } from 'onefold';

export default function BillingWidget(props: { accountId: string }): Node {
  const usage = createSignal(67);
  // ... rest of the component
}

When this runs in the browser, 'onefold' resolves to the URL declared in the import map. The remote never bundles the framework, and the browser only downloads it once.

When to share vs. when to bundle

Scenario	Approach	Why
All remotes are internal, same team/org	Share via Import Map	Single download, signals work across boundaries
Third-party vendor remote	Let them bundle their own copy	No version coordination needed, full isolation
Local development	Bundle everything (no external)	Simpler dev setup, no CDN dependency
Production with few remotes (1–2)	Either works	The duplication is small (~6kb per remote)
Production with many remotes (5+)	Share via Import Map	Savings add up, consistent behavior

Versioning strategy

Pin to a specific version in the import map:

{
  "imports": {
    "onefold": "https://cdn.example.com/onefold@0.1.5/index.js"
  }
}

Patch updates — safe to update the import map URL without redeploying remotes
Minor updates — generally safe, but test remotes against the new version first
Major updates — coordinate with all teams; update remotes before changing the map

The key advantage of this approach over Module Federation's shared scope: there's no runtime negotiation, no "singleton" vs "eager" vs "strict" semantics to configure, and no version mismatch errors at runtime. The import map is declarative — what you see is what the browser loads.

A note on browser support

Import Maps work in all modern browsers (Chrome 89+, Firefox 108+, Safari 16.4+). If you need to support older browsers, the es-module-shims polyfill handles it with minimal overhead.

Production Checklist

Before going to production with Onefold microfrontends:

[ ] configureSecurity({ requireIntegrity: true }) — always verify remote code
[ ] Generate SRI hashes for every remote build (sha384-...)
[ ] Set isolate: 'shadow' for cross-team widgets
[ ] Set isolate: 'iframe' for third-party vendor code
[ ] Provide onError fallbacks for every remote (graceful degradation)
[ ] Set up CORS headers on remote servers (Access-Control-Allow-Origin)
[ ] Use credentials: 'omit' (Onefold does this by default — cookies are never sent to remote origins)
[ ] Consider Import Maps to share onefold across remotes (eliminates duplication, enables cross-boundary signals)
[ ] Mark onefold as external in remote build configs when using shared deps
[ ] Pin shared dependency versions in the import map
[ ] Test with blockAll: true to verify your app degrades gracefully when remotes are disabled

Wrapping Up

Onefold's microfrontend system gives you the hard parts for free:

Security — origin allowlisting, SRI verification, credential isolation
Isolation — Shadow DOM for CSS, iframe for full sandboxing
Loading — async with fallbacks, error handling, prefetching, caching
DX — CLI template, dual-port dev server, independent builds

The entire API surface is three functions: configureSecurity, loadRemote, and preloadRemote (plus clearRemoteCache for cache management). That's it.

npm create onefold@latest my-platform --template microfrontend

Links:

Onefold is MIT licensed and open source (v0.1.6). The microfrontend module is part of the core package — no extra installation needed.

Getting Started with Onefold: The Complete, Lightweight Reactive UI Framework

Md. Zahirul Haque — Sun, 09 Aug 2026 08:46:35 +0000

If you've ever started a new project and spent half the day wiring up a router, a state manager, a form library, and an HTTP client before writing a single line of actual app code — this one's for you.

Onefold is a TypeScript-first UI framework that ships everything you need in a single package. No virtual DOM, no compiler, zero dependencies, and the core is under 6kb gzipped.

In this article, I'll walk you through the core concepts and build a simple app from scratch so you can see what working with Onefold feels like.

Why Onefold?

Why choose Onefold over traditional setups? Here's the pitch in 30 seconds:

Fine-grained reactivity : Signal updates touch only the exact DOM node that depends on them. No diffing, no reconciliation. Updates are O(1).
Real DOM : No virtual DOM abstraction. The html tagged template builds actual DOM nodes with reactive bindings.
Secure by default : Dynamic text safely binds to textContent instead of risking innerHTML. This structural design completely eliminates cross-site scripting (XSS) risks without needing eval(), keeping you 100% CSP-compliant.
Complete toolkit : Routing, state management, forms with validation, HTTP client, i18n, theming, SSR, accessibility, microfrontend support... all included.
Tiny : Core is ~6kb gzipped. Full bundle with all features is ~16kb.
Zero dependencies : The entire framework has 0 runtime dependencies.

Setting Up Your First Project

The fastest way to get started:

npm create onefold@latest my-app
cd my-app
npm install
npm run dev

This scaffolds a SPA with routing, a dev server with live reload, and a production build script. Open http://localhost:3000 and you're running.

The generated project structure looks like:

my-app/
├── src/
│   ├── main.ts           # Entry point + router setup
│   ├── components/       # Reusable UI components
│   ├── routes/           # Page components
│   └── state/            # Signals & stores
├── public/
│   └── images/logo.svg   # Static assets
├── index.html
├── style.css             # Global styles
├── build.mjs             # Production build (esbuild)
├── dev.mjs               # Dev server + livereload
├── tsconfig.json
└── package.json

Available templates: base, spa, fullstack, and microfrontend.

Core Concept #1: Signals

Signals are the heart of Onefold's reactivity. A signal is a reactive value — when it changes, anything that depends on it updates automatically.

import { createSignal } from 'onefold';

const count = createSignal(0);

// Read
count();          // 0

// Write
count.set(5);
count.set(n => n + 1);  // updater function

// Read without tracking (won't subscribe effects)
count.peek();

You also get computed signals (derived values) and effects (side effects that re-run on change):

import { createSignal, createComputed, createEffect } from 'onefold';

const firstName = createSignal('Jane');
const lastName = createSignal('Doe');

// Automatically recomputes when firstName or lastName change
const fullName = createComputed(() => `${firstName()} ${lastName()}`);

// Runs whenever fullName changes
createEffect(() => {
  console.log(`Name is now: ${fullName()}`);
});

Core Concept #2: Templates

UI is built with the html tagged template literal. It produces real DOM nodes — no compilation step needed.

import { createSignal, html, mount } from 'onefold';

function Counter(): Node {
  const count = createSignal(0);

  return html`
    <div>
      <h1>Count: ${() => count()}</h1>
      <button onclick=${() => count.set(n => n - 1)}>-</button>
      <button onclick=${() => count.set(n => n + 1)}>+</button>
    </div>
  `;
}

mount(Counter(), document.getElementById('app')!);

The #1 Rule: Wrap Signal Reads in `() =>`

This is the most important thing to remember:

// WRONG — renders once, never updates
html`<p>${count()}</p>`

// CORRECT — updates reactively when count changes
html`<p>${() => count()}</p>`

The () => wrapper creates a reactive binding. Without it, you just interpolate the current value once and it's static forever.

Core Concept #3: Components

Components are just plain functions that return Node. No classes, no decorators, no special registration.

import { html } from 'onefold';

function Greeting(name: string): Node {
  return html`<p>Hello, ${name}!</p>`;
}

function App(): Node {
  return html`
    <div>
      ${Greeting('World')}
    </div>
  `;
}

Building a Todo App

Let's put it all together with a practical example. We'll build a reactive todo list with filtering.

State Management

// src/state/todos.ts
import { createSignal, createComputed } from 'onefold';

interface Todo {
  id: string;
  text: string;
  completed: boolean;
}

type Filter = 'all' | 'active' | 'completed';

export const todos = createSignal<Todo[]>([]);
export const filter = createSignal<Filter>('all');

export const filteredTodos = createComputed(() => {
  const items = todos();
  const mode = filter();
  switch (mode) {
    case 'active': return items.filter(t => !t.completed);
    case 'completed': return items.filter(t => t.completed);
    default: return items;
  }
});

export const activeCount = createComputed(
  () => todos().filter(t => !t.completed).length
);

export function addTodo(text: string): void {
  const trimmed = text.trim();
  if (!trimmed) return;
  todos.set(prev => [...prev, {
    id: crypto.randomUUID(),
    text: trimmed,
    completed: false,
  }]);
}

export function toggleTodo(id: string): void {
  todos.set(prev =>
    prev.map(t => t.id === id ? { ...t, completed: !t.completed } : t)
  );
}

export function removeTodo(id: string): void {
  todos.set(prev => prev.filter(t => t.id !== id));
}

Input Component

// src/components/TodoInput.ts
import { createSignal, html } from 'onefold';
import { addTodo } from '../state/todos';

export function TodoInput(): Node {
  const input = createSignal('');

  const handleSubmit = (e: Event) => {
    e.preventDefault();
    addTodo(input());
    input.set('');
  };

  return html`
    <form onsubmit=${handleSubmit}>
      <input
        type="text"
        placeholder="What needs to be done?"
        value=${() => input()}
        oninput=${(e: Event) => input.set((e.target as HTMLInputElement).value)}
      />
      <button type="submit" disabled=${() => !input().trim()}>Add</button>
    </form>
  `;
}

List Component

// src/components/TodoList.ts
import { html } from 'onefold';
import { filteredTodos, toggleTodo, removeTodo } from '../state/todos';

export function TodoList(): Node {
  return html`
    <ul>
      ${() => filteredTodos().map(todo => html`
        <li class=${todo.completed ? 'completed' : ''}>
          <input
            type="checkbox"
            checked=${todo.completed}
            onchange=${() => toggleTodo(todo.id)}
          />
          <span>${todo.text}</span>
          <button onclick=${() => removeTodo(todo.id)}>x</button>
        </li>
      `)}
    </ul>
  `;
}

Filter Component

// src/components/TodoFilter.ts
import { html } from 'onefold';
import { filter, activeCount } from '../state/todos';

export function TodoFilter(): Node {
  return html`
    <div class="filters">
      <button
        class=${() => filter() === 'all' ? 'active' : ''}
        onclick=${() => filter.set('all')}
      >All</button>
      <button
        class=${() => filter() === 'active' ? 'active' : ''}
        onclick=${() => filter.set('active')}
      >Active</button>
      <button
        class=${() => filter() === 'completed' ? 'active' : ''}
        onclick=${() => filter.set('completed')}
      >Completed</button>
      <span>${() => activeCount()} items left</span>
    </div>
  `;
}

Putting It Together

// src/main.ts
import { html, mount, css } from 'onefold';
import { TodoInput } from './components/TodoInput';
import { TodoList } from './components/TodoList';
import { TodoFilter } from './components/TodoFilter';

const styles = css`
  .todo-app {
    max-width: 520px;
    margin: 60px auto;
    background: #ffffff;
    border-radius: 16px;
    padding: 40px 36px;
    box-shadow: 0 4px 24px rgba(0, 0, 0, 0.06);
    font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
  }
  h1 {
    font-size: 32px;
    font-weight: 700;
    color: #1e293b;
    margin-bottom: 24px;
  }
  form {
    display: flex;
    gap: 10px;
    margin-bottom: 20px;
  }
  input[type="text"] {
    flex: 1;
    padding: 12px 16px;
    font-size: 15px;
    border: 1.5px solid #e2e8f0;
    border-radius: 10px;
    outline: none;
    transition: border-color 0.2s;
  }
  input[type="text"]:focus {
    border-color: #3b82f6;
  }
  button {
    padding: 10px 20px;
    background: #3b82f6;
    color: white;
    border: none;
    border-radius: 10px;
    font-size: 14px;
    font-weight: 500;
    cursor: pointer;
    transition: background 0.2s;
  }
  button:hover { background: #2563eb; }
  button:disabled { background: #cbd5e1; cursor: not-allowed; }
  .filters {
    display: flex;
    gap: 6px;
    align-items: center;
    margin-bottom: 20px;
  }
  .filters button {
    padding: 7px 16px;
    background: white;
    color: #64748b;
    border: 1.5px solid #e2e8f0;
    border-radius: 8px;
    font-size: 13px;
  }
  .filters button:hover { border-color: #3b82f6; color: #3b82f6; }
  .filters button.active { background: #3b82f6; color: white; border-color: #3b82f6; }
  .filters span { margin-left: auto; font-size: 13px; color: #94a3b8; }
  ul {
    list-style: none;
    padding: 0;
    margin: 0;
  }
  li {
    display: flex;
    align-items: center;
    gap: 12px;
    padding: 12px 8px;
    border-bottom: 1px solid #f1f5f9;
    font-size: 15px;
  }
  li:last-child { border-bottom: none; }
  li:hover { background: #f8fafc; border-radius: 8px; }
  li.completed span { text-decoration: line-through; color: #94a3b8; }
  li input[type="checkbox"] { width: 18px; height: 18px; accent-color: #3b82f6; }
  li span { flex: 1; }
  li button {
    padding: 4px 10px;
    background: none;
    color: #ef4444;
    border: none;
    font-size: 14px;
    opacity: 0;
    transition: opacity 0.15s;
  }
  li:hover button { opacity: 1; }
  li button:hover { background: #fef2f2; border-radius: 6px; }
`;

function App(): Node {
  return html`
    <div class=${styles.scope}>
      <div class="todo-app">
        <h1>Todos</h1>
        ${TodoInput()}
        ${TodoFilter()}
        ${TodoList()}
      </div>
    </div>
  `;
}

mount(App(), document.getElementById('app')!);

That's it. No boilerplate, no providers wrapping your app, and the scoped CSS keeps all the todo styling contained — nothing bleeds into the rest of the page.

Routing

Onefold includes a client-side router out of the box:

import { Router, navigate, currentRoute, Link, html, mount } from 'onefold';

function Nav(): Node {
  return html`
    <nav>
      ${Link('/', 'Home', () => currentRoute() === '/' ? 'active' : '')}
      ${Link('/about', 'About', () => currentRoute() === '/about' ? 'active' : '')}
    </nav>
  `;
}

function Home(): Node { return html`<h1>Home</h1>`; }
function About(): Node { return html`<h1>About</h1>`; }
function NotFound(): Node { return html`<h1>404 — Not Found</h1>`; }

function App(): Node {
  return html`
    <div>
      ${Nav()}
      ${Router([
        { path: '/', view: () => Home() },
        { path: '/about', view: () => About() },
        { path: '/users/:id', view: (params) => UserProfile(params.id) },
      ], () => NotFound())}
    </div>
  `;
}

mount(App(), document.getElementById('app')!);

It supports dynamic params (:id), nested routes with layouts, hash-based routing for static hosting, and programmatic navigation via navigate('/path').

What Else Is Included?

This is where Onefold really differentiates itself. All of these are part of the same package, available via tree-shakeable sub-path imports:

// Forms with validation
import { createForm, required, email, minLength } from 'onefold/form';

// HTTP client with interceptors
import { createHttpClient } from 'onefold/http';

// Internationalization
import { createI18n } from 'onefold/i18n';

// Persisted state (localStorage/sessionStorage)
import { createPersisted } from 'onefold/persist';

// Theming with CSS variables
import { createTheme } from 'onefold/theme';

// Server-side rendering
import { renderHTML } from 'onefold/ssr';

// WebSocket & SSE
import { createWebSocket, createEventSource } from 'onefold/stream';

// Microfrontend loading with security
import { loadRemote } from 'onefold/remote';

// Accessibility utilities
import { FocusTrap, announce } from 'onefold/a11y';

// Scoped CSS
import { css } from 'onefold';

// Virtual list for large datasets
import { VirtualList } from 'onefold/virtual-list';

// Lazy loading + code splitting
import { lazy } from 'onefold';
import { Suspense } from 'onefold/suspense';

You only bundle for what you import. The core (signals + templates + routing + store) is ~6kb. Import additional modules as needed, each tree-shakes independently.

Scoped CSS

Components can have scoped styles that don't leak to the rest of the page. The css tagged template returns an object with a .scope property — a unique class name (like nf-0, nf-1) that you apply to your root element. All selectors in your CSS block get automatically prefixed with that scope class:

import { html, css } from 'onefold';

const styles = css`
  .card { padding: 16px; border: 1px solid #ddd; border-radius: 8px; }
  .card h2 { margin: 0 0 8px; }
  button { padding: 8px 16px; border-radius: 6px; cursor: pointer; }
`;

function Card(title: string, content: string): Node {
  return html`
    <div class=${styles.scope}>
      <div class="card">
        <h2>${title}</h2>
        <p>${content}</p>
        <button>Action</button>
      </div>
    </div>
  `;
}

The .card, h2, and button styles here are fully scoped — they won't affect any other .card or button on the page. Under the hood, Onefold generates something like .nf-0 .card { ... } and injects a <style> into <head> (deduplicated — identical templates reuse the same scope).

Microfrontends — Built In

This is one of Onefold's standout features. If your organization has multiple teams shipping different parts of a frontend, Onefold handles remote module loading with built-in security controls:

import { html, mount } from 'onefold';
import { loadRemote, configureSecurity, preloadRemote } from 'onefold/remote';

// At app startup: define what origins you trust
configureSecurity({
  trustedOrigins: ['https://widgets.company.com'],
  requireIntegrity: true,
  timeout: 10000,
});

// Load a remote widget — returns a component function
const BillingWidget = loadRemote({
  url: 'https://widgets.company.com/billing.js',
  integrity: 'sha384-abc123...',
  isolate: 'shadow',  // 'none' | 'shadow' | 'iframe'
  fallback: () => html`<p>Loading billing...</p>`,
  onError: (err) => html`<p>Widget unavailable: ${err.message}</p>`,
});

function Dashboard(): Node {
  return html`
    <div>
      <h1>Dashboard</h1>
      ${BillingWidget({ accountId: 'ACCT-7291' })}
    </div>
  `;
}

mount(Dashboard(), document.getElementById('app')!);

Key features:

Origin allowlisting : only modules from explicitly trusted origins can load
Subresource Integrity (SRI) : optionally require hash verification
CSS isolation : Shadow DOM isolates remote widget styles from the host
Graceful fallbacks : loading states and error handling built in
Prefetching : preloadRemote(url) lets you prefetch on hover for faster interaction
Independent deployment : each remote is a standalone ES module, deployable by a different team on a different schedule

The create-onefold CLI even has a microfrontend template that scaffolds a full host shell + remote widgets setup:

npm create onefold@latest my-platform --template microfrontend

CDN Usage (No Build Step)

You can use Onefold directly in the browser without any build tooling:

<!DOCTYPE html>
<html>
<body>
  <div id="app"></div>
  <script type="module">
    import { createSignal, html, mount } from 'https://unpkg.com/onefold';

    function App() {
      const count = createSignal(0);
      return html`
        <button onclick=${() => count.set(n => n + 1)}>
          Clicked ${() => count()} times
        </button>
      `;
    }

    mount(App(), document.getElementById('app'));
  </script>
</body>
</html>

No npm, no bundler, just a <script type="module"> tag.

How Does It Compare?

	Onefold	React	Svelte	Solid
Virtual DOM	No	Yes	No	No
Compiler required	No	No*	Yes	Yes
Bundle size (core)	~6kb	~44kb	~2kb	~7kb
Reactivity	Fine-grained signals	Re-render entire component	Compiler-assisted	Fine-grained signals
Runtime dependencies	0	3	0	0
Built-in router	Yes	No	No	No
Built-in forms	Yes	No	No	No
Built-in HTTP client	Yes	No	No	No
Built-in i18n	Yes	No	No	No
Built-in microfrontends	Yes	No	No	No
SSR support	Yes	Yes	Yes	Yes

*React technically doesn't require a compiler, but JSX practically does.

The trade-off is clear: Onefold gives you a complete toolkit with zero config in exchange for being a newer, less battle-tested ecosystem.

Deployment

The production build outputs static files to dist/:

npm run build

Deploy the dist/ folder anywhere: Vercel, Netlify, GitHub Pages, S3, any static host. For hash-based routing on static hosts, add one line before your Router:

import { configureRouter } from 'onefold';
configureRouter({ hash: true });

Wrapping Up

Building features should be the fun part, but modern web development often forces you to waste hours stitching together five different libraries just to get started. Onefold flips the script, giving you everything you need right out of the box, without the bloated footprint.

The core concept is incredibly straightforward:

Signals manage your reactive state naturally.
html templates build real DOM elements with built-in reactive bindings.
Components are just plain functions that return a Node
Wrap signal reads in () => to make them reactive in templates

Want to take it for a spin? Kick off a project in seconds:

npm create onefold@latest my-app

Links:

Onefold is MIT licensed and open source. It's at version 0.1.5 — early but functional, with a growing set of examples and documentation.

DEV Community: Md. Zahirul Haque

Onefold + Hono + Cloudflare: Building a Fast SSR App on the Edge

Why this stack

How the pieces fit together

Project setup

Project structure

1. The pages

src/shared/Nav.ts

src/server/data.ts

src/pages/Home.ts

src/shared/Counter.ts

src/pages/About.ts

src/pages/NotFound.ts

2. The HTML shell

src/shell.ts

3. The Hono server

src/index.ts

4. The client entry — selective hydration

src/client.ts

5. Build configuration

6. Cloudflare configuration

wrangler.toml

7. Run it locally

8. Deploy

Optional: storing files with R2

A few honest caveats

Wrapping up

Microfrontends Without the Complexity: How Onefold Handles Multi-Team Frontend Architecture

The Problem With Traditional Microfrontend Setups

The Architecture

Security First: configureSecurity

The 7 Security Layers

Configuration Options

Loading a Remote: loadRemote

loadRemote Options

Isolation Modes

'none' — Direct Mount

'shadow' — Shadow DOM Encapsulation

'iframe' — Full Sandbox

When to Use Which

Writing a Remote Widget

Building a Complete Host Shell

Prefetching & Caching

Scaffolding a Full Project

Independent Builds & Deployment

The Remote Contract

Live Data in Remotes

Compared to Module Federation

Shared Dependencies: Marking Onefold as External

Step 1: Build the remote with onefold as external

Step 2: Add an Import Map to the host HTML

Step 3: The remote code stays clean

When to share vs. when to bundle

Versioning strategy

A note on browser support

Production Checklist

Wrapping Up

Getting Started with Onefold: The Complete, Lightweight Reactive UI Framework

Why Onefold?

Setting Up Your First Project

Core Concept #1: Signals

Core Concept #2: Templates

The #1 Rule: Wrap Signal Reads in () =>

Core Concept #3: Components

Building a Todo App

State Management

Input Component

List Component

Filter Component

Putting It Together

Routing

What Else Is Included?

Scoped CSS

Microfrontends — Built In

CDN Usage (No Build Step)

How Does It Compare?

Deployment

Wrapping Up

`src/shared/Nav.ts`

`src/server/data.ts`

`src/pages/Home.ts`

`src/shared/Counter.ts`

`src/pages/About.ts`

`src/pages/NotFound.ts`

`src/shell.ts`

`src/index.ts`

`src/client.ts`

`wrangler.toml`

`'none'` — Direct Mount

`'shadow'` — Shadow DOM Encapsulation

`'iframe'` — Full Sandbox

The #1 Rule: Wrap Signal Reads in `() =>`