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...
But they don't mention that Cloudflare workers supports rust, c... And just say "mainly js"
But they did add it for their own...
So, misleading...
Which should be just a hello world
In practice it make little to no difference, but CF workers are indeed js first
It would only be able to access host directories that you explicitly grant access to (--mapdir from the CLI)
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.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
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?
what's the freakin use case here, do i need gpt4 to eli5 this page?
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!
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 => ...)`
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?
Edit: deleted what I had written. I was mixing up service workers and web workers.
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.
EDIT: Here's an example "service worker" on wasmer: https://github.com/wasmerio/js-service-worker-example/blob/m...
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.