Node.js and Python in the Browser. Server on Demand.

The useful version of "run code in the browser" is not a purity test. It is a hosting decision.

If a workload can run well in the browser, keep it in the browser. If it needs Linux, native packages, larger ceilings, or persistence outside browser storage, move it to a server. Verklet is built around that rule: Node.js-style and supported Python workloads start browser-first, with server execution available on demand.

Browser-first is the fast path

The browser is already where the user is. For embedded demos, tutorials, agent scratchpads, and browser IDEs, that matters.

Browser execution gives you:

• Low-latency startup for supported workloads.
• No container session for every visitor by default.
• Files that can persist locally with OPFS snapshots.
• Isolated previews through a product-owned preview origin.
• A runtime that can live inside the product experience.

That does not make the browser a complete Linux replacement. It makes it the right first host for many interactive workloads.

Node.js-style workloads map well to browser primitives

Node compatibility in a browser runtime is mostly about host APIs and process behavior. The JavaScript engine is already there. The runtime has to provide the surrounding environment: filesystem, module loading, process records, streams, HTTP behavior, package layout, and preview routing.

Verklet uses workers for process isolation and WebAssembly for hot paths like filesystem and archive work. The result is a Node.js-style execution environment that can run common demos and development loops inside the tab.

The compatibility boundary is explicit. Some Node modules are supported, some are partial, and native addons belong on the server path.

Python starts with Pyodide

Python is similar. Supported Python can run in the browser through Pyodide. That is useful for examples, plots, data transforms, notebooks, and agent tasks that do not require native Linux wheels.

When the workload asks for uv, native wheels, subprocess-heavy code, or tools that Pyodide cannot support, the server backend is the right host. The product should not fail late or ask the developer to build a second integration.

Server on demand keeps one programming model

The SDK surface stays the same:

import { Runtime } from '@verklet/sdk';

const runtime = await Runtime.boot({
  projectId: 'prj_your_project_id',
  backend: 'auto',
  persistenceKey: 'hybrid-workspace',
});

With backend: 'auto', the runtime can begin in the browser. When it detects a server-only command, it snapshots the browser filesystem, creates a server session, mounts the snapshot, and continues through the same runtime object.

Your UI still reads files, spawns commands, listens to diagnostics, and renders previews through one integration.

Why not start every session on a server?

You can. For some products, backend: 'server' is the right default. But for many embedded experiences, server-first is unnecessarily heavy.

Starting every session remotely means paying container or VM cost before the user has done anything that requires it. It also adds cold starts, capacity planning, quota behavior, and remote workspace lifecycle to flows that may only need a small local exercise.

Browser-first changes the default. The cheap capable host runs first. The server is reserved for the work that proves it needs a server.

The boundary should be visible to developers

Hybrid execution should not be mysterious. Developers need to know when they are in the browser, when they are on the server, and why promotion happened.

Runtime capabilities and diagnostic events make that visible. A host app can show that Python is using Pyodide, that OPFS persistence is available, or that the session promoted because a native package was requested.

That kind of visibility is what turns hybrid execution from magic into an operationally understandable product feature.

The short version

Node.js and Python in the browser are not replacements for every server workflow. They are a better default for the interactive work that fits the tab.

Server on demand completes the model. Start where the user already is. Promote when the workload needs capabilities the browser cannot provide.