Hacker News Reader

Comment by throwawaysbdi | Hacker News Reader

Is it just me or do Java applets seem like they were way the hell ahead of their time?

If the sandbox didn't have so many holes in it Java applets were arguably better for webapps than the unholy mess we've cobbled together over the last ten years to replace them.

It's sad to me that Java fell out of the browser and was replaced with a slow non standardized single threaded shit language for almost ten years just because Java didn't have DOM access.

JavaScript is just nearing Java feature parity and still not anywhere close for performance.

And I'll tell you what Java didn't have. A unfathomable clusterfuck of module systems, transpilers, shit build tools and IDE support, crazy syntax gotchas, unholy and inconsistent exception handling systems. God dammit what have we done.

Shakes cane at neighborhood kids

View on HN

I remember Java applets, and reading this thread it's hard to square the revisionist nostalgia with those experiences. The Java applets I remember absolutely sucked as a user. They took forever to load, had weird clunky UIs that were out of place in the host OS and the browser, constantly broke due to compatibility issues, and had no concept of graceful degradation. There's a reason Java applets lie in the dustbin of history - good riddance to them, it's where they belong!

The rose tinting of HTML should also be taken into account. Java was maybe 10x slower in those days, but more importantly internet was 100x slower and computers 500x slower.

Java ran pretty damn good for what it pulled off back then. It would have been orders of magnitude easier to make Java into what we have today than it was to bastardize HTML and JS to be usable.

Java these days uses native UI which looks nicer and is much faster than in-browser rending. Graceful degredation is only needed because some browsers are such crap. This was never a big problem in Java and still isn't. If a JVM supports JDK 8 you can expect it to run java 8 apps reliably

Java seems like a resource hog because it will use spare ram when you've got it, but most apps run fine on around 15mb of ram. Less if you use AOT compilation. Modern webapps use around 50-100.

Yes they were slow and clunky, but they ran on computers with 100Mhz processors and 8/16MB of RAM. I doubt you could load a chrome tab on that.

> had weird clunky UIs that were out of place in the host OS and the browser

Just like web apps, the may be prettier, but they look just as out of plus with custom widgets everywhere and complete disregard for the desktop theme. Hell, for some reason chrome added that shitty task bar color attribute that allows a web page to alter the desktop (well mobile top) theme.

Yes, but the competition at the time was HTML (slowly getting interactive with time, and mostly ugly, but fast and dependable), and Flash -- and Flash was way faster, way more compact, and way more prevalent than Java.

So, Java wasn't ahead of its time, and it was much much worse than Flash (which, despite numerous efforts to kill it, is still alive, unlike Java Applets which have essentially been dead for years).

I don't think flash was much better at anything interactive, or at least animated. On the same hardware as above I remember "frog in a blender" could render well south of 1FPS, on a 486/686 (outdated but still in common use) it was more like 0.1FPS.

Too be fair though, it's a hard comparison, applets were generally apps while flash was fancy graphics.

Java could have worked fine in the browser. All feature phones (which are/were almost universally less powerful than a desktop PC) were able to run Java ME applications just fine.

My memory from the mid/late nineties is that Microsoft wanted to balkanise Java with J++ (or was it J# ?) and got into a big argument with Sun, and because of this and the fact they eventually came to own the browser market there was no way they'd embed a JVM in the browser.

Sun/Oracle also took about a five year hiatus after Java 6, and let the platform languish during a critical period.

Ironically, MS browsers remain the only ones to support Applets today.

firefox extended support release has NPAPI support for another year: https://www.mozilla.org/en-US/firefox/52.0esr/releasenotes/

EDGE does not.

do Java applets seem like they were way the hell ahead of their time?

Pretty much. If Sun had made a decent plugin instead of expecting every browser to roll their own VM, and if AWT had been a lot less buggy, it could have worked.

A unfathomable clusterfuck of module systems, transpilers, shit build tools and IDE support, crazy syntax gotchas, unholy and inconsistent exception handling systems.

Amen. It's ridiculous how many millions of engineer-hours have been spent trying to turn JS into a usable environment.

> Amen. It's ridiculous how many millions of engineer-hours have been spent trying to turn JS into a usable environment.

It's not just JS: https://en.wikipedia.org/wiki/List_of_JVM_languages

:) if you'll notice maybe half of those are other languages adapted to the JVM to make them more usable, which should say something is redeeming about the JVM at least.

Java applets never had, and never were planned to, have access to the DOM. Without access to the DOM, they had to implement their own GUI from scratch. The Java UI experience has always suffered from it's platform-agnostic look that never fits in (and is just ugly).

Webasm still can't manipulate the DOM, so it's still not very useful as a replacement for JS, but it is planned. To really replace JS though, we'd need webasm to support garbage-collected languages for ease of use. Probably, some dynamically typed languages as well.

> Java applets never had, and never were planned to, have access to the DOM.

Well... see https://en.wikipedia.org/wiki/NPAPI#LiveConnect

Now it's true that it involved more hoops, especially for someone who just knew Java but not DOM bits, so implementing a GUI using Swing or whatever was a path of least resistance. But it wasn't the only path.

> Webasm still can't manipulate the DOM

Not directly, but via FFI to JS it can.... Pretty similar to LiveConnect in some ways.

Compile time in Java is way bigger than in JS. What do I need to do in order to compile a simple hello world in java ? In JS i only need the browser and a text editor if i'm fancy.

Java is slow on the first run (even if you admit it is just the JVM running your already compiled code). Try running a different java code in every site and you will understand why JS is prefered to it.

Also JS has a foot in functional programming and is much less verbose, it also has evolved to be even leaner. e.g. The current lambda syntax (fat arrows) is a treat

As a Java engineer, I'm enjoying ES6/7 development much more these days.

I wanted to point out, however, that Java 8/9 has excellent support for basic functional programming features, with an equally-nice syntax for lambdas, but with a good type system (via Functional interfaces) to boot.

The thing that I get hung up time and again, with ES6/7, is lack of a type system. We write some complex ES6/7 + Immutable JS apps (e.g. in the financial services domain), and haven't managed to extract full value from Flow or TypeScript just yet, due to library constraints etc.

Indeed, coming from a Haskell background I also have some problems with Flow. I spend more time struggling with it than with reaping the benefits it brings. Perhaps this will change in a near future.

I would like to look into the Java functional approach. Is there any reference you recommend ?

Java's type system and FP features are really weak compared to Haskell's :-) But it compares favourably with ES6's, until you start using ImmutableJS, and ES6 currying. Then Java lags far behind...

I've always been deeply into it, and using it for years at work, so no good off-hand reference. I'd be picking one as random as any web search that you'd perform, sorry!

I should never have learnt Haskell. It messes with your mind [1] whenever you write in any other programming language, yet you can hardly ever use it in practice. Well, certainly here in South Africa.

[1] Obligatory link: http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/0441...

Running babel is consistently slower than running MSBuild or javac in any of my projects. Not to mention all the other linting, uglifying, minifying, bundling and copying bullshit the gulp script is doing.

The same could be said about Netbeans or other specific optional parts of Java development. JS devs that target anything after the iphone 5S (2013, almost 4 years ago, before 64bit processors even arrived in android land) don't need to use babel, and arguably http2 takes most of the benefits from minifying and bundling.

It is amazing the amount of stuff that JS does if you don't follow the trends blindly and think a bit about your usage and tools.

The performance of JS these days, for such a dynamic language, is actually very impressive.

If Java were our only option I assure you we'd have come up with all kinds of crazy alternative systems of doing things.

Plus, targeting the JVM for weird transpiled language was what all of the cool kids did before doing it in JS became cool. This isn't unique to JS. It's probably unique to any language with that much adoption.

I was a very early adopter of java in the browser and we compared shockwave (Macromedia/Adobe Director) with java and despite java being so allegedly ahead of its time, shockwave was far better in all respects (speed, functionality, size, spinup time, user experience). And shockwave was awful (it was rendered irrelevant by Flash, which rose on its coat tails (SWF stands for "shockwave flash", although the two had nothing in common).

WebAssembly also lacks Javascript's problems with its tool ecosystem, syntax, and exception handling system.

Or Flash, for that matter. We keep trying to rebuild what we used to have, using shittier tools.

Reply on news.ycombinator.com