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.
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).
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.
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).
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
or
sudo -E env -- -v
(sudo stops parsing its own flags after 'env', the positional argument).
> 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 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.
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?
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 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.
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.
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.
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.
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)?
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.
>> 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?
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?
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 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.
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