TCL/TK wasn't an especially pleasant toolkit for users or developers, although compared to the HTML5 stack building a house out of matchsticks will seem convenient and pleasant. There were much better toolkits even back then: Delphi's component library was my favourite.

IMHO the web is one of the biggest downgrades to app development that has ever happened, in so many ways. And what's really sad is that so many developers joined the industry since around 2000 that it feels like the majority of programmers have never written anything but web apps, they literally have never used a professional, well designed UI toolkit! The closest many people have got to that is doing mobile development.

One project I occasionally daydream about doing (if/when I get spare time again), is trying again to make Java applets work, with the following fairly major changes:

1) No browser dependencies beyond a URL handler. The 'app browser' would register some sort of app:// URL handler and that's the only way to invoke apps from the browser.

2) Core app browser uses the same auto-update tech as Chrome. Silent, invisible, in the background, continuous.

3) Old cruft like AWT that exposes huge amounts of native code (i.e. exploitable code) would be removed. Sooooo many Java exploits boiled down to exploiting native libraries shipped along side the JVM, but these days you can do most stuff without needing support from C/C++ libraries.

4) App code is compressed, reordered to be streamable and then app servers stream everything via HTTP/2 with server push. The average web page is now 2mb in size so with some careful design you could make apps written in this way start faster than actual web apps can, especially as you'd remove a lot of overhead that's useful for documents but not so much for apps.

5) Apps would also update themselves in the same way as Chrome does. You could mark apps as "check for update on every launch" but if you don't, apps will start even when offline.

6) There'd be a universal, reference app server that accepts sandboxed app uploads and provides access to a few useful services like a Postgres. By default it'd let anyone upload any app to any server. Again, the server would update in exactly the same way as Chrome (no apt-get required).

7) Things like CSS would be replaced by type safe DSLs that compile down to bytecode.

There are a bunch of other improvements I'd like to put into my ideal app platform, but I can't list them all here.

The above might sound completely crazy given Java's track record of exploits, but you have to consider a few things.

One is that HotSpot got a LOT more secure in recent years due to heavy investment in security. When the last zero day was discovered (a bug in a Microsoft DLL shipped for AWT), over two and a half years had passed between that and the previous zero day. Java has reached the same point that browsers have: the security bugs are almost all being discovered by whitehats. Unfortunately browser makers had decided to kill off applets entirely by this point and users had learned to hate them, partly because of the obnoxious update process on Windows (Ask Toolbars and such). But the underlying core tech isn't actually that bad anymore. Compare the list of CVEs between HotSpot and Firefox and it doesn't look so different.

Another reason for Java's poor reputation is that it historically exposed far more functionality to applets than HTML did to web pages. But the HTML5 effort has been changing this and by now, the modern web platform exposes a vast and rapidly increasing surface area to web pages. Massive new chunks of functionality like video chat or OpenGL can appear almost overnight, it seems. But all of this stuff is implemented in C++ and suffers the usual litany of bugs associated with that language. Whereas the trend in the Java world has been the opposite: new functionality is often mostly or entirely implemented in Java itself, and so cannot be buffer-overflowed or double-freed.

Finally, the Java team are still making major architectural improvements that should reduce security holes even further, in particular, the Jigsaw effort supposedly would have avoided about a third of all the security bugs in Java in recent years.

Given that any large app platform that supports mobile code will have security bugs, I feel it's really more about how you manage them than a simple "web rocks, java sucks" world view. And the advantage of using a platform actually designed for apps instead of documents should be obvious.