1. 21
  1.  

  2. 12

    I have to wonder whether wide-spread adoption of Java applets might have led to an outcome qualitatively better than the modern web. I mean, the Java runtime was intended to be an application platform, whereas the web is a document delivery system abused and contorted to make do as an application platform.

    1. 12

      Except we had widespread adoption of java applets and the web platform turned out to be a better application platform. On the desktop we’re running VS Code (the web platform) rather than Eclipse (Java).

      I wrote Java applets professionally in the 90s and then web apps. Even back in the pre dynamic html days native web apps were better for most interesting stuff.

      1. 4

        we had widespread adoption of java applets

        We did?

        My memory isn’t what it used to be but I can’t remember a single instance of seeing this in the wild.

        1. 4

          I remember quite a few. Maybe you didn’t really notice them? Even today I occasionally run across a site with an applet that won’t load, especially older sites for demonstrating math/physics/electronics concepts. It also used to be a popular way to do remote-access tools in the browser, back when you couldn’t really do any kind of realtime two-way communication using browser APIs, but you could stick a vnc viewer in an applet.

          1. 1

            Aha; now that you mention it I do remember using a VNC viewer that was done as an applet, and also an SSH client. So I don’t think I ever used a Java applet on my own computer, but I did use a couple in university when I was stuck on a Windows machine and didn’t have anything better around.

          2. 4

            They were supported in all popular browsers. Java was widely taught and learned. There definitely were lots and lots of applets deployed but compared to the web they were bad for actually building the applications people wanted to use.

            1. 4

              I recall Yahoo using these for apps/games and what not.

              1. 4

                Not widespread like today where a large fraction of websites run JS on load. But I did run across pages here and there that would present an applet in a frame on the page, and you’d wait for it to load separately.

                1. 3

                  Runescape Classic xD

              2. 9

                I have to agree with ianloic. Applets just didn’t work very well. They weren’t part of the web, they were a (poorly designed) GUI platform shoehorned into a web page with very limited interconnection. And they were annoyingly slow at the time.

                Flash was a much more capable GUI but still badly integrated and not web-like.

                With HTML5 we finally got it right, absorbing the lessons learned.

                1. 8

                  With HTML5 we finally got it right, absorbing the lessons learned.

                  Now, instead of a modular design with optional complexity (user installs/loads given module only when needed), we have bloated web browsers consisting of 20+ millions lines of code with complexity that is mandatory often even for simple tasks (e.g. submit a form with some data, read an article or place order in an e-shop).

                  1. 6

                    Very strongly agree.

                    Back when Flash was widespread, it didn’t seem that popular - it was a delivery mechanism for overzealous advertising that jumped all over content. People were happy to embrace the demise of Flash because Flash was a liability for users.

                    What we have today are synchronous dialog boxes that jump all over content which are very difficult to remove because they’re indistinguishable from the content itself. The “integration” has meant it can no longer be sandboxed or limited in scope. The things people hated about Flash have become endemic.

                    The web ecosystem is not doing a good job of serving users today. I don’t know the mechanism, but it is ripe for disruption.

                    1. 3

                      Flash was also a delivery mechanism for games and videos that entertained millions, and educational software that probably taught more than a few people. If you think games, videos, and education beyond what flat HTML can provide are not “valid” that’s fine, but Flash filled a role and it served users.

                      1. 3

                        I didn’t mean to suggest that all uses of flash are not “valid”; if there was no valid use, nobody would intentionally install it. I am suggesting that it became misused over time, which is why Steve Jobs didn’t encounter too much resistance in dropping it.

                        But the real point from franta which I strongly agree with is being a plugin model it was relatively easy for users to enable when the content really needed it, and leave disabled in other cases. Personally I had two browser installs, one with flash and one without. That type of compartmentalization isn’t possible with HTML5.

                    2. 3

                      Optional complexity is not the right choice in this context. Nobody wants to design an experience where most users are just met with complex plug-in installation instructions. One of the best parts of the HTML5 ecosystem is that it’s largely possible to make websites which work on most of the browsers your users are actually going to use.

                      I agree that the complexity of “HTML5” is a problem. Maybe it would be nice to have two standards, one “simplified” standard which is basically Google’s AMP but good and standardized, and one heavy-weight standard. Simpler websites like news websites and blogs could aim to conform to the simplified standard, and simple document viewer browsers could implement only the simplified standard. But it definitely 100% wasn’t better when the “web” relied on dozens of random proprietary closed-source non-standard plug-ins controlled by single entities with a profit motive.

                    3. 2

                      I think that’s an overstatement. We haven’t gotten it right yet. Browser APIs are getting decent, but HTML+CSS is not a felicitous way to represent a UI. It’s a hack. Most everything to do with JavaScript is also a hack, although on that front we’ve finally started to break the “well, you have to write JS, or transpile to JS, because JS is the thing browsers have” deadlock with WASM, which finally offers what Java and Flash had a quarter century ago: compact bytecode for a fairly sensible VM.

                    4. 4

                      The biggest problem was that Java wasn’t integrated with the DOM. The applet interface was too impoverished.

                      jQuery had a nice tight integration that was eventually folded into the browser itself (document.querySelector). And if you look at modern frameworks and languages like React/preact, Elm, etc. you’ll see why that would continue to be a problem.

                      They use the DOM extensively. Although interestingly maybe the development of the virtual DOM would have been a shim or level of indirection for Java to become more capable in the browser.

                      The recent Brendan Eich interview has a bunch of history on this, i.e. relationship between Java, JavaScript, and the browser:

                      https://lobste.rs/s/j82tce/brendan_eich_javascript_firefox_mozilla

                      1. 3

                        It was in fact perfectly possible to manipulate the DOM from an applet (although at some level you did still need to have the applet visible as a box somewhere; I don’t think it was possible or at least frictionless to have “invisible applets”).

                        I would instead say the biggest problem was the loading/startup time; the JVM was always too heavy-weight; there was a noticable lag while applets started up; early on it would even freeze the whole browser. There were also a lot of security issues; the Java security model wasn’t great (it was fine in principle, but very difficult to get right in practice).

                        Now, funnily enough, the JVM can be much more light-weight (the “modules” effort helps, along with a raft of other improvements that have been made in recent JDKs) and the startup time is much improved, but it’s too late: applets are gone.

                        1. 2

                          I don’t think it was possible or at least frictionless to have “invisible applets”

                          it totally was. Make them 1x1 pixel large and use css to position them off screen. I have used that multiple times to then give the webpage access to additional functionality via scripting (applets could be made accessible to JS)

                          Worse: the applets could be signed with a code signing cert which gave them full system access, including JNA to FFI call into OS libraries.

                          Here is an old blog post of mine to scare you: https://blog.pilif.me/2011/12/22/grave-digging/

                          1. 1

                            It was in fact perfectly possible to manipulate the DOM from an applet

                            How? I don’t recall any such thing. All the applets I used started their own windows and drew in them.

                              1. 1

                                OK interesting. It looks like this work was done in the early 2000’s. I think it must have lagged behind the JS implementations but I’m not sure. In any case jQuery looks a lot nicer than that code! :)

                          2. 2

                            In that interview, Brendan noted that JavaScript was async, which helped adoption in a UI world. It’s true, it made it nearly impossible to block a UI on a web request.

                            1. 3

                              Yes good point. IIRC he talks about how JavaScript was embedded directly in Netscape’s event loop. But you can’t do that with Java – at least not easily, and not with idiomatic Java, which uses threads. As far as I remember Java didn’t get async I/O until after the 2000’s, long after Javascript was embedded in the browser (and long after Python).

                              So yeah I would say those are two absolutely huge architectural differences between JavaScript and Java: integration with the DOM and the concurrency model.


                              This reminds me of this subthread with @gpm

                              https://lobste.rs/s/bl7sla/what_are_you_doing_this_weekend#c_f62nl3

                              which led to this cool experiment:

                              https://github.com/gmorenz/async-transpiled-xv6-shell

                              The question is “who has the main loop”? who can block? A traditional Unix shell wants to block because wait() for any process is a blocking operation. But that conflicts with GUIs which want to have the main loop.

                              Likewise Java wants the main loop, but so does the browser. JavaScript cooperates better by allowing callbacks.

                              When you have multiple threads or processes you can have 2 main loops. But then you have the problem of state synchronization too.

                        2. 7

                          End of an era… I remember the heady days of the early web, with stuff like “push technology”, applets, VRML, and the like. So many ideas that never worked out, for good reasons.

                          1. 8

                            Flash effectively became the new Java applet, and now there’s no more Flash. No reason for the Java applet to come back.

                            1. 4

                              Flash was very lightweight and amazingly powerful, before Adobe bought Macromedia and slowly rotted it to garbage. Apple insisting it was a no-go on their first venture into the smartphone market also gave it pause.

                              Java applets were always problematic when it came to performance, which is what allowed Flash to thrive. It is the end of an era for sure.

                              1. 7

                                One might say that Flash died once it started to want to look like Java (AS3 and later, AIR). To this day, we still don’t have a visual interactive editing environment like Flash. It was the VisualBasic for creative coders.

                                1. 2

                                  Flash, too, was a document system (well, animations) that got pushed to be an application layer.

                            2. 3

                              Does any of the Applet APIs happen to get used inside the interior of non-Applet java GUI applications, I wonder?