3 ms·

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

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 goes way over the edge. On this connection I can’t update any native apps because they’re all much too big - but the ones I have continue to work fine. But web apps generally don’t guarantee persistence in the same way. If an app I need is suddenly removed from cache at an inopportune time, I’m screwed. That’s why web apps really need to be leaner.

jeffreportmill1 9y ago
I don't disagree it's not for general web pages, but it's more than fine for any non-trivial app. Downloads less data than 60 seconds of YouTube. The runtime is CDN shared, so the more apps that use it, the less it will matter.
throwawaydbd 9y ago
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.

jeffreportmill1 9y ago

I don't disagree it's not for general web pages, but it's more than fine for any non-trivial app. Downloads less data than 60 seconds of YouTube. The runtime is CDN shared, so the more apps that use it, the less it will matter.

throwawaydbd 9y ago

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.