Wasmer 5.0 | Hacker News Reader

Wasmer 5.0

wasmer.io

198 pointssyrusakbary82 comments

These performance graphs are confusing and possibly cursed. Sometimes they're log scale (confusing enough) and others, I have no idea what they're trying to say.

For example, the first graph, labelled "Argon 2", nearly all the bars are the same length, labelled "100" (no units given, apparently log scale) and the individual bars are labelled with entirely different numbers in ms (presumably milliseconds).

> having V8 as a backend also means supporting WebAssembly Exceptions and Garbage Collection under the hood. Stay tuned for more news on this front soon

Looking forward to this and languages that can make use of wasm-gc.

Does wasm-gc allow sharing of host data/strings across different modules in the same runtime, or is it contained to only single module with repeated calls/invocations? The scenario I am considering would invoke several different modules in a pipeline, pass data between each step in an efficient manner.

That's what reference types (the Wasm proposal) are for, GC builds on top of that.

Sharing GC data between wasm modules is supported, yes. You just need to define the types identically on both sides, and things work.

I have a hard time understanding what Wasmer does from their landing page. I understand it runs everything everywhere, unbound and above the cloud, but what does it do? From the name it seems like a very dev oriented product, and I can’t find a single technical word, just buzzwords

From my understandning, it's a runtime that runs webassembly (wasm). So anything that can be compiled to wasm can be runned with this which means it can be executable everywhere wasmer exists.

It's a runtime for WASI blobs (basically a WASM based standard for crossplatform command line tools), for instance:

    emcc hello.c -o hello.wasm
    wasmer hello.wasm
    Hello World!

This uses Emscripten as C compiler, but alternatively you can use the wasi-sdk toolchain instead of Emscripten to build WASI blobs:

- https://github.com/WebAssembly/wasi-sdk

...or Zig as C compiler:

    zig cc -target wasm32-wasi hello.c -o hello.wasm
    wasmer hello.wasm
    Hello World!

...or of course Zig as Zig compiler :)

    zig -target wasm32-wasi hello.zig
    wasmer hello.wasm
    Hello World!

(not sure if the Rust toolchain comes with builtin WASI support, but probably yes).

...or instead of wasmer use another WASI runtime:

- https://github.com/wasmerio/awesome-wasi?tab=readme-ov-file#...

...this is probably the best part of WASM and WASI, there's no 'vendor lock-in'.

> It's a runtime for WASI blobs (basically a WASM based standard for crossplatform command line tools)

Thanks! I wish this was the subtitle on their homepage :)

I mean, it's a Californian tech startup, what did you expect ;)

Anything that isn't "earth-shattering" and "world-changing" would be too pedestrian, especially when your product is essentially a simple cmdline tool for coders (a very useful tool of course but not exactly "glamorous").

Thanks for the feedback! I'm Syrus, from Wasmer. We are currently working on redesigning the homepage so its easier to know what we do and what is our business value. Stay tuned :)

Cool release!

I've yet to personally find a good use case for wasm in any project, kind of the same way I'm not quite sure what to do with a bunch of Raspberry Pis

It fills a need, I just don't know who/what has that need.

Example: Say I write a bunch of Rust async projects for fun. Scraping APIs, etc.

How/why would I choose wasm/wasmer to do that instead? I'd do it in Rust (awkwardly/in some specific non-standard way) to compile to wasm to then run in wasmer? To what benefit? Ok, that's not a good usecase/example

So what is?...

Take that API scraping script example. Imagine next you want to build a platform where you run code written by your users who want to e.g. scrape APIs. Think ParseHub I guess? Zapier is another good example.

You'd let them write in Rust or some other language that can target WASM, then you'd run the WASM blobs in a controlled sandboxed execution environment in your platform.

So basically: what every single platform with plugins should be doing to protect their users. Or similar via some other language that allows sandboxing, e.g. Lua.

Yeah, but the plugins can be written in Rust!

OK, OK, it’s a bad example. WASM is language agnostic though, so as more languages can target WASM, then the possible advantage is programming language agnosticism. If I have some code, I don’t have to re-write it in Lua.

Yes, that's right. It's just another option that lets you do that in a different (better?) way, and doesn't force all your users to write Lua.

yea https://blog.cloudflare.com/announcing-wasi-on-workers/ and such.

I cross-compile a native qt app in windows, Mac, and Linux variants. It’s pretty neat to see it compile in wasm as well.

It probably makes sense if you're running untrusted code or handling untrusted data, or running code that was written after the rest of your app

So for a solo dev it doesn't add much, but for a web browser or something that needs plugins it could make a lot of sense.

> It probably makes sense if you're running untrusted code or handling untrusted data

I never understood this because... I feel like wasm (the standard) is an empty box and a lot of runtimes help you attach things to it / make it useful (able to read/write to filesystem, call the Internet, etc.)

history tells us, that usecase will go out the window as soon as the usual suspects do their usual standards capture by implementation to support something or another related to advertising attribution.

WASM has two primary usages:

1) Making canvas webapps with unblockable ads built-in

2) Downloading and running random blobs of other people's code in a sandbox

To be fair, a rock-solid sandbox with extremely well defined and host controlled ingress/egress in a tiny package sounds absolutely fantastic

That’s what it is.

that would have been implement in something like forward only language like ebpf. wasm is just an outgrown hack that people are hopping will be that safe sandbox and solve all JavaScript problems.

do not fool yourself with this temporary feature. wasm was first for js performance. secondly for portability. and third and accidentally for sandbox.

> that would have been implement in something like forward only language like ebpf. wasm is just an outgrown hack that people are hopping will be that safe sandbox and solve all JavaScript problems.

It's funny that every time an article on new functionality for eBPF appears in LWN everybody is like "why don't they just use WASM???". More seriously, a forward only language is by definition too strict for the general case of sandboxing, unless you mean using it only for hooking the syscalls rather than as a target for your program. In particular, the Linux implementation caps your execution to 1M instructions, which is not a lot for something you'd want on your browser.

forward only requires you to think harder. that's very true.

You can do both of those things in JavaScript.

WebAssembly brings every language to the web and does it with higher performance than JavaScript.

For sandboxing in JS, we can use sandboxed iframes or webworkers. Both of those communicate to hosted code via postmessage which serializes an object and this can be used as a base for implementing function calls.

Whereas if I understand correctly, WASM can be provided with host approved JS functions to call directly in importObject. This seems more convenient and fast.

But for a plugin system, many people would prefer to write plugins in JS itself, so for WASM plugins, they might have to be compiled to WASM first. Dont know how if there is a mature implementation of JS->WASM.

> But for a plugin system, many people would prefer to write plugins in JS itself, so for WASM plugins, they might have to be compiled to WASM first. Dont know how if there is a mature implementation of JS->WASM.

Not everyone tho, which is kinda the point of abstracting away your language for plugins. People like Python, Lua, Go, Rust, etc... Some do like JS of course, but not everybody. Re: mature implementations, I would guess worst case QuickJS probably can compile to WASM and it's small enough that your runtime will probably offset the extra blob size.

Javy project seems more active.

> I would guess worst case QuickJS probably can compile to WASM

That's actually exactly what Figma is doing for their plugins. [1] Seems to be working ok, though not without some pain [2].

[1] https://www.figma.com/blog/an-update-on-plugin-security/

[2] https://macwright.com/2024/03/29/figma-plugins

I am happy with

3) Bring back all the plugins that were taken away.

See no other use for it.

> 1) Making canvas webapps with unblockable ads built-in

Which isn't any different from Javascript if you choose to embed the ads right into the Javascript code - but nobody does this because it doesn't make any sense.

In reality, a WASM app that displays ads would also need to load the ad content over one of the existing ad-network mafias (serving ads any other way simply doesn't make any financial sense), and those HTTP requests initiated by a WASM blob (by calling out into JS - because that's the only way in browsers) will be blocked just as fine by existing ad-blockers.

...but I'm also not actually aware of any webpage that does this (trying to defeat ad-blockers via wasm), do you have any example?

ONNX has a WASM backend for running models in a browser. It’s what transformer.js (from HuggingFace) uses behind the scenes.

I've used wasm to write web applications in Go that run in the browser, both HTML applications (https://github.com/octoberswimmer/masc) and TUI apps using xterm.js (https://github.com/charmbracelet/bubbletea/pull/887).

A toy project, but I'm working on a Scrabble clone for my mother to play. There's singleplayer against an AI, and then multiplayer against other people (myself, mostly). Multiplayer needs a server backend with all the game logic which I have programmed in Rust, but there's no reason I can't have the game logic for singleplayer running entirely in the browser.

By compiling my backend code to WASM I basically do that - the client can use either a client-side 'server' or connect to a real server. The UI code itself is unchanged in either case.

I suppose the need in this case is that I have code written in a language other than JS and I want to run it in a browser; inversely I could have written the entire project in JS and hosted my backend server on say Node.

> Multiplayer needs a server backend

Did you mean single player? Although perhaps I'm just old and thinking about this in a strange way.

And can I clarify.. your scrabble app is web based already right? connecting to a rust web server for the game logic? And you want to embed that server by compiling to wasm? I probably should go read up on how this works.

Not the OP, but most web-based multiplayer games use a server backend to communicate between the multiple players.

> connecting to a rust web server for the game logic? And you want to embed that server by compiling to wasm?

I would assume so, and it being in WASM means they can use the exact same binary code on the server and in the webbrowser.

You could of course do the same thing by writing in Javascript (running in Node on the server or in the browser) but then you are in JS instead of Rust.

Thank you, that clears it up for me. Tech has changed a lot since I was exposed to web programming.

i did almost the exact same thing except i wanted the client to enforce the same logic as the server would without having to do api request on every action or having 2 implementations so i just compiled the library code to wasm and that way both the server and the client share the same logic

I’m using WASM as the modding interface in my game. (I’m using wasmtime from Rust, but same principle.)

Main benefits are isolation, binary portability, and hot reload.

Everyone else has answered about WASM, so I'll answer about raspberry pi. I've got 5 of them. One is running Home Assistant for all my home automation and camera recording. One is running a quadruped that I built. And three are connected to three sets of speakers around the house running a home-rolled Sonos-like setup so I can stream the same music all around the house from my phone.

Cool! Thanks! I've got none of that.

I think the biggest company using wasm in production is figma (though there might be others). Otherwise, here is an example where wasm shines. Say you have an editor (rvim) and you want to support plugins. Usually, you’ll have a language interpreter and ask developers to develop in this language. With wasm, you can give them the freedom to use whatever stack they want. Then you expose an interface for their wasm artifacts. This abstract the host OS away. Another example is game mods/plugins.

> I think the biggest company using wasm in production is figma (though there might be others)

Amazon uses Rust to wasm for the Prime video app and Google uses Java to wasm for Google Sheets. Both get higher performance and lower memory usage versus JavaScript:

https://www.amazon.science/blog/how-prime-video-updates-its-...

https://web.dev/case-studies/google-sheets-wasmgc

Abode uses wasm in the web based version of Photoshop:

https://medium.com/@addyosmani/photoshop-is-now-on-the-web-3...

Wasm could be a handy way of letting users mod your app using their choice of programming language that can compile to wasm. Compare with how lua is used.

Interesting.

I am happy with wasmtime though.

Hacking on a wasm component model and wasi based plugin system these days.

Having loads of fun. (I am aware of extism, but I am doing it for the fun :))

> Hacking on a wasm component model and wasi based plugin system these days.

Same here! Can you share what you're working on? I'm (slowly) making a 3D CAD modeling API, so you write Rust code to define a model, and compile it to WASM so it can hot-reload and let you iterate faster.

https://github.com/bschwind/opencascade-rs/tree/main/crates/...

shape.faces().farthest(Direction::PosZ)

nice. is this original from openscad (if that even is your inspiration)?

OpenSCAD is of course the OG for code-based CAD, but this particular syntax came about from converting CadQuery-esque queries into Rust iterators with a bit more type-safety instead of something stringly-typed.

Here's a snippet from a CadQuery example:

    # 3a. The top-most Z face is selected using the >Z selector.
    # 3b. The lower-left vertex of the faces is selected with the <XY selector.
    result = result.faces(">Z").vertices("<XY")

Right now it just does a naive linear search but at some point I'd like to extend it to use more of OpenCascade's underlying geometric acceleration structures (which I assume exist), and add more and more iterator adapters.

I wish they had a solution that didn't require Cross-Origin Isolated headers. I am still using an older version where that wasn't required.

What do you mean? Wasmer isn't a web frontend tech

Well apparently it is? I am confused https://github.com/wasmerio/wasmer-js

Don't browsers support wasm natively?

wasmer is a software to run a wasm binary locally like an app.

wasm is a web standard supported by browsers and lets this wasm binary run in the browser.

Also, the project called "wasmer" that is discussed in this thread is https://github.com/wasmerio/wasmer and not wasmer-js that you link to.

Could this ever function as a less resource intensive substitute for Electron apps? WASM doesn't have DOM access, but could it be added in these extensions?

Edit: Maybe this question doesn't make sense as the OS would need to have the runtime installed, and if that can be assumed, we would have lightweight apps already.

Ha e a look at Tauri for a less resource intensive electron alternative. Written in rust and supports any framework on the frontend side, with strong access control & lightweight backend.

Take a look at Electrobun. It’s a Tauri alternative where you write typescript instead of rust. App bundles as small as 16MB and it creates update patches for your app as small as 4KB.

Written in zig and Bun, and uses the system webview by default.

I'm having a really hard time reading the performance graps.

The thousand separator comma and dot are both used (which is not correct in any part of the world), and precision is being randomly rounded to 1, 2 or 3 digits.

Would this allow to safely eval Node.js code in a sandbox?

Not "Node.js code" specifically as Node.js itself can't be compiled to wasm. JavaScript can be compiled to wasm, but that won't include the whole Node.js standard library and doesn't seem to be what you are asking.

Check out Deno for a sandbox that is getting there. Their new release does (aim to) support most Node.js code, where it previously and intentionally did not support node_modules nor CommonJS to the best of my knowledge.

If you care more about wasm than sandboxing in general, one project called javy is interesting, but you'll quickly notice they bring their own IO library and not much else in terms of something that compares to Node.js' API.

I really don't know what problem(s) this solves. Don't all the javascript runtimes already have wasm engines built into the runtimes?

You don't need to carry around a whole Javascript engine when all you want is running some WASM/WASI code. Granted, the real-world differences aren't all that big:

    - wasmer: single 45 MByte exe
    - wasmtime: single 28 MByte exe
    - node.js: 87 MByte, lots of individual files
    - deno: 186 MByte over two executables (deno and denort not sure what denort is though)

As an extreme outlier, there's wasm3 which is a WASI interpreter and which is just a single 255 KB executable (not a typo).

All sizes looked up on an ARM Mac.

Is this (size) an issue in the real world?

It depends what real world is for you. In embedded or with low bandwith it might.

On desktop and server machines probably not. But more code also means a bigger attack surface.

Ok where to use it? Anybody using it? How it gives benefit over docker?

Not specific to wasmer, but WASI runtimes are much more lightweight than Docker, especially on Windows or macOS.

For instance on macOS, a wasmer installation is a single 45 MByte executable, the alternative wasmtime is 28 MBytes, and if performance doesn't matter much, the wasm3 WASI interpreter is a 255 KBytes(!) executable - compared to that, a macOS Docker installation is 1.5 GBytes (and that doesn't even include any docker images).

WASI itself can also be used in places where Docker doesn't make sense, for instance in this VSCode extension I'm using a C cmdline tool compiled to a 209 KB WASI blob:

https://github.com/floooh/vscode-kcide

Is Wasmer still openly adversarial wrt the Bytecode Alliance?

can you link more infos on the drama pls

Most prolific example was this: https://news.ycombinator.com/item?id=30758651

Not a big one, but this was of personal note: https://github.com/bytecodealliance/wit-bindgen/issues/306

Sorry to be that guy but what's the business model for all these web assembly runtime companies?

This one runs their own serverless platform that you can deploy your WASM apps to, but their pricing is... vague.

I think it's same docker Inc. all over. A great open source tool but no viable business model.

God, please stop using random AI-generated images in a release post..

What is the issue with AI-generated images? Just being overdone in general? Or ethical concerns?

Makes your article looks cheap like a random blogspam. My personal opinion, obviously.

What's the difference between this and a generic photo from one of the dozens stock photo catalogs? Is this somehow "cheaper" because it's "AI" generated? Using stock photos is also cheap (free or cents per)...

Second, does anyone really care? Has anyone spent more than half a second looking at a generic picture on an unrelated article? Does the generic hoodie hacker look good on security articles? Or the earth with pretty links on a networking article? Or the overdone handshake on a deal article? They feel equally as cheap and more importantly equally unimportant. It's a placeholder that noone should really care about.

Third, what's the value of having human beings spend time on an image that's just there to fill space? I kinda get the argument for company identity and things that matter, but filler for an article? Nah, that's exactly where we shouldn't be spending human resources, IMO.

I think using a stock photo in this case is also bad but not as bad; because the photo itself usually looks fine.

I hate AI-generated photo more simply because they're not good enough (yet) to not look fake immediately; it even has somewhat uncanny valley effect. If one day they're as good as stock photos, then my opinion with them would be on par with that, too.

I care, hence the comment. Can't speak for others.

> where we shouldn't be spending human resources

I agree; which is why in general I don't see the need to include irrelevant pictures at all for a software release post.

It looks soulless, even more than a the generic "hacker man" picture, at least you could tell these were made by a human. For me its one of the lowest "effort" you could put in a picture. Of course thats entirely subjective but personally I hate it and it doesn't seems like im the only one here.

> What's the difference between this and a generic photo from one of the dozens stock photo catalogs?

You see an AI generated image next to a bullet point list and start to suspect all you are reading is AI generated nonsense.

It doesn't exactly help communicating professionalism if that is the intended goal.

Rather, it gives the idea that the author did a minimal effort post.

> What's the difference between this and a generic photo from one of the dozens stock photo catalogs?

None really, using a stock photo in a blog post is also a stupid idea. Just don't add any image if it isn't needed to get an important point across.

I personally find title images pretty helpful to remember a certain blog post, quickly identify it when I have several of the same blog open as tabs etc.

Of course it can be overdone, but it definitely does add utility for me at least sometimes.

Reply on news.ycombinator.com