[AndrewStephens]

Partly marketing but the integration certainly existed. As I recall, public methods in the main applet class are exposed to JavaScript. It was a little slow and clunky but it worked.

The idea was similar to how web components are used today. Your web page would contain custom applets for a fancy input field, a calendar control date picker, and whatever other controls html didn’t provide, all implemented as Applets.

It could have worked out and the web today would have looked very different except that Java applets always performed terribly on first load. Nobody wanted to have their customers wait 30 seconds for the custom controls to initialize.

I sometimes wonder what might have been if Sun had actually fixed the initialization of Applets. In many ways Applets were nicer to develop than today’s web components.

[ethbr0]

Technically, why are / were Java applets so slow? I never dug into the ecosystem deeply enough to understand (plus a bit before my time).

Was it JVM startup time, Java xfactory-begat-y-begat-z code init time, what?

Also, applets run outside the browser, correct? I.e. on the browser's host system in a separate JVM process?

[AndrewStephens]

Sun seemed to have a real mental block when it came to applets - people screamed at them for years about performance and they refused to do anything about it. Indeed, in 1995 the simpliest applet would take several seconds to appear. In 2005 (about the time everyone stopped caring), the same applet would take ... several seconds to appear. They never got faster even as CPUs improved by several hundred percent.

The Applets ran fast enough (even on 1995 machines) once loaded, at least fast enough to be useful. But that delay at startup when your CPU went to 100% and your hard drive buzzed away, freezing everything else you machine was doing, just killed any interest the public had in using applets.

Part of the problem is that they JIT'ed everything without caching it and that included the standard Java libraries. So every applet started to execute, called some standard API, the API was JIT'ed, that called some other part of the API which was JIT'ed, etc, etc. I could never understand why they didn't compile at least the standard libraries on install or first use and save the result.

[ethbr0]

From everything I've touched Sun was always very... Unix in regards to UX.

As in "Well, just learn to deal with it. And be grateful you have a graphical interface at all."

Making things better, or pushing the state of graphical presentation art never seemed to even be a core interest, much less competency.

Which is ironic, because a lot of that organizational choice seems reflected in Java, e.g. having to boil the ocean and re-implement everything for major arch changes.

[smm11]

Sun briefly toyed with OpenStep, or essentially the UI of the NeXT machines that morphed into today Apple's OS X interface.

Anything would have been better than CDE or OpenWindows at the time, and the NeXT GUI was quite innovative in the 90s.

[DonHopkins]

I always thought JIT should be spelled JATWPT, for Just At The Worst Possible Time (when the user's waiting for the app to start up).

[lenkite]

This was deliberate - they were afraid Java would become too popular on the browser side and people would stop buying their heavyweight servers. They always pushed Java as the server side language. If they wanted Java at the client side - they wanted pure Java clients (webstart, etc) not browsers hosting Java applets. Browsers hosting Java applets were sneered upon.

JS eventually won the game here after IE advanced Web 1.0 with great support for AJAX, etc.

The funny thing is that if Sun was on the ball and didn't abandon HotJava, your modern day browser would have been a Java app.

[anthk]

>your modern day browser would have been a Java app.

Not so distant to J2ME browsers like Opera Mini, and today with Android I am not sure. Chrome is C++, but on Android everything gets blurred.

[pram]

Yeah I dunno about that. HotJava was aggressively awful to use.

[AndrewStephens]

I agree. One of the many, many, many areas where Sun dropped the ball was the failure to implement a good HTML control in Java. HotJava was very basic.

[lolive]

I think they still have the problem today. Which makes any JVM language to be slow to run in elastic environments (where hardware instances and server runs quickly come and go depending on the load).

[bitwize]

The browser had an embedded JVM and applets ran right on the page. It was very similar to WebAssembly today, just a fair bit chuggier.

Two things caused people to backpedal from the applet strategy:

1) Because there was a large hiring pool of millions of fresh grads leaving college with a little Java under their belts, it having displaced C++ and Pascal as an introductory language, companies began Java projects and Java came to be seen as an enterprise language.

2) The JVM that Microsoft implemented inside IE had proprietary Microsoft extensions for greater Windows integration. Sun sued Microsoft over this, and won. After this, Sun pivoted to having Java be a browser plug-in in order to provide a consistent cross-browser experience, rather than having each browser vendor provide their own implementation. The browser plug-in was way clunkier even than the original embedded JVM was.

[Mountain_Skies]

The death of Microsoft's JVM is when I lost most of my interest in Java. I understand why Sun didn't want Microsoft's JVM to exist. They could see Embrace, Extend, Extinguish coming for them but wow, did Microsoft's version ever work better. I did go on to create a good bit of Java code professionally but never touched it for hobby work.

It really hurt Java in the browser when Microsoft refused to ship Sun's code with Windows. Not sure why Sun assumed that after suing Microsoft about the JVM, they'd be willing to distribute Sun's bits for them. They really seemed surprised and angry when this happened and were unprepared for it. Maybe pivoting to browser plug-ins was the only way forward they could see. Seems like the actual path forward would have been to make the Sun JVM better.

[ethbr0]

It was a weird time.

Now, there's a straightforward business case and examples of the many strategic and financial benefits of owning development and guidance of an open platform.

Then... you either owned a platform completely (closed) or didn't (someone else owned it). Vis: all the bs machinations around proprietary Unix distributions.

Sun + Microsoft was likely seen more in the context of "ceding ownership to Microsoft" than "growing the platform, that we still have majority ownership of."

Ultimately, hardware vs platforms thinking. Or my-share-of-zero-sum vs growing-the-market. Unfortunate.

[kalleboo]

My memory of the time (as a Mac user) was that the JVM startup time was the big killer. It took like 30-60 seconds, during which it completely froze the (cooperatively-multitasked) OS. Of course it ate up a big chunk of memory at a time when our Mac had 16-24 MB of RAM total. And Netscape 3 was unstable enough that in a decent browsing session you'd have to relaunch it 2-3 times (each time unloading the JVM). Lowering the available memory of course worsened the stability.

The applets themselves performed alright. They took a few seconds to initialize but we were used to waiting for JPEGs and hover effects to load over a 14.4 modem so that wasn't too bad relatively.

[other_herbert]

They didn’t have to be slow and you can communicate between the two with a parameter in the applet tag “ mayscript” with that methods in the applet could be called from JavaScript. I used that for an invisible applet that would handle communication and drawing HTML to the browser.. kind. Spa like way back in the Wild West days when applets could nearly do anything.

[hajile]

Java apps didn't integrate with regular HTML. They were more like Flash apps with all those downsides.

Even today JS is interpreted before compiling to bytecode because the startup latency is much lower (JIT only kicks in once the background parsing is complete). Back in those days, the extent of JS was a few click handlers or similar. The JS interpreter would be done long before the JVM was even loaded into memory.

[mikro2nd]

Oh, but they did. The DOM API was there from about 1.3 (iirc).

[dtech]

A combination of needing a heavyweight VM separately from the browser and being either interpreted or having to wait for a slow JIT.

Remember Javascript was slow as ass too until the late 2000's when browsers were implementing efficient JS engines. If web pages would've been build like common JPAs they would've been as bad as applets.

[commandlinefan]

> the integration certainly existed.

Definitely. Even the fourth edition of Javascript: The Definitive Guide (published in 2002) still had an entire chapter on Java/Javascript compatibility.