8 ms·
Sun tried that, back in the day. Maybe you heard about Java applets, maybe you didn't. They were the slowest thing about the web, insecure even with a sandbox,
by mark242 10y ago
Sun tried that, back in the day. Maybe you heard about Java applets, maybe you didn't. They were the slowest thing about the web, insecure even with a sandbox, and just an overall pain. Short of having a jvm always running on your machine, the performance of Android-via-Chrome will completely turn people off the Android ecosystem.
- MarkMc 10y agoSun's execution was poor. Google's doesn't have to be.
- justicezyx 10y agoEric Schmit come from Sun...
- josefx 10y agoI remember two issues with Java Applets: * Java itself was slow for a long time * The Browser would hang while loading an Applet The first is no longer an issue. They can just use a modern just in time compiler and it wont run slower than Java on Android. Chrome already has one to deal with JavaScript powered Web 2.0 applications. The second was as far as I can tell an API issue. Applets would block everything by default until they were loaded. A really bad idea in a single threaded environment when you had to send several MB over low bandwidth and the JVM itself took long to start. Just making the load async with a completion callback could have solved this issue and I remember a few Applets that actually used an async download to reduce the hang.
- username223 10y agoYou missed the biggest issue: "write once, mediocre everywhere." Windows, Mac, and X were all different, and Java Applets were necessarily bad at emulating all of them. While there are fewer Unices today, there are more GUIs, and cross-platform apps suck at least as much.
- scott_karana 10y agoYou missed the biggest difference: Chrome is the same everywhere.
- username223 10y agoSo were Java Applets with AWT. Users hated that, so Sun tried PLAF, a half-assed emulation of each platform. That didn't work either, so Applets died. If Chrome manages to provide better versions of most applications on most platforms, it may win. Otherwise, people who use those applications will hate it with the heat of a thousand Suns, and it will go the way of the Java Applet.
- josefx 10y ago> So were Java Applets with AWT. Users hated that, so Sun tried PLAF Uh, Java AWT was the native toolkit. Swing was the non native UI with the ugly METAL default Look and Feel. There are some nice custom Look and Feel implementations that don't try to emulate a platform, I think Matlab uses one for its UI.
- taneq 10y agoMaybe you somehow haven't noticed that even mobile devices now are an order of magnitude faster than desktop computers were back in the days of applets. Desktop computers can run Java applications with no significant overhead.
- ianai 10y agoNot totally. We support a number of java applets at work. The clients still take "way too long" to load and feel bloated. "Way too long" is a subjective measure based on the current hardware/OS. For a JVM to not feel slow it would have to speed up relative to itself...and I haven't seen them do that.
- RyanZAG 10y agoIf it's specific apps, usually it is just bad coding. 'Enterprise Java' style coding where performance is not even tested for, let alone designed into the algorithms. Usually culprits are things like downloading multiple data files in a single threaded block, or insanely deep object graphs with thousands of memory fetches per real operation. That's not really anything to do with the technique (code in browsers) or the runtime (JVM) or even the programming language (Java) -- and everything to do with poor development.
- ianai 10y agoThey're not really enterprise apps. They're just betting odds displays. But I hear you on the criticism of enterprise software still. I just don't think it's the thing here.
- reacweb 10y agoIMHO, the history was different. Java applets were initially secure in a sandbox and faster than what was possible with the "javascript" of that era. Applets have become slow to start many years latter when bloated "enterprise" applications have been produced in abusive ways. The security of applets has started to deteriorate a bit slightly before the death of Sun. It has become a security hell only since it is in the hands of Oracle.
- e98cuenc 10y agoThe startup time was horrible. The speed, once it was running, was good, but the startup time made it completely unusable on the web. The ugly default UIs in Java did not help. I did my fair share of applets back in the day, starting with the very first public versions and have very vivid memories of the loading screen :)
- whatusername 10y agoI always wonder -- if Sun had forced people to build their own loading screen UI per applet -- how the perception of Java (and Java Applets) would be different.
- OOPMan 10y agoIt's worth remembering that Applets were active at a time when the Internet, as a whole, was a lot slower. Although yeah, even with our newfangled fibre connections applets are still pretty bloated.
- pookeh 10y agoYou should also take into account that internet speeds of that era were not as great. Today, we download multiple megabytes of javascript. Back then downloading the same multiple megabytes of java was slow because of network. At least that was the case for me...
- 72deluxe 10y agoI recall loading webpages in IE where the browser would completely stop for 30 seconds while the JVM fired up. JavaScript at the time was mainly used for snow flakes on the web page or annoying mouse trails on the web page, as I recall. Oh, and maybe rollovers. I remember Microsoft pushing DHTML and seeing IE4 as a leap forward compared to IE3 but I do recall Java being slow. And slow.
- spullara 10y agoJava should have focused on manipulating the DOM rather than creating their own canvas. Was not obvious at the time though.
- pjmlp 10y agoYou mean like JavaScript nowadays uses Canvas and WebGL?
- andybak 10y agoIt's fairly rare to have web UI's built with canvas and WebGL - usually because they need to do something that is impractical using the DOM. They'll still use the DOM for the more conventional parts of the UI.
- lmm 10y agoI think the key difference is you get to that incrementally. You start by "making the monkey dance" on an otherwise-static page, and you can work your way up to rendering everything on a fully-programatically-controlled canvas, a little bit at a time. Forcing you to do everything yourself from the start as TCL (remember tklets?) and Java did makes the barrier to entry much higher.
- mikro2nd 10y agoJava did have an API for accessing and manipulating the DOM since (iirc) JDK1.4 -- org.w3c.dom and sub-packages. It was not at all well known or publicised, though.
- spullara 10y agoYep, this is what I was referring to. It would have been really interesting had people started doing things with it.
- eklavya 10y agoWhat? Android runtime is not JVM, it's AOT compiled to native for quite some time now.
- zigzigzag 10y agoIt's a mix, actually.
- jonathanstrange 10y agoI agree on all counts, but have to say that Java Webstart was cool, it was a pretty neat way of installing and running applications directly from the web. Maybe not very secure, though. One problem I see with Google's ecosystem is that they've betted on the wrong horse - Java is a pain in the ass and Android's Java foundations are its second largest weakness. (The first one being the Google-Vendor relationship that makes all but the very latest Android devices unpatched and 100% insecure.)
- xg15 10y ago> ... Short of having a jvm always running on your machine ... This is basically how Dalvik/Zygote worked on actual Android. From what I know, Chrome too uses always-running background processes even if you don't have a browser window open (for mainentance work and to improve startup times). So I'd assume the project would do exactly that.