Deno as wasm component within the browser

[abflow]

The Stackblitz editor introduced this year in beta its "Web Container" component, which is a closed source wasm component emulating node.js directly within the browser sandbox.

It is quite impressive and allows to run node.js applications such as servers directly within the browser, with numerous benefits in terms of speed and safety compared to a traditional local node.js application. It relies on service worker for all the node.js server parts.

As Deno is built in Rust which is a language that can be compiled into wasm and as it closely follows browser implementations, how feasible would it be to run Deno as a wasm component into the browser ?

Native sockets are on the roadmap in chromium too, so it seems that browsers begin to have all the building blocks of a secure and immediatly available "WebOS" for many types of applications.

A Deno Web WASM Component would allow to have offline-first Deno applications directly into the browser with a nodejs compatibility layer too.

[eramax]

I was going to ask the something.

[load1n9]

This looks promising

[nhrones]

I've been Playing with PWA with Service Worker talking to a local Deno RPC service. The Wasm Container concept would be very Powerful.
When I tried the The Stackblitz Container examples, the very first took over 30 seconds to load (wasm I guess). The next was very fast.

[Marviel]

Hi! I think this has enormous potential and would love to know more about any efforts in this space. :)

[lino-levan]

I've been working on something for this on and off over the past few months. Definitely feasible.

[traceypooh]

From a slightly different approach, I'm trying container2wasm to run a docker container in the browser.

https://traceypooh.github.io/wasm/

I've had pretty good luck with about 10 different containers -- but I can't seem to get a deno binary to run yet (I've tried various alpine linux and debian approaches, but keep getting Illegal instruction when running deno. I can run deno -V fine, though.

[traceypooh]

hmm, ok, if I use the alpine container (compiled to .wasm) in the browser, and then do apk add deno (in the interactive xterm JS) -- then most deno (not repl) seems to works ok.

But so far, if I build the above into an alpine docker container with FROM alpine and RUN apk add deno and then compile it to .wasm and try to run that in the browser, it fails. Emulation, arch(itecture), and platform are all likely getting involved here.

[brettjrea]

I really like this alpine approach, thanks for mentioning it. Since deno is actually the Javascript V8 engine in C++ with Rust used to wrap around it. I'm not sure how compiling it to webassembly would be done. Would we compile each layer to wasm and expect them to still just interoperate. I think your alpine idea holds promise.

[ktock]

@traceypooh FYI Illegal instruction error has been solved in v0.6.4.

On-browser demo of running alpine-based Deno : https://ktock.github.io/container2wasm-demo-deno/

[mash-graz]

Since deno is actually the Javascript V8 engine in C++ with Rust used to wrap around it. I'm not sure how compiling it to webassembly would be done. Would we compile each layer to wasm and expect them to still just interoperate.

With the traditional rust WASM tools it was nearly impossible to link more complex native code into projects. wasm-bindgen is utilizing a slightly incompatible C binary interface and emscripten was never really accepted by the rust WASM maintainers and became also incompatible over time.

Recently the situation has changed to the better, because WASI preview2 and WASM component model open new possibilities and much better cross language compatibility and link support. But that's all in a very early stage. Important features (for example async support) are still missing.

Here is a nice article about this new kind of rust WASM tools: https://benw.is/posts/compiling-rust-to-wasi.

I wouldn't be too optimistic, that a huge project like deno will be easily useable via WASM in the browser. The fact, the rustc and cargo are also not able to compile themselves to runnable WASM artifacts is IMHO a very clear indicator for the existing limits and rather questionable maturity of all this tools.

Nevertheless, development tools, which are able to run in the browser or as platform-agnostic binary in various sandboxed environments (CI pipelines, etc.) are indeed very interesting. Especially for scientific notebook solutions and similar applications it makes a significant difference, if you don't have to trust external service provider, but also do not have to install any complicated local server setups to use this kind of research and demonstration software. jupyterLite has already solved this challenge. It's IMHO a very impressive step forward.