> With this in mind, maybe Wasm is mainstream. Spencer notes, for instance, that anyone who browses the web is likely to be interacting with WebAssembly on a daily basis.
I think that's correct. Non-Web usecases are a more complicated story (that the article focuses on), but the Web side is largely complete and successful, and that was the original purpose of Wasm. In that sense it's already succeeded.
Perhaps from a C++ perspective, say a monolith with kilobytes of bindings driving a canvas. Yet
> the original purpose of Wasm
includes, as per the charter, "and interoperate gracefully with JavaScript and the Web", which is far from complete and, thanks to WASI and the Component Model, hardly improving. I guess it will remain a mystery how WASI could basically replace something as obviously useful as WebIDL-bindings - that is, until someone figures out.
I get the desire for something more "elegant/clean" in this space, but JS is just very hard to beat on the bindings/glue side. I believe that's why approaches like WebIDL bindings did not turn out to be more efficient. I measured that on both code size and speed in Emscripten, for example, back in the day, and JS was good enough.
With WasmGC it is today possible to ship very small binaries, and the size of the bindings alongside them is generally not an issue, from what I hear from WasmGC-using toolchains like Java, Kotlin, and Dart. In fact they benefit a lot from the flexibility of those bindings, e.g. by being able to pull in random JS things (like strings support, RegExp, etc.).
Can WASM access the DOM? Or do you still have to go through a glacially slow Javascript export shim?
Would WASM directly accessing the DOM be an improvement of more than say 5%
Do you have some in mind?
Many more examples, such as those mentioned in this talk about Wasm usage in Google:
https://www.youtube.com/watch?v=2En8cj6xlv4
They mention Google Photos, Google Meet, Google Earth, TensorFlow.js, Ink, CanvasKit, Flutter, etc. And that is just inside Google - many other companies are using it, big and small, such as Figma, Unity, Adobe, etc.
I see a few major sites and some major plugins. The definition of "mainstream (as in used daily) site" may differ between groups.
I wasn't aware a new version of WASI was out. I've been following it for years and its potential is still exciting.
Some quotes:
> WASI 0.2 also introduces two distinct “worlds,” which describe different kinds of hosts that WebAssembly can run on. The first of these worlds is the “command” world, resembling a traditional POSIX command-line application with access to the file system, socket and terminal.
> The second of these worlds is the “HTTP proxy,” which characterizes platforms, like Fastly, that can send and receive streaming HTTP requests and responses, serving as forward or reverse proxies. These worlds represent the beginning of a broader ecosystem, offering developers multiple avenues to explore and innovate, and more worlds will be added to WASI in the future.
Just look at Ruffle (Flash Player reimplementation), V86 (x86 virtual machine), Google Earth, ...
Wasm on the Server is a fad, and sadly it's hijacking resources and design space from the real thing. WASI being a prime example: because of the "Component model", any attempt at tighter integration with the Browser API stopped in the hope for a magical solution to all computing problems.
Once the SIMD stuff is in, it may even have enough performance for music plugins. wasm codecs would be real cool too. Nobody likes having to build and install ffmpeg. `ffmpeg-4.0.wasm`... just imagine.
As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes.
Mind you the Hello World example executable is 80mb and takes 6 seconds to start, but I feel like with the garbage we are used to in regards to desktop applications, this totally holds up -doesn't everything else usually bundle all of chrome? I have also read there are simple command line options to reduce the size to about 50mb.
Why? Or rather, what's the alternative?
In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about.
Worse, it won't ever work if you intended it to be a JavaScript replacement because it cannot integrate into the interaction of the surrounding page, because it is a sandbox without compromise. This line of wishful thinking instills false hope and just pisses off everyone else, which slows adoption among other languages. The Web Assembly effort has been very clear about this from the very beginning, but people believe what they want to believe even after this has been clarified dozens of times.
There are absolutely valid business cases behind Web Assembly though, here are some:
* circumventing iphone restrictions
* desktop application portability
* security
* partial docker alternative
* promoting adoption and access of applications written lesser popular languages
I couldn't speak for "nearly all prior discussions", though I don't doubt there were many devs excited that they could bring their favourite language into a browser.
But if I remember correctly, WASM developed pretty directly out of asm.js, which was about bringing high performance code to the web. Yes, it was compiled from C, but not because people hated JS, but because writing the asm.js subset was awful, and writing C was a better way to target the low level high performance virtual machine.
Sure, there were plenty of existing libraries in C which were leveraged (e.g. the demo of Unreal running in the browser), but "I can compile a Python interpreter into a webpage" did not seem to me to be the reason for WASM, just a frivolous side-effect.
That is a pretty bold statement considering that Blazor actually does allow you to ditch JavaScript and very much integrates with the surrounding page.
It is true that for manipulating the DOM, Blazor internally needs to go through JavaScript as there are no direct WASM-to-DOM binding (yet).
But you, as a developer, can develop sites that runs its interactivity using webassembly instead of Javascript.
In some situations it is harder to support different desktop builds and this might unify that.
I don't think it is the strongest argument but at least on the margins it is an option I can see teams in some places choosing.
If you really want go to all-native JS because it has advantages, sure you can do. But what I see are bloated SPAs written in a language not designed for large software, based on an environment that likes to change and break things. It's abstractions upon abstractions get a hold of this mess.
I don't see why WASM couldn't compete.
On my job I have zero reasons to suggest it, given the split between FE and BE teams.
I'm not sure if I've ever encountered one in the wild, but to be fair I wasn't really looking.
React and other JS native frameworks, as much as they are looked down at from back end (especially dotnet devs) are miles ahead in terms of user experience and even actual development experience (good luck doing more than forms and basic stuff on blazor wasm for example).
It's for c#/dotnet devs that have a single hammer and hate learning new things so they will use csharp everywhere.
As to your point, can you show me a single user facing, non demo app or blazor related website that actually runs on blazor (especially wasm blazor) ? I'm curious to see why you think it's actually replacing or capable of replacing js on the front end.
The ongoing attempts to bring back application servers, but with Kubernetes, WASM and plenty of YAML, is a kind of tragic irony.
And on the browser, if one needs performance it is better served with GPU code than WebAssembly, other than bringing existing libraries into the browser.
At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations.
What? No! Would you suggest replacing e.g. the Linux kernel (parts of which are very performance critical) with GPU code too?
WebGPU is great for, well, GPU-like compute! That's not nearly all performance-critical compute. One example: Stockfish, a top chess engine, is exclusively CPU-based, and runs perfectly in WASM.
> At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations.
Couldn't disagree more. Flash, ActiveX and Java were unpopular because they all came with their own weird/non-native-feeling GUI toolkits and UI paradigms (e.g. breaking right clicks and text selection, Ctrl+F etc.). Flash and ActiveX were also closed source and only available on some platforms. ActiveX was also very badly sandboxed on top of all of that.
WASM is none of that. The only thing you'd notice e.g. about a site bringing its own media codec, game engine etc. in WASM instead of JavaScript is better performance.
Indeed WASM is nothing like yet bytecode being capitalised by startups, in search of the next Java goldmine, by folks that enjoy bashing about it. /s
App servers bad, Kubernetes with WASM, "oh boy that is soooo cool!".
This is the biggest limitation for me. I like WASM fine, but anytime I want to use it I have to turn back to Rust. I like Rust fine, but without support in other languages, it's not necessarily worth diving into.
Unlike those platforms however, the IL was actually interpreted by the ported .NET runtime. Only the runtime was actually running as WASM.
To this day this is still the default, but now you can use a compiler to compile from IL to WASM, and then run full WASM code in the browser. This toolchain is a bit slower on build, but the code will run much faster.
That's not to say that I don't see any benefit in it. I can see use cases for it, they just aren't use cases that I have.
WASM is the spiritual successor to that, getting rid of the (in retrospect quite hilarious) "embedded backwards compatibility layer".
edit: for the record, I think having only one doc type (html) and only one scripting language (js) in the browser is a terrible idea.
I don't know what the other doc types and programming languages should be but performance alone seems like a poor idea. A compile target seems even worse. :)
