8 ms·

The Road to the WASM Component Model 1.0

103 points by emschwartz 3mo ago

simonw 3mo ago
I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access. I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cross-platform sandboxing solution for running real applications.
- grayrest 3mo ago
  The thing that interests me the most is that execution is deterministic. If the inputs to a WASM module are logged you get durable execution and rr style reverse debugging as part of the package.
  - sideeffffect 3mo ago
    If you're interested in this, then you should check out https://github.com/golemcloud/golem https://github.com/golemcloud/golem Golem is a durable workflow platform and can run any wasm.
- pistoriusp 3mo ago
  Why not just run a vm?
  - AndrewDucker 3mo ago
    Far more overhead.
    - ptx 3mo ago
      In particular (as I just learned when looking it up), WASM can dynamically allocate host memory with the memory.grow instruction, so you don't have to waste a huge chunk of statically allocated memory per VM: https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/Memory/grow https://developer.mozilla.org/en-US/docs/WebAssembly/Referen... Although... it doesn't say anything about releasing memory back to the host (I don't see a memory.shrink instruction) so maybe it's not all that helpful? Will WASM applications continue hogging the maximum amount of memory they've ever used until they're restarted? A VM could release memory back to the host using memory ballooning, but this has to be managed manually somehow, at least with QEMU.
- Panzerschrek 3mo ago
  > I don't ever want to run untrusted code from the internet outside of a sandbox ever again WASM is great, but I think it's a wrong approach for sandboxing problem. It's technically possible to sandbox native applications (compiled into target machine code) using OS-builtin mechanisms, but it's not done for compatibility reasons, because this is the way things were done last 50 years or so.
  - tancop 3mo ago
    sandboxing native apps just gives you security. with wasm you also get a single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification. you dont need to write platform specific code or use third party frameworks.
    - deleted 3mo ago
      [deleted]
    - Panzerschrek 3mo ago
      > you dont need to write platform specific code You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice. > single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary.
      - zcw100 3mo ago
        > You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice. That's a circular argument and "some" is doing a lot of work there. What cross-platform framework would you be referring to? > It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary. It my have little value to you but that doesn't mean it has little value to everyone. I don't agree that compiling to multiple architectures is without difficulty and restricting yourself to only popular ones proves the point. What specific "other user-side overhead" would you be referring to? Lots of things aren't strictly necessary, that doesn't imply they're not necessary. Yes, there is a performance cost. Sometimes that cost is worth paying.
- wyager 3mo ago
  I'm curious if people have a good story for why WASI will succeed where Java failed
  - simonw 3mo ago
    My main one is that WASI has benefitted from an additional 31 years of accumulated industry-wide experience compared to when Java was first released.
    - pjmlp 3mo ago
      So where has the experience gone in the support of C and C++ for WASM?
    - DonHopkins 3mo ago
      Plus, Larry Ellison doesn't own WASM: "Lawnmower Not Included"!
  - Panzerschrek 3mo ago
    Programs written in Java require installation of a middleware called Java runtime. It adds extra friction for end-users. And even if one has Java runtime installed, a newer version may be necessary for a recently-published application. With WASM it may be the same, unless al major OS vendors integrate a WASM runtime so that it doesn't need to be installed separately.
    - bzzzt 3mo ago
      > Programs written in Java require installation of a middleware called Java runtime. It's possible to link or embed a Java runtime in an existing application.
    - pjmlp 3mo ago
      It is exactly the same for WASM outside of the browser, and Java has Android as counter part to built in runtime.
      - 3mo ago
- yjftsjthsd-h 3mo ago
  Hey, this is also my interest. I was just looking into whether it was possible to e.g. build an archive extractor that runs like a normal program but does the actual extraction completely in wasm. Unfortunately, AFAICT it's possible but requires custom code; you can't (yet, I hope) just compile unzip/libarchive/whatever with CC=wasicompiler and get a sandboxed binary. But we're getting close.
  - nl 3mo ago
    What do you mean? You absolutely can run compression in WASM. For example here is Gzip in WASM: https://github.com/ColinTimBarndt/wasm-gzip https://github.com/ColinTimBarndt/wasm-gzip
  - fc417fc802 3mo ago
    You should be able to do exactly that though? Why do you think you can't? You will of course need to include a lot of support code to provide the relevant syscalls and otherwise emulate the environment that the code expects. But there are plenty of examples of that at this point.
    - yjftsjthsd-h 3mo ago
      Yeah, it's all that support code that I don't want to write. I want to (roughly) just tar -xf unzip.tar.gz && cd unzip ./configure CC=wasmcc make wasmruntime unzip.wasm testfile.zip
- DanielHB 3mo ago
  Use cases I am more excited about: 1) Replace webhooks in web apps with wasm binaries provided by the customer, but that run in the web app servers. 2) Safer plugin system for professional software (plugins for photoshop, plugins for IDEs, etc) 3) Safer mod system for games and server-side mods that run on the game-maker server.
  - tuananh 3mo ago
    i had this same vision when i created hyper-mcp with modular plugin system via WASM plugins. Too bad, the community moves on from MCP to CLI with coding agent https://github.com/hyper-mcp-rs/hyper-mcp https://github.com/hyper-mcp-rs/hyper-mcp
  - bzzzt 3mo ago
    We had that in the 90's with Java. Why would this approach succeed today?
    - simonw 3mo ago
      Why wouldn't it? It's a different technology stack, developed with the benefit of decades of additional experience running hostile code on the web.
      - pjmlp 3mo ago
        You mean like the CLR? Kind of strange that such experience still allows for WASM to be the target of C and C++ compilers, and there is no bounds checking support inside linear memory regions.
    - dtj1123 3mo ago
      Because Java is a language, not a compilation target?
      - ptx 3mo ago
        From the introduction section of the Java specification [1]: "The Java Virtual Machine is the cornerstone of the Java platform. It is the component of the technology responsible for its hardware- and operating system-independence, the small size of its compiled code, and its ability to protect users from malicious programs." [1] https://docs.oracle.com/javase/specs/jvms/se26/html/jvms-1.html https://docs.oracle.com/javase/specs/jvms/se26/html/jvms-1.h...
- emadda 3mo ago
  I like the technical design of WASM, but I feel that better OS sandboxes for regular native code will be the common approach to running untrusted code. As soon as you compile to WASM you no longer have the C FFI and the ability to call the OS systems interfaces for files, network and others. It is extra work to move something to WASM vs just compiling it and running it in a sandbox.
- samiv 3mo ago
  Sorry but how exactly does the sandboxing help? You download and run an app that you expect to be useful and that you need. The app needs permission to access your data. If you want to use the application what choice do you have except to grant it access? Point being you wouldn't run untrusted code in the first place and for "trusted code" you end up accepting it's access requirements anyway. So logically I'd think that the malware would just get piggy bagged into actual non-obvious utility apps and nothing is gained. Second problem is that the security model hoops make for terrible APIs and user experiences. Just look at the current filesystem browser APIs. It must be mentally challenging to design APIs to Be usable and the nerf them for security purposes to make them "not too usable". Finally one must note that at least right now the webasm ecosystem is rather immature and the de-facto only tool (emscripten) is an amateur hour hobby project. So it's going to take some decades still before the tooling is really getting there.
  - eviks 3mo ago
    > The app needs permission to access your data. If you want to use the application what choice do you have except to grant it access? But it doesn't need network access to be useful, so it doesn't have that permission and can't exfiltrate your data?
    - pjmlp 3mo ago
      https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-configure-using-wsb-file https://learn.microsoft.com/en-us/windows/security/applicati...
      - eviks 3mo ago
        In general, what's three point of a link to a sandbox in a conversation about the benefits of sanboxingm But specifically, this sandbox also kills all interop with your system, other apps/utilities, so way too disruptive for the purpose of isolating just from the network.
        3mo ago
fyrn_ 3mo ago
Please please please bring it to the browser. I'm so done with the terrible ergonomics of everything at the was bounary having to pretend it's JavaScript
- enos_feedler 3mo ago
  It works in the browser already: https://github.com/bytecodealliance/jco https://github.com/bytecodealliance/jco
  - jauntywundrkind 3mo ago
    It works in the browser already, by bundling another browser runtime engine into wasm. You need a whole fork of Mozilla's SpiderMonkey engine, compiled to wasm, running in whatever browser you have, to run wasm components today. I confess I was quite frustrated at first when browsers all said no to wasi / wasm components. But honestly, it was the right call. It's taken so long to make wasm components happen, to get them far enough along to start really consider implementing. I can accept that as just the reality of what it takes for a small team to do such amazing work. I am so thankful for the folks who have kept this going, kept advancing. But it's time now. 0.3 delivers an incredibly comprehensive & gorgeous suite of capabilities that offer a winning combination of characteristics (fast, lightweight, sandboxable, runtime composeable components) that is ideal for the web. I hope browsers can help get us set up for 1.0, help steer us forwards towards that spec, and I hope they're moving quickly towards being ready to implement!
    - enos_feedler 3mo ago
      I agree with you, but sadly without killer use cases in the browser this still ends up being quite political to adopt. I feel good about the approach being taken. The browser vendors have analytics on the usage of JCO and so despite it not being "ideal", it works. We need to make stuff using JCO and make those things popular. It's not on the browser vendors to build native component model yet. At some point I suspect it will be though.
    - tschneidereit 3mo ago
thefounder 3mo ago
It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”
- flohofwoe 3mo ago
  I'm pretty sure you'll will still need a JS shim to talk to most web APIs. For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header (similar to the old 'use asm' for asm.js) as shim, but the JS shim is still there. The component model can marshal 'record types' between different WASM modules, but AFAIK not between a WASM module and a web API.
  - breve 3mo ago
    > For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header As per the article, that's temporary until Component Model 1.0 is implemented natively in the browser. In the meantime, jco can be used: > The groundwork for browser implementations is being laid today: jco’s transpile command already converts any component into equivalent core Wasm and JavaScript glue, making components runnable in any browser without native support. That's no longer needed once native support is there.
- DarkNova6 3mo ago
  I don't get it why you need direct DOM access. Just wrap it in JS calls. It's not like current websites are super fast and creating a wrapper will slow it down unnecessarily.
  - AndrewDucker 3mo ago
    The article cites the research that JS wrapping of DOM calls slows things down by 50%.
    - discreteevent 3mo ago
      Just to be clear: It slows down the overhead of a function call by 50%. It doesn't slow down the function implementation which takes a very large percentage of the time.
shevy-java 3mo ago
WASM first appeared in 2017. It still hasn't really reached a breakthrough. Billions use HTML+CSS+JavaScript. Who really uses WASM? There are of course users, but very, very few in absolute numbers. Many projects are not web-based really. For Autodesk Fusion, as one example for many, I have some mega-slow application that takes forever to work with in some cases on my laptop (it is not the fastest laptop, but I recently tested this on a faster desktop computer with 32GB RAM and it is still slow to no ends; using it all WASM based would be even slower I bet. That's not winning anyone over ...).
- esafak 3mo ago
  WASM made Figma.
- aatd86 3mo ago
  WASM is super useful for FFI in some env
- h4ch1 3mo ago
  I wrote an Unreal file parser in C# and use it in our in-house web based DAM. It was much more ergonomic and performant than writing it in Javascript.
- simonw 3mo ago
  According to https://chromestatus.com/metrics/feature/timeline/popularity/4689 https://chromestatus.com/metrics/feature/timeline/popularity... WebAssembly runs on about 6.11% of Chrome page loads, up from 3.37% in January 2024.
  - pjmlp 3mo ago
    Probably all of that is Figma.
    - afiori 3mo ago
      Sure, figma is 6% of the internet
wyager 3mo ago
Very exited about WASM/WCM as a portable format for capability-secure applications. I had a spec file sitting around for an OS project idea I had, where the kernel would just be the WASM compiler + a few small shim drivers, and everything else (including e.g. PCIe device drivers) would be WASM modules with WIT interface specs. I handed the spec off to Fable and it seems to have made a working proof-of-concept. Has a maximally-WASM OS running on browser/QEMU/Orange Pi. https://eo9.org https://eo9.org
rohitsriram 3mo ago
The microkernel analogy for the Component Model vs WASI is actually a really useful mental model that I hadn't seen framed that way before. Component Model as the always-present kernel, WASI as optional OS services on top. That framing makes it obvious why browser implementation of the Component Model is tractable even though browsers have strong opinions about I/O, and why 1.0 for the Component Model and WASI are separate milestones. The lazy ABI change is also underrated, zero-copy forwarding between calls is going to matter a lot for the use cases where WASM actually competes with native.
mastermage 3mo ago
Oh yes give me the component model lets go.
flohofwoe 3mo ago
> The Component Model can’t formally reach 1.0 without native implementation in at least two browser engines. I don't quite understand why the Component Model is now suddenly a browser thing, and on top something that needs to be implemented natively in browsers instead of a convention between different compiler toolchains. Keep that boondoggle in WASI and the Bytecode Alliance. WASM in the browser works just fine without the added runtime complexity.
- pjmlp 3mo ago
  Because no one cares about yet another CORBA, gRPC is good enough, and going forward stuff like MCP and A2A are way more relevant even, so they need the browser for having any use case at all that people would actually care about. Otherwise in a couple of years no one would care Component Model ever existed.
- yoshuaw 3mo ago
  If you want compilers to be able to natively target browsers and access the browser DOM APIs, then you need to define some kind of contract between browsers and compilers on how to call APIs in one from the other. That is what the Wasm Component Model provides. Perhaps some people are happy to keep the status quo where each call between Wasm and the browser needs to roundtrip through a JS glue layer. But personally I'm excited about a future where that is no longer needed.
  - flohofwoe 3mo ago
    From what I've been reading so far the component model in browsers cannot eliminate the JS glue layer, it can at most auto-generate and hide the JS shim to some extent (but that's nothing that can't be done without the component model, and with currently solutions you'll also usually don't need to deal with the JS shim, the various compiler toolchains will do that for you, e.g. Emscripten). The only advantage you'll get is slightly faster string marshalling, which admittedly is important for DOM access, since the DOM is an extremely string heavy API. Eliminating the glue layer completely would only be possible if the browser offers a separate 'WASM API' for each web API, but this is very unlikely to happen.
baudaux 3mo ago
I will be interested in getting details about the experiments of Ryan Hunt about DOM performances. I am currently developing a WASI runtime for exaequOS and Woua programming language that will target WASI and will have access to DOM through a virtual/dev/dom driver. wex —dir /dev /usr/tests/woua/dom_demo.wasm
pjmlp 3mo ago
So, Jini with RMI, CORBA, DCOM, and gRPC, hello again. Really leave WASM on the browser.
catlifeonmars 3mo ago
I’m curious if this helps make WASM a potential alternative to eBPF for userspace kernel extensions.
DanielHB 3mo ago
The ABI stuff is huge, we might be heading (at least in the WASM world) to a place where non-C libraries are not locked to certain dev ecosystems. On top of not having to deal with C linking madness.

103 points by emschwartz 3mo ago

I'm unreasonably excited about WASI. WASI is the thing which takes WebAssembly from a tool for running stuff in a browser to a tool that can run entire portable sandboxed applications on a computer - with controlled filesystem and network access. I don't ever want to run untrusted code from the internet outside of a sandbox ever again. If WASI lives up to its full potential I won't have to - we'll have a robust, cross-platform sandboxing solution for running real applications.

grayrest 3mo ago
The thing that interests me the most is that execution is deterministic. If the inputs to a WASM module are logged you get durable execution and rr style reverse debugging as part of the package.
- sideeffffect 3mo ago
  If you're interested in this, then you should check out https://github.com/golemcloud/golem https://github.com/golemcloud/golem Golem is a durable workflow platform and can run any wasm.
pistoriusp 3mo ago
Why not just run a vm?
- AndrewDucker 3mo ago
  Far more overhead.
  - ptx 3mo ago
    In particular (as I just learned when looking it up), WASM can dynamically allocate host memory with the memory.grow instruction, so you don't have to waste a huge chunk of statically allocated memory per VM: https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/Memory/grow https://developer.mozilla.org/en-US/docs/WebAssembly/Referen... Although... it doesn't say anything about releasing memory back to the host (I don't see a memory.shrink instruction) so maybe it's not all that helpful? Will WASM applications continue hogging the maximum amount of memory they've ever used until they're restarted? A VM could release memory back to the host using memory ballooning, but this has to be managed manually somehow, at least with QEMU.
Panzerschrek 3mo ago
> I don't ever want to run untrusted code from the internet outside of a sandbox ever again WASM is great, but I think it's a wrong approach for sandboxing problem. It's technically possible to sandbox native applications (compiled into target machine code) using OS-builtin mechanisms, but it's not done for compatibility reasons, because this is the way things were done last 50 years or so.
- tancop 3mo ago
  sandboxing native apps just gives you security. with wasm you also get a single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification. you dont need to write platform specific code or use third party frameworks.
  - deleted 3mo ago
    [deleted]
  - Panzerschrek 3mo ago
    > you dont need to write platform specific code You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice. > single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary.
    - zcw100 3mo ago
      > You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice. That's a circular argument and "some" is doing a lot of work there. What cross-platform framework would you be referring to? > It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary. It my have little value to you but that doesn't mean it has little value to everyone. I don't agree that compiling to multiple architectures is without difficulty and restricting yourself to only popular ones proves the point. What specific "other user-side overhead" would you be referring to? Lots of things aren't strictly necessary, that doesn't imply they're not necessary. Yes, there is a performance cost. Sometimes that cost is worth paying.
wyager 3mo ago
I'm curious if people have a good story for why WASI will succeed where Java failed
- simonw 3mo ago
  My main one is that WASI has benefitted from an additional 31 years of accumulated industry-wide experience compared to when Java was first released.
  - pjmlp 3mo ago
    So where has the experience gone in the support of C and C++ for WASM?
  - DonHopkins 3mo ago
    Plus, Larry Ellison doesn't own WASM: "Lawnmower Not Included"!
- Panzerschrek 3mo ago
  Programs written in Java require installation of a middleware called Java runtime. It adds extra friction for end-users. And even if one has Java runtime installed, a newer version may be necessary for a recently-published application. With WASM it may be the same, unless al major OS vendors integrate a WASM runtime so that it doesn't need to be installed separately.
  - bzzzt 3mo ago
    > Programs written in Java require installation of a middleware called Java runtime. It's possible to link or embed a Java runtime in an existing application.
  - pjmlp 3mo ago
    It is exactly the same for WASM outside of the browser, and Java has Android as counter part to built in runtime.
    - 3mo ago
yjftsjthsd-h 3mo ago
Hey, this is also my interest. I was just looking into whether it was possible to e.g. build an archive extractor that runs like a normal program but does the actual extraction completely in wasm. Unfortunately, AFAICT it's possible but requires custom code; you can't (yet, I hope) just compile unzip/libarchive/whatever with CC=wasicompiler and get a sandboxed binary. But we're getting close.
- nl 3mo ago
  What do you mean? You absolutely can run compression in WASM. For example here is Gzip in WASM: https://github.com/ColinTimBarndt/wasm-gzip https://github.com/ColinTimBarndt/wasm-gzip
- fc417fc802 3mo ago
  You should be able to do exactly that though? Why do you think you can't? You will of course need to include a lot of support code to provide the relevant syscalls and otherwise emulate the environment that the code expects. But there are plenty of examples of that at this point.
  - yjftsjthsd-h 3mo ago
    Yeah, it's all that support code that I don't want to write. I want to (roughly) just tar -xf unzip.tar.gz && cd unzip ./configure CC=wasmcc make wasmruntime unzip.wasm testfile.zip
DanielHB 3mo ago
Use cases I am more excited about: 1) Replace webhooks in web apps with wasm binaries provided by the customer, but that run in the web app servers. 2) Safer plugin system for professional software (plugins for photoshop, plugins for IDEs, etc) 3) Safer mod system for games and server-side mods that run on the game-maker server.
- tuananh 3mo ago
  i had this same vision when i created hyper-mcp with modular plugin system via WASM plugins. Too bad, the community moves on from MCP to CLI with coding agent https://github.com/hyper-mcp-rs/hyper-mcp https://github.com/hyper-mcp-rs/hyper-mcp
- bzzzt 3mo ago
  We had that in the 90's with Java. Why would this approach succeed today?
  - simonw 3mo ago
    Why wouldn't it? It's a different technology stack, developed with the benefit of decades of additional experience running hostile code on the web.
    - pjmlp 3mo ago
      You mean like the CLR? Kind of strange that such experience still allows for WASM to be the target of C and C++ compilers, and there is no bounds checking support inside linear memory regions.
  - dtj1123 3mo ago
    Because Java is a language, not a compilation target?
    - ptx 3mo ago
      From the introduction section of the Java specification [1]: "The Java Virtual Machine is the cornerstone of the Java platform. It is the component of the technology responsible for its hardware- and operating system-independence, the small size of its compiled code, and its ability to protect users from malicious programs." [1] https://docs.oracle.com/javase/specs/jvms/se26/html/jvms-1.html https://docs.oracle.com/javase/specs/jvms/se26/html/jvms-1.h...
emadda 3mo ago
I like the technical design of WASM, but I feel that better OS sandboxes for regular native code will be the common approach to running untrusted code. As soon as you compile to WASM you no longer have the C FFI and the ability to call the OS systems interfaces for files, network and others. It is extra work to move something to WASM vs just compiling it and running it in a sandbox.
samiv 3mo ago
Sorry but how exactly does the sandboxing help? You download and run an app that you expect to be useful and that you need. The app needs permission to access your data. If you want to use the application what choice do you have except to grant it access? Point being you wouldn't run untrusted code in the first place and for "trusted code" you end up accepting it's access requirements anyway. So logically I'd think that the malware would just get piggy bagged into actual non-obvious utility apps and nothing is gained. Second problem is that the security model hoops make for terrible APIs and user experiences. Just look at the current filesystem browser APIs. It must be mentally challenging to design APIs to Be usable and the nerf them for security purposes to make them "not too usable". Finally one must note that at least right now the webasm ecosystem is rather immature and the de-facto only tool (emscripten) is an amateur hour hobby project. So it's going to take some decades still before the tooling is really getting there.
- eviks 3mo ago
  > The app needs permission to access your data. If you want to use the application what choice do you have except to grant it access? But it doesn't need network access to be useful, so it doesn't have that permission and can't exfiltrate your data?
  - pjmlp 3mo ago
    https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-configure-using-wsb-file https://learn.microsoft.com/en-us/windows/security/applicati...
    - eviks 3mo ago
      In general, what's three point of a link to a sandbox in a conversation about the benefits of sanboxingm But specifically, this sandbox also kills all interop with your system, other apps/utilities, so way too disruptive for the purpose of isolating just from the network.
      - 3mo ago

fyrn_ 3mo ago

Please please please bring it to the browser. I'm so done with the terrible ergonomics of everything at the was bounary having to pretend it's JavaScript

enos_feedler 3mo ago
It works in the browser already: https://github.com/bytecodealliance/jco https://github.com/bytecodealliance/jco
- jauntywundrkind 3mo ago
  It works in the browser already, by bundling another browser runtime engine into wasm. You need a whole fork of Mozilla's SpiderMonkey engine, compiled to wasm, running in whatever browser you have, to run wasm components today. I confess I was quite frustrated at first when browsers all said no to wasi / wasm components. But honestly, it was the right call. It's taken so long to make wasm components happen, to get them far enough along to start really consider implementing. I can accept that as just the reality of what it takes for a small team to do such amazing work. I am so thankful for the folks who have kept this going, kept advancing. But it's time now. 0.3 delivers an incredibly comprehensive & gorgeous suite of capabilities that offer a winning combination of characteristics (fast, lightweight, sandboxable, runtime composeable components) that is ideal for the web. I hope browsers can help get us set up for 1.0, help steer us forwards towards that spec, and I hope they're moving quickly towards being ready to implement!
  - enos_feedler 3mo ago
    I agree with you, but sadly without killer use cases in the browser this still ends up being quite political to adopt. I feel good about the approach being taken. The browser vendors have analytics on the usage of JCO and so despite it not being "ideal", it works. We need to make stuff using JCO and make those things popular. It's not on the browser vendors to build native component model yet. At some point I suspect it will be though.
  - tschneidereit 3mo ago

thefounder 3mo ago

It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”

flohofwoe 3mo ago
I'm pretty sure you'll will still need a JS shim to talk to most web APIs. For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header (similar to the old 'use asm' for asm.js) as shim, but the JS shim is still there. The component model can marshal 'record types' between different WASM modules, but AFAIK not between a WASM module and a web API.
- breve 3mo ago
  > For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header As per the article, that's temporary until Component Model 1.0 is implemented natively in the browser. In the meantime, jco can be used: > The groundwork for browser implementations is being laid today: jco’s transpile command already converts any component into equivalent core Wasm and JavaScript glue, making components runnable in any browser without native support. That's no longer needed once native support is there.
DarkNova6 3mo ago
I don't get it why you need direct DOM access. Just wrap it in JS calls. It's not like current websites are super fast and creating a wrapper will slow it down unnecessarily.
- AndrewDucker 3mo ago
  The article cites the research that JS wrapping of DOM calls slows things down by 50%.
  - discreteevent 3mo ago
    Just to be clear: It slows down the overhead of a function call by 50%. It doesn't slow down the function implementation which takes a very large percentage of the time.

shevy-java 3mo ago

WASM first appeared in 2017. It still hasn't really reached a breakthrough. Billions use HTML+CSS+JavaScript. Who really uses WASM? There are of course users, but very, very few in absolute numbers. Many projects are not web-based really. For Autodesk Fusion, as one example for many, I have some mega-slow application that takes forever to work with in some cases on my laptop (it is not the fastest laptop, but I recently tested this on a faster desktop computer with 32GB RAM and it is still slow to no ends; using it all WASM based would be even slower I bet. That's not winning anyone over ...).

esafak 3mo ago
WASM made Figma.
aatd86 3mo ago
WASM is super useful for FFI in some env
h4ch1 3mo ago
I wrote an Unreal file parser in C# and use it in our in-house web based DAM. It was much more ergonomic and performant than writing it in Javascript.
simonw 3mo ago
According to https://chromestatus.com/metrics/feature/timeline/popularity/4689 https://chromestatus.com/metrics/feature/timeline/popularity... WebAssembly runs on about 6.11% of Chrome page loads, up from 3.37% in January 2024.
- pjmlp 3mo ago
  Probably all of that is Figma.
  - afiori 3mo ago
    Sure, figma is 6% of the internet

wyager 3mo ago

Very exited about WASM/WCM as a portable format for capability-secure applications. I had a spec file sitting around for an OS project idea I had, where the kernel would just be the WASM compiler + a few small shim drivers, and everything else (including e.g. PCIe device drivers) would be WASM modules with WIT interface specs. I handed the spec off to Fable and it seems to have made a working proof-of-concept. Has a maximally-WASM OS running on browser/QEMU/Orange Pi. https://eo9.org https://eo9.org

rohitsriram 3mo ago

The microkernel analogy for the Component Model vs WASI is actually a really useful mental model that I hadn't seen framed that way before. Component Model as the always-present kernel, WASI as optional OS services on top. That framing makes it obvious why browser implementation of the Component Model is tractable even though browsers have strong opinions about I/O, and why 1.0 for the Component Model and WASI are separate milestones. The lazy ABI change is also underrated, zero-copy forwarding between calls is going to matter a lot for the use cases where WASM actually competes with native.

mastermage 3mo ago

Oh yes give me the component model lets go.

flohofwoe 3mo ago

> The Component Model can’t formally reach 1.0 without native implementation in at least two browser engines. I don't quite understand why the Component Model is now suddenly a browser thing, and on top something that needs to be implemented natively in browsers instead of a convention between different compiler toolchains. Keep that boondoggle in WASI and the Bytecode Alliance. WASM in the browser works just fine without the added runtime complexity.

pjmlp 3mo ago
Because no one cares about yet another CORBA, gRPC is good enough, and going forward stuff like MCP and A2A are way more relevant even, so they need the browser for having any use case at all that people would actually care about. Otherwise in a couple of years no one would care Component Model ever existed.
yoshuaw 3mo ago
If you want compilers to be able to natively target browsers and access the browser DOM APIs, then you need to define some kind of contract between browsers and compilers on how to call APIs in one from the other. That is what the Wasm Component Model provides. Perhaps some people are happy to keep the status quo where each call between Wasm and the browser needs to roundtrip through a JS glue layer. But personally I'm excited about a future where that is no longer needed.
- flohofwoe 3mo ago
  From what I've been reading so far the component model in browsers cannot eliminate the JS glue layer, it can at most auto-generate and hide the JS shim to some extent (but that's nothing that can't be done without the component model, and with currently solutions you'll also usually don't need to deal with the JS shim, the various compiler toolchains will do that for you, e.g. Emscripten). The only advantage you'll get is slightly faster string marshalling, which admittedly is important for DOM access, since the DOM is an extremely string heavy API. Eliminating the glue layer completely would only be possible if the browser offers a separate 'WASM API' for each web API, but this is very unlikely to happen.

baudaux 3mo ago

I will be interested in getting details about the experiments of Ryan Hunt about DOM performances. I am currently developing a WASI runtime for exaequOS and Woua programming language that will target WASI and will have access to DOM through a virtual/dev/dom driver. wex —dir /dev /usr/tests/woua/dom_demo.wasm

pjmlp 3mo ago

So, Jini with RMI, CORBA, DCOM, and gRPC, hello again. Really leave WASM on the browser.

catlifeonmars 3mo ago

I’m curious if this helps make WASM a potential alternative to eBPF for userspace kernel extensions.

DanielHB 3mo ago

The ABI stuff is huge, we might be heading (at least in the WASM world) to a place where non-C libraries are not locked to certain dev ecosystems. On top of not having to deal with C linking madness.