They say running the hello world example "is as simple as this:"
wasmer run wasmer/winterjs --dir=. serviceworker.js
But ... what does that mean?
After I turned on a new computer, I certainly can't type that command and have it running "a JavaScript Service Workers server written in Rust, that uses the SpiderMonkey runtime to execute JavaScript" as they put it.
What is the background here? Say I have a newly installed Debian 12 machine - how do I get to use this thing?
On a tangent here: many IT people really suck at explaining things from the start.
I sometimes wonder if they fail to remember a time where it was them that didn't know e.g. what a console actually is and how it can be used, before giving the person opposite an non-explaination like: "You just have to do $CLI-APPLICATION-TASK"
Not that I have anything against command line applications (quite the opposite) — but if you, the trusty IT person, recommend someone to do X, you better check if the know the things required to even understand what X is.
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 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?
I actually tried writing something like this one weekend last year. I really like the idea of the https://wintercg.org/ group this runtime is named after, and I wanted a non-Node, non-Cloudflare, non-X version just to explore what it took to implement some of the APIs they've standardised on.
It was based on QuickJS and Tokio and never got far. Instead of implementing builtins in C, as the article suggests you would with QuickJS, I was implementing them in JS. I think I got to the point where the very simplest hello world would work.
It is weird that this is so high up in the frontpage yet no one in the comments understands what it is. Hopefully someone from the project team sees this and comes up with an understandable description.
> The WinterJS server is published in Wasmer as wasmer/winterjs.
Struggling with the assumed knowledge here, and having to hop a number of pages. What is wasmer? Why is this published there and not npm.
I think there is a new set or layer of terminology, some very close to each other, that the wasm world introduces but which nobody wants to explain. That leads to confusing when trying to understand a project like this.
You need to be careful when looking at wasmer.
They build upon the Wasm and WASI standard their own stuff like WASIX.
Running WASIX compatible services/stuff may not be compatible with other WASI runtimes.
Furthermore they do offer their own package manager to serve Wasm modules. Which is why it is published there.
They are doing a lot of effort to speed up the development around Wasm, but you need to know what you can use with your run time and what is the "real" Wasm/WASI standard.
What does it mean "blazing fast"? Every new thing is blazingly fast nowadays.. deno, bun, turbopack, etc. I don't even know what does it mean to me as a user, does it really super fast or it is just some fancy words. "blazingly fast" compared to what?
Something that helps me: instead of reading "blazing/blazingly fast" as "blazingly fast", read it as "blazingly fast". As in, it is fast at doing whatever it's doing, as are almost all entrants in... whatever this stuff is. But it is doing it in a way that is figuratively analogous to a large conflagration. Whatever is running on it will end up a blackened, twisted pile of wreckage. Perhaps after achieving its purpose, perhaps a bit before.
I'm not saying that's what they're saying, but I am saying it's a valid interpretation of what they're saying. It's worth speculating about which interpretation better fits the subject at hand.
Yeah this kind of statement drives me up the wall. It's even more annoying when they do show some benchmark stats, but don't provide any details on how to run the benchmark yourself.
Especially considering that SpiderMonkey is definitively not blazing fast compared to V8 or JSC, for common web workloads anyway. At most it’s comparable. Somehow doubt adding a layer of wasm indirection makes it faster. But I suppose everything is indeed blazing fast when compared to no target at all.
I assume they mean startup speed (cold-start). Since they're not using JIT (WASM doesn't support it) the runtime performance will be miles beyond V8 and JSC.
They use Rust (i like Rust), so they have to somehow convince themselves that their mess of overly abstracted code strewn across 2000 crates is, in fact, very very fast and it's all worth it.
I think people use a language like Rust because they hear its got potential for performance, but its told to them like so: "Rust is blazing fast!".
So they perpetuate that idea, and just hope to god that their program, even if its horribly cache-inefficient, allocates aggressively, context switches constantly, etc. is still fast enough that it feels fast.
Also, of course, on dev machines which often have high end hardware, it probably does feel very fast. "I can't even see any time between input and result, its so fast!", said the programmer running his script on an overclocked i9-9900k with nothing else open
To be clear, nothing about Rust or C or C++ is fast. They allow you to write faster code than most other languages, some more easily than others. All of those you can easily write the slowest code imaginable in. Try doing a bunch of very expensive copies in C# or Java - youd have to go out of your way. In C++ its default behavior.
I suppose that for the platform provider it's easier to ship only one runtime and then run everything over it, also might be better in terms of security because of the sandboxed nature of WASM.
Once WASI gets stabilized, you will also have the option to mix JS with the other languages that already target WASM, so your infra could be build on top of different languages and change them according to the requirements, just think of you build your entire system in JS, compile in modules and deploy them as components, then you can swap one component at the time when necessary.
Cpu architectures and hardware is incompatible, so OSs provide a layer across. OSs are incompatible, so browsers and their virtual machines (i.e. javascript runtimes) provide a layer across. Browsers are incompatible (in some ways more than others), so wasm provides a layer across. Wasm is cool, so we backport wasm + the vm + the browser + the OS to a new program, which abstracts all that again. Cross platform is hard and hasn't gotten any easier.
I don't think that's the intended use-case for this.
If you want to do this, I think something like ComponentizeJS[0] is what you would be looking for. As far as I can tell you'd also need to create WIT (Wasm Interface Type) definitions for the interface(s) that mod_wasm expects for its WASM modules, as they don't provide them themselves.
[+] [-] TekMol|2 years ago|reply
After I turned on a new computer, I certainly can't type that command and have it running "a JavaScript Service Workers server written in Rust, that uses the SpiderMonkey runtime to execute JavaScript" as they put it.
What is the background here? Say I have a newly installed Debian 12 machine - how do I get to use this thing?
[+] [-] atoav|2 years ago|reply
I sometimes wonder if they fail to remember a time where it was them that didn't know e.g. what a console actually is and how it can be used, before giving the person opposite an non-explaination like: "You just have to do $CLI-APPLICATION-TASK"
Not that I have anything against command line applications (quite the opposite) — but if you, the trusty IT person, recommend someone to do X, you better check if the know the things required to even understand what X is.
[+] [-] jokethrowaway|2 years ago|reply
You can install it with a package manager. I just add wasmer-pack on nixos, I see available wasmer on arch, you can also cargo install wasmer.
Or even:
$ curl https://get.wasmer.io -sSfL | sh
[+] [-] the_duke|2 years ago|reply
You need a fairly recent version, so using the install script is recommended.
> curl https://get.wasmer.io -sSfL | sh
[+] [-] Muromec|2 years ago|reply
[+] [-] Nathanba|2 years ago|reply
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...
[+] [-] katspaugh|2 years ago|reply
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...
[+] [-] api|2 years ago|reply
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?
[+] [-] simonw|2 years ago|reply
[+] [-] scary-size|2 years ago|reply
[+] [-] joshxyz|2 years ago|reply
what's the freakin use case here, do i need gpt4 to eli5 this page?
[+] [-] TimTheTinker|2 years ago|reply
Edit: deleted what I had written. I was mixing up service workers and web workers.
[+] [-] defanor|2 years ago|reply
[+] [-] crabmusket|2 years ago|reply
It was based on QuickJS and Tokio and never got far. Instead of implementing builtins in C, as the article suggests you would with QuickJS, I was implementing them in JS. I think I got to the point where the very simplest hello world would work.
Anyway, I'm glad someone else has done it.
[+] [-] remram|2 years ago|reply
[+] [-] CharlesW|2 years ago|reply
WinterJS is a JavaScript Service Workers¹ server.
It's for JavaScript runtimes that aren't browsers², so that you can write JavaScript Service Workers that run (fast!) on those non-browser platforms.
¹ Service Workers allow developers to write code that runs in the background, independent of the main appliaction thread.
² Like Cloudflare Workers, Deno Deploy, Vercel, and Wasmer Edge.
[+] [-] politelemon|2 years ago|reply
Struggling with the assumed knowledge here, and having to hop a number of pages. What is wasmer? Why is this published there and not npm.
I think there is a new set or layer of terminology, some very close to each other, that the wasm world introduces but which nobody wants to explain. That leads to confusing when trying to understand a project like this.
[+] [-] dkwr|2 years ago|reply
Furthermore they do offer their own package manager to serve Wasm modules. Which is why it is published there.
They are doing a lot of effort to speed up the development around Wasm, but you need to know what you can use with your run time and what is the "real" Wasm/WASI standard.
[+] [-] vasergen|2 years ago|reply
[+] [-] resonious|2 years ago|reply
[+] [-] keyle|2 years ago|reply
Comes free with most snake oil marketing kit.
[+] [-] o_m|2 years ago|reply
[+] [-] rickstanley|2 years ago|reply
[+] [-] sfink|2 years ago|reply
I'm not saying that's what they're saying, but I am saying it's a valid interpretation of what they're saying. It's worth speculating about which interpretation better fits the subject at hand.
[+] [-] mstade|2 years ago|reply
[+] [-] oefrha|2 years ago|reply
[+] [-] typosaur|2 years ago|reply
[+] [-] gregd|2 years ago|reply
[+] [-] lionkor|2 years ago|reply
I think people use a language like Rust because they hear its got potential for performance, but its told to them like so: "Rust is blazing fast!". So they perpetuate that idea, and just hope to god that their program, even if its horribly cache-inefficient, allocates aggressively, context switches constantly, etc. is still fast enough that it feels fast.
Also, of course, on dev machines which often have high end hardware, it probably does feel very fast. "I can't even see any time between input and result, its so fast!", said the programmer running his script on an overclocked i9-9900k with nothing else open
To be clear, nothing about Rust or C or C++ is fast. They allow you to write faster code than most other languages, some more easily than others. All of those you can easily write the slowest code imaginable in. Try doing a bunch of very expensive copies in C# or Java - youd have to go out of your way. In C++ its default behavior.
[+] [-] charcircuit|2 years ago|reply
[+] [-] norman784|2 years ago|reply
Once WASI gets stabilized, you will also have the option to mix JS with the other languages that already target WASM, so your infra could be build on top of different languages and change them according to the requirements, just think of you build your entire system in JS, compile in modules and deploy them as components, then you can swap one component at the time when necessary.
[+] [-] lionkor|2 years ago|reply
[+] [-] pleoxy|2 years ago|reply
[+] [-] ushakov|2 years ago|reply
[+] [-] hobofan|2 years ago|reply
[+] [-] hackandthink|2 years ago|reply
Taking Javascript Code and generating a specialized Interpreter for this Code which can be compiled to Webassembly. (Chris Fallin)
https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...
via https://github.com/cfallin/weval
[+] [-] indeyets|2 years ago|reply
Fair question
[+] [-] chiubaca|2 years ago|reply
[+] [-] dynamite-bud|2 years ago|reply
[+] [-] elvis19|2 years ago|reply
[+] [-] hobofan|2 years ago|reply
If you want to do this, I think something like ComponentizeJS[0] is what you would be looking for. As far as I can tell you'd also need to create WIT (Wasm Interface Type) definitions for the interface(s) that mod_wasm expects for its WASM modules, as they don't provide them themselves.
[0]: https://github.com/bytecodealliance/componentize-js
[+] [-] throwoutway|2 years ago|reply