Every new standard today doesn't care about being clean and simple to use. They all maximize the JS boilerplate needed to make a basic example work. Everything is designed today for 'engineers' and not 'authors' without any friendly default workflow. I'm glad they still care about this.
This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time.)
I worked on the original interface-types proposal a little bit before it became the component model. Two goals that were added were:
1. Support non-Web API's
2. Support limited cross language interop
WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Component interfaces take more of an intersection approach that isn't as expressive, but is much more portable.
I personally have always cared about DOM access, but the Wasm CG has been really busy with higher priority things. Writing this post was sort of a way to say that at least some people haven't forgotten about this, and still plan on working on this.
The WASM cliff is very real. Every time I go to use it, because of the complexity of the tool chain and process of going from zero to anything at all, I feel like I'm already paying a cognitive tax. I worry that I should update my tooling, look into the latest and greatest, understand the tooling better, etc... It would be incredible to see that improved.
The difference in perf without glue is crazy. But not surprising at all. This is one of the things I almost always warn people about, because it's such a glaring foot gun when trying to do cool stuff with WASM.
The thing with components that might be addressed (maybe I missed it) is how we'd avoid introducing new complexity with them. Looking through the various examples of implementing them with different languages, I get a little spooked by how messy I can see this becoming. Given that these are early days and there's no clearly defined standard, I guess it's fair that things aren't tightened up yet.
The go example (https://component-model.bytecodealliance.org/language-suppor...) is kind of insane once you generate the files. For the consumer the experience should be better, but as a component developer, I'd hope the tooling and outputs were eventually far easier to reason about. And this is a happy path, without any kind of DOM glue or interaction with Web APIs. How complex will that get?
I suppose I could sum up the concern as shifting complexity rather than eliminating it.
I agree that a lot of the tooling is still early days. There has also been a lot of churn as the wasm component spec has changed. We personally have a goal that in most cases web developers won't need to write WIT and can just use Web API's as if they were a library. But it's early days.
This is the right direction. Another important bit I think it’s the GC integration. Many languages such Go, C# don’t do well on wasm due the GC. They have to ship a GC as well due the lack of various GC features(I.e interior pointers)
At a high level this sounds great. But looking into the details about how the component model will be implemented, it looks very complicated due to concurrency:
Great to see it happening finally. Can we also get compute shaders with WebGL2 now? I don't want to move everything to WebGPU just for compute shaders and I don't know why they kept rejecting the proposals.
Nice to see momentum here. Even outside of direct access to WebAPIs, having the ability to specify interfaces for WASM modules is a big deal, and unlocks all sort of cool options, like sandboxed WASM plugins for native apps...
E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM.
E.g. if I mainly work with web APIs like WebGL2, WebGPU or WebAudio I seriously doubt that the component model approach will cause a 2x speedup, the time spent in the JS shim is already negligible compared to the time spent inside the API implementations, and I don't see how the component model can help with the actually serious problems (like WebGPU mapping GPU buffers into separate ArrayBuffer objects which need to be copied in and out of the WASM heap).
It would be nice to see some benchmarks for WebGL2 and WebGPU with tens-of-thousands of draw calls, I seriously doubt there will be any significant speedup.
I agree there are some cases that won't see a huge boost, but also DOM performance is a big deal and bottleneck for a lot of applications.
And besides performance, I think there are developer experience improvements we could get with native wasm component support (problems 1-3). TBH, I think developer experience is one of the most important things to improve for wasm right now. It's just so hard to get started or integrate with existing code. Once you've learned the tricks, you're fine. But we really shouldn't be requiring everyone to become an expert to benefit from wasm.
JavaScript is the right abstraction for running untrusted apps in a browser.
WebAssembly is the wrong abstraction for running untrusted apps in a browser.
Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing.
Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented.
WebAssembly is statically typed and its most fundamental abstraction is linear memory. It's a poor fit for the web.
Sure, modern WebAssembly has GC'd objects, but that breaks WebAssembly's main feature: the ability to have native compilers target it.
I think WebAssembly is doomed to be a second-class citizen on the web indefinitely.
> WebAssembly is the wrong abstraction for running untrusted apps in a browser
WebAssembly is a better fit for a platform running untrusted apps than JS. WebAssembly has a sandbox and was designed for untrusted code. It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.
> Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing.
There are dynamic languages, like JS/Python that can compile to wasm. Also I don't see how dynamic typing is required to have API evolution and compt. Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways.
> Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented
The first major language for WebAssembly was C++, which is object oriented.
To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.
> WebAssembly has a sandbox and was designed for untrusted code.
So does JavaScript.
> It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.
They have that infrastructure because JS has access to the browser's API.
If you tried to redesign all of the web APIs in a way that exposes them to WebAssembly, you'd have an even harder time than exposing those APIs to JS, because:
- You'd still have all of the security troubles. The security troubles come from having to expose API that can be called adversarially and can pass you adversarial data.
- You'd also have the impedence mismatch that the browser is reasoning in terms of objects in a DOM, and WebAssembly is a bunch of integers.
> There are dynamic languages, like JS/Python that can compile to wasm.
If you compile them to linear memory wasm instead of just running directly in JS then you lose the ability to do coordinated garbage collection with the DOM.
If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upside.
> Also I don't see how dynamic typing is required to have API evolution and compt.
Because for example if a browser changes the type of something that happens to be unused, or removes something that happens to be unused, it only breaks actual users at time of use, not potential users at time of load.
> Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways.
We're talking about the browser, which is a particular platform. Not all platforms are the same.
The largest comparable platform is OSes based on C ABI, which rely on a "kind" of dynamic typing (stringly typed, basically - function names in a global namespace plus argument passing ABIs that allow you to mismatch function signature and get away with it.
> The first major language for WebAssembly was C++, which is object oriented.
But the object orientation is lost once you compile to wasm. Wasm's object model when you compile C++ to it is an array of bytes.
> To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.
Then what's your excuse for why wasm, despite years of investment, is a dud on the web?
> Then what's your excuse for why wasm, despite years of investment, is a dud on the web?
It's not really a dud on the web. It sees a ton of use in bringing heavier experiences to the browser (i.e Figma, the Unity player, and so on).
Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve.
Then give me a counterargument instead of just saying that I'm wrong.
My points are validated by the reality that most of the web is JavaScript, to the point that you'd have a hard time observing degradation of experience if you disabled the wasm engine.
All those projects also compile into native Windows/Linux/macOS/Android/iOS executables without any code changes, but compiling to WASM and running in web browsers is the most painless way to get this stuff to users.
Dealing with minor differences of web APIs in different browsers is a rare thing and can be dealt with in WASM just the same as in JS: a simple if-else will do the job, no dynamic type system needed (apart from that, WASM doesn't have a "type system" in the first place, just like CPU instruction sets don't have a "type system" - unless you count integer and float types as a "type system"). Alternatively it's trivial to call out into Javascript. In Emscripten you can even mix C/C++ and Javascript in the same source file.
E.g. for me, WASM is already a '1st class citizen of the web' no WASM component model needed.
The fact that you made some webassembly things isn't an answer to the question of why webassembly is not used by the overwhelming majority of websites.
> why webassembly is not used by the overwhelming majority of websites
This is such a bizarre take that I don't know whether it's just a trolling attempt or serious...
Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS? The two technologies live side by side, each with specific advantages and disadvantages, they are not competing with each other.
Every new standard today doesn't care about being clean and simple to use. They all maximize the JS boilerplate needed to make a basic example work. Everything is designed today for 'engineers' and not 'authors' without any friendly default workflow. I'm glad they still care about this.
This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time.)
Better late than never I guess.
[1] https://github.com/WebAssembly/interface-types/commit/f8ba0d...
[2] https://wingolog.org/archives/2023/10/19/requiem-for-a-strin...
[3] https://queue.acm.org/detail.cfm?id=3746174
I worked on the original interface-types proposal a little bit before it became the component model. Two goals that were added were: 1. Support non-Web API's 2. Support limited cross language interop WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Component interfaces take more of an intersection approach that isn't as expressive, but is much more portable.
I personally have always cared about DOM access, but the Wasm CG has been really busy with higher priority things. Writing this post was sort of a way to say that at least some people haven't forgotten about this, and still plan on working on this.
The WASM cliff is very real. Every time I go to use it, because of the complexity of the tool chain and process of going from zero to anything at all, I feel like I'm already paying a cognitive tax. I worry that I should update my tooling, look into the latest and greatest, understand the tooling better, etc... It would be incredible to see that improved.
The difference in perf without glue is crazy. But not surprising at all. This is one of the things I almost always warn people about, because it's such a glaring foot gun when trying to do cool stuff with WASM.
The thing with components that might be addressed (maybe I missed it) is how we'd avoid introducing new complexity with them. Looking through the various examples of implementing them with different languages, I get a little spooked by how messy I can see this becoming. Given that these are early days and there's no clearly defined standard, I guess it's fair that things aren't tightened up yet.
The go example (https://component-model.bytecodealliance.org/language-suppor...) is kind of insane once you generate the files. For the consumer the experience should be better, but as a component developer, I'd hope the tooling and outputs were eventually far easier to reason about. And this is a happy path, without any kind of DOM glue or interaction with Web APIs. How complex will that get?
I suppose I could sum up the concern as shifting complexity rather than eliminating it.
I agree that a lot of the tooling is still early days. There has also been a lot of churn as the wasm component spec has changed. We personally have a goal that in most cases web developers won't need to write WIT and can just use Web API's as if they were a library. But it's early days.
This is the right direction. Another important bit I think it’s the GC integration. Many languages such Go, C# don’t do well on wasm due the GC. They have to ship a GC as well due the lack of various GC features(I.e interior pointers)
At a high level this sounds great. But looking into the details about how the component model will be implemented, it looks very complicated due to concurrency:
https://github.com/WebAssembly/component-model/blob/main/des...
Great to see it happening finally. Can we also get compute shaders with WebGL2 now? I don't want to move everything to WebGPU just for compute shaders and I don't know why they kept rejecting the proposals.
Nice to see momentum here. Even outside of direct access to WebAPIs, having the ability to specify interfaces for WASM modules is a big deal, and unlocks all sort of cool options, like sandboxed WASM plugins for native apps...
Discussed 12 days ago (13 comments):
https://news.ycombinator.com/item?id=47167944
We've decided to give it another try as it didn't get much front page time or discussion.
It's still not a great idea IMHO ;)
(there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837)
E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM.
E.g. if I mainly work with web APIs like WebGL2, WebGPU or WebAudio I seriously doubt that the component model approach will cause a 2x speedup, the time spent in the JS shim is already negligible compared to the time spent inside the API implementations, and I don't see how the component model can help with the actually serious problems (like WebGPU mapping GPU buffers into separate ArrayBuffer objects which need to be copied in and out of the WASM heap).
It would be nice to see some benchmarks for WebGL2 and WebGPU with tens-of-thousands of draw calls, I seriously doubt there will be any significant speedup.
I agree there are some cases that won't see a huge boost, but also DOM performance is a big deal and bottleneck for a lot of applications.
And besides performance, I think there are developer experience improvements we could get with native wasm component support (problems 1-3). TBH, I think developer experience is one of the most important things to improve for wasm right now. It's just so hard to get started or integrate with existing code. Once you've learned the tricks, you're fine. But we really shouldn't be requiring everyone to become an expert to benefit from wasm.
It's simple.
JavaScript is the right abstraction for running untrusted apps in a browser.
WebAssembly is the wrong abstraction for running untrusted apps in a browser.
Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing.
Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented.
WebAssembly is statically typed and its most fundamental abstraction is linear memory. It's a poor fit for the web.
Sure, modern WebAssembly has GC'd objects, but that breaks WebAssembly's main feature: the ability to have native compilers target it.
I think WebAssembly is doomed to be a second-class citizen on the web indefinitely.
I'm not sure I follow this.
> WebAssembly is the wrong abstraction for running untrusted apps in a browser
WebAssembly is a better fit for a platform running untrusted apps than JS. WebAssembly has a sandbox and was designed for untrusted code. It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.
> Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing.
There are dynamic languages, like JS/Python that can compile to wasm. Also I don't see how dynamic typing is required to have API evolution and compt. Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways.
> Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented
The first major language for WebAssembly was C++, which is object oriented.
To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.
> WebAssembly has a sandbox and was designed for untrusted code.
So does JavaScript.
> It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.
They have that infrastructure because JS has access to the browser's API.
If you tried to redesign all of the web APIs in a way that exposes them to WebAssembly, you'd have an even harder time than exposing those APIs to JS, because:
- You'd still have all of the security troubles. The security troubles come from having to expose API that can be called adversarially and can pass you adversarial data.
- You'd also have the impedence mismatch that the browser is reasoning in terms of objects in a DOM, and WebAssembly is a bunch of integers.
> There are dynamic languages, like JS/Python that can compile to wasm.
If you compile them to linear memory wasm instead of just running directly in JS then you lose the ability to do coordinated garbage collection with the DOM.
If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upside.
> Also I don't see how dynamic typing is required to have API evolution and compt.
Because for example if a browser changes the type of something that happens to be unused, or removes something that happens to be unused, it only breaks actual users at time of use, not potential users at time of load.
> Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways.
We're talking about the browser, which is a particular platform. Not all platforms are the same.
The largest comparable platform is OSes based on C ABI, which rely on a "kind" of dynamic typing (stringly typed, basically - function names in a global namespace plus argument passing ABIs that allow you to mismatch function signature and get away with it.
> The first major language for WebAssembly was C++, which is object oriented.
But the object orientation is lost once you compile to wasm. Wasm's object model when you compile C++ to it is an array of bytes.
> To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.
Then what's your excuse for why wasm, despite years of investment, is a dud on the web?
> Then what's your excuse for why wasm, despite years of investment, is a dud on the web?
It's not really a dud on the web. It sees a ton of use in bringing heavier experiences to the browser (i.e Figma, the Unity player, and so on).
Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve.
That's just like your opinion man ;)
(I'm not a fan of the WASM component model either, but your generalized points are mostly just wrong)
Then give me a counterargument instead of just saying that I'm wrong.
My points are validated by the reality that most of the web is JavaScript, to the point that you'd have a hard time observing degradation of experience if you disabled the wasm engine.
I created and maintain a couple of WASM projects and have not experienced the problems you describe:
- https://floooh.github.io/tiny8bit/
- https://floooh.github.io/sokol-webgpu/
- https://floooh.github.io/visualz80remix/
- https://floooh.github.io/doom-sokol/
All those projects also compile into native Windows/Linux/macOS/Android/iOS executables without any code changes, but compiling to WASM and running in web browsers is the most painless way to get this stuff to users.
Dealing with minor differences of web APIs in different browsers is a rare thing and can be dealt with in WASM just the same as in JS: a simple if-else will do the job, no dynamic type system needed (apart from that, WASM doesn't have a "type system" in the first place, just like CPU instruction sets don't have a "type system" - unless you count integer and float types as a "type system"). Alternatively it's trivial to call out into Javascript. In Emscripten you can even mix C/C++ and Javascript in the same source file.
E.g. for me, WASM is already a '1st class citizen of the web' no WASM component model needed.
What toolchain do you use to build your apps?
The fact that you made some webassembly things isn't an answer to the question of why webassembly is not used by the overwhelming majority of websites.
> why webassembly is not used by the overwhelming majority of websites
This is such a bizarre take that I don't know whether it's just a trolling attempt or serious...
Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS? The two technologies live side by side, each with specific advantages and disadvantages, they are not competing with each other.