WinterJS
wasmer.io
wasmer.io
wasmer run wasmer/winterjs --dir=. serviceworker.js
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?
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.
To be fair, the reason I'd fail to remember such a time is the same reason that I can't remember anything else from that time. Most people don't remember being a baby.
Unless you think knowing the word "console" is the important part there. I would have just said "DOS".
I have been programming for half of my life since I was a teenager, but I can still remember how frustrating it was that some things just were assumed. I still remember when software without a GUI was an unpleasant thing for me, I can still remember struggling to understand how all the web technologies tie together and so on.
Understanding that what you know isn't automatically self-evident or obvious even to a person that might be more intelligent than yourself is an important skill in the IT sector if you want to communicate effectively.
The family computer had Windows, but I would not use it other than to play Solitaire, because it functioned worse than DOS. The default UI was DOS Shell ( https://en.wikipedia.org/wiki/DOS_Shell ; the page image there is not a perfect match to our installation, but it's close.), so most often I'd be using what amounted to a very primitive graphical interface, but I would also use straight DOS for reasons I do not recall.
† Almost. I vaguely remember the large boards that my mother prepared in order to teach me to read, things like a magazine photograph of a horse juxtaposed with a large letter H, but I don't remember being so instructed, and that memory is subject to later reinforcement because those boards were kept for a long time. But it stands to reason that I would have needed to learn to read before learning to use a computer, so there's a chance some of those board memories predate that knowledge. I can remember my mother singing to me, but there's no way to date those memories precisely. Any memories that still maintain concrete details come from well after I could use a computer.
I recommend grabbing a bucket of patience and sitting down with an older but interested non-technical person and telling them to do some normal everyday things on their PC. You will quickly learn to start tutorials with: "First, make sure you have git installed. Then clone this repo by opening a terminal like so: ..."
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
You need a fairly recent version, so using the install script is recommended.
> curl https://get.wasmer.io -sSfL | sh
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?
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...
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.
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 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.
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.
Do you mean: "it's *a* JavaScript runtime that isn't a browser"?
You are implying that JavaScript runtimes would be the users of WinterJS. That has me even more confused.
Good catch! It is indeed a JavaScript runtime for Service Workers.
By "for", I was attempting to make the point that it's intended to be deployed to non-browser JavaScript/Wasm runtimes.
Seemingly.
> Why does a JavaScript runtime need a JavaScript runtime?
Because if you want to create a Service Worker server for CloudFlare Workers and other JavaScript/Wasm runtimes, that's the only option for doing that AFAIK.
FWIW, this isn't a new idea. For example, Figma uses QuickJS (https://bellard.org/quickjs/) for their plug-in runtime: https://www.figma.com/blog/an-update-on-plugin-security/
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.
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.
facebook/zstd has performance as a selling point, by doing extensive benchmarks and presenting them.
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’m sorry if you’re one of the developers who’s stuck on Java or C# and feeling frustrated for whatever reasons. The JVM is fast and will continue to power much of the world for decades to come, and C#, well, it’s probably not going anywhere either. But what you’re writing about here doesn’t really make a lot of sense in the greater scheme of things. Right now, the client side of things is JavaScript and while we build it in a lot of different ways it’s hard to argue against the need for better service workers until we have a suitable replacement, which we likely won’t have in our careers.
Maybe you expected me to have a combative point due to my introduction, but i dont - im just pointing out that people use languages like Rust and C++ thinking they are fast, when really, an inexperienced programmer in either will write slower code than an inexperienced programmer in a lot of other languages.
They feel they dont need benchmarks, because their language is "fast".
Java/C# code can become incredibly slow if you allocate way too many objects, use Streams/LINQ or touch URL#equals. Why are managed languages specifically better here?
You're right of course. It's very easy to write shitty code with much futher reaching consequences in C++, but I've never really experienced it. Like, we use Typescript for basically everything (not because we necessarily like Typescript but because it allows us to share developer resources across basically everything) but when we need performance we turn to C or C++. We also use C and C++ for embedded, but that's mostly because we kind of have to. We'll eventually turn to Rust exactly because it offers some of the benefits you talk about from Java or C# without any of the downsides.
I know both Java and C# have large fanbases, and for Java at least, there is good reason behind that, but even if you went that road in 2023, I'm not sure why you wouldn't follow the good people at places like Lunar and simple turn to Go. Unless of course you're stuck with some huge legacy codebase, which in itself is a very good reason to stick with Java.
> They feel they dont need benchmarks, because their language is "fast".
It's not though. Even if you use Java or C# you're eventually going to need to turn to C and C++ for better computation. I know a lot of medium sized C# houses never get there, but maybe there is a reason C# is basically only used by companies that stagnate at a certain size?
Have you actually taken the time to read the source code of this project to see how many creates are used and how it is architected, or are you just piling shit on them for no reason?
But I wouldn't say this is a special quality of Rust. I'd expect similar winnings had I chosen any other non-GC compiled language like, say, Zig. Just saying that the well known tiering of languages has held true for me.
Comes free with most snake oil marketing kit.
Anything else marketing staff.
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.
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.
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...
Fair question
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.