7 ms·

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

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 6y ago
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?
- dtech 6y ago
  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.
- other_herbert 6y ago
  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.
- AndrewStephens 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
    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).
- bitwize 6y ago
  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 6y ago
    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 6y ago
      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.
- hajile 6y ago
  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 6y ago
    Oh, but they did. The DOM API was there from about 1.3 (iirc).
- kalleboo 6y ago
  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.
commandlinefan 6y ago
> 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.

ethbr0 6y ago

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?

dtech 6y ago
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.
other_herbert 6y ago
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.
AndrewStephens 6y ago
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 6y ago
  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 6y ago
    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 6y ago
  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).
bitwize 6y ago
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 6y ago
  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 6y ago
    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.
hajile 6y ago
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 6y ago
  Oh, but they did. The DOM API was there from about 1.3 (iirc).
kalleboo 6y ago
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.

commandlinefan 6y ago

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