8 ms·

So basically we're reinventing the JVM and it's ecosystem?

pjmlp 2y ago
Yeah, by folks that most likely used to bash Application Servers from early 2000's. 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.
- thot_experiment 2y ago
  The coolness of WASM is that I can run WASM on like 99.999% of the targets I care to run code on with zero friction. Everyone (well it's HN so someone is probably on LYNX) reading this page is doing so in a browser with a WASM runtime. That has tremendous value.
  - pjmlp 2y ago
    Applies to most bytecode formats, it is a matter of implementation.
    - marcosdumay 2y ago
      It never applied to any web bytecode formats, and applies to very few local local ones (arguably, none). It's just a matter of having everybody agree to install the same interpreter, yes. That never happened before.
      - pjmlp 2y ago
        Another example of lack of computing history. 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.
        thot_experiment 2y ago
        You're missing the forest for the trees. You already have the bytecode interpreter in front of you and so does everyone else. You are already running it, the difference between "it's definitely already running" and "you could trivially make this work if you put a bit of effort in" is enormous.
        marcosdumay 2y ago
        Never happened before. 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.
  - anthk 2y ago
    Not Lynx as it doesn't show up the correct layout on comments. 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.
- iforgotpassword 2y ago
  That's a bit oversimplified. I had this thought too and tried to figure out why this is different, and I think there are some major points. The biggest one is in which order they were built and designed. If we take Java and ask why applets didn't take off since they could do everything WASM offers and more, two things come to mind: it was fucking slow on contemporary machines, and the gui framework sucked. WASM is the complete opposite. The gui framework is HTML/CSS, which despite its idiocy in many places had a long time to mature and we've generally came to accept the way it works. Now we just tacked a powerful VM onto it so we don't need to target slow Javascript. There isn't even a new language to learn, just compile whatever you want to WASM, which means you can use a familiar and mature dev environment. 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.
  - singularity2001 2y ago
    Any reasonable interaction between WASM and JS/DOM gets postponed seemingly indefinitely though.
  - pjmlp 2y ago
    Same premise of many other bytecode formats since 1958, a matter of implementation and marketing.
  - kaba0 2y ago
    Wasm is more open, because we effectively have 1.5 browsers left, and whatever google decides will be the de facto “web standard” everyone should follow. If google were pushing for a slightly revamped jvm/applet model, that would be the standard (as the JVM is as open/standardized as it gets)
    - pjmlp 2y ago
- SkiFire13 2y ago
  All of those bytecode formats were designed to support higher abstractions. WASM on the other hand was born from asm.js, which tried to remove abstraction to make code run faster. Ultimately the goal for WASM was to run code faster, hopefully near native speed, which is not a priority for all the bytecodes you mentioned. If that wasn't needed then Javascript would have been enough.
  - pjmlp 2y ago
    Revealing lack of knowledge, some of those bytecode formats were designed for low level languages like Pascal, Modula-2, C, C++, among others.
palmfacehn 2y ago
If your webserver is already JVM based, there's no context switch between the webserver and the application. Not sure how this would be solved with WASM.
- SkiFire13 2y ago
  This doesn't make sense, WASM is supposed to run on the client, which is generally a different machine than the webserver, while a context switch is an event that happens within a single machine.
  - palmfacehn 2y ago
    From the article: >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.
  - mlnj 2y ago
    WASM on the server also means that an execution engine that containerizes and runs server code in one of the many languages without the overhead of an entire OS like we do with containers now.
thot_experiment 2y ago
Sort of yes, but WASM is designed with a different set of constraints in mind that make more sense when you just want to shove the runtime into your whatever. Sometimes reinventing X with lessons learned is actually a great idea.
mlhpdx 2y ago
Yes, and the .Net CLR, etc.
epistasis 2y ago
The JVM is great and all, but that doesn't mean that it is the be-all end-all of the genre. And having mucked with class loaders and writing directly in JVM assembly in the 2000s as part of programming language classes, I'm not sure that the JVM is even a very high point in the genre. 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.
singularity2001 2y ago
except that WASM has a huge classloader / linker problem: It's still very hard to combine two wasm files into one and get the memory merger right. Maybe component model can fix it but it comes with so much bloated nonsense that an adaption in Safari might take forever.
- iainmerrick 2y ago
  It's a problem for some use cases, but is it really a "huge" problem in general? 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?
  - flohofwoe 2y ago
    The only situation I can think of is a plugin system for native applications, where 'WASM DLLs' would solve a lot of issues compared to native DLLs. 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).
    - nilslice 2y ago
      this is exactly what we created Extism[0] and XTP[1] for! [0]: https://extism.org https://extism.org [1]: https://getxtp.com 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.
  - fwsgonzo 2y ago
flohofwoe 2y ago
In a way yes, except that WASM supports many more languages (e.g. back when I started to look into running C/C++ code in the browser - around 2010 or so - it was absolutely impossible to compile C/C++ to the JVM, which at the time would have been nice because Java Applets still were a thing - of course WASM didn't exist yet either, but Emscripten did, which eventually led to the creation of WASM via asm.js).

Yeah, by folks that most likely used to bash Application Servers from early 2000's. 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.

thot_experiment 2y ago
The coolness of WASM is that I can run WASM on like 99.999% of the targets I care to run code on with zero friction. Everyone (well it's HN so someone is probably on LYNX) reading this page is doing so in a browser with a WASM runtime. That has tremendous value.
- pjmlp 2y ago
  Applies to most bytecode formats, it is a matter of implementation.
  - marcosdumay 2y ago
    It never applied to any web bytecode formats, and applies to very few local local ones (arguably, none). It's just a matter of having everybody agree to install the same interpreter, yes. That never happened before.
    - pjmlp 2y ago
      Another example of lack of computing history. 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.
      - thot_experiment 2y ago
        You're missing the forest for the trees. You already have the bytecode interpreter in front of you and so does everyone else. You are already running it, the difference between "it's definitely already running" and "you could trivially make this work if you put a bit of effort in" is enormous.
      - marcosdumay 2y ago
        Never happened before. 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.
- anthk 2y ago
  Not Lynx as it doesn't show up the correct layout on comments. 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.
iforgotpassword 2y ago
That's a bit oversimplified. I had this thought too and tried to figure out why this is different, and I think there are some major points. The biggest one is in which order they were built and designed. If we take Java and ask why applets didn't take off since they could do everything WASM offers and more, two things come to mind: it was fucking slow on contemporary machines, and the gui framework sucked. WASM is the complete opposite. The gui framework is HTML/CSS, which despite its idiocy in many places had a long time to mature and we've generally came to accept the way it works. Now we just tacked a powerful VM onto it so we don't need to target slow Javascript. There isn't even a new language to learn, just compile whatever you want to WASM, which means you can use a familiar and mature dev environment. 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.
- singularity2001 2y ago
  Any reasonable interaction between WASM and JS/DOM gets postponed seemingly indefinitely though.
- pjmlp 2y ago
  Same premise of many other bytecode formats since 1958, a matter of implementation and marketing.
- kaba0 2y ago
  Wasm is more open, because we effectively have 1.5 browsers left, and whatever google decides will be the de facto “web standard” everyone should follow. If google were pushing for a slightly revamped jvm/applet model, that would be the standard (as the JVM is as open/standardized as it gets)
  - pjmlp 2y ago
SkiFire13 2y ago
All of those bytecode formats were designed to support higher abstractions. WASM on the other hand was born from asm.js, which tried to remove abstraction to make code run faster. Ultimately the goal for WASM was to run code faster, hopefully near native speed, which is not a priority for all the bytecodes you mentioned. If that wasn't needed then Javascript would have been enough.
- pjmlp 2y ago
  Revealing lack of knowledge, some of those bytecode formats were designed for low level languages like Pascal, Modula-2, C, C++, among others.

palmfacehn 2y ago

If your webserver is already JVM based, there's no context switch between the webserver and the application. Not sure how this would be solved with WASM.

SkiFire13 2y ago
This doesn't make sense, WASM is supposed to run on the client, which is generally a different machine than the webserver, while a context switch is an event that happens within a single machine.
- palmfacehn 2y ago
  From the article: >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.
- mlnj 2y ago
  WASM on the server also means that an execution engine that containerizes and runs server code in one of the many languages without the overhead of an entire OS like we do with containers now.

thot_experiment 2y ago

Sort of yes, but WASM is designed with a different set of constraints in mind that make more sense when you just want to shove the runtime into your whatever. Sometimes reinventing X with lessons learned is actually a great idea.

mlhpdx 2y ago

Yes, and the .Net CLR, etc.

epistasis 2y ago

The JVM is great and all, but that doesn't mean that it is the be-all end-all of the genre. And having mucked with class loaders and writing directly in JVM assembly in the 2000s as part of programming language classes, I'm not sure that the JVM is even a very high point in the genre. 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.

singularity2001 2y ago

except that WASM has a huge classloader / linker problem: It's still very hard to combine two wasm files into one and get the memory merger right. Maybe component model can fix it but it comes with so much bloated nonsense that an adaption in Safari might take forever.

iainmerrick 2y ago
It's a problem for some use cases, but is it really a "huge" problem in general? 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?
- flohofwoe 2y ago
  The only situation I can think of is a plugin system for native applications, where 'WASM DLLs' would solve a lot of issues compared to native DLLs. 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).
  - nilslice 2y ago
    this is exactly what we created Extism[0] and XTP[1] for! [0]: https://extism.org https://extism.org [1]: https://getxtp.com 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.
- fwsgonzo 2y ago

flohofwoe 2y ago

In a way yes, except that WASM supports many more languages (e.g. back when I started to look into running C/C++ code in the browser - around 2010 or so - it was absolutely impossible to compile C/C++ to the JVM, which at the time would have been nice because Java Applets still were a thing - of course WASM didn't exist yet either, but Emscripten did, which eventually led to the creation of WASM via asm.js).