WASM 3.0 Completed | Hacker News Reader

WASM 3.0 Completed

webassembly.org

1,086 pointstodsacerdoti494 comments

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more.

If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious), then we should be honest and build a virtualization abstraction that is actually what we want, rather than converting a document reader into a video editor…

> ... document browser ... document reader ...

I'm going to assume you're being sincere. But even the crustiest among us can recognize that the modern purpose for web browsers is not (merely) documents. Chances are, many folks on HN in the last month have booked tickets for a flight or bought a home or a car or watched a cat video using the "document browser".

> If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious)...

Like ... the WASM virtual machine? What if the WASM virtual machine were the culmination of learning from previous not-quite-good-enough VMs?

WASM -- despite its name -- is not truly bound to the "document" browser.

Personally not a fan of Windows 95 in the browser, however the browser stoped being a “document reader” a decade ago it’s the only universel, sandbox runtime, and everything is moving in that direction ... safe code. WASM isnt a worst VM; it’s a diffrent trade off: portable, fast start, capability scoped compute without shiping a OS. Raw device still have their place (servers). If you need safe distribution + performance thats “good enough” WASM in the browser is going to be the future of client.

The problem is: even us old timers can't deny nor change the fact that operating systems have been putting up barriers to disallow running untrusted code downloaded from the internet.

Try to distribute an installer on Windows that isn't signed with an extensive EV-certificate for instance. It's scare popup galore.

Not to mention the closed gardens of the Apple and Google Stores which even when you get in, you can be kicked out again for absolutely no objective reason (they don't even need to tell you why).

> then we should be honest and build a virtualization abstraction that is actually what we want,

This is not in the interest of Microsoft, Google or Apple. They can't put the open web back into the box (yet, anyway), but they will not support any new attempts to create an open software ecosystem on "their" platforms.

Think of it like emacs. Browsers are perfectly good operating systems just needing a better way to view the web.

The browser removes the friction of needing to install specialized software locally, which is HUGE when you want people to actually use your software. Figma would have been dead in the water if it wasn't stupidly simple to share a design via a URL to anyone with a computer and an internet connection.

I would argue that as soon as it was decided to include JavaScript runtime in the browser, it stopped being a plain document browser. From then on, we were just on the evolutionary path of converting it from a low capability app sandbox to a highly capable one.

There are projects to run WASM on bare metal.

I do agree that we tend to run a lot in a web-browser or browser environment though. It seems like a pattern that started as a hack but grew into its own thing through convenience.

It would be interesting to sit down with a small group and figure out exactly what is good/bad about it and design a new thing around the desired pattern that doesn't involve a browser-in-the-loop.

There is no difference between a "document" and an "app". There has never been a difference between the two, it's a purely artificial distinction.

Word and LibreOffice "documents" can run embedded macros. Emacs has `org-mode`, which can call out to any programming language on your $PATH. A PDF document is produced by running code in a stack-based virtual machine. Even fonts have bytecode instructions embedded inside them that are used for hinting.

If by "document" you mean "static text with no executable bits", then only plain text files can truly be called documents. Everything else is a computer program, and has been since the dawn of computing.

I'm a fan of the browser becoming a sandbox for much more than "documents". It has the most developed, flexible, and powerful UI system ever, it established numerous standards that pervade modern software development, and it's already available as one of the most cross-platform standard utilities.

If the browser sandbox is a reliable cross-platform sandbox, the potential to develop and distribute software is huge. Progressive Web Apps are awesome because you can visit the website and use it normally, and then click a button to "install" the website to your device. If designed correctly, the website can work offline. By doing this, you get free distribution, automatic updates, no app stores, an excellent platform to develop an app on top of (the browser), etc.

I think PWAs are the future, but the web platform still has some ways to go. There are numerous amazing examples of what you can accomplish with PWAs in their current state, though.

Plenty of people still want local-first apps that function offline.

The browser became an app engine so app developers could escape the Wintel monopoly that was pretty tight in the 90's and 00's when the Internet became a thing. These days, it's so there can be apps outside of app stores.

There's been various attempts to build "Internet operating systems" that are little more than a browser (that's what Chrome OS was intended to be in the beginning I thought) but Windows and it's pre-internet legacies are so entrenched in PCs and corporate life that nothing's ever gonna change there until Microsoft makes the entirety of Windows an app.

I a 64yo fart. Started programming with machine codes. Native is my bread and butter. Still have no problems and am using browser as a deployment platform for some type of applications. Almost each thing has it's own use.

Basically OS developer dropped the ball. Internet caught them by surprise and few decades is apparently too short for them to come up with new appealing abstractions to fit the new environment. So browser developers took over and did just that.

Same way webdevs ate desktop app dev's lunch because they had no idea how to innovate on decade old ideas.

To sum up, no matter how well you are positioned for something on paper, if you won't do it, someone else will.

But that's what they're doing. The hard part isn't the VM. The hard part is the long fought functional yet secure sandbox that a browser provides.

I feel way safer using apps inside web browser than installing / executing them directly on my PC.

.NET does this and nowadays you can compile most of your .NET code to machine code, it only keeps bytecode for the reflection pieces of code, but everything else is Ahead of Timed iirc basically you get all the VM benefits, and some native speeds in one go.

The browser has become the operating system for a while now because native OS things were too fragmented and too slow to keep pace with what people wanted.

PostScript is turing complete. SVG almost got the ability to open raw network sockets. Word files were (are?) a common platform for distributing malware.

Security model of web is needed to be brought to the OS.

lmfao

Unfortunately, Memory64 comes with a significant performance penalty because the wasm runtime has to check bounds (which wasn't necessary on 32-bit as the runtime would simply allocate the full 4GB of address space every time).

But if you really need more than 4GB of memory, then sure, go ahead and use it.

Actually, runtimes often allocate 8GB of address space because WASM has a [base32 + index32] address mode where the effective address could overflow into the 33rd bit.

On x86-64, the start of the linear memory is typically put into one of the two remaining segment registers: GS or FS. Then the code can simply use an address mode such as "GS:[RAX + RCX]" without any additional instructions for addition or bounds-checking.

The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.

The irony for me is that it's already slow because of the lack of native 64-bit math. I don't care about the memory space available nearly as much.

Bounds checking in other PLT is often reproted to result in pretty low overheads. Will be interesting to see some details about how this turns out.

I still don't understand why it's slower to mask to 33 or 34 bit rather than 32. It's all running on 64-bit in the end isn't it? What's so special about 32?

Webapps limited by 4GiB memory?

Sounds about right. Guess 512 GiB menory is the minimum to read email nowadays.

I know you're in this for the satire, but it's less about the webapps needing the memory and more about the content - that's why I mentioned video editing webapps.

For video editing, 4GiB of completely uncompressed 1080p video in memory is only 86 frames, or about 3-4 seconds of video. You can certainly optimize this, and it's rare to handle fully uncompressed video, but there are situations where you do need to buffer this into memory. It's why most modern video editing machines are sold with 64-128GB of memory.

In the case of Figma, we have files with over a million layers. If each layer takes 4kb of memory, we're suddenly at the limit even if the webapp is infinitely optimal.

It doesn't actually allocate 4 GiB. Memory can be mapped without being physically occupied.

In fairness, this is talking about Figma, not an email client

Finally a web browser capable of loading slack

I assume that looking into the present we need to think about running local LLMs in the browser. Just a few days ago I submitted an article about that [1].

[1] https://news.ycombinator.com/item?id=45200414

I'm excited by the GC, ref types and JS string API! Been a while J, how are you going?

> Garbage collection. In addition to expanding the capabilities of raw linear memories, Wasm also adds support for a new (and separate) form of storage that is automatically managed by the Wasm runtime via a garbage collector. Staying true to the spirit of Wasm as a low-level language, Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of struct and array types, plus unboxed tagged integers, whose allocation and lifetime is then handled by Wasm. But that’s it.

Wow!

It's very refreshing and good to see WASM is embracing GC in addition to non-GC support. This approach is similar to D language where both non-GC and GC are supported with fast compilation and execution.

By the way now you can generate WASM via Dlang compiler LDC [1].

[1] Generating WebAssembly with LDC:

https://wiki.dlang.org/Generating_WebAssembly_with_LDC

Does this allow for shrinking the WebAssembly.Memory object?

- https://github.com/WebAssembly/design/issues/1397

- https://github.com/WebAssembly/memory-control/issues/6

This is a crucial issue, as the released memory is still allocated by the browser.

No, I don't think it will. Pointers to managed objects are opaque, and aren't actually backed by the wasm memory buffer. The managed heap is offloaded.

Shrinking the memory object shouldn't require any special support from GC, just an appropriate API hook. It would, as always, be up to the application code running inside the module to ensure that if a shrink is done, that the program doesn't refer to memory addresses past the new endpoint.

If this hasn't been implemented yet, it's not because it's been waiting on GC, but more that it's not been prioritized.

Wasm GC is entirely separate from Wasm Memory objects, so no, this does not help linear memory applications.

I'm not familiar with WASM. Can someone explain why this is a good thing? How does this work with languages that do not have a garbage collector, like Rust?

The answer was kind of known before hand. It was to enable the use of GCed languages like Python on Ruby to create WASM applications. Meanwhile, non-GCed languages like Rust, C and C++ were supposed to continue to work as before on WASM without breaking compatibility. This is what they seem to have finally achieved. But I needed to make sure of it. So, here are the relevant points from the WASM GC proposal [1]:

  * Motivation
  - Efficient support for high-level languages
      - faster execution
      - smaller modules
      - the vast majority of modern languages need it

  * Approach
  - Pay as you go; in particular, no effect on code not using GC, no runtime type information unless requested
  - Don't introduce dependencies on GC for other features (e.g., using resources through tables)

[1] https://github.com/WebAssembly/spec/blob/wasm-3.0/proposals/...

Note that the high level language needs a sufficient abstraction in its own runtime to allow substituting the Wasm GC for the runtime’s own GC. Work has been done for Java and Kotlin, but Python, C#, Ruby, Go can’t yet use the Wasm GC.

to also consider this one https://github.com/6over3/zeroperl

Non-GCed languages will continue to manage memory themselves. Previously, GCed languages that wanted to run on WASM had to have an implementation of their runtime including GC compiled to WASM. The idea or hope here is that those languages can use the built-in GC instead and slim down the amount of WASM that needs to be delivered to run the application to only include a minimal runtime. The current scenario is closer to if a web app or node app built with JavaScript had to ship a significant portion of V8 with it to function.

This will probably benefit Java applets targeting Wasm the most considering the huge size of their JVM.

Here's a fun example of a language that takes advantage of this: https://spritely.institute/hoot/

I works very well, thank you for asking: https://rustwasm.github.io/book/

This seems less than ideal to me.

1. Different languages have totally different allocation requirements, and only the compiler knows what type of allocator works best (e.g. generational bump allocator for functional languages, classic malloc style allocator for C-style languages).

2. This perhaps makes wasm less suitable for usage on embedded targets.

The best argument I can make for this is that they're trying to emulate the way that libc is usually available and provides a default malloc() impl, but honestly that feels quite weak.

I don't see this as a problem in the JVM, where independently of what programming language you are using, you will use the GC configured on the JVM at launch.

That sounds like WASM is going into the Java direction. Is that really a good thing?

What do you mean by the Java direction? It's a virtual machine with GC support, so I guess in that regard it's similar to the JVM, CLR, BEAM, et al. If anything, those VMs show performance improvement and better GC over time and a strong track record of giving legacy software longevity. The place where things seem to fall apart over the long term is when you get to the GUI, which is arguably a problem with all software.

Java approach: create the JVM to support one language, so it has rich high-level concepts that are unfortunately skewed toward certain assumptions about language design, and it can be reused only for other languages that are similar enough.

WASM approach: start very low-level so C is definitely supported. Thus everything is supported, although every language has to roll its own high-level constructs. But over time more patterns can be standardised so languages can be interoperable within a polyglot WASM app.

When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?

Agreed. This and (sane) access to multi-threading. I want to be able to write a Rust application, compile to wasm and load it with

    <html>
    <body>
        <div id="root"></div>
        <script type="application/wasm" src="./main.wasm"></script>
    </body>
    </html>

Would be great for high performance web applications and for contexts like browser extensions where the memory usage and performance drain is real when multiplied over n open tabs. I'm not sure how code splitting would work in the wasm world, however.

v8 could be optimized to reduce its memory footprint if it detects that no JavaScript is running - or wasm-only applications could use an engine like wasmer and bypass v8 entirely.

Another factor is that web technologies are used to write desktop applications via Electron/similar. This is probably because desktop APIs are terrible and not portable. First class wasm support in the web would translate to more efficient desktop applications (Slack, VSCode, Discord, etc) and perhaps less hate towards memory heavy electron applications.

> <script type="application/wasm" src="./main.wasm"></script>

Plus ça change...

The difference is that now it is cool.

https://cheerpj.com/

  <!doctype html>
  <wasm src="my-app.wasm">

Why not just do the whole DOM out of your WASM?

If you're at that point, the logical step would be to just support replying to the HTTP request with a "content-type: application/wasm" and skip the initial html step entirely.

Not sure what the Rust situation is like, but last I checked (and compiled a non-trivial personal application) WASM supported the pthreads API and it seemed to work reasonably well. Have you encountered stumbling points porting a heavily MT Rust program to WASM?

That's supposedly WASI, an interface specifically designated for system programming use, and that's where it implements part of the POSIX support including pthread.

OTOH you still need to start a wasm runtime first, then import the WASI module into the wasm host.

P.S.: used to tinker with wasmtime and wasmi to add wasm support to my half abandoned deno clone ;) I learned this the hard way

WASM itself does not support pthreads. However things like Emscripten have very good support for pthreads. WASM is one of the compilation targets of Emscripten (we had asm.js before that) and on top of that emscripten provides excellent shims for many POSIX APIs. Regarding Rust which has supported WASM as a compilation target for a long time now, the idiomatic way of doing this is not shiming, but using higher level APIs: if you need parallel execution threads and need to compile to WASM you would use a crate (such as rayon) that is able to compile to WASM (and will use web workers under the hood just like Emscripten does). You would not use pthreads directly (std::thread)

WASM does not support pthreads in the browser, only web workers, which are much more limited.

You can do all of this using Rust today. Very sane access to multi-threading => writing rust code that runs in parallel and is compiled without you worrying about it to run under several web workers

That still requires a bunch of glue code right? Like, I can't simply compile my application to a wasm target and threads just work

   cargo build --release --target wasm64

I think wasi has access to threading, but I don't think browsers support wasi?

I completely agree. The WebAssembly multi-threading programming model with its reliance on the web worker API is a pain to deal with. Google’s Native Client had native threading support, why can this not be replicated in WebAssembly?

Basically never, because it would require re-standardizing the DOM with a lower-level API. That would take years, and no major browser implementor is interested in starting down that road. https://danfabulich.medium.com/webassembly-wont-get-direct-d...

Killing JavaScript was never the point of WASM. WASM is for CPU-intensive pure functions, like video decoding.

Some people wrongly thought that WASM was trying to kill JS, but nobody working on standardizing WASM in browsers believed in that goal.

People have to look at it, from the same point of view Google sees the NDK on Android.

"However, the NDK can be useful for cases in which you need to do one or more of the following:

- Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

- Reuse your own or other developers' C or C++ libraries."

And I would argue WebGL/WebGPU are preferably better suited, given how clunky WebAssembly tooling still is for most languages.

It's really not that hard. Node.js has a very mature C FFI for interacting with JavaScript.

Just agree on some basic bindings

   wasb_create_u32(env: *const env, value: u32, result *mut value) -> status
   wasb_create_string_utf8(env: *const env, str: *const c_char, length: i32, result: *mut value) -> status

There is even a shim that ports the Node.js C FFI to wasm: https://github.com/devongovett/napi-wasm/blob/main/index.mjs...

Heck, just include that in the browser so it doesn't need to be loaded at runtime

Stack that with support in the browser for wasi and you have everything you need to work with the DOM from wasm as well as things like threading

That's the issue with WASM. Very, very few people want a limited VM that's only good for CPU-intensive pure functions. The WASM group has redirected a huge amount of resources to create something almost nobody wants.

A bit unrelated, but are there any recent benchmarks comparing it with native perf?

Hard to believe it can compete with V8 JIT anytime soon. Might be easier to integrate fast vector libraries within javascript engines.

Contrary to naysayers, I'm pretty sure this is very doable. Most browser JS objects map 1-1 to C++ native objects implemeneted in the browser.

As others have pointed out, the Js compoment interface is define in a language called WebIDL:

https://firefox-source-docs.mozilla.org/dom/webIdlBindings/i...

How it works in Chrome(Blink) is that a compiler generates a wrapper between V8, which is a V8 object that holds onto the native object reference using this IDL.

Once V8 cleans up the Js object, the native code, holding a weak reference to the native objects, detects that it has become unreachable and cleans that up.

In any ways, the object lifetime is encapsulated by the v8 Isolate (which is depending on how you look at it, the lifetime of the HTML document or the heap), so it'd be perfectly fine to expose native references as they'd be cleaned up when you navigate away/close the page.

Once you support all the relevant types, define a calling convention, and add an appropriate verifier to Wasm, it'd be possible to expose all native objects to Wasm, probably by generating a different (and lighter weight) glue to the native classes, or delegating this task to the Wasm compiler.

Of course, if you wanted to have both JS and Wasm to be able to access the same object, you'd have to do some sort of shared ownership, which'd be quite a bit more complicated.

So I'd argue it'd make sense to allow objects that are wholly-owned by the Wasm side or the JS side, which still makes a ton of sense for stuff like WebGL, as you could basically do rendering without calling into JS.

I'm going out on a limb here, but I'd guess since this multi-memory support has landed, that means a single webassembly instance can map multiple SABs, so it might be the beginnings of that.

You can write a WASM program today that touches the DOM, it just needs to go through the regular JS APIs. While there were some discussions early on about making custom APIs for WASM to access, that has long since been dropped - there are just too many downsides.

But then you need two things instead of one. It should be made possible to build WASM-only SPAs. The north star of browser developers should be to deprecate JS runtimes the same way they did Flash.

That is never going to happen until you create your own browser with a fork of the WASM spec. People have been asking for this for about a decade. The WASM team knows this but WASM wants to focus on its mission of being a universal compile target without distraction of the completely unrelated mission of being a JavaScript replacement.

I agree with the first part, but getting rid of JS entirely means that if you want to augment some HTML with one line of javascript you have to build a WASM binary to do it?

I see good use cases for building entirely in html/JS and also building entirely in WASM.

You can use a framework that abstracts all the WASM to JS communication for DOM access. There are many such framework already.

The only issue is that there’s a performance cost. Not sure how significant it is for typical applications, but it definitely exists.

It’d be nice to have direct DOM access, but if the performance is not a significant problem, then I can see the rationale for not putting in the major amount of work work it’d take to do this.

I was under the impression that this very much still on the table, with active work like the component model laying the foundation for the ABI to come.

I have slightly different question than OP - what's left until it feels like javascript is gone for people who don't want to touch it?

Say I really want to write front end code in Rust* does there just need to be a library that handles the js DOM calls for me? After that, I don't ever have to think about javascript again?

> Say I really want to write front end code in Rust* does there just need to be a library that handles the js DOM calls for me? After that, I don't ever have to think about javascript again?

yes, e.g. with Leptos you don't have to touch JS at all

Isn't going through the JS APIs slow?

used to be, in the early days, but nowadays runtimes optimized the function call overhead between WASM and JS to near zero

https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

Could you list some of these downsides and what are the reason of their existence?

For starters, the DOM API is huge and expansive. Simply giving WASM the DOM means you are greatly expanding what the sandbox can do. That means lower friction when writing WASM with much much higher security risks.

But further, WASM is more than just a browser thing at this point. You might be running in an environment that has no DOM to speak of (think nodejs). Having this bolted on extension simply for ease of use means you now need to decide how and when you communicate its availability.

And the benefits just aren't there. You can create a DOM exposing library for WASM if you really want to (I believe a few already exist) but you end up with a "what's the point". If you are trying to make some sort of UX framework based on wasm then you probably don't want to actually expose the DOM, you want to expose the framework functions.

I am watching patiently from a distance to my hands on a well-designed frontend language but can't help to wonder... is it really _that_ inefficient to call a JS wrapper to touch the DOM?

Most code already is so horribly inefficient that I can't imagine this making a noticeable difference in most scenarios.

No, it's not that bad honestly. But it's not more efficient than JS either, and all this ugly glue code hurts my sensibility.

Sounds like something that could be trivially turned into a library, no?

GC was required part, because it was needed to allow interaction between DOM-side lifetimes and WASM-side lifetimes. You might still need a puny shim to essentially "declare" whatever form you want the DOM API to look like on WASM side (probably utilizing components and WIT in the future) but that shim won't have to do anything other than register the APIs because WASM will be able to take a reference to DOM object and vice versa instead of throwing a copy of data over the wall as it is now.

> When can we finally kill JavaScript?

If you think JavaScript has problems I have bad news about the DOM…

Wanted to say the same thing. People often conflate JS with the DOM API, but that couldn't be further from the case.

You can get rid of JS, but that won't help much because it's just a small language interfacing with a huge, old, backwards compatible to 20+ years ago system that is the DOM.

yep, ive still never understood the fetish of HN folks wanting to eliminate JS completely. you tell them to use TS, they say its overcomplicated... i've never heard a definitive or decent answer to "ok what language WOULD you use for manipulating the DOM?" its infuriating, though i suppose those complaining have probably built like one website once. yes, JS is not your strongly typed Rust / Go / .NET, get over it - go learn TypeScript and be happy

I don't think WASM by itself will finally kill Javascript, other languages and their tooling are not well equipped to create DOM-based applications with the constraints expected for the web (fast loading times, lazy-loading, asset bundling, etc).

I don't think most languages it is even feasible to compile to wasm in a way that doesn't include a splashscreen for any non-trivial application. Which is simply unacceptable for most web content. And that is even before all the work required in user-land to support browser primitives (like URL routing, asset loading, DOM integration, etc).

So I can foresee this unlocking "heavy duty productivity apps" to run in the browser things like video editors or photoshop using web-first GUI (meaning DOM elements) without significant amounts of JS. But for general web content consumed by the masses I find it unlikely.

I expect the real "javascript death" will mean a completely new language designed from the ground-up to compile to WASM and work with browser APIs.

One of the things that I think make this tricky is that if you have any DOM references you now have visibility into a GCable object.

Part of the web Javascript security model is that you cannot see into garbage collection. So if you have some WASM-y pointer to a DOM element, how do you handle that?

I think with GC in properly people might come at this problem again, but pre-GC WASM this sounds pretty intractable

Probably never. There's a pretty good recent thread on this topic:

https://news.ycombinator.com/item?id=44775801

Hot take alert

> When is WASM finally going to be able to touch the DOM?

Coming from a web background, and having transitioned to games / realtime 3D applications...

Fuck the DOM dude. The idea that programming your UI via not one but TWO DSLs, and a scripting language, is utter madness. In principal, it might sound good (something something separation of concerns, or whatever-the-fuck), but in reality you always end up with this tightly coupled garbage fire split across a pile of different files and languages. This is not the way.

We need to build better native UI libraries that just open up a WebGL context and draw shit to that. DearIMGUI can probably already do like 85% of what modern webapps do.

Anyways .. /rant

> DearIMGUI can probably already do like 85% of what modern webapps do

I’m with you. Main blocker I’ve seen to “just use ImGui for everything” (which I’d love to adopt), is if I run ImGui in WASM the keyboard doesn’t open on mobile. This seems possible in theory because egui does it.

Even though running ImGui on mobile via WASM isn’t the primary use case, inevitably the boss or someone is going to need to “just do a quick thing” and won’t be able to on mobile, and this seems to be a hard ceiling with no real escape hatch or workaround.

One of those scenarios where, if we have to use a totally different implementation (React or whatever) to handle this 1% edge case, we might as well just use that for the other 99%.

I'd say two things about this.

1. Opening the native keyboard and plumbing those events through to the WASM runtime sounds pretty easy. It's probably not cause modern software, but conceptually it should be trivial.. right??

2. In terms of 'the boss' wanting to do 'that one weird thing' that there isn't a library/plugin/whatever for in DearImgui land. If dev time for everything else gets faster, than the 10x cost of that small corner case can be absorbed by net win. Now, I'm pretty sus on the claim everything else gets better today, but we can certainly imagine a world where they do, and it's probably not far away

Preach. HTML and CSS are markup languages for creating documents. Using them for GUI applications is wild and obviously a bad idea.

HTML is pretty bad (XUL was better), but (subset) of CSS is probably OK.

HTML isn't even a particularly good markup language for documents, web or otherwise.

> Using them for GUI applications is wild and obviously a bad idea.

I agree it's wild, but bad idea implies there are better options for cross platform applications with the same ease of distribution, and accessibility as the web.

Most major GUI frameworks operate on something very similar to HTML + CSS.

> We need to build better native UI libraries that just open up a WebGL context and draw shit to that. DearIMGUI can probably already do like 85% of what modern webapps do.

Would be totally into that! But then as soon as you're developing for a worldwide paying audience (or your employer is), one manager realizes the need for ARIA stuff, another for SEO, another for fully-native input controls (textboxes, checkboxes, radios, buttons etc) for most-fluid&familiar UX on every OS, another for embedding externally loaded markup+scripts (whether that's social media sharing widgets, auth providers, Google Maps / OpenStreetMaps etc), for supporting user-generated `<img>`s and `<video>` in all the various formats the browser natively furnishes, and on and on and on =)

That's true. But without the DOM we also loose the browser native accessibility support and text interaction and so on.

I know nothing about how accessibility supports works in the browser, but could they offer a way to use the accessibility API with your custom UI rendered in WebGL/WebGPU?

> We need to build better native UI libraries that just open up a WebGL context and draw shit to that.

This is what Flutter does. It works well, but you do lose some nice things that the browser/DOM provides (accessibility, zooming, text sizing/selection, etc). There’s also a noticeable overhead when the app + renderer is initially downloaded).

Couldn't you implement something like HTMX in wasm then and still have locality-of-behavior by specifying the behavior as html attributes?

Maybe some day, maybe never. A different, perhaps more important question is, does it matter?

https://youtu.be/4KtotxNAwME?si=Egu05co4q7-RsanU

Probably only after Components and WIT are stabilized. No point of making it wihtout it IMO.

From what I understand, WASM is purely functional, to perform side effects, you will need a runtime like WASI to implement it

Even if you had that environment today, how would you replace the function of JS?

Web development moves faster than any software in history. A lot of this is on the back of JS being ergonomic/fast to code and having very good performance and a lot of what makes it good at this is also what coders familiar with other languages dislike.

What other language has that right combination of really fast development and good performance?

You would probably have to go outside the mainstream to something like Scheme or StandardML to get the ergonomics and performance, but that would upset a whole other group of people.

After that is an even bigger problem. If everyone adopts different languages, different frameworks for those languages, and different user-facing APIs for the WASM APIs, then finding devs for your frontend team who can be productive quickly suddenly becomes impossibly hard.

I would bet on browsers being able to consume Typescript before WASM exposing any DOM API. That'd improve the Javascript situation a bit, at least.

Not TS, but there are plans to allow something similar with special type annotation syntax. The runtimes still won't do anything with that extra info though, it'll get stripped just like comments.

https://github.com/tc39/proposal-type-annotations

Pretty sure this is here, my dude.

What are you referring to?

this is a really bad and out of touch take

I haven't really been following WASM development in the last year and didn't realize that WASM had moved to a versioned release model. I've been aware of the various features in development[1] and had thought many of the newer features were going to remain optional but I guess now that implementations are expected to support all the features to be able to claim compatibility with e.g. "WASM 3.0"?

It'll be interesting to see what the second non-browser-based WASM runtime to fully support 3.0 will be (I'm guessing wasmtime will be first; I'm not counting Deno since it builds on v8). Garbage collection seems like a pretty tricky feature in particular.

Does anyone know how this 3.0 release fits into the previously announced "evergreen" release model?[2]

> With the advent of 2.0, the Working Group is switching to a so-called “evergreen” model for future releases. That means that the Candidate Recommendation will be updated in place when we create new versions of the language, without ever technically moving it to the final Recommendation state. For all intents and purposes, the latest Candidate Recommendation Draft[3] is considered to be the current standard, representing the consensus of the Community Group and Working Group.

[1] https://webassembly.org/features/

[2] https://webassembly.org/news/2025-03-20-wasm-2.0/

[3] https://www.w3.org/TR/wasm-core-2/

> It'll be interesting to see what the second non-browser-based WASM runtime to fully support 3.0 will be (I'm guessing wasmtime will be first; ...)

Wasmtime already supports every major feature in the Wasm 3.0 release, I believe. Of the big ones: garbage collection was implemented by my colleague Nick Fitzgerald a few years ago; tail calls by Jamey Sharp and Trevor Elliott last year (with full generality, any signature to any signature, no trampolines required!); and I built our exceptions support which merged last month and is about to go out in Wasmtime 37 in 3 days.

The "3.0" release of the Wasm spec is meant to show progress and provide a shorthand for a level of features, I think, but the individual proposals have been in progress for a long time so all the engine maintainers have known about them, given their feedback, and built their implementations for the most part already.

(Obligatory: I'm a core maintainer of Wasmtime and its compiler Cranelift)

> garbage collection was implemented by my colleague Nick Fitzgerald a few years ago

The wasm features page says it is still behind a flag on wasmtime (--wasm=gc). Is that page out of date?

Wizard supports all of Wasm 3.0, but as a research tool, it only has an interpreter and baseline compiler tier (no opt compiler), so it doesn't run as fast as, say, V8 or wasmtime.

I suspect the versioning is going to replicate the JavaScript version system where versions are just sets of features that a runtime can support or not, I am not sure how feature discovery works in wasm though

The WebAssembly community should really focus more the developer experience of using it. I recently completed a project where I wrote a compiler¹ targeting it and found the experience to be rather frustrating.

Given that Wasm is designed with formal semantics in mind, why is the DX of using it as a target so bad? I used binaryen.js to emit Wasm in my compiler and didn't get a feeling that I am targeting a well designed instruction set. Maybe this is a criticism of Binaryen and its poor documentation because I liked writing short snippets of Wasm text very much.

1. https://git.sr.ht/~alabhyajindal/jasmine

Binaryen has a lot of baggage from Wasm early days, when it was still a strict AST. Many newer features are difficult to manipulate in its model.

In our compiler (featured in TFA), we chose to define our own data structure for an abstract representation of Wasm. We then wrote two emitters: one to .wasm (the default, for speed), and one to .wat (to debug our compiler when we get it wrong). It was pretty straightforward, so I think the instruction set is quite nice. [1]

[1] https://github.com/scala-js/scala-js/tree/main/linker/shared...

For what it's worth, I also tried Binaryen from TypeScript and similarly found it frustrating. I switched to using wasm-tools from Rust instead, and have found that to be a vastly better experience.

Isn't wasm-tools for working with Wasm modules? Maybe I'm missing something. I was using Binaryen to compile an AST to WebAssembly text. Also worth mentioning that Binaryen is the official compiler/toolchain for this purpose which is why I expected more from it.

Currently you use Binaryen to build up a representation of a Wasm module, then call emitText to generate a .wat file from that. With wasm-tools you'd do the same thing via the wasm-encoder crate to generate the bytes corresponding to a .wasm file, and then use the wasmprinter crate to convert from the .wasm format to the .wat format. Alternatively, I believe the walrus crate gives you a somewhat higher-level API to do the same thing, but I haven't used it because it's much heavier-weight.

What were your specific pain points? One thing that can be annoying is validation errors. That's one of the reasons that Wizard has a --trace-validation flag that prints a nicely-formatted depiction of the validation algorithm as it works.

Validation errors were bit of an issue. Especially because Binaryen constructs an internal IR that remains opaque until we emit the Wasm text. I did consider Wizard for my project but settled on Wasmtime because I needed WASI support.

My major pain point was the documentation. The binaryen.js API reference¹ is a list of function signatures. Maybe this makes sense to someone more experienced but I found it hard to understand initially. There are no explanation of what the parameters mean. For example, the following is the only information the reference provides for compiling an `if` statement:

  Module#if(condition: Expression, ifTrue: Expression, ifFalse?: Expression): Expression

In contrast, the Wasm instruction reference on MDN² is amazing. WASI again suffers from the same documentation issues. I didn't find any official resource on how to use `fd_write` for example. Thankfully I found this blog post³.

Wasm feels more inaccessible that other projects. The everyday programmer shouldn't be expected to understand PL research topics when they are trying to do something with it. I understand that's not the intention but this is what it feels like.

1. https://github.com/WebAssembly/binaryen/wiki/binaryen.js-API

2. https://developer.mozilla.org/en-US/docs/WebAssembly/Referen...

3. https://tty4.dev/development/wasi-load-fd-write/

Thanks for bringing Wizard to my attention, the next time I need to validate wasm it's going to save me a ton of time.

Sorry about binaryen.js - those JS/TS bindings could be a lot better, and better documented, but priorities are generally focused on improving optimizations in core Binaryen.

That is, most work in Binaryen is on improving wasm-opt which inputs wasm and outputs wasm, so any toolchain can use it (as opposed to just JS/TS).

But if someone had the time to improve the JS/TS bindings that would be great!

i found assembly is easier to assemble from scratch (it's apple and orange but.). Most materials should exclude these tooling, mostly rust based tools. We should be able to write them by hands just like when assembly was taught. Compiler and assembly are separate classes. I think it's bad assumption that only compiler devs only care about wasm. It's compiling target, sure, but framing it this way will not broaden its knowledge.

I've tried using binaryen, and I've also tried emitting raw wasm by hand, and the latter was far easier. It only took ~200 lines of wasm-specific code.

The SpecTec mentioned in the announcement is really cool. They're using a single source of truth to derive LaTeX, Sphinx docs, Coq definitions for proofs, and an AST schema. Building the language spec in a way that its soundness can be proven and everything derived from one truth in this way seems super useful.

https://webassembly.org/news/2025-03-27-spectec/

Since it hasn't been mentioned here yet: I wonder if the multiple-memories feature will somehow allow to avoid the extra copy that's currently needed when mapping a WebGPU resource. This mapping is available in a separate ArrayBuffer object which isn't accessible from WASM without calling into JS and then copying from the ArrayBuffer into the WASM heap and back.

Multiple WASM memories and Clang's/LLVM's address space feature sound like they should be able to solve that problem, but I'm not sure if it is as trivial as it sounds...

There has been a discussion (https://github.com/WebAssembly/multi-memory/issues/45) on the toolchain support, but I'm not sure if there have been steps to use multiple address spaces to support Wasm multi-memory in LLVM yet.

I'm just getting horrible segmenting and far-pointer vibes of the whole thing, been coding a classic Gameboy game for fun so fiddling with memory mappings is part of the "fun" but for anything non-constrained I'd hate that.

We buried far pointers with DOS and Win16 for a good reason..

I'd take segment-pointers over copying megabytes of memory around anyday though ;)

It's not much different than dealing with all the alignment rules that are needed when arranging data for the GPU.

"Far" memory is already a central concept in modern GPU APIs. Not all GPUs naturally share memory with the CPU they're running against and handles for resources are a requirement.

I'm a simple man who has simple needs. I want a better and faster way to pass Go structs in and out of the runtime that doesn't mean I have to do a sword dance on a parquet floor wearing thick knit wool socks and use some fragile grafted on solution.

If there can be a solution that works for more languages: great. I mostly want this for Go. If it means there will be some _reasonable_ limitations, that's also fine.

You're doing native code, this the solution is the same as in native code: your languages agree on a representation, normally C's, or you serialize and deserialize. Mixing language runtimes is just not a nice situation to deal with without the languages having first class support for it, and it should be obvious why.

I am not sure what you actually want but it sounds like something where the component model (the backbone of WASI) might help.

It defines a framework to allow modules to communicate with structured data types by allowing each module to decide how to map it to and from its linear memory (and in future the runtime GC heap)

In your case you could be able to define WIT interfaces for your go types and have your compiler of choice use it to generate all the relevant glue code

This is the truth, and it's not really much better in non-GCed languages either. (In reality my impression is the GCed wasm side runtimes are even worse).

Some of the least fun JavaScript I have ever written involved manually cleaning up pointers that in C++ would be caught by destructors triggering when the variable falls out of scope. It was enough that my recollections of JNI were more tolerable. (Including for go, on Android, curiously).

Then once you get through it you discover there is some serious per-call overhead, so those structs start growing and growing to avoid as many calls as possible.

I too want wasm to be decent, but to date it is just annoying.

Was this dealing with DOM nodes and older IE versions by chance? That was probably the single biggest reason to wrap all DOM manipulation with JQuery in that it did a decent job of tracking and cleanup for you. IIRC, a lot of the issues came from the DOM and JS being in separate COM areas and the bridge not really tracking connections for both sides.

I need to pass all the user input events to a game engine, and get back the results into the webgl JS runtime side renderer. (The games at https://www.luduxia.com/ )

That would be more of a library than a WASM spec thing, no? I wrote a code generator that does this well for some internal use-cases.

This is exactly why I say WebGL/WebGPU are much better for perfomance code on the browser than dealing with WebAssembly tooling.

Still looking forward to when they support OpenMP. We have an experimental Solvespace web build which could benefit quite a bit from that.

https://cad.apps.dgramop.xyz/

Open source CAD in the browser.

This is one of the best WASM-based web UIs I've seen! What was the hardest part of getting your desktop build working via Emscripten?

I didn't do the WASM port. It was started by our previous lead whitequark, and some more work done by a few others. It's not quite complete, but you can do some 3d modeling. Just might not be able to save...

One thing worth noting, everything but the menus and popups is drawn with openGL. The text window uses GNU unifont which is a bitmap font. All the interactions are handled the same way as the desktop versions.

Sounds like that would be something on a different abstraction level than WebAssembly itself, or are there some blockers in the platform that preclude a OpenMP implementation targeting WebAssembly?

I just want to say that Solvespace is amazing, I was able to follow a tutorial on YouTube and then design a split keyboard case for CNCing, all pretty quickly a few years ago.

Thank you for maintaining it!

I really hope this spurs AssemblyScript to just port to WASM GC: https://github.com/AssemblyScript/assemblyscript/issues/2808

There's comments in there about waiting for a polyfill, but GC support is widespread enough that they should probably just drop support for non-GC runtimes in a major version.

I'm still hype about WASM. This looks like a cool release. I'm running some pretty high traffic WASM plugins on envoy, running some plugins for terminal apps (zellij), and for one of my toy side projects, I'm running a wasm web app (rust leptos).

For 2 of those 3 use cases, i think it's not technically the optimal choice, but i think that future may actually come. Congratulations and nice work to everyone involved!

I don't think the GC in this version has the features required to enable a C# runtime on top of it yet: https://github.com/WebAssembly/gc/issues/77

I wonder what language this GC can actually be used for at this stage?

The article answers your question, there are at least 6 languages: Java, OCaml, Scala, Kotlin, Scheme, and Dart.

OCaml with wasocaml: https://github.com/OCamlPro/wasocaml

Dart for a long time now.

Kotlin/WASM is a thing

I'm not familiar with all the implementation details of objects in C#, but the list of issues mixes runtime implementation details (object layouts) that should be fairly low effort to work around with actual language/runtime features (references, finalization).

In general though most regular C# code written today _doesn't directly_ use many of the features mentioned apart from references. Libraries and bindings however do so a lot since f.ex. p/invoke isn't half as braindead as JNI was, but targeting the web should really not bring along all these libraries anyhow.

So, making a MSIL runtime that handles most common C# code would map pretty much 1-1 with Wasm-GC, some features like ref's might need some extra shims to emulate behaviour (or compiler specializations to avoid too bad performance penalties by extra object creation).

Regardless of what penalties,etc goes in, the generated code should be able to be far smaller and far less costly compared to the situation today since they won't have to ship both their own GC and implement everything around that.

Part of the problem is you would need to fork the base class libraries and many popular nuget packages to remove any uses of ref/in/out, along with any interior references, spans, etc. The .NET type system has allowed 'interior references' (references into the inside of a GC object) for a long time and it's difficult to emulate those on top of WasmGC, especially if your goal is to do it at low cost.

It's definitely true that you could compile some subset of C# applications to WasmGC but the mismatch with the language as it's existed for a long time is painful.

Like I wrote, references could be managed with shims (basically a getter-setter interface per-referenced-value-type that's then implemented per-target type) and yes it'd be a painfully "expensive" variation, but for 90% of the cases those can probably be rewritten by a compiler to an inlined variation without those performance penalties.

My argument is that, code that goes on the web-side mostly would adhere to the subset, many of the ref-cases can be statically compiled away and what remains is infrequent enough that for most users it'll be a major win compared to avoid lugging along the GC,etc.

On gc:

> Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of struct and array types, plus unboxed tagged integers, whose allocation and lifetime is then handled by Wasm.

There's already a lot misunderstandings about wasm, and I fear that people will just go "It supports GC, so we can just export python/java/c#/go etc."

This is not a silver bullet. Cpp, or rust are probably still going to be the way to go.

Relying on the GC features of WASM will require writing code centered around the abstractions for the compiler that generates WASM.

I thought that the purpose of GC in WASM was to allow such higher level languages to be placed there without a bulky runtime also in WASM.

What's the value proposition of WASM GC if not this?

As I understand it, WASM GC provides a number of low level primitives that are managed by the WASM host runtime, which would theoretically allow languages like Go or Python to slim down how much of their own language runtime needs to be packaged into the WASM module.

But how those languages still need to carry around some runtime of their own, and I don't think it's obvious how much a given language will benefit.

Programming languages with type erasure would have no runtime, just raw program code and the WASM GC. Languages that have runtime types still need a runtime for that functionality.

>But how those languages still need to carry around some runtime of their own

Also just there will be a special version of those language runtimes which probably won't be supported in 10 years time. Just like a lot of languages no longer have up to date versions that can run on the common language runtime.

The Kotlin wasm compiler was basically engineered on top of wasm's GC support. Works fairly OK. As far as I understand it's essentially the same garbage collector that is also used for regular javascript.

> This is not a silver bullet. Cpp, or rust are probably still going to be the way to go.

I don't think that's necessarily true anymore. But as you say, it depends on the compiler you use and how well it utilizes what is there. Jetbrains has big plans with Kotlin and Wasm with e.g. compose multiplatform already supporting it (in addition to IOS native and Android).

Dart is in a more advanced state in that front.

This isn’t true at all in Dart for example which is a WASM-GC language. Literally one of the very main selling points of Dart is you write your code once and it runs anywhere, WASM is just another compile target like x64 or RISC-V or iOS.

Wasm-GC are abstractions for compiler writers to enable GC dependent languages to run without shipping a GC to run inside the already GC'd browser/Wasm heap and instead just use the browser GC directly.

So yes, Java,C#,etc will work better (If you look at the horrible mess the current C# WASM export generates it basically ships with an inner platform containing a GC), and no, it will explicitly not speak with "javascript" objects (you can keep references to JS objects, but you cannot call JS methods directly).

C# cannot be compiled to WASM GC yet: https://github.com/WebAssembly/gc/issues/77.

The two main benefits of wasm GC are that compilers can avoid implementing or compiling a full GC but also that the guest and the host can share structured data types

That was the hope but unfortunately the browser can't do anything with WASM GC structs, not even read them!

Is there a technical reason for the web limit to be 16 GB specifically? Or is it just a round number picked so that the limit could be standardized? Also, has the limit on JS heap size (and ArrayBuffer size) also been relaxed to 16 GB or is it still lower?

Still no mention of DOM.

See you all for WASM 4.0.

That old thing again ;)

Direct DOM access doesn't make any sense as a WASM feature.

It would be at best a web-browser feature which browser vendors need to implement outside of WASM (by defining a standardized C-API which maps to the DOM JS API and exposing that C API directly to WASM via the function import table - but that idea is exactly as horrible in practice as it sounds in theory).

If you need to manipulate the DOM - just do that in JS, calling from WASM into JS is cheap, and JS is surprisingly fast too. Just make sure that the JS code has enough 'meat', e.g. don't call accross the WASM/JS boundary for every single DOM method call or property change. While the call itself is fast, the string conversion from the source language specific string representation on the WASM heap into JS strings and back is not free (getting rid of this string marshalling would be the only theoretical advantage of a 'native' WASM DOM API).

> If you need to manipulate the DOM - just do that in JS, calling from WASM into JS is cheap, and JS is surprisingly fast too.

From the point of view of someone who doesn't do web development at all, and to whom JS seems entirely cryptic: This argument is weird. Why is this specific (seemingly extremely useful!) "web thing" guarded by a specific language? Why would something with the generality and wide scope of WASM relegate that specific useful thing to a particular language? A language that, in the context of what WASM wants to do in making the web "just another platform", is pretty niche (for any non-web-person)?

For me, as a non-web-person, the big allure of WASM is the browser as "just another platform". The one web-specific thing that seems sensible to keep is the DOM. But if manipulating that requires learning web-specific languages, then so be it, I'll just grab a canvas and paint everything myself. I think we give up something if we start going that route.

Think of it as traditional FFI (foreign function interface) situation.

Many important libraries have been written in C and only come with a C API. To use those libraries in non-C languages (such as Java) you need a mechanism to call from Java into C APIs, and most non-C language have that feature (e.g. for Java this was called JNI but has now been replaced by this: https://docs.oracle.com/en/java/javase/21/core/foreign-funct...), e.g. C APIs are a sort of lingua franca of the computing world.

The DOM is the same thing as those C libraries, an important library that's only available with an API for a single language, but this language is Javascript instead of C.

To use such a JS library API from a non-JS language you need an FFI mechanism quite similar to the C FFI that's been implemented in most native programming languages. Being able to call efficiently back and forth between WASM and JS is this FFI feature, but you need some minimal JS glue code for marshalling complex arguments between the WASM and JS side (but you also need to do that in native scenarios, for instance you can't directly pass a Java string into a C API).

The practical argument is that while initially the DOM API was developed to be language agnostic with more of an eye to Java/C++ than JavaScript since a while ago this is no longer the case and many web APIs use JavaScript data types and interfaces (eg async iterators) that do not map well to wasm

The good news is that you can use very minimal glue code with just a few functions to do most JavaScript operations

WASM is an abbreviation for WebAssembly. If it doesn't have DOM access, WebAssembly is as related to the Web as JavaScript is to Java. A language ecosystem with no I/O capability is as much use as a one-legged man at an arse-kicking party.

Webgl can't access the dom either

Well, arguably the worst thing about WASM is the naming.

It's neither directly related to the web, nor is it an assembly syntax.

It's just another virtual ISA. "Direct DOM access for WASM" makes about as much sense as "direct C++ stdlib access for the x86 instruction set" - none ;)

WASM is to webbrowsers what WebGPU is to webbrowsers. Designed with browsers in mind, but not bound to them.

Like C, which offloads IO to the standard library?

Isn’t the whole reason why people want DOM access is so that the JavaScript side doesn’t have any meat to it and they can write their entire web app in Rust/Go/Swift/etc compiled to webasm without performance concerns?

Spoiler: there will be performance concerns.

The bottleneck is in the DOM operations themselves, not javascript. This is the reason virtual-dom approaches exist: it is faster to operate on an intermediate representation in JS than the DOM itself, where even reading an attribute might be costly.

> Direct DOM access doesn't make any sense as a WASM feature.

I disagree. The idea of doing DOM manipulation in a language that is not Javascript was *the main reason* I was ever excited about WASM.

> Direct DOM access doesn't make any sense as a WASM feature.

…proceeds to explain why it does make sense…

WASM is a toy solution to an uninteresting problem without DOM access. It will continue to be a footnote until the. Maintainers get that through their fucking skulls.

Wasm doesn't specify any I/O facilities at all. DOM is no different. There's a strict host/guest boundary and anything interacting with the outside world enters Wasm through an import granted by the host. On the web, the host is the JS runtime.

Wasm 3.0, with its GC and exception support, contains everything you need. The rest is up to the source language to deal with. For example, in Scala.js [1], which is mentioned in the article, you can use the full extent of JavaScript interop to call DOM methods right from inside your Scala code. The compiler does the rest, transparently bridging what needs to be.

[1] https://www.scala-js.org/doc/project/webassembly.html

Don't sleep on the Rust toolchain for this! You can have DOM-via-Wasm today, the tools generate all the glue for you and the overhead isn't that bad, either.

Yep and with better raw DOM performance than React:

https://leptos.dev/

https://krausest.github.io/js-framework-benchmark/current.ht...

Got a rec? The reply to you is talking about a component framework, rather than actual vanilla html/css access. I haven't seen anything, personally, that allows real-time, direct DOM interaction.

https://github.com/wasm-bindgen/wasm-bindgen is the tool for raw access to the DOM APIs.

https://danfabulich.medium.com/webassembly-wont-get-direct-d...

DOM wouldn't be part of WASM, it'd be part of the host.

If there ever is a WASM-native DOM API, WASM GC should help a lot with that.

End-users DON'T want developers' apps running in the browser to have freedom to access everything on the end-users' machines. Not having direct dom access is a security feature, as much as an MMU is. Please don't ask for this.

Wasm is sandboxed at pretty much the same security boundary as js there is nothing a DOM-enabled wasm module could do (security/privacy wise) that JavaScript can't already do

Except avoid supply chain attacks by not having the shittiest package management system in the current era.

I wish the same mate, Please wasm team, I am more than happy waiting 3 years if you can guarantee that you are looking into the best way possible into integrating this feature of dom manipulation.

I sometimes feel like js is too magic-y, I want plain boring golang and want to write some dom functions without using htmx preferably.

Please give us more freedom! This might be the most requested feature and this was how I came across knowing wasm in the first place (leptos video from some youtuber I think, sorry if i forgot)

I was even trying to be charitable and read the feature list for elements that would thin down a third party DOM access layer, but other than the string changes I’m just not seeing it. That’s not enough forward progress.

WASM is just an extremely expensive toy for browsers until it supports DOM access.

It's a chicken egg situation. The people already using WASM either don't care about the DOM or had realized long ago that going through a JS shim works just as well, the rest just complain time and time again that WASM has no DOM access whenever there's a HN thread about WASM, but usually don't even use WASM for anything.

My old team shipped a web port of our 3D modeling software back in 2017. The entire engine is the same as the desktop app, written in C++, and compiled to wasm.

Wasm is not now and will never be a magic "press here to replace JS with a new language" button. But it works really well for bringing systems software into a web environment.

The three main camps of wasm use cases are ( in no particular order )

1. Non browser application (lightweight cloud, plugins, sandboxing)

2. Performance kernels (like compiling a game/rendering engine or AI stuff)

3. Compiling js-like applications from other languages (eg blazor wasm and others)

The only case where DOM access would be useful is 3 and even there 90% of the gains are already available from the JS-strings proposal to avoid copying+reencoding.

Direct DOM access is otherwise mostly a red herring

It's explicitly negated from the Wasm-GC spec, too damn much security issue surface that keeps all of the browser makers solidly in the "do not want to touch" camp.

If you give WASM access to everything, you've defeated the main reason it exists. Ambient authority is the reason we need WASM in the first place.

For server applications true, but the reason browsers made wasm was because they needed a safer/portable/standardizable alternative to PNaCl

Does WASM still have 64 KiB pages? I get why for desktops, but there are use-cases for running WASM on microcontrollers where that's either inconvenient or outright impossible.

The one in particular I have in mind would be to put WASM on graphical calculators, in order to have a more secure alternative to the ASM programs (it's possible nowadays to write in higher-level languages, but the term stuck) that could work across manufacturers. Mid-range has RAM on the order of 256 KiB, but a 32-bit core clocked at more than 200 MHz, so there's plenty of CPU throughput but not a lot of memory to work with.

Sadly, the closest thing there is for that is MicroPython. It's good for what it does, but its performance and capabilities are nowhere near native.

https://github.com/WebAssembly/custom-page-sizes is a proposal championed by my colleague to add single byte granularity to Wasm page sizes, motivated by embedded systems and many other use cases where 64kb is excessive. It is implemented in wasmtime, and a Firefox implementation is in progress.

> Allow Wasm to better target resource-constrained embedded environments, including those with less than 64 KiB memory available.

If it has less than 64 kB of memory how is it going to run a WASM runtime anyway?

And even cheap microcontrollers tend to have more than 64 kB of memory these days. Doesn't not seem remotely worth the complexity.

It's not about the whole microcontroller having less than 64kB of memory - it's that each WASM module has a minimum memory size of 64kB, regardless of how much it actually requires. Also, if you need 65kB of memory, you now have to reserve 2 pages, meaning your app now needs 128kB of memory!

We're working on WASM for embedded over at atym.io if you're interested.

> If it has less than 64 kB of memory how is it going to run a WASM runtime anyway?

There is WARDuino (https://github.com/TOPLLab/WARDuino and https://dl.acm.org/doi/10.1145/3357390.3361029).

A runtime that accepts Wasm modules that use a large fraction of the functionality, there is going to be a RAM requirement in the few KiB to few tens of KiB. There seems to be a branch or fork of Wasm3 for Arduino (https://github.com/wasm3/wasm3-arduino).

If you are willing to do, e.g. Wasm -> AVR AOT compilation, then the runtime can be quite small. That basically implies that compilation does not happen on device, but at deployment time.

> in order to have a more secure alternative to the ASM programs

What security implications are there in graphical calculators in terms of assembler language?

Exam mode, or test mode. It's something that appeared about ten years ago, to ensure that a graphical calculator isn't loaded with cheats or has certain features enabled. The technical reason is that the RESET button no longer clears all of the calculator's memory (think Flash, not RAM) and proctors like to see a flashing LED that tells them everything's fine.

It's a flawed idea and has led to an arms race, where manufacturers lock down their models and jailbreaks break them open. Even NumWorks, who originally had a calculator that was completely unprotected and used to publish all of their source code on GitHub, had to give in and introduce a proprietary kernel and code signing, in order to stop custom firmwares and applications from accessing the LED and stop countries from outlawing their calculators.

Sad state of affairs. I had no idea this was a thing.

Are the cases tamper proof as well? Because it's not like it's hard to open up a calculator and connect the LED somewhere else..

Why WASM and not, like, java or something?

As in, Java ME?

Unless I'm mistaken, it's been on life support for the past 15 years. It's probably more heavyweight and firmware size/Flash usage is a concern. I don't think performance would be on par with WASM and there are use-cases where that really matters (ray tracing rendering for example). I'm also not sure there are many maintained, open-source implementations for it out there. I've also heard stories that it was quite a mess in practice because it was plagued by bugs and quirks specific to phone models, despite the fact that it was supposed to be a standard.

I'd gladly be proven wrong, but I don't think Java ME has a bright future. Unless you were thinking of something else?

Custom Page Size didn't make it. It's useful for running WASM on microcontrollers where 64k of minimum RAM isn't feasible. Oh well, next time.

https://github.com/WebAssembly/custom-page-sizes/blob/main/p...

Is the component model work (https://component-model.bytecodealliance.org/) related to the 3.0 release in any way?

No, the component model proposal is not part of the Wasm 3.0 release. Proposals only make it into a Wasm point release once they reach stage 5, and the component model is still under development and so is not trying to move through the phases yet.

Unlike any of the proposals which became part of Wasm 3.0, the component model does not make any changes to the core Wasm module encoding or its semantics. Instead, it’s designed as a new encoding container which contain core Wasm modules, and adds extra information alongside each module describing its interface types and how to instantiate and link those modules. By keeping all of these additions outside of core Wasm, we can build implementations out of any plain old Wasm engine, plus extra code that instantiates and links those modules, and converts between the core wasm ABI to higher level interface types. The Jco project https://github.com/bytecodealliance/jco does exactly that using the common JS interface used by every web engine’s Wasm implementation. So, we can ship the component model on the web without web engines putting in any work of their own, which isn’t possible with proposals which add or change core wasm.

Thanks for clarifying.

Has anyone benchmarked 64bit memory on the current implementations? There's the potential for performance regressions there because they could exploit the larger address space of 64bit hosts to completely elide bounds checks when running 32bit WASM code, but that doesn't work if the WASM address space is also 64bit.

> WebAssembly apps tend to run slower in 64-bit mode than they do in 32-bit mode. This performance penalty depends on the workload, but it can range from just 10% to over 100%—a 2x slowdown just from changing your pointer size.

> This is not simply due to a lack of optimization. Instead, the performance of Memory64 is restricted by hardware, operating systems, and the design of WebAssembly itself.

https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...

Oof, that's unfortunate. I'm sure there's good reasons why WASM works like it does but the requirement for OOB to immediately abort the program seems rough for performance, as opposed to letting implementations handle it silently without branching (e.g. by masking the high bits of pointers so OOB wraps around).

Is this WASM specific though? Some apps suffer in performance when they move to 64-bit in general due to larger pointers and not taking sufficient advantage of/or needing 64-bit data types in general, hence the increased memory bandwidth/cache space slows them down (one of the reasons many people like a 32-bit address space, 64-bit data model).

The blog post explains that it's more than that. Bounds checking, in particular, costs more for reasons having to do with browser implementations, for example, rather than for architectural reasons.

This looks like a great release! Lots of stuff people have wanted for a long time in here.

Tail calls. Tail calls!

The tail call instructions (return_call and friends) were crucial for compiling Scheme. Safari had a bug in their validator for these instructions but the fix shipped in their most recent release so now you can use Wasm tail calls to their fullest in all major browsers.

Folks here might be interested in WebAssembly from the Ground Up (https://wasmgroundup.com) — an online book to learn Wasm by building a simple compiler in JavaScript. (Disclaimer: I'm one of the authors.)

So far the book only covers WebAssembly 1.0 though. We'll likely publish an update to cover the (few) new features in 2.0, but WebAssembly 3.0 is a pretty big update. Garbage collection and typed references especially add quite a lot to the spec. But, they also make a lot more things possible, which is great.

The spec itself is also very readable and accessible. Everything in the spec that's described formally is also described in plain language. I can't think of any other spec that's quite as nice to read.

Support for garbage collection is really nice to see. Previously, it’s been very difficult to do garbage collection in WASM because you don’t have direct access to the stack, so traditional approaches like stack scanning haven’t been feasible.

One bright point here is that the WASM changes may force v8 to improve its IPC by having a feature that Bun gets from JSC, which is passing strings across isolate boundaries.

IPC overhead is so bad in NodeJS that most people don’t talk about it because the workarounds are just impossibly high maintenance. We reach straight for RPC instead, and downplay the stupidity of the entire situation. Kind of reminiscent of the Ruby community, which is perhaps not surprising given the pedigree of so many important node modules (written by ex Rails devs).

I've never used WASM so apologies in advance but for

>Typed references. The GC extension is built upon a substantial extension to the Wasm type system, which now supports much richer forms of references. Reference types can now describe the exact shape of the referenced heap value, avoiding additional runtime checks that would otherwise be needed to ensure safety.

Why is an assembly-like dialect interacting with concepts that are at a much higher level than it?

To WASM isn't it all just pointers in a big heap like every other assembly?

IIRC initially this was proposed so the runtime (i.e. the browser) could expose its APIs directly to wasm code, without the need for JS wrappers.

Many users demand DOM access but how about starting with browser(js) access to wasm gc objects? I understand that storing the whole thing might interfere with GC, but just reading a property? If I define a well structured struct in wasm I should be able to read it from the host without creating a special read_my_object_xyz_property_abc() glue function, no?

My dream is we get pluggable execution runtimes (wasm, jvm, , LLVM IR?) with pluggable display tech (svg, html, opengl) and each tech JITs itself on your platform.

While we do need a default “text mode” (html), js is not the answer to a common language and is holding everything back.

I'm both excited and terribly disappointed.

I feel like webdev ecosystem after the fall of Flash took a wrong turn and missed a huge opportunity. For whatever reason people opted for both sticking with JS and backward compatibility. I can clearly see an alternative universe where you have a browser that accepts both a <script> with JS and another, modern language, and it's up to the developer to chose if he wants to transpile/recompile the code for backward compatibility or go all in for new features.

I mean Typescript is cool, but it's reinventing the wheel, we already had that with ES4 over 15 years ago and WASM is still a second class citizen for hackers.

This. And it feels so frustrating, people keep defending w3c... I'm feeling let down by specs that instead of giving me a graphic, accessibility and input api, tells me where I should use <article> vs <aside> or whatever useless stuff

I'm glad I'm not alone with these feeling.

I was there when Macromedia took JS as their scripting language for animating GIFs. People soon started doing silly things and everyone realized it was not fit for the task. We had AS2 which added some syntactic sugar and was the exact same thing as early Typescript - an escape hatch that allowed you to use OOP while the resulting code was still just plain old JS.

But meanwhile Macromedia worked on a whole new thing called AS3. It was codified as ES4 and it's the reason why JS had all these "private", "abstract" keywords reserved.

Heck, we even had redtamarin for running AS as console! And there was Alchemy which is grandfather of WASM.

We were that close to having a compiled JS++.

But times were different, we were still in the middle of browser wars, and the standard was eventually scrapped because noone was interested in JS at the time.

And then Apple decided to kill Flash.

And for some reason the community decided to burn the library of Alexandria and spend the next 10 years on reinventing the wheel.

Sure, V8 is a world wonder, no question about it, the fact that JS can run that fast is just amazing. And people finally wrapped their head around TS and realized that types are useful. Wonderful. But I really think that we've lost 10 years running in circle and producing smart looking docs while tech is slowly getting back where it was 15 years ago.

It strikes me that V8's purpose is to dominate in a world with a terrible spec, much like Microsoft deal with its own office files, or how some industries suppress competition via regulatory capture. The intention might not have started out this way, but Google has no incentive to invite any technology that could loosen its dominance.

> 64-bit address space. Memories and tables can now be declared to use i64 as their address type instead of just i32.

Could be nitpicking but in the PDF (https://webassembly.github.io/spec/core/_download/WebAssembl...), there's a passage that says:

> 32-bit integers also serve as Booleans and as memory addresses. (under 1.2.1 Concepts)

While 64-bit is not mentioned. Could it be an oversight or I understood it wrong?

I'd really like browser vendors exposing to wasm a graphics api, input and accessibility. So we can skip the dom and start making actual apps

Oh no, right after I started writing a binary decoder for 2.0. Does anybody know how much this changes things as far as a decoder is concerned?

Wasm only gets additive changes - the binary format can't change in a way that breaks any previously existing programs, because that would break the Web. So, you just have to add more opcodes to your implementation.

Awesome, thanks!

It introduces new types (structs and arrays), a new section for tags, and several dozen instructions (first-class functions, GC, tail calls, and exception handling). It generalizes to multiple memories and tables, as well as adding 64-bit memories. The binary format changes aren't too bad, but it's a fairly big semantic addition.

Does anyone know whether the exception handling implementation supports restartable exceptions like Common Lisp's and Scheme's?

Speaking for CL, it seems so for me.

The whole magic about CL's condition system is to keep on executing code in the context of a given condition instead of immediately unwinding the stack, and this can be done if you control code generation.

Everything else necessary, including dynamic variables, can be implemented on top of a sane enough language with dynamic memory management - see https://github.com/phoe/cafe-latte for a whole condition system implemented in Java. You could probably reimplement a lot of this in WASM, which now has a unwind-to-this-location primitive.

Also see https://raw.githubusercontent.com/phoe-trash/meetings/master... for an earlier presentation of mine on the topic. "We need means of unwinding and «finally» blocks" is the key here.

Scheme doesn't have restarts as a core concept like Common Lisp, but it does have continuations. For the Scheme implementation I worked on [0], the exception system is built on top of the continuation system. In other words, Scheme exceptions are not Wasm exceptions. However, we did find a use for Wasm exceptions in the implementation of the runtime. We realized it would be useful to mark the entry point into Scheme with a Wasm 'try' block for re-entrancy reasons. Programs might call from Scheme to JS back to Scheme and on and on. When we suspend the current continuation we throw a Wasm exception and find the correct entry point for doing our stack tomfoolery, re-throwing until we find it. I don't know if my explanation makes any sense but that's how we're using Wasm exceptions.

[0] https://spritely.institute/hoot/

No, that functionality would fall under the stack-switching proposal, which builds on the tags of Wasm exception handling.

This looks like a huge release for C# and Java I guess. Half of the features are useful elements they no longer have to polyfill.

Are there any languages which actually support these modern features? e.g. better exception handling, 64bit, tail calls etc. Seems they are all way behind?

These features look compelling. When will they all be available in mainstream browsers?

64-bit addr space and deterministic profiles ftw!

Really nice new set of features.

Do WASM apps have now direct access to DOM?

Kinda off-topic but do you see any value in a (rust) library that does only the binary decoding part + validation?

Having wasm 3.0 and a project named wasm3 which doesn't seem to support wasm 3.0 is sure going to get confusing!

This is so exciting! Been waiting for this for years, very interested to see what people can do with this

Great work. WASM will eat the world :D.

Why exceptions were difficult without the builtin support? Sttange to hear that.

Can QuickJS run in WASM3.0 with deterministic profile?

That would be pretty rad!

Anyone know a language that compiles to WASM v3?

What cool new features could this enable in Pyodide?

Doesn't look like they took anything out.

What do we need it for?

But looks like you still cannot open a raw TCP or UDP socket? Who needs this internet network thing huh?

I appreciate it is a potential security hole, but at least make it behind a flag or something so it can be turned on.

Opening a socket would fall under WASI[1].

[1] https://github.com/WebAssembly/wasi-sockets

> GC and Exception handling

This was not necessary.. what a mistake, specially EH..

Not including GC would have been a mistake. Having to carry a complete garbage collector with every program, especially on platforms like browsers were excellent ones already exist, would have been a waste.

It's also important because sometimes you want a WebAssembly instance to hold a reference to a GC object from Javascript, such as a DOM object, or be able to return a similar GC object back to Javascript or to another separate WebAssembly instance. Doing the first part alone is easy to do with a little bit of JS code (make the JS code hold a reference to the GC object, give the Wasm an id that corresponds to it, and let the Wasm import some custom JS functions that can operate on that id), but it's not composable in a way that lets the rest of those tasks work in a general way.

Doesn't every WASM program have to carry its own malloc/free today?

how is that different from compiling against a traditional CPU which also doesn't have a built in GC? i mean those programs that need a GC already have one. so what is the benefit of including one on the "CPU"?

It's kinda nice to have 1st class exception support. C++ exceptions barely work in Emscripten right now. Part of the problem is that you can't branch to arbitrary labels in WASM.

I think it's a "you don't pay for it if you don't use it" thing, so I guess it's fine. It won't affect me compiling my C or Zig code to WASM for instance since those languages have neither garbage collection nor exceptions.

WASM isn't a language, so them adding stuff like this serves to increase performance and standardize rather than forcing compilers to emulate common functionality.

This allows more languages to compile to it. You don't need to use these features if you don't want to.

Besides making it much nicer for GC'd languages to target WASM, an important aspect is that it also allows cross-language GC.

Whereas with a manual GC, if you had a JS object holding a reference to an object on your custom heap, and your heap holds a reference to that JS object (with indirections sprinkled in to taste) but nothing else references it, that'd result in a permanent memory leak, as both heaps would have to consider everything held by the other as GC roots; so you'd still be forced to manually avoid cycles despite only ever using GC'd languages. Wasm GC entirely avoids this problem.

steve job's ghost will prevent wasm adoption.

> steve job's ghost will prevent wasm adoption.

https://webassembly.org/features/

That isn't updated for Safari 26, but by that table Safari 18 is only missing 3 standardized features that Chrome supports, with a fourth that is disabled by default. So what's the point of your comment? Just to make noise and express your ignorance?

What ignorance? Safari doesn't support the most important additions:

- memory64

- multiple memories

- JSPI (!!)

I recently explored the possibility of optimizing qemu-wasm in browser[0].. and it turns out that the most important features were those Safari doesn't implement.

[0] https://zb3.me/qemu-wasm-test/

Historically speaking, apple has consistently limited web app functionality on iOS since 2008. I think we would be much further ahead if it wasn't for Apple’s policies under his leadership.

Apple took over the distribution to prioritize a cut to the app store which crippled/slowed the open web PWA and WASM adoption.

There's a joke in Brazil saying "Brazil is the country of the future and will always be that. It will never be the country of the present".

WASM is and will always be the greatest technology of the future. It will never be the greatest technology of the present.

WASM enables some pretty cool apps in the present, though. I think Figma heads the list.

We use it heavily here at Ditto. It's fantastic.

Wasm is one of the best solutions for running untrusted code. Alternative are more complicated or have limited language choices.

Reply on news.ycombinator.com