v0.20.6 — EARLY ACCESS

with Pulse YOU CAN'T A BAD PAGE.

ONE SPEC. ONE WAY TO BUILD.

A server-first Node.js framework. Streaming SSR, security headers, and production caching are enforced by the architecture, not left to configuration.

So constrained that doing it wrong isn't an option. Whether you write it or an AI does.

Get Started Read the Spec
4 kB Runtime JS · first visit
0.00 Cumulative Layout Shift
100 Lighthouse · by design
0 Runtime dependencies
THE IDEA

The spec is the page

Everything a page needs lives in one plain JS object: server data, client state, mutations, and view. One format. No split files. No hidden conventions.

The schema is the contract

Every spec is validated at startup. Either it's correct or it's rejected. No ambiguity, no misconfiguration that surfaces later in production.

The framework is the guarantee

Streaming SSR, security headers, and production caching come from the architecture. You write the product logic. The framework ships the quality.

Everything a page needs.
Nothing it doesn't.

Server fetchers, client state, mutations, and view. All co-located in one object. The spec is the page.

export default {
  route: '/dashboard',
  meta: {
    title: 'Dashboard — My App',
    styles: ['/app.css'],
  },
  server: {
    data: async (ctx) => {
      const user = await db.users.find(ctx.cookies.userId)
      return { user, stats: await db.stats.forUser(user.id) }
    },
  },
  state: { filter: 'all' },
  mutations: {
    setFilter: (state, event) => ({ filter: event.target.value }),
  },
  view: (state, server) => `
    <main id="main-content">
      <h1>Hello, ${server.data.user.name}</h1>
      <select data-event="change:setFilter">
        <option value="all">All time</option>
        <option value="week">This week</option>
      </select>
      <p>${server.data.stats[state.filter].total} requests</p>
    </main>
  `,
}
AI + PULSE

Constrained enough
to be trusted.
Free enough
to be creative.

The spec format tells an agent exactly how to wire up data, state, and behaviour. What it doesn't do is dictate the design. Layout, typography, CSS — those are still real decisions. The agent makes them. Pulse just makes sure the page it builds actually works.

The structure is fixed
  • One spec format. No ambiguity about how a page should be built
  • Schema validation at startup. Bad output is rejected before it ships
  • Security, SSR, and caching are part of the architecture. Not optional
  • Consistent, reviewable output across every agent and every session
The design is not
  • The view is a plain JS function. The agent writes whatever HTML it wants
  • CSS, layout, and typography are entirely up to the agent
  • A component library is there when needed. Custom HTML when it isn't
  • The result looks considered because the agent had room to make it so
HOW PULSE COMPARES

Constraints enforced.
Not recommended.

PULSE Next.js / Remix SvelteKit
Ways to write a page One: the spec schema App Router, Pages Router, RSC, client components, loaders… +page.svelte, +page.server.js, load(), form actions…
Agent-readable structure One JS object per page Files, folders, magic exports spread across dirs Files, folders, Svelte syntax
SSR out of the box Streaming SSR, zero config Yes, but client hydration adds JS on every page Yes, but requires an adapter and client runtime on every page
Client JS shipped ~4 kB brotli on first visit; 0 kB on static pages 50–200 kB+ depending on features used ~15 kB brotli
Security headers On every response, built in Manual middleware or plugin Manual hooks setup
Runtime dependencies Zero. Pure Node.js HTTP React, 50+ transitive packages Svelte runtime + adapters
Production build step Server needs none. node server.js is production Required: next build Required: vite build

Performance by design

The shell streams to the browser instantly. Deferred segments arrive as data resolves. ~4 kB of JS on first visit. Zero CLS. Immutable bundle caching on deploy. Not configured. Structural.

Safe by design

Security headers on every response, including 404 and 500. Declarative constraints enforce state bounds after every mutation. Guard runs before any server fetcher. Not a plugin. Part of the pipeline.

Nothing to configure

No bundler config. No runtime dependencies to install, audit, or upgrade. node server.js is production. No breaking upgrades. Page files have no framework imports to version.

BY THE NUMBERS

Performance you can measure.

Report generated 18 Jul 2026, 20:52 · measured from a real Pulse build

Lighthouse
100 Accessibility
100 Best Practices
100 SEO
Bundle sizes
0 kB Static page — no JS shipped
4.2 kB Single page app — runtime + page (brotli)
3.8 kB Multi-page — shared runtime, cached (brotli)
0.4 kB Multi-page — per-page JS bundle (brotli)
Web Vitals
0.00 Cumulative Layout Shift
Architecture
0 Runtime dependencies
None Production build step
Brotli Automatic compression

Your first page
in under
2 minutes.

One spec object. Server data, client state, mutations, and view. In one place. Streaming SSR, security headers, and 100 Lighthouse scores come with it. Nothing to configure.

Pulse is in early access. The goal is not to compete on features. It is to eliminate the class of problems that come from having too many of them.

Get Started Read the Spec