6 ms·

Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for

Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)

pie_flavor 5y ago
Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not, under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work with than Flash, it tried to do both and ended up doing neither. So, why should WASM succeed where Java failed? Well, for pretty much every actual reason Java failed. There's really no places to compare them. WASM is implemented in-browser (and the runtime is very small), it's got a ~1.5x slowdown compared to the 2.5x-3x of the big clunkers like Java and C#, and most importantly it knows its place: low level computation. It does not try to do GUI, but leaves that up to the environment; it does not try to do a high level object model, but leaves that up to the language being compiled for it. What reason do you see that Java failed that's also applicable to WASM?
- charcircuit 5y ago
  >- it was not, under any circumstances, performant It was performant enough for one of the most popular games of all time, Minecraft, which was originally a game in a Java applet.
  - kaba0 5y ago
    As mentioned, that happened much later, so it is irrelevant. But for the others, java is insanely fast today, with pretty much the state of the art GC it has. In practice, a really significant chunk of all important server backends run on the JVM.
  - pie_flavor 5y ago
    Minecraft was started in 2009. Applets were one of Java's flagship features, i.e. released well before the VM became in a performant enough state.
  - the_duke 5y ago
    Incidentally, Minecraft Java has always had horrible performance, to the point where it was rewritten in C++. There are two versions of Minecraft now. The main reason Minecraft Java is still alive is the hackability and the resulting extensive mod ecosystem.
    - pjmlp 5y ago
      It was rewritten in C++, because Playstation, XBox, iOS, Android[0] don't do Java and Microsoft wanted a single codebase. [0] - Android Java isn't really the same Java as in Minecraft.
      - jacquesm 5y ago
        Write once, run anywhere ;)
- SquibblesRedux 5y ago
  In the 1990s I was building, among other things, web-based controls (in Java) for backend systems. People were completely blown away with what could be done. (The major competing technology was HTML forms and HTTP PUT with Perl CGI.) With the exact same language I was also able to build a high-performance peer-to-peer file sharing system for backend systems. (2+GB files to personal workstations across a large geographic area through ATM -- practically in real time compared to the NFS alternatives.) There was every reason to believe that Java's portability and just-in-time technologies would dominate the computing landscape. I think we can look to Sun Microsystems (and now Oracle) for reasons why Java was eclipsed[0] by other technologies. I have no idea what kind of longevity WASM will have, but I have seen so many technologies come and go over the decades, I know technical excellence is not the primary predictor of what stays or goes. [0] Yes, there is a pun buried in there.
  - johannes1234321 5y ago
    A big difference: As a user I could "feel" whenever a Java Applet was loaded. Suddenly everything became slow and only rarely the GUIs were acceptable. That diminished reputation in users, aside from security problems etc. With WASM the user doesn't notice it. Without looking at dev tools you can't tell if some of the functionality is coming from wasm or JavaScript/typescript/.. In consequence users won't develop the "yikes, Java" reaction. wasm got the chance to slowly creep into stacks.
- kaba0 5y ago
  I always feel these comparisons do not make much sense - it’s like comparing some pre-industrial thing with its today’s equivalent: browsers were simply absolutely not what they are now. Like, 2 of your points were simply politics, where js just happened to get chosen, while performance got rapidly faster in the coming years. If anything, Java was well ahead of its time and the surrounding environment was not yet ready.
the_duke 5y ago
There are fundamental differences here. Webassembly is a small stack machine based on an open standard. It is built bottom up, with a very small core. Additional features like SIMD, garbage collection,posix style system interfaces (WASI), linking, garbage collection,... are built as optional extensions based on real world feedback. There already are a multitude of different implementations. (the three browsers, the Wasm3 interpreter, wasmtime, Wasmer, ... ) Java, in contrast, was and is a huge runtime , not based on a standard, and has extremely complex semantics, many of them tied to a single language model. Wasm is already seeing adoption across a wide range of domains. I do believe the potential for WASM to succeed where Java failed is wide open.
- jvanderbot 5y ago
  So, honest question. if we're compiling our code to run on servers, why are we compiling it to run on a bytecode interpreter rather than native? My single use for docker is to containerize / isolate, not to run across architectures. I get the in-browser optimized / compiled code. That makes sense.
  - the_duke 5y ago
    Wasm doesn't have to run in an interpreter. Many of the runtimes (like Wasmtime, Wasmer) compile the Webassembly to native machine code first. But that native code is still constrained by the Wasm security/sandboxing model, which includes memory isolation. (there is no direct memory sharing between the host and a Webassembly instance) A few benefits why it is even useful in a server context: You can distribute a single (small!) artifact and run it everywhere. On a developer machine, on Windows, on a x86 server, on an ARM server, ... Right now you have to build a separate Docker image for each architecture. And Docker is really a second class citizen on Windows. Docker images have a huge dependency: an entire operating system syscall API and an entire userspace (with libraries, binaries, a file system, ...) The surface for a Wasm module is much smaller. Building a Docker image is a somewhat redundant exercise of picking a base image, figuring out the dependencies, keeping it up to date, ... None of that should be necessary. Security is another benefit. The vulnerability exposure of a Wasm module is much lower than that of an entire OS + userspace sandbox. Wasm is designed around isolation. In addition, the interface types proposal + WASI is pushing capability based security that works by passing around capabilities, which is a pretty great model. I outlined some more benefits here a few days ago: https://news.ycombinator.com/item?id=30020121&p=2#30020964 https://news.ycombinator.com/item?id=30020121&p=2#30020964
62951413 5y ago
The parallels with the JVM are obvious on multiple levels. In case of WASM I'm curious specifically about cross-language portability. We have learned from the JVM that while technically possible it may not be a popular choice. Java/Kotlin/Scala ecosystems diverged quickly. So WASM could become a browser technology the way JVM became a strictly server-side thing. Or allow backend developers build frontend applications in a language they are used to. On a related note, there's something funny about everyone stacking on top of each other. At some point Java will be probably compiled to WASM. You already can go in the other direction with https://www.graalvm.org/22.0/reference-manual/wasm/ https://www.graalvm.org/22.0/reference-manual/wasm/ . And GraalVM itself is designed to support a wide range of programming languages.

pie_flavor 5y ago

Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not, under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work with than Flash, it tried to do both and ended up doing neither. So, why should WASM succeed where Java failed? Well, for pretty much every actual reason Java failed. There's really no places to compare them. WASM is implemented in-browser (and the runtime is very small), it's got a ~1.5x slowdown compared to the 2.5x-3x of the big clunkers like Java and C#, and most importantly it knows its place: low level computation. It does not try to do GUI, but leaves that up to the environment; it does not try to do a high level object model, but leaves that up to the language being compiled for it. What reason do you see that Java failed that's also applicable to WASM?

charcircuit 5y ago
>- it was not, under any circumstances, performant It was performant enough for one of the most popular games of all time, Minecraft, which was originally a game in a Java applet.
- kaba0 5y ago
  As mentioned, that happened much later, so it is irrelevant. But for the others, java is insanely fast today, with pretty much the state of the art GC it has. In practice, a really significant chunk of all important server backends run on the JVM.
- pie_flavor 5y ago
  Minecraft was started in 2009. Applets were one of Java's flagship features, i.e. released well before the VM became in a performant enough state.
- the_duke 5y ago
  Incidentally, Minecraft Java has always had horrible performance, to the point where it was rewritten in C++. There are two versions of Minecraft now. The main reason Minecraft Java is still alive is the hackability and the resulting extensive mod ecosystem.
  - pjmlp 5y ago
    It was rewritten in C++, because Playstation, XBox, iOS, Android[0] don't do Java and Microsoft wanted a single codebase. [0] - Android Java isn't really the same Java as in Minecraft.
    - jacquesm 5y ago
      Write once, run anywhere ;)
SquibblesRedux 5y ago
In the 1990s I was building, among other things, web-based controls (in Java) for backend systems. People were completely blown away with what could be done. (The major competing technology was HTML forms and HTTP PUT with Perl CGI.) With the exact same language I was also able to build a high-performance peer-to-peer file sharing system for backend systems. (2+GB files to personal workstations across a large geographic area through ATM -- practically in real time compared to the NFS alternatives.) There was every reason to believe that Java's portability and just-in-time technologies would dominate the computing landscape. I think we can look to Sun Microsystems (and now Oracle) for reasons why Java was eclipsed[0] by other technologies. I have no idea what kind of longevity WASM will have, but I have seen so many technologies come and go over the decades, I know technical excellence is not the primary predictor of what stays or goes. [0] Yes, there is a pun buried in there.
- johannes1234321 5y ago
  A big difference: As a user I could "feel" whenever a Java Applet was loaded. Suddenly everything became slow and only rarely the GUIs were acceptable. That diminished reputation in users, aside from security problems etc. With WASM the user doesn't notice it. Without looking at dev tools you can't tell if some of the functionality is coming from wasm or JavaScript/typescript/.. In consequence users won't develop the "yikes, Java" reaction. wasm got the chance to slowly creep into stacks.
kaba0 5y ago
I always feel these comparisons do not make much sense - it’s like comparing some pre-industrial thing with its today’s equivalent: browsers were simply absolutely not what they are now. Like, 2 of your points were simply politics, where js just happened to get chosen, while performance got rapidly faster in the coming years. If anything, Java was well ahead of its time and the surrounding environment was not yet ready.

the_duke 5y ago

There are fundamental differences here. Webassembly is a small stack machine based on an open standard. It is built bottom up, with a very small core. Additional features like SIMD, garbage collection,posix style system interfaces (WASI), linking, garbage collection,... are built as optional extensions based on real world feedback. There already are a multitude of different implementations. (the three browsers, the Wasm3 interpreter, wasmtime, Wasmer, ... ) Java, in contrast, was and is a huge runtime , not based on a standard, and has extremely complex semantics, many of them tied to a single language model. Wasm is already seeing adoption across a wide range of domains. I do believe the potential for WASM to succeed where Java failed is wide open.

jvanderbot 5y ago
So, honest question. if we're compiling our code to run on servers, why are we compiling it to run on a bytecode interpreter rather than native? My single use for docker is to containerize / isolate, not to run across architectures. I get the in-browser optimized / compiled code. That makes sense.
- the_duke 5y ago
  Wasm doesn't have to run in an interpreter. Many of the runtimes (like Wasmtime, Wasmer) compile the Webassembly to native machine code first. But that native code is still constrained by the Wasm security/sandboxing model, which includes memory isolation. (there is no direct memory sharing between the host and a Webassembly instance) A few benefits why it is even useful in a server context: You can distribute a single (small!) artifact and run it everywhere. On a developer machine, on Windows, on a x86 server, on an ARM server, ... Right now you have to build a separate Docker image for each architecture. And Docker is really a second class citizen on Windows. Docker images have a huge dependency: an entire operating system syscall API and an entire userspace (with libraries, binaries, a file system, ...) The surface for a Wasm module is much smaller. Building a Docker image is a somewhat redundant exercise of picking a base image, figuring out the dependencies, keeping it up to date, ... None of that should be necessary. Security is another benefit. The vulnerability exposure of a Wasm module is much lower than that of an entire OS + userspace sandbox. Wasm is designed around isolation. In addition, the interface types proposal + WASI is pushing capability based security that works by passing around capabilities, which is a pretty great model. I outlined some more benefits here a few days ago: https://news.ycombinator.com/item?id=30020121&p=2#30020964 https://news.ycombinator.com/item?id=30020121&p=2#30020964

62951413 5y ago

The parallels with the JVM are obvious on multiple levels. In case of WASM I'm curious specifically about cross-language portability. We have learned from the JVM that while technically possible it may not be a popular choice. Java/Kotlin/Scala ecosystems diverged quickly. So WASM could become a browser technology the way JVM became a strictly server-side thing. Or allow backend developers build frontend applications in a language they are used to. On a related note, there's something funny about everyone stacking on top of each other. At some point Java will be probably compiled to WASM. You already can go in the other direction with https://www.graalvm.org/22.0/reference-manual/wasm/ https://www.graalvm.org/22.0/reference-manual/wasm/ . And GraalVM itself is designed to support a wide range of programming languages.