I think this is for people who want to run their own cloudflare workers (sort of) and since nobody wants to run full node for that, they want a small runtime that just executes js/wasm in an isolated way. But I wonder why they don't tell me how I can be sure that this is safe or how it's safe. Surely I can't just trust them and it explicitly mentions that it still has file IO so clearly there is still work I need to do customize the isolation further. The reason why they dont show more info about this is probably because they don't really want you to use this to run it on your own, they are selling you on running things on their edge platform called "Wasmer Edge".
So that's probably why this is so light on information.. the motivation isn't to get you to use this yourself, just to use this via their hosted edge platform. But then I wonder why I wouldn't just use https://github.com/cloudflare/workerd which is also open source. Surely that is fast enough? If not then it should show some benchmarks?
I suppose the performance claim is here:
https://wasmer.io/products/edge#:~:text=Cloud-,Cold%20Startu...
The documentation is lacking, but the important context is that you can run this through the Wasmer webassembly runtime, which provides complete isolation.
It would only be able to access host directories that you explicitly grant access to (--mapdir from the CLI)
Cloudflare workers support wasm via JavaScript. At least I believe that if you write a worker in rust what happens is that CF wraps your wasm in the correct js to provide environment bindings.
In practice it make little to no difference, but CF workers are indeed js first
The way I understand it, it's a JS interpreter (SpiderMonkey) compiled to WASM that supports the Service Worker API[1].
So you basically get an unlimited number of sandboxed JS environments, that you can spawn very quickly like browser tabs. Unlike Node.js with which you'd have to do a cold start every time.
And on top of that, there's another layer of sandboxing thanks to WASM, but that's just because they already run everything on WASM.
So to summarize, it gives you speed and process isolation plus a standard API.
You just described what’s wrong with a lot of the WASM world.
I understand what WASM is and how it works at the base level but the ecosystem seems fragmented and loaded with technologies described in terms that would only make sense if I knew the rest of the ecosystem.
How do I port something to WASM? Is that even possible. What problem does it solve?
There seems to be no entry point.
The only area where WASM seems straightforward is things like Dioxus where you compile Rust or some other language to run in the browser as an alternative to JS. That makes sense. But server or “edge” WASM?
It solves the problem of cold-starts, isolation/security and portability. Basically, WASM-based cloud offerings will be able to offer more performant, cheaper and scalable compute that works everywhere regardless of the underlying architecture. Basically Docker 2.0
Here is an ELI5 explanation of the Wasmer blog post announcing WinterJS:
WinterJS is a new way to run JavaScript Service Workers that Wasmer created. Service Workers are little programs that run in your web browser to make websites work better.
The normal way to run Service Workers is using Node.js. But Node.js can be slow and heavy.Wasmer made WinterJS using the Rust programming language. Rust makes it very fast!
WinterJS also uses the same JavaScript engine that Firefox uses, called SpiderMonkey. This makes it work the same way as a web browser.So WinterJS lets you run Service Workers in a fast and lightweight way, without needing Node.js. You can run it on your computer with a simple command.WinterJS is special because it can also be compiled to WebAssembly. This means it can run in Wasmer Edge or even directly in your web browser!
> The normal way to run Service Workers is using Node.js.
This is false, and is not claimed in the original post. Service Workers run in the browser, and Node.js is not compatible with the service worker API. By which I mean that in Node, one cannot write `self.addEventListener("fetch", event => ...)`
It’s all to do with the latest trends of edge computing. If you’re not familiar with that then a lot of the principles here wouldn’t make much sense. But equally, if you’re not interested in edge computing then this is going to be of zero value for you regardless.
So one is meant to deploy these services workers on this runtime at edge nodes?
Like, user sends message to their geographically close edge node --> service worker on there caches it and routes it to appropriate main server? Or something?
> Service workers are like adding extra threads when running JS in your browser. People use them in client-side web app code to get around the single-threadedmess of JavaScript. [...]
Aren't you just describing workers in general here (without the "service" part)?
To me "Service Workers" is a worker purposed especially for proxyfying requests made by the client, on the client, and act upon it (example: by returning a version cached by the js). The main use-case I've seen is implementing an offline mode.
When you just want to unlock multi-threading capabilities in JavaScript, you just rely on "WebWorkers" another worker mechanism without the proxy part, I've never seen those referred as "Service Workers".
With that written, I don't get what Service Workers have to do being on the server-side though :/
> I don't get what Service Workers have to do being on the server-side though
Yeah, this is extremely confusing. Other posts talk about running your own CloudFlare workers... but I fail to see any potential connection between service workers and code that executes on edge nodes.
I think they're calling these edge workers "service workers" which is an unfortunate name as it clashes with the name of the Service Worker web API. This is just some JS running under a reduced set of runtime APIs (vs Node or the browser).
Also I think the project's goal is to extend the Wasmer platform (which appears to have the limitation of only running WASM assemblies) with the ability to run JS workers. Hence the need for a JS interpreter and runtime compiled to WASM.
