no
Show HN: 300k lines of Java UI code running as JavaScript in browser
41–50 of 75 posts
Re: Show HN: 300k lines of Java UI code running as JavaScript in browser
#42That's impressive. Now it's only a matter of time for the Java app compiled to JS running on Electron.
...Electron x86 running on Windows-on-ARM.
Re: Show HN: 300k lines of Java UI code running as JavaScript in browser
#43See also GWT if you are just hell bent on running Java in the browser. As one of our developers commented, 'it is webforms all over again'. Also see https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... For legacy apps or if your back end is Java and you need to share code, GWT and this concept is a good solution. If you are just trying to avoid learning JavaScript/CSS this will leave you very unhappy.
You don't have to use GWT webforms-style: you can also use something like GWTReact[1]. It ends up being more verbose than JS or TS, of course, but might be useful if you've got a lot of business logic in Java that you want to be able to use easily in a modern web app.
There's also JSweet[2], which compiles Java to TypeScript. I believe it can automatically convert TypeScript definitions into Java, so it's a good way to write Java that calls existing JS libraries.
Granted, writing Java to run in the browser probably isn't the best solution for most people. But there are certain situations where it makes sense, and it doing so doesn't mean you're condemned to write an application that feels like crufty legacy garbage.
[1] https://github.com/GWTReact/gwt-react-examples [2] http://www.jsweet.org/
Re: Show HN: 300k lines of Java UI code running as JavaScript in browser
#44Earlier quoted context omitted.
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.
Think bigger. Start a consulting company that just runs around and recompiles all people's old Java Swing crap into "web apps" like this one. Charge $10-50k / pop. Get on the consulting gravy train by somehow allowing piecemeal callouts to "real dom" (kindof like an IFRAME from within JAVA) which lets you start rewriting bits and pieces into some angular.next framework. By the time you finish converting the majority…
Sounds like a great instance of the old adage "Consulting: If you can't be part of the solution, there's good money to be made in prolonging the problem."
Re: Show HN: 300k lines of Java UI code running as JavaScript in browser
#45That's impressive. Now it's only a matter of time for the Java app compiled to JS running on Electron.
...Electron x86 running on Windows-on-ARM.
Ewwwwwwww lol.
That would be like me hopping on my bike, pedaling for hours, which charges up a battery that is attached to it with an inverter, putting it into a carboat, driving onto the water, to get into my seaplane.
The original goal was for me to be in the air. LOL
Re: Show HN: 300k lines of Java UI code running as JavaScript in browser
#46"We test extensively on the latest versions of Chrome and Safari. For the best experience, we recommend Chrome."
Why no FF? What could possibly cause them not to support it? Any specialists out there?
Re: Show HN: 300k lines of Java UI code running as JavaScript in browser
#47Appears 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 I'm mistaken. I don't think the 'world has moved on'. As an example, I believe Eclipse Che (a relatively new project with a decent UI) uses GWT mixed with a little bit of Typescript. https://github.com/eclipse/che/blob/master/ide/che-core-ide-...
eclipse has been trying for a while to move on the web - eclipse RAP dates as far back as 2007
Re: Show HN: 300k lines of Java UI code running as JavaScript in browser
#48I’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.
Re: Show HN: 300k lines of Java UI code running as JavaScript in browser
#49Appears 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…
> Appears the tech behind this "cheerpj" a java transpiled to javascript[1] system that appears to contain all of openjdk including swing(!?!).
IANAL, but what about copyright here? AFAIU, you create a derivative work of JDK.
Re: Show HN: 300k lines of Java UI code running as JavaScript in browser
#50Java finally made it on my iPhone. "Java uh.. finds a way." -Goldblum This is actually pretty cool, though something about seeing my taskbar containing a window that contains an jvm that contains another window drawn in swing makes me think we've lost our way somewhat.. better we make the computers do it than rewrite everything by hand I suppose.
I see it another way... It's actually a Holy Grail in a way.
OS makers have made things intentionally incompatible since the beginning of time. Developers are finally finding effective ways to fight back.
We could have had Java/whatever everywhere ages ago if the OS makers were not purposely segmenting the market.
We might finally have a way out of the tyranny of OS makers taking 30% of the revenue in apps stores for example.
WASM will change everything. Every platforms will be compatible somewhat against the will of OS creators. Expect some kind of backlash or walled gardening to commence shortly...