Art 12 ↔ Art 19 — Privacy autonomy (Article 12) conflicts with information access and readership tracking (Article 19); content shares knowledge freely but tracking collects behavior data without consent, subordinating privacy to engagement analytics.

Art 12 ↔ Art 26 — User privacy (Article 12) versus educational access (Article 26); unconditional tracking enables content delivery but reduces user control over personal data collected during learning participation.

swiftcoder 2026-03-11 16:26 UTC link

Nice to see momentum here. Even outside of direct access to WebAPIs, having the ability to specify interfaces for WASM modules is a big deal, and unlocks all sort of cool options, like sandboxed WASM plugins for native apps...

flohofwoe 2026-03-11 16:32 UTC link

It's still not a great idea IMHO ;)

(there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837)

E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM.

E.g. if I mainly work with web APIs like WebGL2, WebGPU or WebAudio I seriously doubt that the component model approach will cause a 2x speedup, the time spent in the JS shim is already negligible compared to the time spent inside the API implementations, and I don't see how the component model can help with the actually serious problems (like WebGPU mapping GPU buffers into separate ArrayBuffer objects which need to be copied in and out of the WASM heap).

It would be nice to see some benchmarks for WebGL2 and WebGPU with tens-of-thousands of draw calls, I seriously doubt there will be any significant speedup.

mananaysiempre 2026-03-11 16:40 UTC link

This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time.)

Better late than never I guess.

[1] https://github.com/WebAssembly/interface-types/commit/f8ba0d...

[2] https://wingolog.org/archives/2023/10/19/requiem-for-a-strin...

[3] https://queue.acm.org/detail.cfm?id=3746174

steve_adams_86 2026-03-11 16:43 UTC link

The WASM cliff is very real. Every time I go to use it, because of the complexity of the tool chain and process of going from zero to anything at all, I feel like I'm already paying a cognitive tax. I worry that I should update my tooling, look into the latest and greatest, understand the tooling better, etc... It would be incredible to see that improved.

The difference in perf without glue is crazy. But not surprising at all. This is one of the things I almost always warn people about, because it's such a glaring foot gun when trying to do cool stuff with WASM.

The thing with components that might be addressed (maybe I missed it) is how we'd avoid introducing new complexity with them. Looking through the various examples of implementing them with different languages, I get a little spooked by how messy I can see this becoming. Given that these are early days and there's no clearly defined standard, I guess it's fair that things aren't tightened up yet.

The go example (https://component-model.bytecodealliance.org/language-suppor...) is kind of insane once you generate the files. For the consumer the experience should be better, but as a component developer, I'd hope the tooling and outputs were eventually far easier to reason about. And this is a happy path, without any kind of DOM glue or interaction with Web APIs. How complex will that get?

I suppose I could sum up the concern as shifting complexity rather than eliminating it.

skybrian 2026-03-11 16:58 UTC link

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...

thefounder 2026-03-11 17:04 UTC link

This is the right direction. Another important bit I think it’s the GC integration. Many languages such Go, C# don’t do well on wasm due the GC. They have to ship a GC as well due the lack of various GC features(I.e interior pointers)

koolala 2026-03-11 17:08 UTC link

Every new standard today doesn't care about being clean and simple to use. They all maximize the JS boilerplate needed to make a basic example work. Everything is designed today for 'engineers' and not 'authors' without any friendly default workflow. I'm glad they still care about this.

lich_king 2026-03-11 18:09 UTC link

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 principles and mitigations in place and 0-days in JS engines are getting expensive and rare... we're set on ripping it all out and replacing it with a new and even riskier execution paradigm.

I'm not mad, it's kind of beautiful.

exabrial 2026-03-11 18:24 UTC link

I'd really like to be able to run _any_ language in the browser. WASM is a great first step.

koenschipper 2026-03-11 18:44 UTC link

This article perfectly captures the frustration of the "WebAssembly wall." Writing and maintaining the JS glue code—or relying on opaque generation tools—feels like a massive step backward when you just want to ship a performant module.

The 45% overhead reduction in the Dodrio experiment by skipping the JS glue is massive. But I'm curious about the memory management implications of the WebAssembly Component Model when interacting directly with Web APIs like the DOM.

If a Wasm Component bypasses JS entirely to manipulate the DOM, how does the garbage collection boundary work? Does the Component Model rely on the recently added Wasm GC proposal to keep DOM references alive, or does it still implicitly trigger the JS engine's garbage collector under the hood?

Really excited to see this standardize so we can finally treat Wasm as a true first-class citizen.

shevy-java 2026-03-11 18:50 UTC link

> Yet, it still feels like something is missing that’s holding WebAssembly back from wider adoption on the Web.

> There are multiple reasons for this, but the core issue is that WebAssembly is a second-class language on the web

It would be nice if WebAssembly would really succeed, but I have to be honest: I gave up thinking that it ever will. Too many things are unsolved here. HTML, CSS and JavaScript were a success story. WebAssembly is not; it is a niche thing and getting out of that niche is now super-hard.

ventuss_ovo 2026-03-11 19:31 UTC link

The phrase "first-class" matters here because most developers do not reject a platform over peak performance, they reject it over friction. If the happy path still requires language-specific glue, generated shims, and a mental model of two runtimes, then WebAssembly remains something you reach for only when the pain is already extreme.

What would really change perception is not just better benchmarks, but making the boring path easy: compile with the normal toolchain, import a Web API naturally, and not have to become a part-time binding engineer to build an ordinary web app.

ilaksh 2026-03-11 19:34 UTC link

I love WebAssembly components and that's great progress. But I feel like everyone is missing a golden opportunity here to take apart the giant OS-sized web API and break some of it out into smaller standard or subscribable subsets that also don't try to mix information presentation and applications in a forced way.

Example subsets:

- (mainly textual) information sharing

- media sharing

- application sharing with, small standard interface like WASI 2 or better yet including some graphics

- complex application sharing with networking

Smaller subsets of the giant web API would make for a better security situation and most importantly make it feasible for small groups to build out "browser" alternatives for information sharing, media or application sharing.

This is likely to not be pursued though because the extreme size of the web API (and CSS etc.) is one of the main things that protects browser monopolies.

Even further, create a standard webassembly registry and maybe allow people to easily combine components without necessarily implementing full subsets.

Do webassembly components track all of their dependencies? Will they assume some giant monolithic API like the DOM will be available?

What you're doing is essentially creating a distributed operating system definition (which is what the web essentially is). It can be designed in such a way that people can create clients for it without implementing massive APIs themselves.

hardwaresofton 2026-03-11 22:49 UTC link

If you’d like to get acquainted with modern WebAssembly, check out the component model book:

https://component-model.bytecodealliance.org/

It includes high level concepts, practical code samples and more that introduce the really powerful parts of WebAssembly.

With regards to the JS ecosystem specifically there are 3 projects to know:

https://github.com/bytecodealliance/StarlingMonkey

https://github.com/bytecodealliance/ComponentizeJS

https://github.com/bytecodealliance/jco

The most mature tool chain right now is Rust, but there is good support for most things with LLVM underneath (C/C++ via clang). Golang, python and support for other languages is getting better and better (tinygo and big go) and there’s even more to come.

One of the goals of WebAssembly is to melt right into your local $TOOLCHAIN as a compilation target, and we are getting closer every week.

esprehn 2026-03-12 01:54 UTC link

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.

GianFabien 2026-03-12 03:15 UTC link

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.

TheLNL 2026-03-12 09:07 UTC link

Say goodbye to writing multiple kinds of plugins and userscripts for random websites I guess. I don't want the transition to wasm because it looks like it will make most things unchangeable binary blobs

u1hcw9nx 2026-03-12 10:43 UTC link

This was supposed to happen already in the 2000s. JVM in everywhere, especially in the browser. There was Java rings you could wear, Java Card VM (JCVM), Squawk VM, Java ME.

"Java the language is almost irrelevant. It's the design of the Java Virtual Machine. And I've seen compilers for ML, compilers for Scheme, compilers for Ada, and they all work. Not many people use them, but it doesn't matter: they all work." --James Gosling

Then Microsoft happened. MS realized that "Write Once, Run Anywhere" kills their OS monopoly, so they polluted Java with brilliant Embrace, Extend, Extinguish strategy (Sun vs. Microsoft revealed the emails where the stated goal was "Kill cross-platform Java" by growing the "polluted" Java market.):

Embrace: Microsoft licensed Java from Sun Microsystems and built the MSJVM. It was the fastest JVM for some time.

Extend: They created a programmer tool for Java with proprietary Windows-specific "extensions" and also removed standard features like RMI and JNI.

Extinguish: Developers using MS tools (90% of devlopers at the time) produced "Write Once, Run Only on Windows" software and killed it and pivoted to C# and .NET

pmkary 2026-03-12 12:01 UTC link

Not only are they a decade late while everyone expected WASM to liberate us from JS, and it ended up being a useless toy in JS whose improvements would have been crushed by having to send all progress to JS to apply it, but then giving it access to DOM is also something you'll realize wasn't enough a decade later. Flutter doesn't need DOM; it has all of its own engine. The browser should give the whole viewpoint to the WASM so that apps can directly implement their own GUIs. And then there will be an app revolution. You can directly port your GUI to the web and have it work. No more your GUI as a WASM worker that has to have its frames painted by JS on a canvas; direct painting. You could have wxWidgets, GTK, Flutter, ... all working insanely fast, insanely beautiful. And then people can do amazing things. Imagine a web alternative that is powered by maestro Knuth's TeX; imagine operating systems as web pages, imagine alternative layout systems that do not have to rely on Web events and frame timing. That is all if the browser allows for WASM to bypass the web part and do it itself.

utopiah 2026-03-12 14:00 UTC link

I feel like the bottleneck for WASM integration isn't WASM itself but rather how to interface with it.

Quite often it comes with a mandatory service worker which has to be communicated to in a specific fashion, then some specific headers need to be available server side, etc. I'm not saying it's not required but ... I imagine most Web developer are used to requiring a library, calling its function, getting the result. Until it reaches that stage then JavaScript fallbacks will be preferred until there is absolutely no alternative but the WASM binary.

PS: this might sound like such a low bar... but the alternative is giving up entirely on either, starting a container with a REST API then calling it with a client. That's very easy and convenient when you've done it once and you decouple. So maybe I'm finicky but when very popular alternatives exist I believe the tipping point won't happen unless it becomes radically easier than what exists.

eqrion 2026-03-11 16:53 UTC link

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 portable.

I personally have always cared about DOM access, but the Wasm CG has been really busy with higher priority things. Writing this post was sort of a way to say that at least some people haven't forgotten about this, and still plan on working on this.

eqrion 2026-03-11 16:57 UTC link

I agree that a lot of the tooling is still early days. There has also been a lot of churn as the wasm component spec has changed. We personally have a goal that in most cases web developers won't need to write WIT and can just use Web API's as if they were a library. But it's early days.

eqrion 2026-03-11 17:04 UTC link

I agree there are some cases that won't see a huge boost, but also DOM performance is a big deal and bottleneck for a lot of applications.

And besides performance, I think there are developer experience improvements we could get with native wasm component support (problems 1-3). TBH, I think developer experience is one of the most important things to improve for wasm right now. It's just so hard to get started or integrate with existing code. Once you've learned the tricks, you're fine. But we really shouldn't be requiring everyone to become an expert to benefit from wasm.

phickey 2026-03-11 17:23 UTC link

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 don't have to ever read the CM spec or care about the minutae of how it gets implemented.

eqrion 2026-03-11 17:26 UTC link

The concurrency part of the C-M is complicated (I think for inherent reasons), but won't be exposed to end users. It's basically defining an API that language toolchains can use to coordinate concurrency.

For end users, they should just see their language's native concurrency primitives (if any). So if you're running Go, it'll be go routines. JS, would use promises. Rust, would have Futures.

davexunit 2026-03-11 17:54 UTC link

I really want stringref to make a comeback.

dbdr 2026-03-11 18:09 UTC link

If it "only" speeds up DOM access, that's massive in itself. DOM is obviously a crucial element when running inside a browser.

glenstein 2026-03-11 18:10 UTC link

With Google now pushing developer certification, Android and iOS practically being mandatory for certain basic functions like accessing your bank or certain government services, Webassembly would make web apps first class citizens that aren't subject to mobile operating system lockdown.

Being able to complete on efficiency with native apps is an incredible example of purposeful vision driving a significant standard, exactly the kind of thing I want for the future of the web and an example of why we need more stewards like Mozilla.

Retr0id 2026-03-11 18:27 UTC link

What makes WASM execution riskier than JS?

traderj0e 2026-03-11 18:29 UTC link

I only got mad when people wanted to add browser features that clearly break sandboxing like WebUSB. How does wasm break this?

traderj0e 2026-03-11 18:30 UTC link

Probably needs to be fixed by bundling runtimes for things like Go, or bringing back cross-website caching in some secure way if that's possible

JoshTriplett 2026-03-11 18:45 UTC link

> just to get 2x faster string marshalling

That is a useful benefit, not the only benefit. I think the biggest benefit is not needing glue, which means languages don't need to agree on any common set of JS glue, they can just directly talk DOM.

leptons 2026-03-11 19:11 UTC link

>20 years of serious browser security bugs caused chiefly by JavaScript

I think you may be confusing Javascript the language, with browser APIs. Javascript itself is not insecure and hasn't been for a very long time, it's typically the things it interfaces with that cause the security holes. Quite a lot of people still seem to confuse Javascript with the rest of the stuff around it, like DOM, browser APIs, etc.

joshuaissac 2026-03-11 19:25 UTC link

Internet Explorer used to support any language that Windows Script Host could run. By default, that was JScript and VBScript, but there were third-party engines for Python, Perl, Ruby, Lua, and many others.

Possibly disabled now as they announced VBScript would be disabled in 2019.

hinkley 2026-03-11 20:35 UTC link

I’m wondering if the recent improvements in sending objects through sendMessage in v8 and Bun change the math here enough to be good enough.

SendMessage itself is frustratingly dumb. You have excessively bit fiddly or obnoxiously slow as your options. I think for data you absolutely know you’re sending over a port there should be an arena allocator so you can do single copy sends, versus whatever we have now (3 copy? Four?). It’s enough to frustrate use of worker threads for offloading things from the event loop. It’s an IPC wall, not a WASM wall.

Instead of sending bytes you should transfer a page of memory, or several.

rishflab 2026-03-11 23:33 UTC link

> 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.

nneonneo 2026-03-12 00:06 UTC link

Your comment - and your last two comments too - all sound very LLM-written. Using an LLM for commenting is explicitly against the site rules (https://news.ycombinator.com/newsguidelines.html#generated).

leptons 2026-03-12 03:57 UTC link

I have to wonder if Apple will allow any of this to move forward in the W3C standards committee since they've been blocking many things that would make web browsers as capable as native apps.

Apple perceives web-based applications as chipping away at their app store (which makes them money), and so they cripple their Safari browser and then force all mobile browsers on iOS to use their browser engine, no exceptions, so that developers are forced to make a native app where Apple can then charge the developers (and thus the users) for a cut of any sales made through the app.

It's one reason the DOJ started suing Apple, but I fear that may have been sidelined due to politics.

https://www.justice.gov/archives/opa/media/1344546/dl?inline

thezipcreator 2026-03-12 04:54 UTC link

iirc webassembly components need to explicitly import anything they use, so it should be transparent which dependencies something has by just grepping its WIT for `import`

thezipcreator 2026-03-12 04:56 UTC link

webassembly components use a borrow checking model[1], so I assume that would be used to manage DOM components?

I'm not exactly sure how this works when binding it to GC languages.

[1] https://component-model.bytecodealliance.org/design/wit.html...

thezipcreator 2026-03-12 05:02 UTC link

I disagree. That's how WASM is now, and I guess that's fine, but that's not all it could be. I really think it would be awesome if you could write code for the web in your preferred programming language.

flohofwoe 2026-03-12 07:58 UTC link

Get your blatant component model propaganda outta here ;)

(to elaborate: WASM works just fine without the component model, it's not "the future of WebAssembly", just an option built on top of it, and of questionable value tbh)

pjmlp 2026-03-12 08:20 UTC link

Hello COM, CORBA, RMI, Jini, .NET Remoting, Tcl Agents,..., that is basically what it is.

flohofwoe 2026-03-12 09:03 UTC link

Yeah, the web API layer stack is essentially inverted, and important parts are missing entirely. Ideally there would be a 3D API at the bottom, on top of that a text-and-font API (e.g. allow to render high quality text into a 3D-API surface without bringing your own text renderer), to the side a vector/shape rendering API as the base for SVG, and a layouting/compositing API, the DOM should only be implemented on top that.

The chance for that ever materializing is most like zero though.

zeratax 2026-03-12 10:40 UTC link

I don't follow? when you write userscripts you modify the dom not the already running scripts usually, no?

rkangel 2026-03-12 10:43 UTC link

Your logic is circular though. You are saying that there won't be much speedup for the sort of things people already do in WASM - but the reason they're doing them in WASM is because they're not slowed down too much.

What you don't get much is people doing standard SPA DOM manipulation apps in WASM (e.g. the TodoMVC that they benchmarked) because the slowdown is large. By fixing that performance issue you enable new usecases.

fzzzy 2026-03-12 12:10 UTC link

And it would be 100% inaccessible.

gumby271 2026-03-12 13:18 UTC link

Which is very much Google's approach to Android. AOSP could be targeted directly by devs, but Google pushes everyone to use Google services in their apps (and assume it's available on any android device) which means Android with Google services is the only viable version of Android out there.

wffurr 2026-03-12 13:32 UTC link

JVM bytecode didn't have support for C and required GC. Even in the early days it was a lot heavier than Wasm.

gzread 2026-03-12 14:37 UTC link

Java failed because of its security model - trying to run trusted and untrusted code in the same VM without a hard boundary - a given call is trusted if every call stack entry at the time of the call is in a trusted class. There were too many confused deputies - if you can set up a trusted object to make a call that requires trust later on without your involvement, then you have privilege escalation.

The solution was to sandbox the whole VM but this breaks all the existing code designed for partial sandboxing (e.g. most of the standard library). WASM uses this approach from the start.

Editorial Channel

What the content says

Structural Channel

What the site does