[PedroBatista]

About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me.

I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical perspective.

For SO MUCH effort over a decade I feel it's more and more a nerd kingdom where it's full "of cool things" and much more work on creating and resolving problems that were solved years and decades ago and I still miss the point of all of this, I get the "big promise" but 10 years have passed and still nothing.

Also, I see a lot of Rust ( and I mean a lot ) attached to Wasm. Sorry but it's not going to happen, it just isn't. Rust is a systems programming language and Wasm has been pretty much another eternal tech demo. Real "mid" - as the gen-z says - use cases and products are needed and Rust is not going to cut it for a general product audience. This whole thing seems more like a "Run Rust in the browser" than a common runtime to run every language in the browser.

And since "running stuff on the browser" is kinda of old news, these new "wasm runtimes" ( which I get it and support ) in reality are basically a basic shitty proto-JVM.. again what's the point of all of this having spend 10 years?

The "devx" ( always a sucker for a new marketing term :) ) is HORRIBLE! Ever tried to compile a moderately complex ( and useful ) C program to wasm?

On a positive note, I wish success to Wasm/WASI because it's a cool idea and can open a lot of doors. If not for the actual reality and implementation of things, I'm optimistic about the general idea.

Sorry for my "ignorance" and if I hurt anyone's feelings.

[callahad]

You almost certainly use WebAssembly today in widely deployed / commercial products without realizing it.

Figma, Microsoft Flight Simulator, Disney+, Amazon Prime Video, Photoshop for Web, 1Password, and uBlock Origin all implement significant portions of their applications as WebAssembly modules.

Many of those examples are building their Wasm modules from Rust codebases.

From what I can see, Rust and Wasm have undeniably crossed the chasm into pragmatic, mainstream applications. The serverside Wasm ecosystem is still nascent, but that's what initiatives like WASI and the Component Model are designed to address. Yesterday's vote to launch WASI Preview 2 is a huge step towards building a stable, interoperable foundation for WebAssembly outside of web runtimes.

[galangalalgol]

Ruffle is a good example too. It brought most of the old flash content back to the web in a safe sandboxed way. To the point I could see people using the old adobe tools to make new content, if they haven't already.

[cornstalks]

One realistic use case I’m currently exploring is game scripting with Wasm. I don’t want to write Lua. And I don’t want modders to be compelled to use some specific scripting language.

If I use Wasm in my native game then it’s easy for modders and others to create their own scripts and mods that can then be compiled to machine code by the game and safely executed on others’ computers. They don’t have to trust the modder because Wasm’s sandboxed design protects against a lot of bad behaviors.

It’s not so much that Wasm is totally unique here. Rather, to me it has many of the features and attributes I’m looking for in one single package/technology.

[mc_woods]

There are compelling applications for WASM in the embedded space, here we run C / C++ applications and WASM supports this well. We can also run other languages compiled to WASM too.

On the server side this is less clear. Typically we don't write system level languages server side - we use other languages, like Ruby, Python, JavaScipt etc. These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient. The benefit to the cloud / infrastructure provider is often not-clear, not when it's possible to run these very same applications in existing infrastructure. On the server side the benefit to the application developer is also not clear. There are few providers who have infrastructure to support WASM applications directly. You'd really need to see the big 3 cloud providers look at supporting WASM directly, without hypervisors / vm / container technology under it, to realize any performance improvements and hence pass on some cost benefit to the developer ecosystem.

"running stuff in the browser"; isn't old news. There are a growing number of applications that are migrating toward web-based UI and for these WASM is really useful. WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world....

Rust-Focus; yes, you are correct the existing technology, with the exception of perhaps WAMR and CloudEdge runtimes are rust based. As WasmTime is the only standalone technology which currently supports preview2, and it's written in rust, then the associated examples and tooling are naturally rust focused.

[phickey]

> WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world

The jco project (https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon.

> These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient.

The Bytecode Alliance has made big improvements to SpiderMonkey performance on WASM/WASI systems, and has work in progress to take advantage of SpiderMonkey's "native" codegen targeting WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/. We targeted JS first for this work because it is the most popular language with our customers and users, but we expect that this will show the path to adding similar improvements to Ruby, Python, and other languages commonly thought of as "interpreted".

[meheleventyone]

For WASM in the browser I'd gesture at Figma for a economically viable product.

From my own perspective, which is browser based games, WASM opens up a lot of options. From using battle tested physics engines that are written in systems languages to the ability to access SIMD primitives. One of the underrated capabilities from that perspective to me is that floating point math is deterministic across browsers and platforms which is a bit of a holy grail for multiplayer games programming. Beyond that it promises to get faster and more efficient over time which is a good thing for performance heavy web apps.

Outside the browser MS Flight Sim uses WASM for the UI in part. WASI I know less about but doesn't seem totally crazy and in comparison to things like the JVM has a broader set of languages that can use it.

[apitman]

> One of the underrated capabilities from that perspective to me is that floating point math is deterministic across browsers and platforms which is a bit of a holy grail for multiplayer games programming

This is interesting and relevant to me. Do you have any suggested links where I can read more about this aspect of wasm?

[flohofwoe]

Might be part of the nerd kingdom for you, but I recently made pretty cool use of WASM+WASI in a VSCode extension:

https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html

Also quite a few 'CPU nerds' found my 'visual6502 remixes' useful so far:

https://floooh.github.io/visual6502remix/

https://floooh.github.io/visualz80remix/

Development experience with Emscripten and WASI SDK is fine really (in the sense that these are "just another gcc-style cross-compilation toolchain"), and with those it's not much different than bringing a C code base to any other platform. It depends a lot on how portable the code is in the first place of course.

[boomskats]

I read your post on WASM debugging with Emscripten and VSCode[0] just last week, thought it was amazing!

Not quite the same, but tangentially related since we're talking WASM+WASI and VSCode extensions - I have high hopes for the vscode-wasm[1] project. The VSCode extension host is a massive hog, and this seems like a big step in the right direction.

[0]: https://floooh.github.io/2023/11/11/emscripten-ide.html [0]: https://github.com/microsoft/vscode-wasm

[flohofwoe]

Yeah, this vscode-wasm thingie is exactly what I'm using to run a command line assembler tool in VSCode. Pretty neat, only downside currently is that it is only available as pre-release, which makes installing extension which depend on vscode-wasm awkward for the user.

[fwsgonzo]

I have had the same experience compiling for WASM. It's always a bunch of commenting out code that doesn't compile. Thankfully we have other things backend side. I'm guessing people writing Rust are having a better time with WASM.

As far as WASM going away: Sadly, I think browsers are just going to make up a larger and larger share of what computers do.

[elviejo]

I'm in the same boat. I've been looking at this space since (P)NaCL With a nagging question in my mind:

What does this do that we couldn't do with Java Applets? So far the response is very few things and a lot less. On the few things that it does differently is: + it focus on multi language support. as opposed to the JVM which was focused in getting all of us in writing Java. Here they want to actually use different languages to write webapps. - Although Rust is the favorite (As is C# in the .net) + It has a clear mechanism to communicate with Javascript and therefore the web. + timing bandwidth is now big enough to make this apps seem practical. + it is done by a coallition of vedors (as opposed to java that was only Sun's baby).

Very minor advantages in my opinion... but well I also think that lip's s-expressions are better than json, xml and yaml. and the world has thought differently every single time.

[marwis]

Security. Applets exposed massive API surface while wasm exposes almost nothing.

Also applets were too slow to start with Sun's implementation of the day while wasm works reasonably well in all browsers from day one. That matters a lot for adoption.

JVM improved but applets missed their chance. You only get one.

[mike_hearn]

WASM exposes nothing ... except the entire browser app surface.

WASI starts with nothing and then exposes a bit more. WASI2 exposes more than WASI1. Preview 3 will also add more. Eventually there will be sandbox escapes in WASM runtimes as well. There's nothing about WASM that makes sandbox escapes harder.

Bear in mind, applets exposed a large surface area, because you need that to write useful apps. Currently WASI looks useful for, maybe, some subset of CLI tools. Everything else is kicked to Chrome. It's not as ambitious.

[rockwotj]

I have compiled JQ to wasi (in terms of moderately complex ( and useful )).

Took me a couple of hours, mostly because of some pthread stuff I had to noop. And that's being fixed with wasi-threads

https://github.com/rockwotj/jq-wasi

[mc_woods]

unfortunately wasi-threads is deprecated. You'll need to wait for threading support from "core-wasm" and that's a while off, there is no date on the horizon for this, as far as I know.

WASI-threads is not compatible with WASI-Preview2

[rockwotj]

Thanks for the correction! It's hard to track all of this :)

[G4Vi]

On the devx, there's definitely some rough edges around building and using Wasm. My company has been working on a framework to ease integrating Wasm into existing applications. One area it focuses on is providing easy data passing between the host program and the Wasm and vice versa. https://github.com/extism/extism We do not have WASI preview 2 support yet, but are interested in integrating it.

[make3]

We've seen a lot of ppl write electron apps because they're portable. I see this as electron/jvm for code that already exists in non vm languages, so that in theory you don't need to do nearly as much rewriting, or any at all. that's pretty cool.

[PedroBatista]

Yes, that's the idea. In theory.. :)

[flohofwoe]

I recently made a command line assembler tool written in C in the early 90's run in a VSCode extension via WASI just by compiling with the WASI SDK, IMHO that's pretty cool:

https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html

(same with my home computer emulators, but those were written right from the start with the web as "just another platform" in mind: https://floooh.github.io/tiny8bit/)

[ramses0]

So..... think of it this way:

HTML was built for the "internet", but works just as well for plain local files (eg: file:///one.html => file:///two.html).

JS was added to HTML, and much gnashing of teeth ensued.

JS (minified), HTML (generated), CSS (compiled), Flash, Java Applets, etc... move away from the "original" internet (Hyper-Text DOCUMENTS) into Web2.0 "Apps" and Web3.0 "Walled Gardens".

What if instead of shipping `my_application.html`, we could ship `my_application.exe`, and "break free" of needing the UI's being written in HTML, JS, CSS, etc.

What some of this WASM/WASI/etc... seems to be trending towards is building up enough of a foundation amongst interoperable _CLIENTS_ that have ZERO dependency on HTML, JS, CSS, and instead you get much closer to:

    curl 'https://example.com/one.html'
       => curl 'wasm://example.com/one.app'

...to the extent that "the internet" has hit a complexity wall of what's possible (manageable, maintainable) with HTML+JS+CSS, the people tackling WASM seem to be saying:

Forget trying to coerce a buggy browser into running my `for ...` loops (and rendering my graphics) correctly, and you can't realistically decompile or hand-edit the HTML+JS+CSS for 99.9% of the stuff your browser is rendering... how can we _skip_ the HTML,JS,CSS and get directly at "the VM" and run what we actually want.

Secondarily (but importantly, and interestingly): How can we make 'webapp.wasm.exe' support everything that a "native" app would need (eg: GL, GPU, Bluetooth, Local Files, USB devices, Camera, Sensors, etc...)

There's likely mega-trillions (no exaggeration!) of effort that's been poured into tooling for "the internet", what is the unifying effort/effect that would unlock that for local app development? How can I get `msword.exe` to run "on the internet" for free? How can I get `make clean ; make install ; make wasm` working for any internet connected client?

As a thought experiment, we're almost there! We could technically have `win95.img + bochs86vm.wasm + autorun.inf + msword.exe` wrapped in a "browser evaluator" that could conceivably run `msword.exe` transparently to the user, but still allow you to use `msword.exe` indistinguishably from the "original" native app (bridging the local filesystem, exposing virtual devices, etc).

See also https://www.destroyallsoftware.com/talks/the-birth-and-death... ... circa a decade(!) ago!

[dns_snek]

> As a thought experiment, we're almost there! We could technically have `win95.img + bochs86vm.wasm + autorun.inf + msword.exe` wrapped in a "browser evaluator"

I looked into this and... holy crap! We are there. Not for modern programs quite yet, sure, but this is amazing. You can use Windows 2000 from your browser, running inside an x86 emulator for WASM.

https://copy.sh/v86/?profile=windows2000

[ramses0]

Yup! ...and noodling around with their `wordpad.exe`, you could pretty easily imagine `My Network => My Workgroup => ...etc...` to samba-share in your local filesystem (provided by the bochs86vm "container") ....... or since it's turtles all the way down, just map your local computer drive as `D:\...` and let the VM "think" it has access to all your files on the vm-local disk.

[crq-yml]

As it is, I already run a Debian VM locally to seal off the "development" stuff from my primary desktop.

Is is kinda heavy? Yeah. The hard disk footprint is substantial. But it works fine for writing some Python, compiling a few dependencies and bringing up a browser to test stuff. Even on a six-year-old laptop, it runs OK.

If the client application needs 1990's capabilities, "chuck it in a VM" will work today, and it will only be limited by protocol support, I/O access, and OS integration. There are substantial accessibility problems presented by VMs - seemingly basic things like clipboard support are disagreeable and require a "smart emulator" inserting itself to provide that feature.

Perhaps the right direction to take is to develop MAME to contain every accessibility feature. It already emulates all the old hardware.