Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Road to the WASM Component Model 1.0

bytecodealliance.org

Post reply on HN
Print view View original

11–20 of 111 posts

Re: The Road to the WASM Component Model 1.0

#11

Post by simonw »

shevy-java wrote: post #5

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 recen…

According to https://chromestatus.com/metrics/feature/timeline/popularity... WebAssembly runs on about 6.11% of Chrome page loads, up from 3.37% in January 2024.

Re: The Road to the WASM Component Model 1.0

#12

Post by Panzerschrek »

simonw wrote: post #2

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, cros…

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

Re: The Road to the WASM Component Model 1.0

#13

Post by wyager »

simonw wrote: post #2

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, cros…

I'm curious if people have a good story for why WASI will succeed where Java failed

Re: The Road to the WASM Component Model 1.0

#14

Post by tancop »

Panzerschrek wrote: post #12
simonw wrote: post #2

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, cros…

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

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.

Re: The Road to the WASM Component Model 1.0

#15

Post by wyager »

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

Re: The Road to the WASM Component Model 1.0

#16

Post by simonw »

wyager wrote: post #13
simonw wrote: post #2

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, cros…

I'm curious if people have a good story for why WASI will succeed where Java failed

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.

Re: The Road to the WASM Component Model 1.0

#17

Post by rohitsriram »

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.

Re: The Road to the WASM Component Model 1.0

#18

Post by Panzerschrek »

tancop wrote: post #14
Panzerschrek wrote: post #12

Earlier quoted context omitted.

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

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.

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

Re: The Road to the WASM Component Model 1.0

#19

Post by rvz »

Panzerschrek wrote: post #12
simonw wrote: post #2

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, cros…

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

Exactly. It is entirely a misconception to believe that WASM is this silver bullet on sandboxing and it is not that great security-wise I’m afraid.

It is only now being inspected by researchers and attackers who have found sandbox escapes [0] (chrome 0day), out-of-bounds [1] / use-after-free [2] and many other [3] flaws [4] in WebAssembly which I also agree that it is not enough for sandboxing at all.

[0] https://nvd.nist.gov/vuln/detail/CVE-2026-11645

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=2009901

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=2013741

[3] https://www.miggo.io/vulnerability-database/cve/CVE-2026-269...

[4] https://github.com/bytecodealliance/wasm-micro-runtime/secur...

Re: The Road to the WASM Component Model 1.0

#20

Post by Panzerschrek »

wyager wrote: post #13
simonw wrote: post #2

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, cros…

I'm curious if people have a good story for why WASI will succeed where Java failed

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.

Post reply on HN