Live data from Hacker News

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

reportmill.com

1–10 of 75 posts

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

#4
Java and JavaScript are not that different. We used to have a security testing engine that was written in Java and transpiled into JavaScript with our own compiler. It works and it was OK in the days when static typing was one of those things that were missing from modern JavaScript. We do not do this any more. Everything is JavaScript these days.

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

#5
Runs smoothly - almost indistinguishable from native. With webassembly (and I know this is in JS) and the general progression of the web platform and JS engines it seems to me that web apps will continue to grow in number and in popularity. I don't see why the web app should die.

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

#6
post #4

Java and JavaScript are not that different. We used to have a security testing engine that was written in Java and transpiled into JavaScript with our own compiler. It works and it was OK in the days when static typing was one of those things that were missing from modern JavaScript. We do not do this any more. Everything is JavaScript these days.

People often emphasize that their etymology is just incidental, but the similarities are definitely deeper than just the names. Why else would the creator have named it JavaScript?

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

#7

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

As long as the app performs well, who cares how many layers of abstraction exist between the app logic and hardware? If it took like 2 seconds a button to register a click, then I would say the layers of abstraction are too numerous. But this app seemed very responsive - and all I would have to do to start it is navigate to a page in my browser.

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

#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 appeal of this; unless you're a java shop hell bent on NOT learning modern frontend development.

[1] https://www.leaningtech.com/cheerpj/faq/

[2] http://www.gwtproject.org/

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

#9
post #2

This is… actually not bad. :shocked:

Uhh... It seems very bad. I clicked "Run RMStudio DOM" in Chrome. It loaded dozens of java packages for half a minute, and then showed me a 90s looking splash screen with three buttons on it. None of them do anything.

I'm assuming I'm supposed to be seeing something else.

Edit: I tried "Run RMStudio Swing". That one actually loads eventually. I don't understand what kind of app it is, but it appears to leak DOM elements. I see 99 DOM elements when the editor first loads ("New"). Mousing back and forth over the menus for a few seconds makes the number of elements increase by hundreds, and it never goes back down.

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

#10
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…

Legacy systems that haven't migrated to some other front end yet. There would be a lot of companies in this situation. That said, I'm not convinced this is the best approach. I think I'd prefer rewriting parts at a time of a system that big.
Post reply on HN