12 ms·

WASM 3.0 Completed

1086 points by todsacerdoti 1y ago

jsheard 1y ago
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.
- kg 1y ago
  > 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-actually-worth-using.html https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
  - jsheard 1y ago
    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).
  - nu11ptr 1y ago
    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).
    - aag 1y ago
      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.
steveklabnik 1y ago
This looks like a great release! Lots of stuff people have wanted for a long time in here.
- leoc 1y ago
  Tail calls. Tail calls!
  - davexunit 1y ago
    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.
j0e1 1y ago
> 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!
- baxuz 1y ago
  Does this allow for shrinking the WebAssembly.Memory object? - https://github.com/WebAssembly/design/issues/1397 https://github.com/WebAssembly/design/issues/1397 - https://github.com/WebAssembly/memory-control/issues/6 https://github.com/WebAssembly/memory-control/issues/6 This is a crucial issue, as the released memory is still allocated by the browser.
  - azakai 1y ago
    Wasm GC is entirely separate from Wasm Memory objects, so no, this does not help linear memory applications.
  - kannanvijayan 1y ago
    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.
- teleforce 1y ago
  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 https://wiki.dlang.org/Generating_WebAssembly_with_LDC
WhereIsTheTruth 1y ago
> GC and Exception handling This was not necessary.. what a mistake, specially EH..
- aag 1y ago
  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.
  - ridiculous_fish 1y ago
    Doesn't every WASM program have to carry its own malloc/free today?
    - phickey 1y ago
      Yes, every wasm program that uses linear memory (which includes all those created by llvm toolchains) must ship with its own allocator. You only get to use the wasm GC provided allocator if your program is using the gc types, which can’t be stored in a linear memory.
    - flohofwoe 1y ago
      Yes, but Emscripten comes with a minimal allocator that's good enough for most C code (e.g. code with low alloc/free frequency) and only adds minimal size overhead: https://github.com/emscripten-core/emscripten/blob/main/system/lib/emmalloc.c https://github.com/emscripten-core/emscripten/blob/main/syst...
  - em-bee 1y ago
    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"?
    - aag 1y ago
aag 1y ago
Does anyone know whether the exception handling implementation supports restartable exceptions like Common Lisp's and Scheme's?
- phoe-krk 1y ago
  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 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/stack/2020/presentations/2020-11-30-herda-control-flow-in-common-lisp.pdf 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.
- titzer 1y ago
  No, that functionality would fall under the stack-switching proposal, which builds on the tags of Wasm exception handling.
- davexunit 1y ago
  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/ https://spritely.institute/hoot/
jjcm 1y ago
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.
- deleted 1y ago
  [deleted]
- renehsz 1y ago
  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.
  - jsheard 1y ago
    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.
    - baq 1y ago
      didn't we call it 'segmented memory' back in DOS days...?
      - munificent 1y ago
        We call it "pointer compression" now. :)
        mananaysiempre 1y ago
        Seriously though, I’ve been wondering for a while whether I could build a GCC for x86-64 that would have 32-bit (low 4G) pointers (and no REX prefixes) by default and full 64-bit ones with __far or something. (In this episode of Everything Old Is New Again: the Very Large Memory API[1] from Windows NT for Alpha.) [1] https://devblogs.microsoft.com/oldnewthing/20070801-00/?p=25763 https://devblogs.microsoft.com/oldnewthing/20070801-00/?p=25...
modeless 1y ago
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?
- deleted 1y ago
  [deleted]
pbiswal 1y ago
Is the component model work (https://component-model.bytecodealliance.org/ https://component-model.bytecodealliance.org/) related to the 3.0 release in any way?
- phickey 1y ago
  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 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.
  - pbiswal 1y ago
    Thanks for clarifying.
spankalee 1y ago
I really hope this spurs AssemblyScript to just port to WASM GC: https://github.com/AssemblyScript/assemblyscript/issues/2808 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.
preommr 1y ago
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.
- john01dav 1y ago
  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?
  - TUSF 1y ago
    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.
    - discreteevent 1y ago
      >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.
    - naasking 1y ago
      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.
boricj 1y ago
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.
- MangoToupe 1y ago
  Why WASM and not, like, java or something?
  - boricj 1y ago
    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?
    - MangoToupe 1y ago
      I wasn't thinking of a particular implementation so much as a VM in the abstract. So Java ME failed (I don't know much about it)—but I just didn't even think performance would matter much for a graphing calculator with how cheap hardware is. Those things must be almost entirely profit margin these days. Do kids even use them any more for school?
- 1y ago
moralestapia 1y ago
Great work. WASM will eat the world :D.
flohofwoe 1y ago
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...
- whizzter 1y ago
  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..
  - flohofwoe 1y ago
    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.
  - dontlaugh 1y ago
    "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.
- titzer 1y ago
  There has been a discussion (https://github.com/WebAssembly/multi-memory/issues/45 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.
hinkley 1y ago
Still no mention of DOM. <sets alarm for three years from now> See you all for WASM 4.0.
- 0xfffafaCrash 1y ago
  https://danfabulich.medium.com/webassembly-wont-get-direct-dom-support-any-time-soon-a3e0ea04c688 https://danfabulich.medium.com/webassembly-wont-get-direct-d...
- Imustaskforhelp 1y ago
  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)
  - hinkley 1y ago
    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.
    - flohofwoe 1y ago
      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.
      - lyu07282 1y ago
unaut 1y ago
64-bit addr space and deterministic profiles ftw! Really nice new set of features.
endorphine 1y ago
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?
- phickey 1y ago
  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.
  - endorphine 1y ago
    Awesome, thanks!
- titzer 1y ago
  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.
diego_moita 1y ago
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.
- TimTheTinker 1y ago
  WASM enables some pretty cool apps in the present, though. I think Figma heads the list.
  - stusmall 1y ago
    We use it heavily here at Ditto. It's fantastic.
- themerone 1y ago
  Wasm is one of the best solutions for running untrusted code. Alternative are more complicated or have limited language choices.
oaiey 1y ago
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.
jasonthorsness 1y ago
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 https://github.com/WebAssembly/gc/issues/77 I wonder what language this GC can actually be used for at this stage?
- outadoc 1y ago
  Kotlin/WASM is a thing
- markdog12 1y ago
  Dart for a long time now.
- programLyrique 1y ago
  OCaml with wasocaml: https://github.com/OCamlPro/wasocaml https://github.com/OCamlPro/wasocaml
- davexunit 1y ago
  The article answers your question, there are at least 6 languages: Java, OCaml, Scala, Kotlin, Scheme, and Dart.
- whizzter 1y ago
  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.
bborud 1y ago
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.
- zdandoh 1y ago
  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.
- mixedCase 1y ago
  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.
- afiori 1y ago
  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
- fidotron 1y ago
  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.
hinkley 1y ago
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).
deleted 1y ago
[deleted]
quix0t3 1y ago
steve job's ghost will prevent wasm adoption.
- Jtsummers 1y ago
  > steve job's ghost will prevent wasm adoption. https://webassembly.org/features/ 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?
  - quix0t3 1y ago
    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.
    - whizzter 1y ago
      Sure, and that's why Asm.JS(regular JS with special semantics) and later Wasm(bytecode translateable to JS) was so brilliant. It already worked on Safari, they had the option of either: A: look slow compared to other engines that supported it B: implement it Now, stuff like the exception handling stuff and tail calls probably aren't shimmable via JS, but at this point they don't gain much from being obstructionists.
  - zb3 1y ago
    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/ https://zb3.me/qemu-wasm-test/
    - 1y ago
re 1y ago
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/ https://webassembly.org/features/ [2] https://webassembly.org/news/2025-03-20-wasm-2.0/ https://webassembly.org/news/2025-03-20-wasm-2.0/ [3] https://www.w3.org/TR/wasm-core-2/ https://www.w3.org/TR/wasm-core-2/
- titzer 1y ago
  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.
- afiori 1y ago
  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
- cfallin 1y ago
  > 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)
jamesu 1y ago
Having wasm 3.0 and a project named wasm3 which doesn't seem to support wasm 3.0 is sure going to get confusing!
denis_dolya 1y ago
[flagged]
phkahler 1y ago
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/ https://cad.apps.dgramop.xyz/ Open source CAD in the browser.
- atroche 1y ago
  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?
  - phkahler 1y ago
    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...
    - threeducks 1y ago
      > Just might not be able to save... Oops, I did not read that before going ham in the editor. It seems that the files are stored inside the emscripten file system, so they are not lost. I could download my exported 'test.stl' with the following JavaScript code: var data = FS.readFile('test.stl'); var blob = new Blob([data], { type: 'application/octet-stream' }); var a = document.createElement('a'); a.href = URL.createObjectURL(blob); a.download = 'test.stl'; a.click();
      - phkahler 1y ago
        PRs are welcome. ;-)
  - phkahler 1y ago
    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.
alabhyajindal 1y ago
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 https://git.sr.ht/~alabhyajindal/jasmine
- sestep 1y ago
  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.
  - alabhyajindal 1y ago
    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.
    - sestep 1y ago
      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.
- titzer 1y ago
  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.
mattlondon 1y ago
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.
- grayrest 1y ago
  Opening a socket would fall under WASI[1]. [1] https://github.com/WebAssembly/wasi-sockets https://github.com/WebAssembly/wasi-sockets
mistahchris 1y ago
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!
alphazard 1y ago
Doesn't look like they took anything out.
k__ 1y ago
Can QuickJS run in WASM3.0 with deterministic profile? That would be pretty rad!
cedws 1y ago
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?
- ygouzerh 1y ago
  From what I understand, WASM is purely functional, to perform side effects, you will need a runtime like WASI to implement it
- DarkNova6 1y ago
  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.
  - thrance 1y ago
    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.
    - DarkNova6 1y ago
      Sounds like something that could be trivially turned into a library, no?
      - thrance 1y ago
        There are some already (https://docs.rs/web-sys/latest/web_sys https://docs.rs/web-sys/latest/web_sys, for example), and I made mine too as an exercise. But it's still ugly, unecessary, verbose and inefficient code.
- icar 1y ago
  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.
unit149 1y ago
[dead]
Dabbling_Dion 1y ago
[dead]
jadenPete 1y ago
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.
__grob 1y ago
This is so exciting! Been waiting for this for years, very interested to see what people can do with this
nirui 1y ago
> 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/WebAssembly.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?
pveierland 1y ago
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/ https://webassembly.org/news/2025-03-27-spectec/
deleted 1y ago
[deleted]
endorphine 1y ago
Kinda off-topic but do you see any value in a (rust) library that does only the binary decoding part + validation?
haberman 1y ago
These features look compelling. When will they all be available in mainstream browsers?
nairboon 1y ago
What cool new features could this enable in Pyodide?
DeathArrow 1y ago
Do WASM apps have now direct access to DOM?
exabrial 1y ago
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.
roschdal 1y ago
What do we need it for?
zeroq 1y ago
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.
- hollowturtle 1y ago
  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
  - zeroq 1y ago
    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.
OhNoNotAgain_99 1y ago
[dead]
flowerthoughts 1y ago
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/proposals/custom-page-sizes/Overview.md https://github.com/WebAssembly/custom-page-sizes/blob/main/p...
hollowturtle 1y ago
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
pdubroy 1y ago
Folks here might be interested in WebAssembly from the Ground Up (https://wasmgroundup.com 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.
sebstefan 1y ago
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?
- grishka 1y ago
  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.
singularity2001 1y ago
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?
avodonosov 1y ago
Why exceptions were difficult without the builtin support? Sttange to hear that.
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
ferahl 1y ago
Anyone know a language that compiles to WASM v3?
ferahl 1y ago
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?

1086 points by todsacerdoti 1y ago

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.

kg 1y ago
> 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-actually-worth-using.html https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
- jsheard 1y ago
  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).
- nu11ptr 1y ago
  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).
  - aag 1y ago
    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.

steveklabnik 1y ago

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

leoc 1y ago
Tail calls. Tail calls!
- davexunit 1y ago
  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.

j0e1 1y ago

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

baxuz 1y ago
Does this allow for shrinking the WebAssembly.Memory object? - https://github.com/WebAssembly/design/issues/1397 https://github.com/WebAssembly/design/issues/1397 - https://github.com/WebAssembly/memory-control/issues/6 https://github.com/WebAssembly/memory-control/issues/6 This is a crucial issue, as the released memory is still allocated by the browser.
- azakai 1y ago
  Wasm GC is entirely separate from Wasm Memory objects, so no, this does not help linear memory applications.
- kannanvijayan 1y ago
  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.
teleforce 1y ago
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 https://wiki.dlang.org/Generating_WebAssembly_with_LDC

WhereIsTheTruth 1y ago

> GC and Exception handling This was not necessary.. what a mistake, specially EH..

aag 1y ago
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.
- ridiculous_fish 1y ago
  Doesn't every WASM program have to carry its own malloc/free today?
  - phickey 1y ago
    Yes, every wasm program that uses linear memory (which includes all those created by llvm toolchains) must ship with its own allocator. You only get to use the wasm GC provided allocator if your program is using the gc types, which can’t be stored in a linear memory.
  - flohofwoe 1y ago
    Yes, but Emscripten comes with a minimal allocator that's good enough for most C code (e.g. code with low alloc/free frequency) and only adds minimal size overhead: https://github.com/emscripten-core/emscripten/blob/main/system/lib/emmalloc.c https://github.com/emscripten-core/emscripten/blob/main/syst...
- em-bee 1y ago
  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"?
  - aag 1y ago

aag 1y ago

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

phoe-krk 1y ago
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 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/stack/2020/presentations/2020-11-30-herda-control-flow-in-common-lisp.pdf 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.
titzer 1y ago
No, that functionality would fall under the stack-switching proposal, which builds on the tags of Wasm exception handling.
davexunit 1y ago
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/ https://spritely.institute/hoot/

jjcm 1y ago

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.

deleted 1y ago
[deleted]
renehsz 1y ago
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.
- jsheard 1y ago
  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.
  - baq 1y ago
    didn't we call it 'segmented memory' back in DOS days...?
    - munificent 1y ago
      We call it "pointer compression" now. :)
      - mananaysiempre 1y ago
        Seriously though, I’ve been wondering for a while whether I could build a GCC for x86-64 that would have 32-bit (low 4G) pointers (and no REX prefixes) by default and full 64-bit ones with __far or something. (In this episode of Everything Old Is New Again: the Very Large Memory API[1] from Windows NT for Alpha.) [1] https://devblogs.microsoft.com/oldnewthing/20070801-00/?p=25763 https://devblogs.microsoft.com/oldnewthing/20070801-00/?p=25...

modeless 1y ago

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?

deleted 1y ago
[deleted]

pbiswal 1y ago

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

phickey 1y ago
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 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.
- pbiswal 1y ago
  Thanks for clarifying.

spankalee 1y ago

I really hope this spurs AssemblyScript to just port to WASM GC: https://github.com/AssemblyScript/assemblyscript/issues/2808 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.

preommr 1y ago

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.

john01dav 1y ago
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?
- TUSF 1y ago
  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.
  - discreteevent 1y ago
    >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.
  - naasking 1y ago
    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.

boricj 1y ago

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.

MangoToupe 1y ago
Why WASM and not, like, java or something?
- boricj 1y ago
  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?
  - MangoToupe 1y ago
    I wasn't thinking of a particular implementation so much as a VM in the abstract. So Java ME failed (I don't know much about it)—but I just didn't even think performance would matter much for a graphing calculator with how cheap hardware is. Those things must be almost entirely profit margin these days. Do kids even use them any more for school?
1y ago

moralestapia 1y ago

Great work. WASM will eat the world :D.

flohofwoe 1y ago

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

whizzter 1y ago
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..
- flohofwoe 1y ago
  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.
- dontlaugh 1y ago
  "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.
titzer 1y ago
There has been a discussion (https://github.com/WebAssembly/multi-memory/issues/45 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.

hinkley 1y ago

Still no mention of DOM. <sets alarm for three years from now> See you all for WASM 4.0.

0xfffafaCrash 1y ago
https://danfabulich.medium.com/webassembly-wont-get-direct-dom-support-any-time-soon-a3e0ea04c688 https://danfabulich.medium.com/webassembly-wont-get-direct-d...
Imustaskforhelp 1y ago
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)
- hinkley 1y ago
  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.
  - flohofwoe 1y ago
    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.
    - lyu07282 1y ago

unaut 1y ago

64-bit addr space and deterministic profiles ftw! Really nice new set of features.

endorphine 1y ago

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?

phickey 1y ago
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.
- endorphine 1y ago
  Awesome, thanks!
titzer 1y ago
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.

diego_moita 1y ago

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.

TimTheTinker 1y ago
WASM enables some pretty cool apps in the present, though. I think Figma heads the list.
- stusmall 1y ago
  We use it heavily here at Ditto. It's fantastic.
themerone 1y ago
Wasm is one of the best solutions for running untrusted code. Alternative are more complicated or have limited language choices.

oaiey 1y ago

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.

jasonthorsness 1y ago

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 https://github.com/WebAssembly/gc/issues/77 I wonder what language this GC can actually be used for at this stage?

outadoc 1y ago
Kotlin/WASM is a thing
markdog12 1y ago
Dart for a long time now.
programLyrique 1y ago
OCaml with wasocaml: https://github.com/OCamlPro/wasocaml https://github.com/OCamlPro/wasocaml
davexunit 1y ago
The article answers your question, there are at least 6 languages: Java, OCaml, Scala, Kotlin, Scheme, and Dart.
whizzter 1y ago
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.

bborud 1y ago

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.

zdandoh 1y ago
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.
mixedCase 1y ago
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.
afiori 1y ago
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
fidotron 1y ago
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.

hinkley 1y ago

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

deleted 1y ago

[deleted]

quix0t3 1y ago

steve job's ghost will prevent wasm adoption.

Jtsummers 1y ago
> steve job's ghost will prevent wasm adoption. https://webassembly.org/features/ 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?
- quix0t3 1y ago
  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.
  - whizzter 1y ago
    Sure, and that's why Asm.JS(regular JS with special semantics) and later Wasm(bytecode translateable to JS) was so brilliant. It already worked on Safari, they had the option of either: A: look slow compared to other engines that supported it B: implement it Now, stuff like the exception handling stuff and tail calls probably aren't shimmable via JS, but at this point they don't gain much from being obstructionists.
- zb3 1y ago
  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/ https://zb3.me/qemu-wasm-test/
  - 1y ago

re 1y ago

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/ https://webassembly.org/features/ [2] https://webassembly.org/news/2025-03-20-wasm-2.0/ https://webassembly.org/news/2025-03-20-wasm-2.0/ [3] https://www.w3.org/TR/wasm-core-2/ https://www.w3.org/TR/wasm-core-2/

titzer 1y ago
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.
afiori 1y ago
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
cfallin 1y ago
> 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)

jamesu 1y ago

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

denis_dolya 1y ago

[flagged]

phkahler 1y ago

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/ https://cad.apps.dgramop.xyz/ Open source CAD in the browser.

atroche 1y ago
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?
- phkahler 1y ago
  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...
  - threeducks 1y ago
    > Just might not be able to save... Oops, I did not read that before going ham in the editor. It seems that the files are stored inside the emscripten file system, so they are not lost. I could download my exported 'test.stl' with the following JavaScript code: var data = FS.readFile('test.stl'); var blob = new Blob([data], { type: 'application/octet-stream' }); var a = document.createElement('a'); a.href = URL.createObjectURL(blob); a.download = 'test.stl'; a.click();
    - phkahler 1y ago
      PRs are welcome. ;-)
- phkahler 1y ago
  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.

alabhyajindal 1y ago

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 https://git.sr.ht/~alabhyajindal/jasmine

sestep 1y ago
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.
- alabhyajindal 1y ago
  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.
  - sestep 1y ago
    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.
titzer 1y ago
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.

mattlondon 1y ago

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.

grayrest 1y ago
Opening a socket would fall under WASI[1]. [1] https://github.com/WebAssembly/wasi-sockets https://github.com/WebAssembly/wasi-sockets

mistahchris 1y ago

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!

alphazard 1y ago

Doesn't look like they took anything out.

k__ 1y ago

Can QuickJS run in WASM3.0 with deterministic profile? That would be pretty rad!

cedws 1y ago

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?

ygouzerh 1y ago
From what I understand, WASM is purely functional, to perform side effects, you will need a runtime like WASI to implement it
DarkNova6 1y ago
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.
- thrance 1y ago
  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.
  - DarkNova6 1y ago
    Sounds like something that could be trivially turned into a library, no?
    - thrance 1y ago
      There are some already (https://docs.rs/web-sys/latest/web_sys https://docs.rs/web-sys/latest/web_sys, for example), and I made mine too as an exercise. But it's still ugly, unecessary, verbose and inefficient code.
icar 1y ago
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.

unit149 1y ago

[dead]

Dabbling_Dion 1y ago

[dead]

jadenPete 1y ago

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.

__grob 1y ago

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

nirui 1y ago

> 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/WebAssembly.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?

pveierland 1y ago

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/ https://webassembly.org/news/2025-03-27-spectec/

deleted 1y ago

[deleted]

endorphine 1y ago

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

haberman 1y ago

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

nairboon 1y ago

What cool new features could this enable in Pyodide?

DeathArrow 1y ago

Do WASM apps have now direct access to DOM?

exabrial 1y ago

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.

roschdal 1y ago

What do we need it for?

zeroq 1y ago

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.

hollowturtle 1y ago
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
- zeroq 1y ago
  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.

OhNoNotAgain_99 1y ago

[dead]

flowerthoughts 1y ago

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/proposals/custom-page-sizes/Overview.md https://github.com/WebAssembly/custom-page-sizes/blob/main/p...

hollowturtle 1y ago

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

pdubroy 1y ago

Folks here might be interested in WebAssembly from the Ground Up (https://wasmgroundup.com 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.

sebstefan 1y ago

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?

grishka 1y ago
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.

singularity2001 1y ago

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?

avodonosov 1y ago

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

deleted 1y ago

[deleted]

deleted 1y ago

[deleted]

deleted 1y ago

[deleted]

ferahl 1y ago

Anyone know a language that compiles to WASM v3?

ferahl 1y ago

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?