Home
AI
Blog

Node.js in Your Browser (Just Like That) with almostnode

basanta sapkota
Node. So doesn’t belong in the browser. Never really did.

And yet… here we are. Writing files with fs, pulling down npm packages, even kicking up Vite or Next dev servers inside a single tab. Node.js in your browser, just like that.

If you’ve ever tried building a playground, an interactive tutorial, or one of those “try it now” docs pages, you know the usual choices are kind of brutal. Either you fake half of Node with bundler gymnastics, or you bounce people to a remote sandbox and pray latency, cold starts, and random hiccups don’t steal the magic.

So yeah. Enter almostnode.

What “Node.js in your browser” actually means

No, the browser doesn’t magically turn into Linux. And no, you’re not running the official Node binary in there.

What people usually mean is something more like:

  • a browser-native runtime emulates Node.js APIs
  • a virtual or in-memory filesystem
  • a way to resolve and run npm packages on the client
  • some kind of isolation story, like Service Worker, Web Worker, or a cross-origin sandbox

That’s basically how almostnode describes itself. “A lightweight, browser-native Node.js runtime environment” where you can run Node code, install npm packages, and develop with Vite/Next… without a server.
Source. Https://github.com/macaly/almostnode and https://almostnode.dev/

Node.js vs the browser: why this gets gnarly fast

The official Node.Plus docs don’t sugarcoat it. Same JavaScript language, sure, but the environments are “radically different.”
Source: https://nodejs.org/en/learn/getting-started/differences-between-nodejs-and-the-browser

A few differences that come back to haunt you the moment you attempt “Node in the browser”:

  • Node doesn’t ship with window or document. Browsers do.
  • Browsers don’t give you a “real” filesystem in the Node sense. No direct disk access fs.
  • Module systems aren’t a neat match. Node has CommonJS and ES Modules, while the browser world mostly lives in ES Modules and leans on bundlers when things get weird.
  • You can pick your Node version on a server. On the web, your users stroll in with whatever runtime they’ve got.

So if you want it to feel legit, you need shims, a filesystem model, and tooling that behaves like Node while still playing by the web’s security rules.

almostnode: “Node.js in your browser” with the gloves off

From the repo and the site, almostnode’s feature set is… honestly kind of stacked:

  • Virtual File System, full in-memory filesystem with a Node-compatible API
  • Node.Still API shims, 40+ shimmed modules like fs, path, http, events, and more
  • npm package installation in the browser, including bin entries
  • CLI tools can work, stuff like vitest, eslint, tsc
  • built-in Vite and Next.js dev servers
  • HMR with React Refresh support
  • TypeScript/TSX support via esbuild-wasm
  • Service Worker architecture for intercepting requests and smoothing the dev loop
  • optional Web Worker support so the UI doesn’t choke
  • secure-by-default options, including cross-origin sandbox support for untrusted code

Source. Https://github.com/macaly/almostnode and https://almostnode.dev/

And it’s not some dusty gist, either. At the time of the research snapshot, the repo showed ~560 GitHub stars and 45 forks. It’s still marked experimental though, so… keep your eyes open.
Source: https://github.com/macaly/almostnode

Quickstart: run Node.js in your browser and use fs

Want the fastest “okay wow” moment? Do the most Node-ish thing possible. Write a file, read it back, use require().

npm install almostnode

Then in the browser:

import { createContainer } from "almostnode".

// Create a Node.js container in the browser
const container = createContainer(). Const result = container.execute. Fs.writeFileSync;
  module.exports = fs.readFileSync;
`);

console.log. // "Hello from the browser!"

Straight from the repo, and it makes the point loudly. yes, you can use fs in the browser… as long as it’s backed by a virtual filesystem.
Source: https://github.com/macaly/almostnode

Installing npm packages in-browser

This is where a lot of “Node-ish” browser setups start to get flaky. Almostnode exposes an npm.install() flow:

import { createContainer } from "almostnode". Const container = createContainer(). Await container.npm.install;

container.execute(`
  const _ = require("lodash"). Console.log(_.capitalize("hello world")).
`);

Real npm packages. Resolved and installed client-side. Wild.
Source: https://github.com/macaly/almostnode

Running CLI tools: where it stops being a toy

The real fun starts when you stop running cute snippets and start running tooling. The stuff people actually do. Almostnode can run shell-ish commands against your virtual project, like npm run ...:

container.vfs.writeFileSync(
  "/package.json",
  JSON.stringify({
    name. "my-app",
    scripts: { test: "vitest run" }
  })
);

const result = await container.run("npm run test"). Console.log(result.stdout).

This is the line between “demo” and “developer experience.” You can ship an interactive example that runs tests, lints, builds, serves… without the user installing anything locally.

If you want a wider view of this whole space, Nearform talks about similar approaches like StackBlitz WebContainers and CodeSandbox Nodebox, and why people do it for real-time experimentation. Their example target is running Fastify in-browser.
Source: https://nearform.com/insights/how-to-run-node-js-in-the-browser/

Security: Node.js in your browser, without getting owned

Alright, the uncomfortable bit.

If you run arbitrary code on the main thread, it can touch your page. Almostnode’s repo is very clear about this:

Do not use createContainer() / container.execute() with untrusted code.

For untrusted code, almostnode recommends a runtime with a cross-origin sandbox:

import { createRuntime, VirtualFS } from "almostnode". Const vfs = new VirtualFS();

const runtime = await createRuntime(vfs, {
  sandbox: "https://your-sandbox.vercel.app",
}). Const result = await runtime.execute(untrustedCode);

Source: https://github.com/macaly/almostnode

Nearform also flags the bigger theme. Running untrusted code in the browser is risky, so isolation matters if you want to prevent DOM access or data exfiltration. They also mention how some runtimes rely on things like SharedArrayBuffer, which has been disabled by default in many browsers since 2018 because of Meltdown/Spectre-style concerns. That’s where cross-origin isolation with COOP/COEP can end up in your setup.
Source: https://nearform.com/insights/how-to-run-node-js-in-the-browser/

So treat this like a plugin system. Sandbox it, or it’ll eventually bite you. Not “might.” Eventually.

When “Node.js in your browser” is brilliant… and when it’s a headache

I’ve wrestled with docs playgrounds before, and the dream is always the same. Instant feedback. No setup drama.But “works on my machine” energy.

Where this shines:

  • interactive docs where people can edit, run, see output immediately
  • workshops and training where you’d rather not spend 45 minutes installing stuff
  • repro sandboxes for bug reports
  • running small test suites in tutorials with vitest
  • teaching Node APIs without requiring Node installed

Where it’s not so hot:

  • anything depending on native addons like node-gyp and lots of *.node modules
  • heavy CPU work on the main thread, unless you push it into a Worker
  • production backend workloads, because the browser is not your server
  • workflows needing “real disk” behavior since it’s virtual and refresh can wipe state unless you persist it

Wrap-up

“Node.js in your browser” used to mean awkward hacks, fake fs, and a lot of hand-waving. With almostnode, it’s starting to look like a real runtime. Node-style modules, an in-memory filesystem, npm installs, even dev servers.
Sources. Https://github.com/macaly/almostnode and https://almostnode.dev/

Start with trusted code in a container. Then switch to a sandboxed runtime when you let users run arbitrary snippets. And if you want the official grounding for why any of this is tricky, the Node team’s write-up on differences between Node.js and the browser is still the cleanest baseline.
External link: https://nodejs.org/en/learn/getting-started/differences-between-nodejs-and-the-browser

If you’re into tooling like this, you might also like this internal post: 5 free open-source tools for web developers.

Got a use case in mind? Docs playground, in-browser linter, teaching repo. Drop it in the comments and I’ll help you sanity-check whether “Node.js in your browser” is the right hammer.

Post a Comment