Hacker News Reader

Comment by grzm | Hacker News Reader

You don't need to have Java enabled in your browser.

The problem with that is you'll essentially re-download the entire JVM (and libraries) on each page load. If you don't want to use a Java applet, you would need to reimplement GC, JNI, and so on. Java didn't work on the web for a reason.

GC should be available in WASM in the future. And, not all applets needed JNI.

In other words, this is enabling a subset of well behaved applets, while excluding the naughty (or advanced) applets.

Caching exists. You hsouldn't have to redownload the same libraries for each page load.

The JVM can be very small. The libraries shouldn't be any worse than with current JS.

The browser won't have to re-download on each page load because the browser has a cache, which can be validated on each page load to check for updates.

The browser would cache that automatically. And in many cases, you'd probably use a Service Worker to implement your own custom cache and "install" the application locally in the browser, so that is usable offline and only version updates are downloaded in the background.

Weren't applets also cached?

To be honest, I think that hate of applets comes from a time when 56kbps download speeds were considered very high, the average CPU had 1 core at 200 Mhz and the average webpage weighed 20k and executed 5-10 lines of Javascript.

I haven't used applets in the time, but if the user experience would be improved (nice looking UI, respecting modern UX conventions, etc.), I imagine your average applet from circa 1999 would run circles around Gmail, for example :)

Not only that, swing applets are notoriously fugly. One reason electron is successful is because it kinda looks like native. Swing Look and Feels all seem alien.

Swing can be styled, it's that not a lot of people really bothered. Jetbrains products use Swing and they're decent.

Not amazing, but decent.

> The problem with that is you'll essentially re-download the entire JVM (and libraries) on each page load.

I always here these arguments, but if you develop an angular application and somehow can't turn on AoT you need to download a ton of stuff, too. Also it's way easier to make use of dead-code elimination on java than on javascript (especially without reflective code)

GC is only about 300 lines of code. There's no JNI in TeaVM (and never will be), instead of JNI there's JSO to interact with JavaScript, and still no interop layer for WebAssembly (that's why I claim WASM support to be experimental). JSO is rather lightweight, and I hope I'll be able to implement a lightweigh interop for WASM.

As for Java libraries, TeaVM is able to throw away unused parts of it, producing relatively small binaries.

Reply on news.ycombinator.com