I'm not sure how it's for others, but for me there was a perception issue with java applets on the web in the mid 2000s:
Java applets loading on a website started as a gray rectangle, which loaded very slowly, and sometimes failed to initialize with an "uninited" error. Whenever you opened a website with a java applet (like could happen with some math or physics related ones), you'd go "sigh" as your browser's UI thread itself halted for a while
Flash applets loading on a website started as a black rectangle, did not cause the UI thread to halt, loaded fast, and rarely gave an error
(the only reason I mention the gray vs black rectangle is because seeing a gray rectangle on a website made me go "sigh")
JavaScript was not yet optimized but the simple JS things that worked, did work without loading time.
Runescape (a 3d MMORPG from the early 2000s that still exists) used Java though and somehow they managed to use it properly since that one never failed to load and didn't halt the browser's UI either despite being way more complex than any math/physics Java applet demo. So if Java forced their applets to do whatever Runescape was doing so correctly, they'd not have had this perception issue...
The fact that we said “Java” and you went to thinking about “Java applets” is part of the problem. Java was meant to be a universal executable format. It ended up confined to the web (mostly, at least in the popular consciousness).
Well actually that was because the topic of the article was webassembly :) I have seen Java used for backends / software as well (and other than the lack of unsigned integers for e.g. crypto/hashing/compression/..., and lack operator overloading for e.g. vectors/matrices/bigints/..., it's 'fine' to me)
But that’s the point! “Web” Assembly really has nothing to do with the web, or browsers :) It came out of the web standards groups, that’s all. It is an architecture agnostic executable format.
That's because Java used the old piece-of-shit NPAPI (Netscape Plugin Application Programming Interface) from 1995, first released in the NetScape 2.0b3 Plug-in SDK:
>I hope NetScape can come up with a plug-in interface that is good enough that they can implement their own navigator components with it (like the mail reader, outliner, progressive jpeg viewer, etc). The only way it's going to go anywhere is if they work closely with developers, and use the plug-in interface for non-trivial things themselves. Microsoft already has a VRML plug-in for their navigator, so presumably they have a plug-in interface, and from what I've seen on their web site, it may not be "good enough", but it's probably going to do a lot more that you can do with NetScape right now, since they're exposing a lot of their navigator's functionality through OLE. They seem to understand that there's a much bigger picture, and that the problems aren't trivial. Java isn't going to magically solve all those problems, folks.
>Wow, a blast from the past! 1996, what a year that was.
>Sun was freaking out about Microsoft, and announced Java Beans as their vaporware "alternative" to ActiveX. JavaScript had just come onto the scene, then Netscape announced they were going to reimplement Navigator in Java, so they dove into the deep end and came up with IFC, which designed by NeXTStep programmers. A bunch of the original Java team left Sun and formed Marima, and developed the Castanet network push distribution system, and the Bongo user interface editor (like HyperCard for Java, calling the Java compiler incrementally to support dynamic script editing).
>At the time that NSAPI came around, JavaScript wasn't really much of a thing, and DHTML didn't exist, so not many people would have seriously thought of actually writing practical browser extensions in it. JavaScript was first thought of more as a way to wire together plugins, not implement them. You were supposed to use Java for that. To that end, Netscape developed LiveConnect.
>Microsoft eventually came out with "ActiveX Behavior Components" aka "Dynamic HTML (DHTML) Behaviors" aka "HTML Components (HTCs)" that enabled you to implement ActiveX controls with COM interfaces in all their glory and splendor, entirely in Visual Basic Script, JavsScript, or any other language supporting the "IScriptingEngine" plug-in interface, plus some XML. So you could plug in any scripting language engine, then write plug-ins in that language! (Easier said than done, though: it involved tons of OLE/COM plumbing and dynamic data type wrangling. But there were scripting engines for many popular scripting languages, like Python.)
>Though Netscape has ceased development efforts on its Java-based browser, it may pass the baton to independent developers.
Shockwave (the Macromedia Director Player Library) came long before Flash, and it used NPAPI (and ActiveX on IE), but later on, Google developed another better plug-in interface called "Pepper" for Flash.
1995: Netscape releases NPAPI for Netscape Nagivator 2.0, Macromedia releases Shockwave Player on NPAPI for playing Director files
1996: Microsoft releases ActiveX, FutureWave releases FutureSplash Animator and NPAPI player for FutureSplash files, Macromedia acquires FutureSplash Animator and renames it Flash 1.0
2009: Google releases PPAPI (Pepper Plugin API) as part of the Native Client project, suddenly Flash runs much more smoothly
I asked a number of times on HN why wasm was good when java applets, exactly the same thing, were bad. There was a vague feeling that java applets were insecure and that this would somehow not be an issue for wasm.
It's not just applets; we also had Flash, which was a huge success until it was suddenly killed.
As far as I can tell, the difference between java applets and Flash is that you, the user, have to install java onto your system to use applets, whereas to use Flash you have to install Flash into your browser. I guess that might explain why one became more popular than the other.
> There was a vague feeling that java applets were insecure and that this would somehow not be an issue for wasm.
Nothing "vague" or "somehow" about that.
Applets were insecure, because A) they were based on the Netscape browser plugin API, which had a huge attack surface, and B) they ran in a normal JVM with a standard API that offeres full system access, restricted by a complex sandbox mechanism which again had a huge attack surface.
This IS, in fact, not an issue for wasm, since A) as TFA describes it has by default no access at all to the JavaScript browser API and has to be granted that access explicitly for each function, and B) the JavaScript browser API has extremely restricted access to OS functionality to begin with. There simply is no API at all to access arbitrary files, for example.
There wasn't a vague feeling. Both kept getting exploited. My favorite is Trusted Method Chaining, which is hard to find a reference on now, but showed the whole Java security model was fundamentally flawed. These days that security model has simply been removed: all code in the VM is assumed to run in the privilege level of the VM.
WASM sandboxes the entire VM, a safer model. Java ran trusted and untrusted code in the same VM.
Flash, while using the whole-VM confinement model, simply had too many "boring" exploits, like buffer overflows and so on, and was too much of a risk to keep using. While technically nothing prevented Flash from being safe, it was copyright Adobe and Adobe didn't make it safe, and no one else was allowed to.
I don't think "exactly the same thing" is accurate. And WASM has put more effort into sandboxing, both in the design (very limited interfaces outside the sandbox) and implementations (partially because we've just gotten a lot better at that as an industry).
WASM doesn’t feel like an “applet” and can be either seamlessly integrated or take over the space.
Applets felt horrible, maybe if they appeared today it would be different but back then the machines were not powerful enough and the system not integrated enough to make it feel smooth.
Every few months Sun / Oracle would release a new update requiring new incantations in the manifest files. If you didn't constantly release patched versions of your applet, your software stopped working.
Javascript from 20 years ago tends to run just fine in a contemporary browser.
abundance of the runtime, ease of distribution of programs, the permission model which was bolted on, appropriate sandboxing mechanism leading to authorisation problems and performance when people were not ready to sacrifice a very significant amount for no reason.
Oh, and breaking changes between versions meaning you needed multiple runtimes and still got weird issues in some cases.
Because the underlying philosophy was not the same.
Java bytecode was never originally intended as a generic low-level assembly language. Its semantics are defined largely by the needs of Java the language, which means that, on one hand, it doesn't even have pointers (only object references; so you can't e.g. point into the middle of an array), and, on the other hand, it has opcodes like "call method" that map nicely to what Java does but not necessarily to what other languages do.
wasm, on the other hand, is sufficiently low-level that you can compile C into it.
Oracle bought Sun and now owns Java, remember? All technical discussions about Java -vs- any other languages can now be immediately terminated by mentioning the word "Lawnmower", which overrides all technical issues.
Java didn't fail, it was replaced by the web to a large part, but remains strong not only as the original JVM, but the Android clone and .NET. As for why the clones... IP issues. Otherwise Java would dominate, like the web does.
Um, Java has dominated enterprise computing, where the money is, for 25+ years.
There's no money in browser runtimes. They're built mostly defensively, i.e., to permit ads or to prohibit access to the rest of the machine.
> why would wasm succeed when the underlying philosophy is the same?
wasm is expressly not a source language; people use C or rust or Swift to write it. It's used when people want to move compute to the browser, to save server resources or move code to data instead of data to server. Thus far, it hasn't been used for much UI, i.e., to replace Javascript.
Java/Oracle spent a lot of money to support other JVM languages, including Kotlin, Scala, Clojure - for similar reasons, but also without trying to replace Javascript, which is a loss leader for Google.
