Making WebAssembly a first-class language on the Web • Hacker News Board

Re: Making WebAssembly a first-class language on the Web

#151

Post by esprehn » Thu, Mar 12, 2026, 1:54 AM UTC

The web doesn't work without dynamic feature detection. I couldn't find anything in the component model about how this is expected to work.

The DOM is not a static interface, it changes both across browsers based on implemention status and also based on features enabled on a per page load basis.

The multi browser ecosystem also mainly works because of polyfills.

It's not clear how to polyfill random methods on a WIT interface or how to detect at runtime which methods exist.

OTOH the JS bridge layer we use today means you can load JS side polyfills and get wasm that's portable across browsers with no modifications. There's more to the ecosystem than just performance.

Re: Making WebAssembly a first-class language on the Web

#152

Post by infamia » Thu, Mar 12, 2026, 2:07 AM UTC

pizlonator wrote: post #12

eqrion wrote: post #10

Earlier quoted context omitted.

I'm not sure I follow this. > WebAssembly is the wrong abstraction for running untrusted apps in a browser WebAssembly is a better fit for a platform running untrusted apps than JS. WebAssembly has a sandbox and was designed for untrusted code. It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.…

> WebAssembly has a sandbox and was designed for untrusted code. So does JavaScript. > It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code. They have that infrastructure because JS has access to the browser's API. If you tried to redesign all of the web APIs in a way that exposes them to WebAssemb…

> Then what's your excuse for why wasm, despite years of investment, is a dud on the web?

Depending on how you count, it took JS about 20 years and billions of dollars plowed into it to do the same, so why expect any less from wasm?

Re: Making WebAssembly a first-class language on the Web

#153

Post by skybrian » Thu, Mar 12, 2026, 2:20 AM UTC

phickey wrote: post #33

skybrian wrote: post #18

At a high level this sounds great. But looking into the details about how the component model will be implemented, it looks very complicated due to concurrency: https://github.com/WebAssembly/component-model/blob/main/des...

Real programs, whether native JavaScript or in any other language that targets Wasm, have concurrency. Would you rather the component model exclude all concurrent programs, and fail to interact with concurrent JavaScript? The component model is meeting the web and programmers where they're at. Unless you're one of the few people implementing the low level bindings between components and guest or host languages, you d…

I was looking there because the high-level documentation doesn't seem detailed enough to understand how it works. Maybe some intermediate-level explanations are needed?

Re: Making WebAssembly a first-class language on the Web

#154

Post by lich_king » Thu, Mar 12, 2026, 2:38 AM UTC

rishflab wrote: post #139

lich_king wrote: post #51

The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. And it turned out that this was insane: we endured 20 years of serious browser security bugs caused chiefly by JavaScript. I'm not saying it wasn't worth it, but it was also crazy. And now that we're getting close to have the right design princi…

> The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. Isnt this what an OS is supposed to do? Mobile operating systems have done a pretty good job of this compared to the desktop OS.

Mobile OSes don't allow random people to run code on your device. They allow you to install software you want and sort-of trust, which is conceptually close to the desktop model. There are some safeguards on top of that, but the primary line of defense is that cheap-pillz.virus-basket.ru can't actually execute anything on your device.

Re: Making WebAssembly a first-class language on the Web

#155

Post by dgudkov » Thu, Mar 12, 2026, 2:58 AM UTC

While WASM Components haven't arrived yet, what's the current best framework for JS/WASM glue?

Re: Making WebAssembly a first-class language on the Web

#156

Post by nineteen999 » Thu, Mar 12, 2026, 3:02 AM UTC

mananaysiempre wrote: post #49

eqrion wrote: post #15

Earlier quoted context omitted.

I worked on the original interface-types proposal a little bit before it became the component model. Two goals that were added were: 1. Support non-Web API's 2. Support limited cross language interop WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Component interfaces take more of an intersection approach that isn't as expressive, but is much more porta…

> Two goals that were added were: 1. Support non-Web API's. 2. Support limited cross language interop. I mean, surely it does not come to a surprise to anyone that either of these is a huge deal, let alone both. It seems clear that non-Web runtimes have had a huge influence on the development priorities of WebAssembly—not inherently a bad thing but in this case it came at the expense of the actual Web. > WebIDL is th…

Technology with "web" in the name, invented by Web fanboys, not really much good for working with key web API's like the DOM.

Cool parts of the webassembly technology aside - this should be no surprise to anybody. News at 11.

The non-sequitur in the title of this post should be enough to give everybody pause.

Waiting for someone to chime in and tell me that the "web" in "webassembly" wasn't meant to refer to the "world wide web". Go on. I dare you!

Re: Making WebAssembly a first-class language on the Web

#157

Post by azakai » Thu, Mar 12, 2026, 3:08 AM UTC

jitl wrote: post #149

azakai wrote: post #141

Earlier quoted context omitted.

> DOM performance is a big deal and bottleneck for a lot of applications What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production. > But we really shouldn't be requiring everyone to become an expert to benefit from wasm. If the toolchain does it for them, they don't need to be experts, no more than people need to be DWARF experts to debug na…

> What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production. any application you use today that is written in JavaScript rendering to the DOM, is much harder to write in not-JavaScript Slack, Teams, Outlook, Word, OpenAI, Anthropic, Github, Twitter, Instagram (web), Notion, Google Docs, ...

Sorry, I'll ask my question in a better way: what applications written in wasm that exist today would benefit from this?

Now, maybe there aren't many because of performance - maybe they haven't used wasm because it was too slow. But I would appreciate seeing data on that - an application that tried wasm and gave up after seeing the overhead, at the least. But I would also expect to see apps that use wasm even despite some DOM overhead, because of the speedup on non-DOM code - and I'd like to see data on how much DOM overhead they are currently suffering.

I am asking because I'm familiar with a lot of apps ported to wasm, and they don't do this. That may just be because I am seeing one particular slice of the ecosystem! So I am very curious to learn about other parts.

Re: Making WebAssembly a first-class language on the Web

#158

Post by GianFabien » Thu, Mar 12, 2026, 3:15 AM UTC

I don't use WASM as a replacement for JS. I never have a need to manipulate DOM, etc from WASM. JS is perfectly fine and performant for those purposes.

As I see it, WASM is used to augment the JS/WebAPI ecosystem. For example, when you need to do heavy bit manipulation, complex numerical processing. The round-trip JS->WASM->JS is an overhead. So the WASM modules should perform a substantial amount of processing to offset that inefficiency.

I frequently find that V8 optimisations yield sufficient performance without needing to delve into WASM.

IMHO if you want to write WebApps in Rust, you're holding it wrong.

Re: Making WebAssembly a first-class language on the Web

#159

Post by azakai » Thu, Mar 12, 2026, 3:18 AM UTC

pizlonator wrote: post #27

swiftcoder wrote: post #22

Earlier quoted context omitted.

> Then what's your excuse for why wasm, despite years of investment, is a dud on the web? It's not really a dud on the web. It sees a ton of use in bringing heavier experiences to the browser (i.e Figma, the Unity player, and so on). Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve.

Figma is one site. There are also a handful of other sites that use wasm. But most of the web does not use wasm. > Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve. I don't think they will succeed at solving the pain, for the reasons I have enumerated in this thread.

> Figma is one site. There are also a handful of other sites that use wasm. But most of the web does not use wasm.

Most of the web also doesn't use the Video element, but it isn't 'a dud' either.

Video and wasm are critical for a small subset of the web. That subset includes YouTube and Netflix for Video, and Figma and Photoshop and Unity games for wasm.

Re: Making WebAssembly a first-class language on the Web

#160

Post by Rohansi » Thu, Mar 12, 2026, 3:21 AM UTC

cogman10 wrote: post #126

pjmlp wrote: post #116

Earlier quoted context omitted.

WasmGC doesn't support interior pointers, and is quite primitive in available set of operations, this is quite relevant if you care about performance, as it would be a regression in many languages, hence why it has largely been ignored, other than the runtimes that were part of the announcement.

Oh interesting. In java land the fact that you effectively don't have pointers but rather everything is an object reference, this ends up not being an issue. I wonder if the WASM limitation is related to the fact that JavaScript has pretty similar semantics with no real concept of a "pointer". It means to get that interior pointer, you'd need to also introduce that concept into the GC of browsers which might be a bit…

Object references are pointers. WasmGC only supports pointers which point to the start of an object. However, some languages have features which require pointers that point inside of an object while still keeping that object alive.

Limiting WASM to what is capable in JavaScript is quite a silly thing to do. But at the same time there are vastly different GC requirements between runtimes so it's a challenging issue. Interior pointers is only one issue!