Hacker News Reader

Comment by SquibblesRedux | Hacker News Reader

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.)

View on HN

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?

>- 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.

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.

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.

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.

Write once, run anywhere ;)

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.

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.

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.

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.

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.

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.

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

One thing I am missing here. Docker, as much as it has the shortcomings you list, has an entire fleet of posix libraries, utils and tools at its availability. This has meant 99% of applications could wholesale lift their application and deploy it within a container. When I look at WASM/WASI there is no networking API, no storage API, crypto, etc etc. I can see its value for offloading parts of a web application that require a more speedy execution, but I cannot see anyway of running a full headless application which is where containers are hugely utilised right now.

Yeah, progress on WASI has been painfully slow.

I think a big reason is that it was pushed by Mozilla, but they laid off all the related employees, and now no-one is really allocating resources to push it forward.

Plus it's still blocked by related proposal like interface types.

I know what WASI is, my point is that there is no where near parity with existing posix implementations. I have been following the bytecode alliance and webassembly communities for a while and they can't seem to get beyond the design phase. You only need to look at the networking API [0] and the thread has not been updated for two months, with prior to that folks asking is the work even happening still

[0] https://github.com/WebAssembly/WASI/issues/370

What's preventing the compilation of dependencies to WASM? Couldn't I (at extreme) run an alpine linux container distro inside WASM? At that point we're full circle, but it should be possible, right?

Very informative, thank you.

Thanks for the explanations.

What is that wasm project you're working on, if it has been publicly announced / released? It sounds very similar to Microsoft's Krustlet.dev and Suborbital's Atmo: https://github.com/suborbital/atmo

With all due respect, do you know anything about Java?

What do you think it is? https://docs.oracle.com/javase/specs/jvms/se7/html/

And no, Java is absolutely not a huge runtime - it is a simple stack-based vm with garbage collection made originally for goddamn TV set-top boxes, so it has an absolutely small instruction set. It just happens to be so good for multitudes of reasons that the biggest implementation (yes, it has absolutely insane amount of ones, tour claim of wasm having multiple implementations is just ridiculous compared to the amount of jvms), OpenJDK basically runs the backend of a great deal of all significant web applications.

Fun exercise: write a simple compiler with a JVM output. The JVM stack language is so easy, and it's the best way to explore it / something like it!

(Otherwise you're spot on and the GP clearly has no idea about Java)

I am (somewhat) familiar with the JVM.

Yes, it's also a stack based VM that is relatively small, at least superficially.

It's really not that simple though. Things like GC, exception handling, a whole class model with constructors and methods, ... All of that brings countless implicit requirements that are only passingly mentioned in the spec. Plus the whole host of complexity needed in practice for supporting the Java Platform.

Core Webassembly has nothing of that.

But to be fair: Webassembly is also growing more and more complex (SIMD, reference types, GC, interface types, module linking, tail calls, exceptions, ...)

Can the JVM be what Webassembly is? Or the CLR, for that matter? Technically: of course.

My point was really more about the ecosystem as a whole. JVMs were never really intended as a general purpose, multi/cross language ecosystem of generic computation. And everything around it is noticeable. In the build tooling, in the libraries, in the development process and focus, the lack of AOT until recently (in open source implementations), ....

Sure, that's changing now with GraalVM and a focus on cross language support. There are some extremely cool things happening there.

I'd still much rather bet on an ecosystem based on an open standard with lots of interest from different parties.

In fact, GraalVM already supports Webassembly, including WASI! So in certain sense Wasm is already more general.

> the lack of AOT until recently (in open source implementations)

The gcc project had a now discontinued AOT java compiler 2 decades ago.

Java is as open as it gets, with a standard, that can be changed through a community process. I feel the web is much less open with behemoths having basically infinite veto powers like google apple microsoft.

> In fact, GraalVM already supports Webassembly, including WASI! So in certain sense Wasm is already more general.

And teavm can run java byte code both in js as well as wasm :D

> Java is as open as it gets, with a standard, that can be changed through a community process.

Isn't the JCP also controlled by a hand full of corporations? Seems pretty much the same to me.

> And teavm can run java byte code both in js as well as wasm

Hah! I didn't know TeaVM had a WASM target, that's actually great to know.

> The gcc project had a now discontinued AOT java compiler 2 decades ago.

Was that ever really production ready?

Yes, Red-Hat used to AOT compile Eclipse with it.

A little bit of an addendum: what will make or break WASM is language support.

If enough languages get official or high quality wasm targets, it has a bright future.

Sadly progress has stalled a little bit here, partially due to very slow progress on some features important for higher level languages.

But we'll see how things develop.

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/ . And GraalVM itself is designed to support a wide range of programming languages.

Reply on news.ycombinator.com