TechPulseTechPulse
Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

80% Positive

Analyzed from 1280 words in the discussion.

Trending Topics

#wasm#browser#wasi#model#component#need#runtime#run#code#platform

Discussion (28 Comments)Read Original on HackerNews

simonw•about 3 hours 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.

DanielHB•6 minutes 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.

Panzerschrek•about 1 hour 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•about 1 hour 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.
pjmlp•3 minutes ago
No you don't, because WASM is only compute, and you need exactly runtime specific code and third party frameworks for everything else as imported functions.
Panzerschrek•33 minutes 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.

rvz•32 minutes ago
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...

hobofan•21 minutes ago
Those are not flaws in WASM itself, but in different WASM runtimes.
yjftsjthsd-h•26 minutes 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.
wyager•about 1 hour ago
I'm curious if people have a good story for why WASI will succeed where Java failed
simonw•about 1 hour 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.
Panzerschrek•29 minutes 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.

fla•24 minutes ago
My main one is: distribution & access. If major browsers implement the WASI runtime then using and distributing a WASI app will be way simpler than the Java equivalent ever was.
thefounder•about 2 hours 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•7 minutes 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.
mastermage•19 minutes ago
Oh yes give me the component model lets go.
rohitsriram•about 1 hour 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.
flohofwoe•17 minutes 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.

wyager•about 1 hour 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

shevy-java•about 2 hours 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 ...).

Deukhoofd•10 minutes ago
When I last played with it checking out its capabilities, I found the thing I was mostly missing to really make use of it was the thing referenced in this article, the Component Model. Without a type model and binary specifications, interop was made a lot harder than it'd have been otherwise. Now that that's in, it becomes a lot more useful.

I was mostly looking at it for its state as being a cross-platform supported output platform of bytecode that's fairly well sandboxed. That makes it an excellent target for things like running untrusted plugins in an application in a performant manner.

simonw•about 1 hour ago
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.
h4ch1•about 2 hours 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.
esafak•about 2 hours ago
WASM made Figma.
aatd86•about 2 hours ago
WASM is super useful for FFI in some env
fyrn_•about 2 hours 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•about 2 hours ago
It works in the browser already: https://github.com/bytecodealliance/jco
jauntywundrkind•about 1 hour 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•3 minutes 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.