top | item 38047872

WinterJS

139 points| kevinak | 2 years ago |wasmer.io | reply

86 comments

order
[+] TekMol|2 years ago|reply
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?

[+] atoav|2 years ago|reply
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.

[+] jokethrowaway|2 years ago|reply
Check the homepage?

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
As the sibling said, you first need to install the wasmer CLI.

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
After reading the whole page I still don’t get what it does, why I need it and how exactly it’s cool. I mean okey, JavaScript ant rust, yeah. Aaand?
[+] Nathanba|2 years ago|reply
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...

[+] katspaugh|2 years ago|reply
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.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

[+] api|2 years ago|reply
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?

[+] simonw|2 years ago|reply
Yeah I'm a bit stuck on "Service Workers server" - so it's a server-side tech that emulates the service workers spec from browsers?
[+] scary-size|2 years ago|reply
I know Rust, Service Workers, JavaScript, even heard of SpiderMonkey. Still, no idea what this is about. What problem does it solve?
[+] joshxyz|2 years ago|reply
dude i went there and tried to prove you wrong but you're right.

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
I guess it helps to utilize otherwise-idle CPUs to keep you warm, hence the name.
[+] crabmusket|2 years ago|reply
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.

Anyway, I'm glad someone else has done it.

[+] remram|2 years ago|reply
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.
[+] CharlesW|2 years ago|reply
I'll take a shot, based on the first paragraph:

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
> 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.

[+] dkwr|2 years ago|reply
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.

[+] vasergen|2 years ago|reply
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?
[+] resonious|2 years ago|reply
I'm starting to wonder why people are saying their stuff is fast. Much of the time there's no benchmark.
[+] keyle|2 years ago|reply
Blazing fast is so fast, one cannot measure it. You'd try and fail because, woof, it's gone. And you know it's good because it has Zing! in it.

Comes free with most snake oil marketing kit.

[+] o_m|2 years ago|reply
It is a meme, but at the same time performance has become a popular selling point again.
[+] rickstanley|2 years ago|reply
I never understood the meaning of using "tm" with "blazing fast" and "it just works", is it a joke that is well known in tech?
[+] sfink|2 years ago|reply
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.

[+] mstade|2 years ago|reply
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.
[+] oefrha|2 years ago|reply
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.
[+] typosaur|2 years ago|reply
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.
[+] gregd|2 years ago|reply
I'm on old curmudgeon and just want to go back to saying, "C#...It's fast enough!"
[+] lionkor|2 years ago|reply
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.

[+] charcircuit|2 years ago|reply
What's the point of running a the javascript virtual machine on the WASM virtual machine?
[+] norman784|2 years ago|reply
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.

[+] lionkor|2 years ago|reply
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.
[+] pleoxy|2 years ago|reply
Pretty confusing to call their target a "service worker" when that is also the name of an in browser platform. Kind of a mess of a post.
[+] ushakov|2 years ago|reply
WinterJS doesn’t support any other runtimes other than wasmer though?
[+] hobofan|2 years ago|reply
Yes, as it's based on WASIX, the superset of WASI created by Wasmer, that is (and probably will be) the only runtime that will run WinterJS.
[+] indeyets|2 years ago|reply
Why do I need service workers as standalone programs on the backend? What am I missing by not running them? Looks like another way to run server app

Fair question

[+] chiubaca|2 years ago|reply
so, is this a cloud flare workers alternative?
[+] dynamite-bud|2 years ago|reply
Yes, it is. It is based on cloudflare's winter-cg spec
[+] elvis19|2 years ago|reply
Can i use this to compile Javascript to .wasm and run it with Apache mod_wasm?
[+] hobofan|2 years ago|reply
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.

[0]: https://github.com/bytecodealliance/componentize-js

[+] throwoutway|2 years ago|reply
Meta: with the double top-banner and the massive side-bar and gutters, the readable space for the blog is <30% of the page