My point about WebAssembly is that by targeting a common standard agreed on by many vendors, developers have the freedom to develop in several languages (Rust, C, C++, Go, and a few more in a growing list). That allows to reuse and compose existing software written in different languages. In short, we have reusability, we have interoperability, and we have composability (well the specifications still have to improve in that direction with interface types and module linking to make this friendly but we'll get there eventually). That is a benefit of standards that are agreed and negotiated on by several vendors. I am opposing that to the closed world of frameworks.
Before WebAssembly we had Google NaCL as an attempt to run native code written in other languages. That was proprietary and not really interoperable. WebAssembly is opening a world of software in the browser, in embedded devices, at the cloud, the edge, you name it. That is why I say that there is lot to win to achieve interoperability instead of duplicating libraries or solutions for each framework.
So that is an example of the benefits of standards. Standard can succeed when they are enough low-level and well-designed that you can construct higher abstractions on top of them.
The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry. — Henry Petroski
Networks are experiencing a similar phenomenon. Subscriber growth and demand is outstripping the gradual theoretical improvements in peak performance and capability, often resulting in a degradation of the average network quality experience in some areas.
That allows to reuse and compose existing software written in different languages.
The majority of existing software hasn't been written with the constraints of the web in mind - be it issues like the "subset of the Go" supported by TinyGo or that web content has to work without the luxury of prior installation or the constraints imposed on generalized distributed computing by the "laws of physics" or security.
As a result there'll be a lot of rewriting where people are expecting reuse. WASI will improve things but at this point it is unclear how far browsers can actually go, beyond existing Web APIs, in exposing "operating-system-like features" to remote content.
I am opposing that to the closed world of frameworks.
Sure. But the reality is that the browser is the client runtime for the web, not the operating system the browser is running on (and in the mobile space the OS fragmentation is getting worse, not better).
WebAssembly is opening a world of software in the browser, in embedded devices, at the cloud, the edge, you name it.
Yes but in embedded systems, the cloud, and the edge we are talking about installed software, not just-in-time delivery over a perhaps questionable network which web content has to contend with - installation of PWAs is optional (usually to support offline functionality), not mandatory.
Standards can succeed when they are enough low-level and well-designed that you can construct higher abstractions on top of them.
The issue is that for decades we have enjoyed the benefits of Moore's law to create the additional headroom needed to afford new abstractions - but that's done now.
As developers we are entering a phase where we need to make harder choices of where we are going to spend our users' runtime resources. This has been historically an issue for the video games industry which typically had to work on low(er) cost platforms. So they have been using Data-Oriented Design (Shooting Yourself in The Foot With OOP) and Entity Component Systems - and other industries are starting to notice.
So it seems only natural if the web at some point will divert away from the monolithic (SPA-style) apps that are preferred on desktop and native.
My point about WebAssembly is that by targeting a common standard agreed on by many vendors, developers have the freedom to develop in several languages (Rust, C, C++, Go, and a few more in a growing list). That allows to reuse and compose existing software written in different languages. In short, we have reusability, we have interoperability, and we have composability (well the specifications still have to improve in that direction with interface types and module linking to make this friendly but we'll get there eventually). That is a benefit of standards that are agreed and negotiated on by several vendors. I am opposing that to the closed world of frameworks.
Before WebAssembly we had Google NaCL as an attempt to run native code written in other languages. That was proprietary and not really interoperable. WebAssembly is opening a world of software in the browser, in embedded devices, at the cloud, the edge, you name it. That is why I say that there is lot to win to achieve interoperability instead of duplicating libraries or solutions for each framework.
So that is an example of the benefits of standards. Standard can succeed when they are enough low-level and well-designed that you can construct higher abstractions on top of them.
Even Go is exhibiting the problems that I was highlighting. A simple "Hello World" file generates a 1.3 MB
wasmfile. One way to whittle that down is to use TinyGo - but this comes at the cost of features and acceptance of limitations.Many consider C#/Blazor another hopeful but that also clocks in at a 1.6 MB
wasmfor "Hello World" due to the overhead of the .NET CLR.Compare that to a suggested JS performance budget of 170KB (0.7MB uncompressed) for an entire page (where the runtime already exists in the browser).
And people who think that the Networks will save us will be disappointed. Consider this quote:
Networks are experiencing a similar phenomenon. Subscriber growth and demand is outstripping the gradual theoretical improvements in peak performance and capability, often resulting in a degradation of the average network quality experience in some areas.
The majority of existing software hasn't been written with the constraints of the web in mind - be it issues like the "subset of the Go" supported by TinyGo or that web content has to work without the luxury of prior installation or the constraints imposed on generalized distributed computing by the "laws of physics" or security.
As a result there'll be a lot of rewriting where people are expecting reuse. WASI will improve things but at this point it is unclear how far browsers can actually go, beyond existing Web APIs, in exposing "operating-system-like features" to remote content.
Sure. But the reality is that the browser is the client runtime for the web, not the operating system the browser is running on (and in the mobile space the OS fragmentation is getting worse, not better).
Yes but in embedded systems, the cloud, and the edge we are talking about installed software, not just-in-time delivery over a perhaps questionable network which web content has to contend with - installation of PWAs is optional (usually to support offline functionality), not mandatory.
The issue is that for decades we have enjoyed the benefits of Moore's law to create the additional headroom needed to afford new abstractions - but that's done now.
As developers we are entering a phase where we need to make harder choices of where we are going to spend our users' runtime resources. This has been historically an issue for the video games industry which typically had to work on low(er) cost platforms. So they have been using Data-Oriented Design (Shooting Yourself in The Foot With OOP) and Entity Component Systems - and other industries are starting to notice.
So it seems only natural if the web at some point will divert away from the monolithic (SPA-style) apps that are preferred on desktop and native.
Related:
Why the #wasmsummit Website isn't written in Wasm
Polyglot WebAssembly