It is a v8 engine, every embed is backed by node running in a container, so you're getting the real deal, not an emulation environment.

That means your embeds can write to the filesystem, use any npm package, (even spin up child processes if that's what you want to show off!).

So it's not embedding node, it's embedding an interface that connects to a remote node instance

Sorry for the confusion, not sure what a "true embed of node" on a webpage would be. "Replicating node" certainly wouldn't be either, I suppose the only thing that would be truly embedding node is compiling the node binary with emscripten or NaCL? If that's what you were thinking then no, we are allowing you to embed "node source code examples" into a webpage that users can run.

My first thought was that it compiles node (+native modules) with emscripten to asm.js and lets me run everything in the browser

a "true embed" would be something like Electron, that's running a node instance on the client, and can work independently without any interaction with a server.

Yes, it is confusing. Title should have been "interface with remote node.js from any website"

That's less clear. That sounds like it's just an API rather than allowing you to put Node code on your page and have it run.

To me, "embedded" would not rely on a remote backend.

We're using the word "embed" in what I feel like is a pretty generically understood web term of "take this external thing and embed it in your page".

The actual thing you are embedding is a version of our app, Tonic, which yes interfaces remotely with Node.js. I think this title is the best way of getting the idea across in a few words though.

something is amiss here: don't you already get a javascript runtime free with every browser already?

It doesn't replicate anything, it's actually running the code in node and sending the result back.

It doesn't seem to be running in the client's JavaScript engine. It sounds like they are sending the source to an API, evaluating, and returning the result.