Live data from Hacker News

Show HN: 300k lines of Java UI code running as JavaScript in browser

reportmill.com

71–75 of 75 posts

Re: Show HN: 300k lines of Java UI code running as JavaScript in browser

#71

Ah, the cycle is complete. Straight back to Java Applets now that we have 8000000 layers of abstraction in the middle. Good riddance horrific ball of JS/HTML/CSS

This is exactly the thought I had. Applets were always a crashy mess. Who knew Java would eventually get into the browser via transpiler (if that's what this is...)

Anyone have a thought on how one might pronounce CheerpJ?

Re: Show HN: 300k lines of Java UI code running as JavaScript in browser

#72
post #8

Appears the tech behind this "cheerpj" a java transpiled to javascript[1] system that appears to contain all of openjdk including swing(!?!). That's kind of cool actually. But creating applications with such a system seems highly problematic. See for example GWT (google web toolkit)[2] which also transpiled java to javascript. I only see legacy GWT apps around nowadays, the world moved on. So I really don't see the a…

> unless you're a java shop hell bent on NOT learning modern frontend development. Sorry, but that statement is dripping with irony. Irrespective of whether GWT was the right implementation, the Swing model is far superior to any of the piles of tangled JS/HTML/Made-Up-Things that comprise "modern frontend" frameworks. I know that's not a popular statement, as everyone seems to have their favorite framework, and I'm…

The web is fundamentally different from every desktop UI framework that has come before. The address bar and back button change everything. Swing doesn't handle it, SWT doesn't, Qt, gtk, cocoa, none of them. So yeah, there has been a lot of development, but the web is different.

Re: Show HN: 300k lines of Java UI code running as JavaScript in browser

#73

I’m on a 2G mobile connection right now, and that site refuses to load. I’m going to guess this has something to do with bundling all of Java, but surely there must be a better way to write UIs that doesn’t involve downloading the whole JDK to my browser cache. This is not a joke - webpage size is a real issue. Even on this connection I can browse a lot of pages normally, but something like this Java UI toolkit just…

Ironically Java apps would ideally be much leaner than JS. Once WASM support is done for CheerpJ the bundles should be quite small.

JavaScript developers are foaming over "tree shaking" which is child's play compared to how much dead code you can remove from a compiled language.

If you don't use tricks like reflection you can eliminate basically all dead code from Java. This is done routinely on Android via proguard and Android apps would be very lean if people didn't take the opportunity to jam tons of crap into them.

It seems the natural way of things is to bloat your app up to at least 5mb by tacking on crap until it's "too slow" for normal users.

The Java Applets of ye old days were basically desktop apps and only took about 3 mb, huge for back then but probably below average for a site these days. And this was before Java had Proguard and related tools to strip unused code.

Re: Show HN: 300k lines of Java UI code running as JavaScript in browser

#74
post #72

Earlier quoted context omitted.

> unless you're a java shop hell bent on NOT learning modern frontend development. Sorry, but that statement is dripping with irony. Irrespective of whether GWT was the right implementation, the Swing model is far superior to any of the piles of tangled JS/HTML/Made-Up-Things that comprise "modern frontend" frameworks. I know that's not a popular statement, as everyone seems to have their favorite framework, and I'm…

The web is fundamentally different from every desktop UI framework that has come before. The address bar and back button change everything. Swing doesn't handle it, SWT doesn't, Qt, gtk, cocoa, none of them. So yeah, there has been a lot of development, but the web is different .

>The address bar and back button change everything.

>the web is different

It's not specifically the desktop UI framework model that's discordant with the Web; it's SPAs in general.

The browser was built around a document model, not a SPA model. Hence, 99% of what you really want to do with the back button in a SPA is try to prevent it from having deleterious effects. You enable it for navigation only because you have no choice (well, you do, but it wouldn't meet user expectations, especially on mobile where the back-button in apps and the browser are the same). Likewise, beyond locating the app, the address bar is really of little use.

So, let's hold that constant. You have to manage it regardless and it's just as easy to build URL-based view-resolution into any framework. Point being that, once the view is resolved, there's absolutely no reason you can't use a Swing-like model to render and manage it.

Re: Show HN: 300k lines of Java UI code running as JavaScript in browser

#75
post #8

Appears the tech behind this "cheerpj" a java transpiled to javascript[1] system that appears to contain all of openjdk including swing(!?!). That's kind of cool actually. But creating applications with such a system seems highly problematic. See for example GWT (google web toolkit)[2] which also transpiled java to javascript. I only see legacy GWT apps around nowadays, the world moved on. So I really don't see the a…

all our products are using GWT and they are super awesome, on the bleeding edge of technology! check it out: https://www.animatron.com

all this GWT bashing is from hipsterish kids who don't know anything else besides latest javascript frameworks.

Post reply on HN