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.
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 :)
Although yeah, even with our newfangled fibre connections applets are still pretty bloated.
At least that was the case for me...
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.
* 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.
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.
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.
For example, look at Windows 10 and the mishmash of controls (are they flat? or do they have a bevel?) available from the control panel, settings app, old COM dialogs, MMC etc. etc.
What choice do we have? Everyone's doing their own walled garden, so it's not like I can go and find an alternative SaaS / operating system with same features but better UI...
One of the last straws for me was the built in mail app that had this awful background image. Too many flashbacks of shitty access apps.
One thing that strikes me as weird is that almost any widget set that does it's own drawing or even just it's own automatic layout and tries to match look and feel of native UI invariably does not match even the basic look because various UI components use wrong size, are placed slightly differently and so on. For example everything I've ever seen that tried to match how windows 3.1 Ctrl3D looked draws window decorations one pixel narrower than the original, which is plainly visible and ugly, similarly things that attempt "looking like Motif" usually use different thickness for various lines and borders and also often mix-up meaning of focus rectangle (which should move by tab) and bevel around default button (which should stay in the same place irrespective of which control has focus). I see no technical reason why either of these things cannot be done right, is there some legal reason for introducing such small differences, that are small, but big enough to be annoying?
A quick check of wikipedia backs my memory, the Java classes were just a thin wrapper around the native components. AWT was mostly bad because it was limited, it does not even have a Table.
> even the basic look because various UI components use wrong size, are placed slightly differently and so on.
The windows API does not come with a layout manager AFAIK. I vagualy remember setting every bit of relevant size/position data by hand last time I used it directly. Same could be done with AWT, so this is mostly likely caused by programmer lazyness.
In any case, Google doesn't need to be as strict as Sun was. It is free to implement "write 90% of your code once and 10% customised for each platform".
Now, consider the orders of magnitude improvement in computing power over the years, and notice that webapps aren't really doing anything more complicated than old applets did...
Actually they suffer from most of the same problems, only computers have gotten faster (masking performance issues) and our expectations have lowered. How many of these web apps obey the native OS themeing for instance?
If an issue no longer affects anyone in any way, is it still an "issue"? Odds are that all the code you've ever written would have been considered criminally bloated at some era of computing history, but it hardly matters now.
I said it was masked, not gone. It still causes a lot of issues for people on resource constrained machines.
> Odds are that all the code you've ever written would have been considered criminally bloated at some era of computing history, but it hardly matters now.
For much of computing history where were making clear gains with newer hardware. Up to the 90's software was getting more bloated but it was doing more. Most apps today really aren't doing much/any more than we were doing in the 90's but require vastly more powerful machines.
Although I think there's more going on in regards to 2. I was never bothered so much by the UI of a java applet looking different. What bothered me was that even very fundamental stuff like input fields and scrolling felt both alien and shittier than native. And while it's certainly possible to make a web app just as shitty, if you rely on 'stock' html elements, a lot of the subtle native behavior carries over.
Just a few weeks ago, for example, I built a web-app for mobile devices. It felt off immediately because the scrolling didn't feel right. All I had to do was turn on the momentum scrolling (with a line of ios-specific css), and the scrolling suddenly felt native. Had I used a hypothetical Java applet equivalent, I might've had to either go for a non-native-feeling scroll or build it myself.
While I of course can't prove any of this, I think what people care about is that things feel native, not the 'skin' used to display it.
I think people finally called the bluff that users have any expectations. And even if they had, what they don't have is choice. The current market is that everyone is building a walled garden around their selling proposition, so if a company decides to make a web app instead of a native one, then that's all you have. Nobody will make a better one and risk getting sued. If a service doesn't want third party applications, then they won't happen.
As you note in your comment, if one sticks with default, "stock" elements in their web app, things look and behave OK on a given platform. But nobody does that, for some reason everyone has to screw this up with tons of CSS and JavaScript that make the whole thing maybe prettier, but also noticeably slower and without all the native idiosyncrasies.
It's a really interesting question actually because it's so hard to compare the two. On any objective measure, today's web apps are much better than applets in terms of responsiveness, etc. But then again, an applet could run on machines with 16MB of RAM total. I think you'd be hard pressed to get plain html page in a modern browser to run on a machine like that. Either way, in both cases we had a much better solution in native apps.
> 2. I was never bothered so much by the UI of a java applet looking different. What bothered me was that even very fundamental stuff like input fields and scrolling felt both alien and shittier than native.
Modern web apps can score better here, but quite often they don't. The more complex the become the less native they get, scrolling, text input, etc are generally OK (unless your an arshole that overrides scroll behaviour), but html still doesn't have an equivalent for native table views and the goodies (navigation, resizing, performance) that comes with them.
For me the skinning does matter though, I have a beautiful, consistent desktop that browsers (not even electron apps) shit all over. When something doesn't look quite right from the second you open it it magnifies all the other differences.
Oh yeah, complex UI stuff is definitely a good reason to avoid web apps.
But for many, probably even most apps it's precisely scrolling, text input, and other 'basic' stuff that matters, and in those cases a web app's 'default' will be more native.
> For me the skinning does matter though, I have a beautiful, consistent desktop that browsers (not even electron apps) shit all over. When something doesn't look quite right from the second you open it it magnifies all the other differences.
I agree on a personal level, but I suspect we're outliers. Can't substantiate that at the moment though, so I might be wrong.
Modern web apps are non standard but pretty.
Forget the theme - how many of these web apps obey the native OS GUI features? TAB-navigation, arrow navigation (in e.g. lists), accelerator shortcuts, editing shortcuts, not to mention a lot of visual idiosyncrasies that together make the interface feel "right"? Ironically, if you use default HTML controls, most of the things will be OK on a decent browser. But no, designers and developers absolutely have to make it worse by applying tons of CSS and JavaScript.
This applies to web apps pretending to be mobile apps, too. You can quickly tell one from another; the web app is the one with mediocre UI that behaves "wrong" in more or less subtle ways.
It seems to me that the 'new' Microsoft (since Satya Nadella took leadership) is changing their closed/proprietary stance on many topics. Not everything of course, they still have to sell stuff, but as far as "genuine cross-platform" is concerned, they are certainly giving developers all the tools to both make and target all major operating system.
Giving anyone not on Windows a second rate experience? Core as the name says provides only a subset of the Windows .Net framework and most .Net code in the wild is written with the implicit assumption that it runs on the Windows framework.
> VS code universal electron app
Instead of making their main IDE a proof of concept for .Net Core they wrote a Web3.50/NodeJS IDE. I am very sensitive to high latency IDEs so that is something I wont ever touch.
> the whole Office 365 paradigm
Trying to keep up with the competition, Google Docs ring a bell?
> since Satya Nadella took leadership
Nadella 2014. Linux on Azure 2012. Office 365 2011. Mono based on Microsoft’s promise not to sue 2004. Open sourcing parts of .Net is really the only thing you can assign to Nadella, everything else was still done by the good old triple E leadership.
Android and Material Design will not be "write once, mediocre everywhere". It may become "write once, great on Android (majority of phones) and ChromeOS, mediocre elsewhere." But writing for Android does not exclude creating native versions for other platforms. Using Java did exclude creating native versions because that was the reason to use Java, to not have to write native versions.
I remember issue no.3 :
United States Court of Appeals,Ninth Circuit.
SUN MICROSYSTEMS, INC., a Delaware Corporation, Plaintiff-Appellee, v. MICROSOFT CORPORATION, a Washington corporation, Defendant-Appellant.
No. 99-15046.
Decided: August 23, 1999
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.
It's not fast on a $200 mobile phone though. It's still pathetically slow.
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.)
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.