So basically we're reinventing the JVM and it's ecosystem?
Sure, it allowed a large ecosystem, but holy crap is the whole JVM interface to the external world a clunky mess. For 20+ years I have groaned when encountering anything JVM related.
Comparing the packaging and ecosystem of Rust to that of Python, or shudder C++, shows that reinvention, with lessons learned in prior decades, can be a very very good thing.
You can't easily publish a library in WASM and link it into another application later. But you can publish it as C++ source (say) and compile it into a C++ application, and build the whole thing as WASM.
What are the scenarios where you really really want libraries in WASM format?
But those WASM plugins would be self-contained and wouldn't need to dynamically load other WASM 'DLLs', so that situation is trivial even without the WASM Component Model thingie (which I also think is massively overengineered and kinda pointless - at least from my PoV, maybe other people have different requirements though).
[0]: https://extism.org [1]: https://getxtp.com
XTP is the first (afaik) platform of its kind meant to enable an app to open up parts of its codebase for authorized outside developers to “push” wasm plugin code extensions directly into the app dynamically.
We created a full testing and simulation suite so the embedding app can ensure the wasm plugin code does what it’s supposed to do before the app loads it.
I believe this is an approach to integration/customization that exceeds the capabilities of Webhooks and HTTP APIs.
Or any other option. Really. So many investigations, so much time wasted.
>Wasm on the Server
>Why on earth are we talking about Wasm? Isn't it for the browser?
>And I really hope even my mention of that question becomes dated, but I still hear this question quite often so it's worth talking about. Wasm was initially developed to run high performant code in the web browser.
Not only JVM, also CLR, BEAM, P-Code, M-Code, and every other bytecode format since UNCOL came to be in 1958, but lets not forget about the coolness of selling WASM instead.
It's just a matter of having everybody agree to install the same interpreter, yes. That never happened before.
Never happened before, really?!?
What examples since 1958 would make you happy?
Burroughs, Corvus Systems, IBM, Apple, Unisys, MSR, embedded,....
Probably none of them, I bet.
And your list has no example of anything that was universally installed on everybody's system. The closest is IBM (if you mean x86 opcodes), but code for that one needed to be specialized by OS before it became ubiquitous, and got competitors before its main OS became ubiquitous, and then became ubiquitous again but with 2 main OSes, and then got competitors again.
But Dillo works perfectly fine. No JS, no WASM, crazy fast on a n270 netbook.
I can't barely run WASM programs that could be run fine under a Pentium 3-4.
The other point is that WASM is way more open than any of the mentioned predecessors were. They were mostly proprietary crap by vendors who didn't give a shit (flash: security, Microsoft: other platforms) so inevitably someone else would throw their weight around (Apple) to kill them, and with good reason. WASM is part of the browser, so as a vendor you're actually in control regarding security and other things, and are not at the mercy of some lazy entity who doesn't give a damn because they think their product is irreplaceable.
And no, for reasons stated before an applet model would never become the standard again. You'd rather have to integrate Java with the browser so it's entirely under your control, and considering how massive it is and how hard it was to properly sandbox it, nobody in their right mind would decide on this. WASM reuses a lot of infrastructure already there, it's simply the best solution from a technical standpoint.