Hacker News Reader

Comment by EMM_386 | Hacker News Reader

I've been a developer for decades and I'm still getting highly confused by all of this WASM, Wasmer, WasmEdge, Wasmtime, etc.

There was another one on the front page today that allowed you to use WASM to program other programming languages ("Extism: make all software programmable").

Where are we headed with all of this?

I can see a future where WASM supports GC-languages, then you esentially have things like C# or Java desktop applications running "in the browser" via WASM? Doesn't that throw all of HTML, CSS, etc out the window?

Honest question, sorry if it's dumb. But all these WASM terms, releases, etc. have me completely lost. I'll stick to my day job.

View on HN

I might be wrong but I think you can conceptualize like this...

Wasm is essentially a target bytecode and runtime based on the well tread security model of javascript in the browser.

Browsers can run it, languages can compile to it, apps of any language can host a runtime that runs it. This leads to infinite permutations and nesting of concepts.

Because its web tech there's a dozen ways to do the same thing.

Yep. That's my take. The vision is that you write code in any language you like. You compile (transpile?) it down to efficient low-level JS (WASM), run in the browser as if you wrote JS code.

I have zero experience with it, but I think I get it and it's neat. I'm a little curious about what working with the DOM is like in C# > WASM or Rust > WASM. I pitty the foo who had to code that... and will we get non-breaking, more efficient native DOM manipulation at some point?

https://stackoverflow.com/questions/59708546/access-the-dom-...

WASM is not low level JS

There was a "predecessor" project (Asm.js) that would output low level JS, though.

https://stackoverflow.com/questions/31502563/what-is-the-dif...

Lots of great answers as to the "how" and "what" here, but here's a real short one for you to answer "why?": Capabilities Security model. It's absolutely ludicrous that all software doesn't run this way. One of those "so obvious, it sounds dumb" things, but that's what all this stuff is bringing imo. And I was an "I hate WASM and I'll never use it" person in the past.

I still think, somehow or another, capability-based microkernels are the future of computing. There have been many attempts, though the most serious one is probably Google's Fuchsia.

Maybe they'll gain some new life as a natural home for WASM.

Actually type 1 hypervisors running cloud workloads happen to the be most successful microkernels, but monolithic defenders still haven't got it.

Extism is great [1], and I have great admiration for what they are doing. We didn't know they were working on that, if that was the case perhaps we the need for WebAssembly Interfaces ("WAI") would have been minimized.

In any case, it seems that there will be multiple ways of generating bindings going on in the future. And you will probably need to pick the option will fit better your needs! (similarly as how you can use Protocol Buffers, Cap'N'Proto or Thrift).

[1]: https://extism.org/

> But all these WASM terms, releases, etc. have me completely lost.

I don't blame you, I work on this and even for me it's a bit hard to keep up. Hopefully things will improve and become more clear over time!

>Where are we headed with all of this?

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Eaglercraft is an early example of a java program compiled to WebAssembly to run in the browser. It's Minecraft 1.5.2

> Where are we headed with all of this?

To the future where Silicon Valley funded startups try to find angles to extract value from WASM. A lot of competing efforts with different business models.

Hopefully in the end we get good VC funded open source and can discard any too aggressive monetisation attempts.

Not dumb, I feel the same way. I need a good WASM primer: what are they all, how do you use them, what interfaces (or doesn't) with them, etc.

You can compile software to WASM using emscripten. When you see a video game that runs in a web browser it was probably done via emscripten and wasm. When you see old DOS games on archive.org those are done by compiling dosbox to the browser. Emscripten includes some shims for pretending you have a file system and a clock and all that stuff.

There are also GC'd languages ported to WASM, things like Pyodide, but they're pretty big and have some rough edges as they're not normally allowed to do things like make network calls.

WASM is just a virtual machine, sort of like the JVM, but that runs in the browser. It might help to think of WASM (Web-ASseMbly) as a new CPU architecture. It's a minimal CPU instruction set (a virtual instruction set) that can be relatively easily jitted or transpiled into machine code.

WASM by itself doesn't do anything, the specs for what kind of interfaces exist between the WASM sandbox and the host app are still sort of in the air. It's soft of like saying "what can I do with a RISC-V CPU". The answer is "not much until we make more infrastructure that supports it.

Right now you can port large C code bases over to run in a browser with emscripten so that's nice. Maybe you'll write a web component using WASM at some point.

Thank you for the explanation! Time to read up on emscripten.

> Right now you can port large C code bases over to run in a browser with emscripten so that's nice. Maybe you'll write a web component using WASM at some point.

But doesn't this have the potential for a massive, paradigm shift in how we look at the "web"?

Take just one example, a GC language like C# or Java being able to run under WASM (inside a web browser?).

It could bypass HTML, CSS, and JS entirely and just run as if it were a desktop application.

Doesn't this lead us down the rabbit hole back to Java applets, Flash plugins and other similar plugins, albeit more secure/sandboxed?

If every website is free to render a button using any programming language it wants, there is no longer any standardization, accessibility features, a layout engine, etc.

What is the point of a "web browser" at all, if all it does is host a WASM-based application?

I think that's the part where my brain starts to give up.

> It could bypass HTML, CSS, and JS entirely and just run as if it were a desktop application.

Not quite, because in order to display anything to the user, it still has to use HTML/CSS/JS

Or canvas elements.

My thought exactly, seeing how Flutter has an output for the web that renders to canvas, bypassing everything entirely.

Then what do we have?

A C# desktop application running under WASM inside a browser with a custom UI rendered to a <canvas> element?

Is that where this is going?

For now C# has Blazor that run .NET in the browser with WASM, that do the same thing that any JS frontend framework do.

https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

>Not quite, because in order to display anything to the user, it still has to use HTML/CSS/JS

Webassembly was designed to be usable outside of the browser, and multiple native runtimes already exist for it. It doesn't require the web stack, that just happens to be the most convenient way to use it at the moment.

Well yes, but it would probably be violating accessibility laws in the US if they did that, and if search engines can't read the text than that's probably going to be a problem.

>What is the point of a "web browser" at all, if all it does is host a WASM-based application?

It's to get around various walled gardens apparently.

I continue to be surprised that nobody has started marketing a browser (complete with accessibility features, internationalization, etc) that’s built in WASM.

I can imagine any number of media companies who would love to continue using their current web-dev pipeline but, by walling access to their servers off to this “trusted” WASM browser, could be reasonably assured that users aren’t using ad blockers, archive bots, etc. It’s the next logical extension of those ridiculous scripts that you used to see, popping up a “Access denied” message on a right-click because the website owner wanted to limit “view source”. The kind of numbskull who would do that would love a WASM-based browser.

could you also compare the Quake Engine's virtual machines to WebAssembly? Or are they incomparable concepts?

A more lightweight tool than emscripten is the WASI SDK (https://github.com/WebAssembly/wasi-sdk/releases). It doesn't generate JS or HTML but you can run its output on the command line with wasmtime or wasmer.

Kinda same, when I learn 8086 assembly it was easy, walk through registers, interrupt, byte|word allocation, draw bitmap on screen, etc. I was able to build a 2D game by hand within 2 weeks. Started with zero assembly knowledge.

Sorry for long whining, Webassembly should have materials for 1) a complete guide on how to write it by hand 2) have a toy language as a source to demonstrate how to map its ast to wasm instruction, it should cover at least 60-70% of wasm essential features.

Stop pointing to c++/rust/and tool chains. It's doesn't help understanding Webassembly itself.

My question is... why do we want to run everything on the web? (unless it's not about it, I wouldn't know)

For me, it's distribution and convenience. I don't have to apply for permission and certification on multiple app stores, no scary popups that my app is untrusted, no worry about dependencies or permission to install locally, just point people to a url on any device and run.

I do not have either of those issues on Linux though, apart from dependencies, unless it is in the form of AppImage (which it often is these days).

> I'm still getting highly confused by all of this WASM

You are not alone.

On my side of things, I've been looking for an approach to deliver non-trivial in-browser apps while protecting the codebase from theft. In the early days I thought WASM could be that. I don't know any more. JS is a non-starter. It is common knowledge that sites where you hire freelancers to write code often result in these freelancers simply stealing JS code from websites with similar code and charging money for it.

A few years ago I was helping a friend who wanted to launch a custom printing (t-shirts and other items) business. He hired someone on a freelancer site to make him a JS tool to add pictures to items, visualize them, etc. He hired three different people in order to have the ability to pick the better solution. In all three cases he got code lifted from existing commercial websites doing similar work. They didn't even bother to remove identifying information from the code. I can see thousands of less sophisticated users of these sites not realize they are being sold stolen code.

Anyhow, I thought WASM would allow one to make a serious investment in R&D and deliver reasonably protected highly-performant in-browser tools for various applications. I don't think that is the case, except, potentially, for the case where the end-user would access the tools behind a login and is "filtered" (B2B SaaS tools behind a login, etc.).

It doesn't quite throw css/js/html out of the window (yet) but it does remove the historic limitation that browsers have had of that being the only thing that worked in them. So, it gives people more choice and indeed the option to not bother at all with html+javascript+css.

That stack has always been a bit limiting and dated as technologies. There's a reason why people feel the need to do native apps on mobile: it's a competitive space and those limitations are simply not acceptable there.

Browser based applications have gotten away with being merely good enough (some would argue barely good enough) for the last 20 years mainly because the tradeoff of them working in any browser was worth some sacrifices with respect to UX, design, performance, etc. Now we are getting some more options.

What would the point of the browser be, then?

It's specifically meant to render HTML, JS, CSS layouts. If it's just a shell hosting a WASM application, you may as well get rid of the browser altogether.

This is where I get confused. It's sort of like what Electron has done to make "web applications" into desktop applications, but here we are talking about true desktop applications, not HTML pages inside an OS shell.

I can't see where this all headed, I'm sure it will become clearer over the coming years.

Just think of WASM as a cross-platform instruction set, similar to .NET or JVM bytecode, but with a few internal design differences, and suddenly everything makes a lot more sense.

Most importantly: "WebAssembly" isn't tied to the web, nor has it anything to do with assembly.

> Where are we headed with all of this?

We are heading nowhere.

Hot take: WASM is a dead technology and has failed to displace vanilla JS. There are only a few very niche use cases, most of which have zero product-market fit (e.g., no one wants to play video games in a browser).

Furthermore, no one wants to seriously write C++/Rust/Java and then compile it to WASM. These days, WASM projects are a neat way to pad your resume or get tech "thought leaders" to tweet about you. As far as Extism goes, it sounds like a problem looking for a solution. We already have LUA and JS as embeddable scripting languages, so here we go overengineering yet again.

App developers wanted it to work. And if apple had allowed it to work in safari like it does on android, it might have made progress.

Erm, WASM works just fine on iOS Safari since a very long time now? I can't remember when I dropped the asm.js fallback for my WASM stuff, maybe around 2017/18? And unlike Chrome, the switch from asm.js to WASM actually made a massive performance difference on Safari, because the Safari team never bothered to add special support for asm.js.

Yeah, I meant on android you can use it to make a webapp that goes full screen, can be granted position info etc. by the user, and push notifications. A PWA in other words. Apple doesn't want PWAs, as they circumvent control of the appstore.

> And if apple had allowed it to work in safari like it does on android, it might have made progress.

WASM has been on Safari since version 11 released 5 years ago. Same year it became available on Chrome and Firefox.

"PWAs" are a dozen different standards. And everyone selects a different subset of them to call "the one true PWA".

Apple has supported the absolute vast majority of them since forever. And they have literally nothing to do with doing anything in WASM.

WASM is involved because webapps would be a primary usecase for it. A way to deploy your webapp with more performance and less effort at obfuscation. If webapps aren't first class citizens, the effort to port buts of your native and webapp together to make a WASM based PWA has a lower ROI.

A quick search show plenty of articles talking about the limitations of webapps on iOS. Here is one, it is a year old, but then most WASM project repos I look at haven't had a commit in that long...

https://hub.tigrenpwa.com/pwa-on-ios/

I'm not attacking anyone's choices. I don't particularly love the idea of all these blackbox WebApps and the more stuff we let theough the sandbox the bigger the attack surface. Once again Apple's motive to retain complete control aligns with the motive to keep devices secure. I don't like native apps either for the most part, black boxes with even more attack surface. If webapps with less attack surface displace native apps with more, I mostly call that a win.

I write embedded numeric heavy code in c++/cuda and rust, so it is at best peripheral to my day job, meaning I don't have the expertise or motivation to have a strong opinion. I'm engaging in the conversation primarily to learn.

> A quick search show plenty of articles talking about the limitations of webapps on iOS.

Again: "PWAs" are a dozen different standards (or perhaps more). And everyone selects a different subset of them to call "the one true PWA".

For example, some may say that "omg I need direct access to Bluetooth or other hardware APIs". Well, those are Chrome-only non-standards that neither Firefox nor Safari will implement.

There are some like push notifications which are debatable (but arriving in Safari this year). And then there's background sync that Chrome enabled by default in 2016, and which still had issues in 2019 that both Firefox and Safari objected to: https://github.com/mozilla/standards-positions/issues/214 No idea what their position on it is now.

And so on and so forth.

But these articles and half of HN will scream until they are blue in the face claiming that "it's Safari that's holding the PWAs back". Where reality is more complex and the narrative is mostly driven by Chrome, unfortunately.

Thanks for the insight! That makes sense, Chrome trying to grab control from native apps feeds Google's ad machine.

yeah I don't understand the hype. Every release of wasmwhatever seems to make the front page here. But the number of real products using the technology seems miniscule. It's been out for many years, if it was going to change the world it seems like it should be making more progress.

Have some hope on Component Model (this is kinda module system for the whole WASI thing). It wasn't growing because .. bespoke ABI for different langs and bespoke interfaces between host<->guest. Lack of guide too, it's mostly specification which is hard to read.

Yeah, they keep repacking ideas of bytecode formats that exist for decades, as if it was something novel.

Nowadays the whole hype about WASM containers is basically reselling what Java and .NET application servers have been doing for 20 years.

You are wrong and missing the point. I mostly agree with you and had the same opinion. BUT, the “money” is in the runtime and the real isolation of code and capability based access.

Forget about the browser, games, etc ( at least for now) and think about the server, dock and kubernetes.

If developers adopt a plug-in model of programming it will be a game changer. I don’t have a crystal ball but that’s what’s fueling wasm right now and it has merits

> Doesn't that throw all of HTML, CSS, etc out the window?

It doesn't. Because those things are already in the browser. With WASM you'll need to download the entire runtime for your app before you're able to run anything.

And you still need to go through the browser to display anything

> And you still need to go through the browser to display anything

No, you don't, and even if that was the case you can just throw a <canvas> tag on a page and render whatever custom UI you want to that, sort of like one of Flutter's web output options is.

This scraps decades of work in HTML, JS, CSS, engines like V8 and SpiderMonkey, etc.

You may as well just toss the browser out the window and consider it a "program" you are running from the internet.

> No, you don't, and even if that was the case you can just throw a <canvas> tag on a page and render whatever custom UI you want to that

Ah, yes. Canvas. Tell me, what is the API for canvas exposed to WASM (hint: there isn't one, you go through the Javascript API)

> This scraps decades of work in HTML, JS, CSS, engines like V8 and SpiderMonkey, etc.

And instead it forces you to do the same decades of wrok because you have to re-invent the whole rendering part from scratch (including the funny little case of accessibility). Canvas couldn't even render text properly until relatively recently.

> You may as well just toss the browser out the window and consider it a "program" you are running from the internet.

Well, of course you can't. Because there are literally no APIs exposed to WASM except a Javascript bridge.

In addition to my other comment, there's also this, for example https://news.ycombinator.com/item?id=33861831

Same. Currently learning Rust because that's the one part that seems to consistently fit well into all these WASM plans.

Presumably once I've made progress on rust the rest will have settled down into something more cohesive

I think one reason many people are really interested in WASM is because it creates the possibility of a secure runtime environment that can be used outside browsers too.

Reply on news.ycombinator.com