4 ms·

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 arguabl

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

wybiral 10y ago
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.
orangecat 10y ago
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.
- wybiral 10y ago
  > 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 https://en.wikipedia.org/wiki/List_of_JVM_languages
  - throwawaysbdi 10y ago
    :) 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.
orangecat 10y ago
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.
Rusky 10y ago
WebAssembly also lacks Javascript's problems with its tool ecosystem, syntax, and exception handling system.
tdeck 10y ago
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!
- throwawaysbdi 10y ago
  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.
- flukus 10y ago
  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.
  - beagle3 10y ago
    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).
HugoDaniel 10y ago
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
- dawidloubser 10y ago
  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.
  - HugoDaniel 10y ago
    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 ?
    - dawidloubser 10y ago
      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/044101.html http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/0441...
rocqua 10y ago
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.
- bzbarsky 10y ago
  > Java applets never had, and never were planned to, have access to the DOM. Well... see https://en.wikipedia.org/wiki/NPAPI#LiveConnect 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.
douche 10y ago
Or Flash, for that matter. We keep trying to rebuild what we used to have, using shittier tools.
Tloewald 10y ago
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).

wybiral 10y ago

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.

orangecat 10y ago

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.

wybiral 10y ago
> 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 https://en.wikipedia.org/wiki/List_of_JVM_languages
- throwawaysbdi 10y ago
  :) 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.

orangecat 10y ago

Rusky 10y ago

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

tdeck 10y ago

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!

throwawaysbdi 10y ago
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.
flukus 10y ago
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.
- beagle3 10y ago
  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).

HugoDaniel 10y ago

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

dawidloubser 10y ago
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.
- HugoDaniel 10y ago
  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 ?
  - dawidloubser 10y ago
    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/044101.html http://www.xent.com/pipermail/fork/Week-of-Mon-20070219/0441...

rocqua 10y ago

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.

bzbarsky 10y ago
> Java applets never had, and never were planned to, have access to the DOM. Well... see https://en.wikipedia.org/wiki/NPAPI#LiveConnect 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.

douche 10y ago

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

Tloewald 10y ago

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