- 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.
by thefounder
3 subcomments
- 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”
by rohitsriram
0 subcomment
- 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.
- 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
by catlifeonmars
0 subcomment
- I’m curious if this helps make WASM a potential alternative to eBPF for userspace kernel extensions.
- 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
- So, Jini with RMI, CORBA, DCOM, and gRPC, hello again.
Really leave WASM on the browser.
- 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
by mastermage
0 subcomment
- Oh yes give me the component model lets go.
- 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.
by flohofwoe
2 subcomments
- > 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.
by shevy-java
6 subcomments
- 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 ...).
Hacker News