Frameworks

Verklet runs Node.js-style code and supported Python in the browser backend, and can promote server-only commands to a managed server backend. Most JavaScript framework dev servers work in principle; the question is which ones we've actually tested and what edge cases bite. This page walks through the current state. The compatibility matrix is the authoritative one-line summary; this page is the longer form.

Node HTTP servers — supported

A plain node:http server is the most exercised path. It boots fast, ports route through the preview service worker, and server-ready fires the moment the listen callback runs.

import { createServer } from 'node:http';

createServer((req, res) => {
  res.writeHead(200, { 'content-type': 'text/plain' });
  res.end('hello from a tab\n');
}).listen(3000);

This pattern is what the playground ships out of the box. Express works too — it's just node:http with middleware on top — though the npm install step adds a one-time cost on cold boot.

Vite dev server — partial

Verklet runs the project-installed Vite CLI inside the node-compat worker. Mount vite and the framework plugins your project needs in node_modules, then spawn vite or an npm script that calls it.

What's there:

• Vite 8 can boot, listen on the preview bridge, and serve project HTML.
• Vite/Rolldown/WASI dependency loading is covered by runtime tests.
• The browser playground validates the Vite path end to end.
• Static assets, transforms, plugins, and HMR are handled by Vite.

What's not:

• Every Vite plugin and framework integration has not been exhaustively tested inside the browser runtime.
• Vite's dev server runs on Verklet's Node compatibility layer, so unsupported Node APIs or native addons can still block specific projects.
• HMR coverage is intentionally conservative; verify the exact starter or plugin stack you plan to embed.

Next.js — partial

A minimal Next app (app router, no server actions, no middleware, no edge runtime) will build and serve. The supported workflow is:

1. Mount a project with next in node_modules.
2. Spawn next dev — it binds a port; the preview SW routes it.
3. Edit a page, see the dev server reload.

What's likely to bite:

• Server actions call out to the framework's RPC system, which expects a real server environment. Not wired up.
• Edge runtime routes assume Vercel's edge primitives. Not available in-browser.
• Image optimisation uses sharp. Next.js supports a wasm32 sharp install path, but Verklet's Next image-optimizer coverage is still experimental. Use plain <img> or next/image with unoptimized unless you've verified the wasm sharp path for your project.
• Build → start mode works in narrow cases. Stick to next dev for tutorial / demo use.

This compatibility band is the same shape as the rest of the "meta-framework on top of Node" category: the dev loop tends to work; the production-server features tend not to.

Vue, Svelte, SvelteKit — partial

Include the framework package and its Vite plugin in node_modules, then run the normal dev command. SvelteKit's adapter system targets Vercel/Node/Cloudflare flavours; only narrow dev-server paths are exercised today.

Nuxt, Astro, Remix, React Router — partial

Each of these has a "dev mode that runs on top of Vite" path and a "production server" path. The dev path should use the project's Vite dependency and plugins. The production build/serve path is generally not exercised.

If you're embedding one of these for a tutorial or a customer demo, test the specific commands you intend to call. The compatibility matrix is conservative — "partial" means "we've seen it work for the canonical starter, not that every plugin combination boots."

What's intentionally out of scope

• Native addons in the browser backend. node-gyp-built modules and .node binaries don't run in browser workers. Use browser-compatible package replacements there, or move the workflow to the server backend when it genuinely needs native tools.
• child_process. Spawning OS processes is meaningless inside a browser worker; the API surface is present but most calls error out. Use the server runtime for workflows that need real OS processes.
• TLS server. You can act as an HTTPS client; you cannot terminate TLS. The preview service worker handles transport.

If a framework you care about isn't on this page, it's not necessarily broken — it's likely just untested. Open an issue at github.com/verklet/verklet with the minimal repro and we'll add it to the matrix.