WebAssembly has been working just fine since 2017.
This article is just hype for WASI 0.2 and the Component Model, which at closer look seems to suffer from second-system effect at best, or Rust people ruining a perfectly fine standard (WASI 0.1) at worst.
We don't need Component Model, rather good tooling that makes as easy to spew WebAssembly as using AssemblyScript, not having to install alternative compiler toolchains.
Additionally the whole WebAssembly on the server is JVM/CLR/BEAM envy, fuelled with SV money for the next big thing, better served with plain old containers.
What problems is WASI 0.2 and the Component Model solving? I've read the project goals but I still don't quite understand.
I mean, I guess having some defined interface between languages might be useful for some specific usecases, I just don't see what that has to do with WASM and I also don't understand how this complexity would be a net benefit to the broader ecosystem.
Basically since they want to redo P-Code/M-Code/JVM/CLR/BEAM/TIMI/Language Environments/..., now they need to re-invent CORBA, DCOM, XPC, AIDL, gRPC as well.
They already reinvented application servers with WASM containers on Kubernetes.
Otherwise how one would expect to create startups whose goal is to deliver services on top of WebAssembly, something whose original goal was only being a safer ActiveX, Flash, Silverlight, Applets, PNaCL, asm.js, alongside JavaScript.
Exactly. AFAIK the idea is the same as 1990's COM or CORBA, but for WASM (e.g. being able to call between WASM "DLLs" written in different languages but without having to define a C API for each DLL), so pretty much irrelevant for statically linked WASM apps or anything that uses C APIs anyway to talk to each other.
> pretty much irrelevant for statically linked WASM apps
One benefit off the top of my head is the extra isolation between component instances within this statically linked app: you can be shielded from many of the ways libwhatever might ruin everything because its linear memory can be totally isolated from the root component (and vice versa) with surprisingly little overhead.
The Wasm Component model takes security seriously, much in the way that Core Wasm does. Even without everything else it has to offer, this is something our craft is desperately in need of.
If Core Wasm took security seriously, the memory access opcodes for arrays would be bound checked like on MSIL and TIMI, instead of "as long as it is inside of a linear memory segment we're good" approach.
Arguably, memory safety inside the WASM heap is the job of the compiler, it's often possible to omit runtime range- and null-checks with the control-flow knowledge the compiler has access to which would be tricky to transmit down to the bytecode level (and even then it would only benefit a handful of languages that have builtin concepts for "ranges" and "nullability".
If you need more fine-grained isolation, split your code into different WASM instances.
"Arguably, memory safety inside the UNIX process heap is the job of the compiler, ...."
See what I did there?
And then we are back at the root problem of goverments having to step in, and hardware vendors coming up with hardware memory tagging, because that isn't scaling.
> "Arguably, memory safety inside the UNIX process heap is the job of the compiler, ...."
In my mind there's nothing controversial about this statement at all.
If memory corruption inside the sandbox allows to manipulate anything outside the sandbox, then the sandbox is broken. It's as simple as that, and it doesn't matter whether it's the WASM heap or a process heap.
And if there is no guarantee that the sandbox is on a safe state, whose execution doesn't translate into nasty side effects, like return true instead of false on a credential check, due to internal memory corruption, then it is equally broken.
It becomes the same approach as attacking OS processes via their public OS IPC end points.
and CM copies everything everywhere between components - so this fictional need to build your program out of wasm components made of several languages which in turn also may link many components will just be a nightmare for performance and memory. WIT has to have a “borrow” concept to alleviate the pain.
For background, WASI 0.1 is one interface: a smaller POSIX. Translating POSIX's low-level ABI concepts into WASM is enough for this. WASI came out of WASM's goal of portability, and 0.1 makes WASM portable across POSIX systems.
WASM and WASI aim to support other embeddings. WASI 0.2 introduces an interface for HTTP servers and clients, aimed at cloud/edge. Currently Docker images (on an OS) get used here, but POSIX, even small POSIX, is bloat. WASI 0.2 plans a range of other interfaces for embedding WASM e.g. IOT, so that even without POSIX, you still have portable standards, in your preferred language.
HTTP is a high-level idea. HTTP libraries in any language are never about writing binary to TCP sockets, they're about requests and responses. Depending on sockets would miss the point of leaving POSIX behind. A smaller, loosely-coupled API surface gives both sides more freedom. The runtime can work with the system, the language can work with its users, and the tooling can generate minimal glue that links them together.
Why define WASI APIs with an abstract interface rather than a rigid binary one? Because it follows the spirit of WASM's existing goals: low-level when needed for performance, and high-level whenever it makes WASM simpler to target, embed or reason about. That's why WASM has low-level assembly instructions yet high-level structured control-flow. It's also why WASI uses types appropriate for the API in question (e.g. files in the POSIX interface, responses in HTTP) yet translates them to binary glue when linking real hosts and guests.
Lin Clark's 2019 article[1] raises an issue that comes with low-level interfaces:
But if a function takes or returns anything besides numbers, things get complicated. You can either:- Ship one module that has a really hard-to-use API that only speaks in numbers… making life hard for the module’s user.- Add glue code for every single environment you want this module to run in… making life hard for the module’s developer.
Clark argues WebAssembly is the right abstraction level to solve this issue in an efficient yet ergonomic way. Frankly, if your WASM module written in Go wants to talk to your host in Java, I don't see why that needs to involve C bindings.
The Component Model falls out of WASI as a bonus. WASI needs to interoperate modules with their embeddings. From there WASI may as well (Lin Clark puts it) "interoperate all the things".
WASI preview1 modules aren't very modular. You can't compose them. All you can do is one shot compile & bundle the world into one massive module. You can't use that module to power another module, it basically has to be standalone.
Luke Wagner has a talk going through WASI 0.2 that's pretty excellent. The title is What is a component (and why)?, and we go step by step through the properties component-model enables: a Standard Portable Lightweight Finely-Sandboxed Cross-Language Compositional Module. You get basically none of these without component-model. https://youtu.be/tAACYA1Mwv4
The properties are amazing. Not only do we get Cross-Language, not only do we get composable, but ideally we get very very lightweight sandboxed processes that can safely re-use modules already loaded by the runtime. This could be such an incredible way to sandbox actively, with a base of supportinginrsriss dwarfing anything computer science has done before.
The wasm view here has been so shortsighted & brutal. Once again, the hype cycle has gotten big enough that a lot of people are very angry & actively trying to tear down & discredit. Like systemd, like K8s. With not even a passing attempt to show balanced views in the process, no nods to the possible or good, just remorseless total war. This is the famous typical dripping sense of disdain, arising again in angry stirrings, here now to rage against component-model. Holy shit yes is it ambitious and hard. Yes you should be afraid of failure, of this crew not pulling it off & not making it work. But my heavens what a bunch of far-too-typical backhanded mean-girl horseshit is being heaped up to spiritually crush & deaden the effort, convincing everyone we should never try hard or attemot big efforts.
I see a future where we can spawn safe secure processes instead of promises, where we can run processes at such scale. Where we can mix languages. There's something so intensely interesting & compelling, upscaling & paving the road for something like V8 isolated that have had such success enabling scalable online platforms, and taking it from exotic dark material for the hyperscalers & turning it to something standard & accessible, fast & secure, spanning the whole technical ecosystem. It's worth the risk ya'll. Maybe we'll hit every branch of the CORBA tree on the way down & fail, but I for one tend to think we're such an improved world since those days: the web technical architecture groups along with open source footing have been an incredible combination for hashing through hard problems & building good protocols & standards piece by piece that let us keep composing better solutions, that let us build upwards successfully. And I'm so excited for this future, for what could be here.
Please educate yourself & come correct if this is an interesting topic that you want to engage in; there's so many resources out there. Never have we had a time where it's easier to dig in, from wonderful talks to in depth meeting notes. Please be more serious than oMGggg cORbA gRoSS it'll never work. Most of all, I dare you imagine it does work. And as a smart open minded technical sort, you should leave some space for that as a possibility in your cynicism, should have the possibility of success in your risk profile.
"This first part of this article discusses creating language-independent components, that is, components that can be consumed by apps that are written in any language. You can also create a single component or app from source code written in multiple languages; see Cross-Language Interoperability in the second part of this article."
From "Language independence and language-independent components" in MSIL, originally published in 2001.
I'm a WASM fanboy and cheerleader as anyone, all the way back before asm.js was even an idea and Emscripten was one of the weirder ways to make C code run in browsers (https://floooh.github.io/2012/10/23/mea-culpa.html).
So far, that whole endeavour made perfect sense to me, one small evolutionary improvement on top of another (even the switch from asm.js to wasm was evolutionary from the pov of the user, you just provided a different compiler switch, and you got wasm output instead of asm.js which ran at the same or slightly better speed).
WASI 0.1 was another evolutionary step that made total sense. It had a clear and simple mission: "provide a POSIX compatibility layer for WASM blobs". Very easy to communicate, very easy to use. You just write against (a subset of) the POSIX API and you get a WASM blob that runs on every WASM runtime that provides WASI compatibility, and providing full WASI compatibility wasn't all that hard, more or less just map to existing POSIX calls of the underlying platform.
But with WASI 0.2 I have for the very first time in 12 years the impression that the involved people are straying away from the successful evolutionary approach into architecture astronaut territory (and I have never seen that end well).
WASI 0.2 (0.3, etc...) should just be small improvements over WASI 0.1: better POSIX compatibility.
But with 'actual' WASI 0.2 I don't even know what it's supposed to be despite trying to keep up, it certainly can't be described in a single sentence except "it's awesome, just educate yourself!" - well I tried and I'm just as clueless as before. The problems it apparently wants to solve are nothing I care about (which isn't the case for WASI 0.1 which solves a very important problem for me).
What would be important to me in the near future is being able to run WASI 0.1 blobs on any popular desktop operating system without having to install a 3rd party runtime, a hard nut to crack of course because it requires getting Microsoft, Apple and probably even Linus on board - and the more complex WASI becomes, the less likely such a thing is.
Meanwhile, there's a real need to improve the POSIX compatibility of WASI 0.1 (for instance currently there's no concept of a current working directory for instance, but a lot of POSIX code depends on this).
Instead I get the impression that the WASI project has been hijacked and is being turned into something entirely different, with the original mission to provide a POSIX compatibility layer just being a little appendix that will soon be forgotten (apparently that appendix is now called 'wasi-libc').
I can only offer this advice: it would be better to take all the things that are not related to POSIX compatibility out of WASI and into a new project under a new name (maybe WASCOM or smth dunno...) and clearly mark that as "experimental". That would entirely avoid all the backlash and confusion you might currently be seeing, and probably also unblock 'actual' WASI progress (in the sense of improving POSIX compatibility).
This is a very well stated and accurate depiction of how wasm has evolved over the years & I couldn’t agree more with your recommendation.
WASI 0.1 should really be improved however necessary to increase secure POSIX compatibility— I think it’s already good enough, and implemented widely, but would be happy to see more APIs in it as long as it doesn’t sacrifice the security of many use cases of wasm.
I agree that WASI 0.2 is too far of a leap from this, creating an entirely new conceptual system in top of wasm, that is not compatible with the standard at all, and will damage the overall wasm ecosystem by fracture.
WASI 0.2 and Component Model are Bytecode Alliance projects and should be collocate in their own GitHub org. Associating them in the WebAssembly org is irresponsible and conveys a false alignment with the overall community and reality of Wasm standards.
I'm sorry I think this is just so sad & lowly. A portability layer for old code seems like such a lowly sad objective, such an incredibly sad unambitious target. I get the want, but letting such a small world dominate would be horrific. It's pathetically unambitious & small.
Wasm has not allowed actual inter-language operation at any serious scale. When we use code, it's basically bundled in, and maybe maybe maybe rust can pull in some c code because of it's own ffi, but that's as much as you get. That will never ever lead to wasm being a broad ecosystem. Everything will be its own distinct thing forever, and that's not a web assembly module if it so drastically fails to get anywhere near any modularity asks.
These small minded asks & desires should not outshadow real ambition. For a practical view of what we should be hoping for, the famous Steve Sanderson has a demonof three-way language interop using wasi preview2 that would not in any way be remotely conceivable in preview1. Spare us from the retrogressives that argue the shallow short preview1 would be anywhere near enough of a stopping point; that would be absurd. https://youtu.be/p9taQkF24Fs
No one is saying anyone should stop exploring new paths. I don't know what you personally are bringing to the table as far as adding to the ambition, so excuse my naivety.
The issue is that there is a misrepresentation by the Bytecode Alliance about WASI, from where it began, to where it is now. And a lot of this has been poorly communicated or not done at all. Which has only left many of us to think that they are trying to pull a fast one over the community to forcefully bring everyone along into Components when that is not desirable.
> Wasm has not allowed actual inter-language operation at any serious scale.
This is untrue, and you may just be unaware of efforts like Extism [0]. While it is intentionally not a binding generator, it does make it very easy to blend languages meaningfully. Disclaimer, I work on Extism and therefore have some bias :) We have different goals than the Component Model, so if you actually want what the component model offers, you should use it!
I believe the easy solution here is to:
1. stop referring to WASI 0.1 as "legacy", implying some obsolete status, or call 0.1 something entirely different. Let it continue to be an easily targetable interface to bridge to the rest of today's software.
2. move WASI and Component Model code repositories out of the WebAssembly github org.
This would clarify the distinction between WebAssembly (the standard) and WASI 0.2 / WIT / CM as a project by Bytecode Alliance. They are not the same, and while the Bytecode Alliance works on making things usable and ready, it doesn't cause harm or confusion for WebAssembly users.
I have no idea what the people guiding WASI are motivated about, but for sure it doesn't seem aligned with the community motivations... which might be hurting the ecosystem in the long run.
For the exact reasons the parent comment mentioned, at Wasmer we aimed for full POSIX compatibility as part of WASIX (a superset of WASI 0.1): https://wasix.org/. WASIX has support for many syscalls not available in WASI: fork, exec, longjmp, setjmp, threads, sockets, and many more.
It's insightful to know that many people, and specially those close to the Bytecode Alliance, neglected the contributions, and try to push down the project, and even tried to make us rename it: https://github.com/wasix-org/cargo-wasix/issues/4
Figma has been using wasm in production since 2017.
Wasm in the browser has its niches, but JS remains the best choice when considering load time and transfer size. JS is not the pinnacle of dev experience, but any other language has megabytes of runtime or libraries which need to be fetched and loaded before your application code. All browsers have JS batteries included, for better and for worse.
> but any other language has megabytes of runtime or libraries which need to be fetched and loaded before your application code.
It's really not that bad for languages that allow an embedded-programming style (C, Rust, C++, Zig, ...). For instance this C64 emulator written in C has a 97.5 KBytes compressed WASM blob (and this includes 20 KBytes of dense ROM data which is barely reduced in size when compressed), plus 14 KBytes for the JS shim:
By comparison, the minified and compressed main.js file of JS Beeb (which I assume contains the bulk of the emulation code) is 119 KBytes download size:
> JS remains the best choice when considering load time and transfer size.
Wasm often has a larger transfer size (although wasmgc might go a long way toward alleviating this). But it also often has a smaller load time. Web browsers can load equivalently sized wasm bundles much faster than they can load JavaScript.
AFAIK /sites subpath is mostly for articles made by "Forbes Contributors". How does one become one? You need to be invited by one of employees[0], but then it seems you can publish whatever with little editorial oversight[1]. You get paid, starting at $250 a month[2].
Personally, I find the idea nice, but a lot of these contributor articles seem to be poorly written anyways, so I try not to bother with them. But I guess that compared to a lot of other places in modern internet, especially medium.com and a ton of blogspammy wordpress sites, these must still look like Shakespeare in comparison.
Once I noticed the surprisingly consistent, legibly distanced branding, I imagined something -- actually more like contributors paying. Thank you for the research & explanation!
Unfortunately the DOM APIs were specified to have Javascript-specific details in them. As far as I understand it, the best way to access the DOM from WASM would be to define a new WASI Component -compatible API for the DOM.
Nobody's done the work yet, and I think the current strategy is to tackle easier APIs first, as WASI might not be good enough to describe the DOM at this time.
With a DOM API independent of Javascript, you could have a C/C++/Rust DOM in the host, and C/C++/Rust code inside WASM calling functions on the DOM, without needing to talk about Javascript types in the middle.
I really wonder why the DOM always comes up. The DOM is just one browser API among many, and WASM is a virtual instruction set. Browser APIs have been designed for Javascript (for better or worse) meaning they work with Javascript objects and properties. WASM isn't Javascript, and it only works with floats and integers, so it needs an FFI layer to talk to browser APIs.
In the end, calling from WASM into JS isn't all that different than calling from native machine code into a virtual machine like .NET or the JVM.
WASM without DOM would be like if your operating system said "you can write your code in any language, but if you want to output anything to the screen, you need to compile your code as a DLL and call it from a C program."
For an assembly language designed to run in the browser, I wouldn't characterize DOM access as "just one of many APIs". DOM access is the most universal need in front end programs.
For me the best way to think about WebAssembly, is to use the same approach as to keep a sane NDK experience on Android, write the code in a way that is always called from the host, instead of a interweb from down and upcalls.
> But WASM is a virtual instruction set for the browser
Depends on how you look at it. WASM itself doesn't have any browser specific features (and on purpose), it's a universal bytecode VM designed with strict sandboxing in mind.
You can manipulate the DOM from WASM by calling through a Javascript shim with very little overhead, same as it works for calling into other browser APIs like WebGL, WebGPU or WebAudio.
It just doesn't make all that much sense since WASM doesn't bring any benefit compared to manipulating the DOM via Javascript. Any theoretical performance advantage is pointless because the entire architecture of the DOM is slow by design.
But if you still want to do it, there are helpers like the Rust web_sys crate:
> Depends on how you look at it. WASM itself doesn't have any browser specific features (and on purpose), it's a universal bytecode VM designed with strict sandboxing in mind.
I know, but other than being able to run it in the browser, does WASM have any other benefits over compiling into C, LLVM, etc?
Firefox has C/C++ libraries compiled into WASM which is then compiled into native code. The end result is that the library is sandboxed into its own memory region.
This article is just hype for WASI 0.2 and the Component Model, which at closer look seems to suffer from second-system effect at best, or Rust people ruining a perfectly fine standard (WASI 0.1) at worst.