Wasmer JavaScript SDK | Hacker News Reader

Wasmer JavaScript SDK

wasmer.io

163 pointsthe_duke41 comments

I use @wasmer/wasi for my npm package `trealla` (wasm port of a Prolog interpreter). For the most part I'm pretty happy with it, but the file size is quite large[1] (taking up around half my bundle size), and it looks like @wasmer/sdk is even larger (wasmer.sh downloads a 1.7MB gzipped wasm binary that I assume is the runtime). It's a tough sell to the frontend folks when my package is this big... currently I have my eye on jco[2] which I hope will be much lighter.

No shade intended towards the Wasmer folks, I appreciate the work they've done.

[1]: https://bundlephobia.com/package/@wasmer/wasi@1.2.2

[2]: https://github.com/bytecodealliance/jco

Thanks, I'm a big fan of your work in Trealla. Is true that there's still room to improve sizes, as right now the bundle size is not ideal.

Hopefully it will not take long for Wasmer to serve packages with a minimum bundle size, stay tuned for updates!

Thank you as well! I am looking forward to it, will keep an eye out & would be happy to test. I know it's difficult to keep the packages small, I struggle with it for sure (e.g. currently I use Wizer to optimize my startup times, but that also takes a significant chunk of the bundle).

Can anyone get the actual JavaScript example posted to work with Node or any JS runtime for that matter?

I tried it with Bun and I feel weird showing examples that don't seem to run.

> $ npm install @wasmer/sdk

```js import { Wasmer } from "@wasmer/sdk";

let cowsay = Wasmer.fromRegistry("cowsay"); let instance = await cowsay.entrypoint.run({ args: "\"Hello world\"" }); let output = await instance.wait(); ```

I also tried to use the <script> approach and I cannot get it working on a local dev server due to CORS.

Note: I tried it with both Bun and Node, neither worked.

Doing some more due diligence: https://docs.wasmer.io/javascript-sdk <-- this is the one source of truth on the docs.

Seems like they still have to update their stuff a fair few places...

Now I'm just struggling to use the package registry, none of the copy and paste examples have worked for me, but I'm sure I can figure it out. Will post here if I do.

Finally got this working. I was unable to get this to play well with Node or Bun but I did get the <script> approach working.

For the CORS with Vite you can just set a config like so in vite.config.ts

import { defineConfig } from "vite";

export default defineConfig({ server: { headers: { "Cross-Origin-Embedder-Policy": "require-corp", "Cross-Origin-Opener-Policy": "same-origin", }, }, });

I was then able to just use this code example with one caveat (https://github.com/wasmerio/wasmer-js?tab=readme-ov-file#use...)

I had to update the SDK import with crossorigin="anonymous"

One interesting thing their examples seem to offer is a pre-configured Vite/Rust toolchain. This is something still lacking in official Rust/WASM examples and something I had to put quite some trial and error into to get working (with auto-reloading and such).

> wasmer run wasmer/ffmpeg -- -i - -f wav - > audio.wav

rather off-topic, but i've noticed quite a few "modern" cli apps do the "--" thing and make it mandatory; am i alone in finding it weird that flag parsing does not automatically stop after the positional argument for a program that expects to accept a command line?

e.g. it's

  sudo -E env -v

not

  sudo -E -- env -v

  sudo -E env -- -v

(sudo stops parsing its own flags after 'env', the positional argument).

I believe this originates from GNU argument syntax and is commonly implemented by software supporting GNU-style long options. Terminating after the first argument IIRC is what software implementing BSD style argument parsing usually does. OTOH though, I am sure there is software that implements hybrids of both approaches. I don't think any approach is particularly "weird" really, both of them make perfect sense in isolation.

edit: relevant GNU docs https://www.gnu.org/software/libc/manual/html_node/Argument-...

Maybe more apps should do like git and make `--end-of-options` the official long form of `--`

https://git-scm.com/docs/gitcli

AFAIK it's all about trying to be POSIX-but-not-quite. Via the POSIX spec https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... :

> The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.

> All options should precede operands on the command line.

> If an argument can be identified according to Guidelines 3 through 10 as an option, or as a group of options without option-arguments behind one '-' delimiter, then it should be treated as such.

I think that the rule "all options should precede operands" has been broken so much in practice (particularly since any subcommand must break it) that it may as well not be a rule. And if it's not a rule, then the only way to unambiguously distinguish options from operands-that-start-with-a-dash-but-should-be-passed-verbatim-as-operands... is to require a double-dash.

If they accept only one positional argument, and do not allow flags after it, yeah that definitely seems weird.

Many of these are flag-position-agnostic though, and for that the -- is a very long-time standard pattern for either "end of this command, forward the rest to the wrapped command" or a list of files (to make a file named --help unambiguous).

Many. Definitely not all. CLI interfaces are even more varied than GUIs in many ways.

I've yet to dip my toes into Wasm. This might push me to finally get going. Based on a quick search, Wasmer and Wasmtime appear to be the two most popular runtimes with the latter being backed by some big names (via the Bytecode Alliance). Wasmer seems to push new features first. Can someone share what their experience was like with either or why they chose one over the other?

wasmtime is closely aligned with where active development is happening in WebAssembly, WASI, and similar standards. You can expect that as the folks working on WebAssembly itself establish support for (for instance) async, or GC, or components and linking, or other new APIs, wasmtime is where those are going to show up first and be aligned with the rest of the industry. It's easy to embed and reasonably easy to expose your own APIs through, so that you can use it for plugins.

The community is also friendly and inviting for folks trying to get started.

In my experience Wasmer is generally disliked by the rest of the WASM community. There’s a long list of reasons for this, including attempting to copyright the term WASM and pushing their own proprietary specs and calling them “standards” while not implementing existing standards.

Their main benefit, from what I can tell, is their “retargetable” compiler architecture, but Wasmtime is improving here as well. Wasmtime is also generally faster at implementing standards.

I wish to live the day where we can incentivize one ecosystem without having to trash another.

This is not a zero-sum game.

If you find Wasmer useful, use it! If you don’t and you prefer others, feel free to use them. There are plenty of choices.

Happy holidays!

I would say that this landing page on your company’s website is unnecessarily trashing wasmtime in the headline

https://wasmer.io/wasmer-vs-wasmtime

Preaching water, drinking wine.

Classic.

No intend of trashing (in marketing pages titles tend to be more flashy).

In any case I just updated it. Happy holidays!

Is it just me or is it weird to show a faster startup speed as a bigger bar?

I thought it was slower until I saw the 1000x. Even 1000x seems kinda meaningless.

None of those are actual answers to the criticism posted by the parent, so it's hard to really care even if it's wrapped around a loving tone.

Happy holidays to you as well!

Thanks!

I sometimes assume people have the same context as I do, and your comment made me realize that it was not the case. Here's some context: https://wasmer.io/posts/wasmer-and-trademarks

Regarding standards, I assume the mention is referring to Wasmer push for WASIX [1]. Which is a specification & implementation that welcomes anyone to participate (even on it's governance model), so I don't think the stance of the previous comment is accurate.

[1] https://wasix.org/

I'm using it for my latest project - writing a cashflow calculator and graphing tool. Really cool to be able to write all the business and graphing logic in Go, then share it with the front end via WASM, so I don't need to implement the same logic in both Go and JS separately.

Things I learned: TinyGo works to get the package size down. Translating values between JS and Go is straightforward (with a lot of boilerplate), but trying to do the JSON dance wasn't worth it - too brittle. Creating SVG in Go and then using it as the innerHTML for a div actually works really well :)

Edit: to be clear, I'm using Go's WASM implementation, not Wasmer

I'm very excited by this, especially the idea of a bash shell with wasmer.sh because so much code depends on a shell to work, and it's the core thing needed to be productive. I couldn't get Python to run in the wasmer.sh shell though with the included wasmer in wasmer command (great inception potential). If it had some kind of compiler or make, that could be really promising. The Linux JS projects aim at emulating specific CPU architectures in the browser, which is probably not that different, but with WASM at least you know it's meant to be portable from the start.

Can anyone confirm if this can do proper TCP sockets? Not Websockets, but bonafide actual sockets?

That will open up a lot of use cases (at least for me)

It seems to say it can run any wasix, so yes? But GitHub page says no networking, so no?

In the browser not yet, but support for TCP is on the roadmap! Feel free to email me at syrus@wasmer.io so I can keep you in the loop for the first trials :)

How could you add this if the browsers don't support it outright? Unless you mean faking it over web sockets to allow compiled applications to just think they're using TCP (in which case you still need a relay server)?

One way to approach this would be to interpose all calls to the TCP interfaces (pretty straightforward with Wasm Components), and tunnel it using Websockets (or whatever) to a server that can make the actual TCP connections on your behalf. So the application running in Wasm doesn't know any different, at least.

I guess that's not quite what you wanted, but browsers don't allow making arbitrary direct TCP connections, so in general I don't think there _is_ a way to do what you wanted.

Use cases like what?

Applications that need to make direct TCP/UDP connections to things, but which you want to run in the browser and don't want to rely on a centralised websockets proxy or other hacks.

Endless use-cases for this. Servers, games, collaboration tools, clients for non-HTTP protocols (email, gopher, Gemini etc), file sharing. You name it.

Similar to ffmpeg, I wonder if I can have the user’s browser run a puppeteer instance in Wasmer?

E.g get it to generate a PDF for the user to “download”

That would be awesome! Although there are still a few edges to resolve to be able to run a full headless browser with Wasmer.

It should be possible though, see: http://trevorlinton.github.io/

>> we were able to allow UNIX-like threading to run via JS Workers by reusing the shared memory from the main WebAssembly process and notifying the memory upon changes (using Wasm notify/wait syntax).

This left me scratching my head. How are JS workers sharing memory with the WASM process?

JS has an API called "SharedArrayBuffer" that allows sharing memory between processes or threads (with the aid of the host)

I wonder how much of a perf hit a normal multithreaded Unix application would take because of this model. Are there any data points around the multi-threading perf here?

I believe JS workers are actually implemented as threads, so the performance overhead might not be as bad as you'd expect.

Usually it adds an extra 10-25% of overhead when the WASIX program uses systemcalls that require unwind/rewind functionality (this is for fork and subprocesses mainly, the multithreaded ones doesn't require asyncify and as such should not experience a performance hit)

It is so cool that people do things like this. For me it is often the exploration that I appreciate as much as what the exploration finds. Don't know if and when I can use this.

My boss once told me he wanted the next release to be "cool". I had no idea what that meant so I thought about it and decided:

"Things are cool when they change how you see the world. When you will never quite see the world the same way again."

Starry Night is cool. Raising metal is cool. Threejs is cool. Webrtc is cool. WASM & wasmer are also cool.

I'm getting lost in all this.

So webassembly is a VM for the browser.

You can compile non-browsery things, like ffmpeg, into webassembly to run on the browser. You usually use emscripten compiler to do that.

Wasmer is a way to run webassembly outside the browser, making portable apps.

Now, wasmer is shipping an SDK for browsers... to bring webassembly back to the browsers?

So it's an emscripten alternative, right?

I haven't touched wasmer specifically, but as a wasm noob who's been playing with dart2wasm/emscripten recently, I'll try and explain as best I can. The ecosystem is a bit messy, so it can be difficult to wrap your head around. If I've got anything wrong, someone please jump in and correct.

wasm is just a bytecode assembly format - you can compile something like "int a = 1; int b = 2; return a+b", but to actually do anything interesting you usually need some kind of runtime environment where you can spawn threads, access a filesystem, print to stdout, etc etc. WASI, for example, is an interface for accessing system libraries via wasm; runtimes like wasmer/wasmtime (for native) or v8 (Chromium) will expose their own implementations of WASI. WASIX is wasmer's own extension for WASI (a point of some contention in the wasm community).

Running wasm in a browser, though, still requires some manual setup with Javascript, along with crossing your fingers that the browser runtime actually supports the system calls for whatever you've compiled.

I guess what wasmer has created here is a Javascript SDK so you can:

1) easily download wasm binaries from a central registry

2) ensure those binaries actually run as intended in a browser environment

3) avoid the manual setup Javascript code currently needed to run wasm modules.

emscripten is a (non-WASI) runtime + compiler so this isn't an exact alternative to emscripten (I guess in theory you could compile something via emscripten, publish to the wasmer registry, then consume solely in Javascript). It does, however, replace the manual JS wiring you need to do to run emscripten-compiled binaries in the browser.

Reply on news.ycombinator.com