Edit: This is not a technical post, but exists overarchingly as a take from a distance. I consume available cursory information about WASM, but I have no technical experience using it, especially at an enterprise level. With that in mind: see what I get right, and see what I get wrong.I have recently seen references to the idea of using unikernels and containers, which (for all I know) might actually be closer in effect to a virtual architecture.
WASM has had a long run already, but has not exploded the way many people had said and believed that it would.
A lot of the WASM dissappointment I have seen seems misunderstood. I think people wanted WASM to fit a narrow identity - to fit it into a smaller box than what it is.
And then judging WASM by applying it to existing JavaScript solutions is a little strange, because they only have the requirements of JavaScript applications. You would try to test relative speed by attempting to apply JavaScript to cases where WASM is supposed to facilitate more capabilities.
It also seems like testing latency when that does not capture the whole picture.
WASM is More Like an Architecture Right?
WASM is based on an idea like JAVA I guess. JAVA has a virtual machine that enables it to run on many machines the same way. You have to install and update the JAVA virtual environment, so that you can run JAVA applications.
Except JAVA is one language. WASM is a target to which any number of languages (but specifically the languages' builders) can choose to compile to. The timeframe of adoption by multiple different languages exists not as a single act, but of many different acts by many different decision makers.
This is different than JAVA or another single language team deciding platform compatibility. On top of this, it is for both the web, and for different hardware platforms. There is nothing else quite like it. WASM is waiting there ready for language developers to build into it when the time feels right to them.
When the comparison brakes down, WASM has an advantage over hardware architectures in lasting power, and waiting power. Because, from the perspective of the app developers, WASM stays the same, and lets the hardware change underneath it. Language compilers do not have to be updated nearly as much as for hardware architecture changes.
Many hardware architectures fail to be realized, but WASM is something different because it is open, and because it is virtual.
When the comparison brakes down, WASM has an advantage over hardware architectures in lasting power, and waiting power. Because, from the perspective of the app developers, WASM stays the same, and lets the hardware change underneath it. Language compilers do not have to be updated nearly as much as for hardware architecture changes.
Many hardware architectures fail to be realized, but WASM is something different because it is open, and because it is virtual.
RISC-V Marketing Rhetoric?
RISC-V's marketing rhetoric describes why it can be similar to other tech, but also different. The significance of this is that RISC-V does not have to be vastly superior in speed to have a particular edge on value.
- RISC-V is open and adaptable
- RISC-V does not hinge on a single company's financial success.
- RISC-V is inevitable, because of what it is, and how it is
- RISC-V has enormous coverage potential accross hardware types
(By the way, what else does this describe? . . . The very successful Linux kernel.)
On a different note, these characteristics circle around a description of WASM being a long-term manifestation. This is one reason why WASM's curve could end up being longer than other language echo systems, and even hardware architectures.
Additionally, WASM does not necessarily have to be rushed to market. It has time to mature, because JavaScript and other solutions already exist. It is a forward thinking technology.
"Write Once, Run Anywhere" But Be the Best?
- An additional abstraction
- A larger grouping of expressions attempting to translate multiple other feature sets expression
The first problem means that there will always* be a performance hit compared to running on hardware.
The second problem is two-fold. It means that the more hardware types there are, then the more intrinsically impossible it is to accomodate all variation. It also means that the expression of interfacing with this is a human abstraction layer. In other words, the human knowledge base of the expression will have to be larger.
The importance of these issues' existence is that they are inherent to the definition of the promise of doing more with less. The goal is very simply stated, but difficult to accomplish: Minimize these negative effects as much as possible.
The perfect engine will never exist, but it does not make sense to give up on added efficiency.
The technological premise of WASM is that it is more low level, as compared to something like the JAVA virtual machine. Every low-level software technology benefits incrementally from a constant churning of changes that tweaked performance year by year. Filesystems for example see efficiency tweaks continually throughout their entire lifespans.
This in essence is the benefit of being a large project that a lot of parties have interest in for an extended period: you get the necessary steady flow of attention. The idea that WASM is like an architecture, but also runs on multilpe architectures is awesome. It creates a positive feedback loop, because more people are interested in maintaining it. Of course its openness also contributes to this positive feedback loop.
For individual languages, the same thing exists, but not necessarily by definition. Typically it is by chance that the particular language has caught on. While nobody can predict the future, WASM's definition and form make it a different proposition.
WASM Feature Overload
In the case of architecture features that get expressed in WASM, WASM cannot be a strict superset of every conceivable feature that any architecture has. That being said, the breadth of support can be segmented into multiple categories, and gain larger coverage than other single architectures.
Solutions Other Than WASM
An application will always run faster on bare hardware. People have very many variables to consider when choosing the right tools for their job. However WASM has very uniquely compelling advantages, especially amidst considering virtual and container solutions.
WASM vs JavaScript
That being said, JavaScript was additive to HTML and CSS. It did not supplant them. One form of WASM has turned into something similar from what I understand. It may evolve as a very common additive measure for the performance tasks that demand it just like JavaScript has with HTML and CSS.
There probably will not be another JavaScript, in how it became ubiquitous, at least in the same timeframe as JavaScript did it. If WASM "takes over", it will not be because it dominated in convenience and performance in a 5-year period, but because JavaScript only slowly died over 20 years or so. (It is weird that anyone got convinced this would happen.)
I suppose JavaScript dominated PHP. And Django never got huge. I think Go has proven a more direct comparison to JavaScript than WASM. Go wins, and it is a little faster as well. But for some odd reason, JavaScript still persists and nobody cares.
JavaScript vs WASM History
JavasScript History
- 1993 - 1995: Creation
- 1997 - 2000: Standardization
- 2008: V8 and JIT (15 year mark)
- 2009: Node.js
- 2012 - 2014: TypeScript (20 year mark)
- 2015 - 2024: Maturation (30 year mark)
- 2025 on: Node.js challengers (15 years of Node.js)
WASM History
- 2015 - 2017: Creation
- 2017 - 2019: Browser compatibility
- 2024 - WASI 0.2.0 (9 years)
- 2025 on: More developer comprehension (barely 10 years)
Of Note: WASI Incomplete
This is understated. WASI standardization is taking a very long time. 2024 only just saw preview 2, which by-the-way has some very important features for creating WASM libraries.
Imagine JavaScript without JIT, and that is potentially comperable to what is going on with WASM and WASI.
Of Note: 32 vs 10 years
WASM is 22 years younger than JavaScript. And indeed WASM is still developing in impactful ways.
WASM's Killer App
Node.js came out 15 years after JavaScript started.
While a lot of the tooling around WASM might seem mature enough, a lot of the tooling is created with obvious forced intention. Often times, the best things happen in their own time.
While a lot of the tooling around WASM might seem mature enough, a lot of the tooling is created with obvious forced intention. Often times, the best things happen in their own time.
Duh, WASM is About Higher and Vaster Performance Loads
But in this case, there could actually be a web app that truly demonstrates - not why WASM is great, but why people want more performance on the web.
What is it that people want and need to do on the web for which this performance is so awesome?
There might be a lot more apps that follow along some kind of collective realization. (I suppose that is what a killer app is.)
But Do People Even Want Web 3.0?
Also, web 3.0 would only be realized retroactively anywaze. People would have to have some drive for more features. I am not even sure people are dying for more kinds of stuff to go on the web for.
We live in a time when many people might not be very fond of the web actually. Web 2.0 seems to have seriously let people down, and to be truly seen by many for being a data mining tool to abuse the masses.
Maybe there will be a web 3.0, but it could be a while. It needs to be better to its users than 2.0 has been.
I think no matter what though, performance requirements will creep higher and higher over time, even if there is not a distinct identification of a Web 3.0.
People act like WASM has a deadline, but this is weird.
WASM Reason 1: The commonality in a virtual architecture with the potential reach of WASM is so much of what makes it a good idea.
WASM Reason 2: Supposing WASM enables much higher performance loads of more varied types, then the desire for this would seem to naturally accelerate with time.
Conclusion
WASM Reason 1: The commonality in a virtual architecture with the potential reach of WASM is so much of what makes it a good idea.
WASM Reason 2: Supposing WASM enables much higher performance loads of more varied types, then the desire for this would seem to naturally accelerate with time.
WASM Considerations:
- WASM will probably not get significantly faster than it is now, but the fact that it is already fast means that it makes sense on more than just paper.
- After this, it is just about the tooling that other people use to funnel it into different purposes. This is what JavaScript went through.
- WASM is exactly the type of technology that must work in tandem with increased performance capabilities and increased performance demands of its surrounding technologies. It crucially does not exist in that particular vacuum.
- The impact of WASI's future progressive completion can be huge.
- WASM's debut was not "timed" well politically or economically.
- WASM's marketing hype was off kilter in many ways
