Show HN: QuickBEAM – run JavaScript as supervised Erlang/OTP processes

28 points by dannote a day ago

QuickBEAM is a JavaScript runtime embedded inside the Erlang/OTP VM.

If you’re building a full-stack app, JavaScript tends to leak in anyway — frontend, SSR, or third-party code.

QuickBEAM runs that JavaScript inside OTP supervision trees.

Each runtime is a process with a `Beam` global that can: - call Elixir code - send/receive messages - spawn and monitor processes - inspect runtime/system state

It also provides browser-style APIs backed by OTP/native primitives (fetch, WebSocket, Worker, BroadcastChannel, localStorage, native DOM, etc.).

This makes it usable for: - SSR - sandboxed user code - per-connection state - backend JS with direct OTP interop

Notable bits:

- JS runtimes are supervised and restartable - sandboxing with memory/reduction limits and API control - native DOM that Erlang can read directly (no string rendering step) - no JSON boundary between JS and Erlang - built-in TypeScript, npm support, and native addons

QuickBEAM is part of Elixir Volt — a full-stack frontend toolchain built on Erlang/OTP with no Node.js.

Still early, feedback welcome.

jbpd924 - an hour ago

Interesting!! I've been playing around with QuickJS lately and uses Elixir at work.

I'm interested to hear about your sandboxing approach running untrusted JS code. So you are setting an memory/reduction limit to the process which 100% is a good idea. What other defense-in-depth strategies are you using? possible support for seccomp in the future?

waffleophagus - 39 minutes ago

Running JS on the Beam VM, all written in C. I don't know if this is just cursed, or absolutely brilliant, either way I love it and will be following closely. Will definitely have to play with it.

theflyinghorse - 2 hours ago

This is very interest to me because we have accumulated a few node packages containing logic that services simply import. So in theory I could now use those node packages in elixir?