Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

reportmill.com

Post reply on HN
Print view View original

61–70 of 75 posts

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

#63

Post by jeffreportmill1 »

fenesiistvan wrote: post #62

How file and network I/O works here?

The standard java.io.File and java.net.URL work as normal. CheerpJ provides a choice of filesystem access methods. This includes a read-only filesystem based on HTTP, a local read-write filesystem based on indexDB which is persistent across sessions, and a facility to access JS strings as files, useful to pass input data to target converted Java programs. DropBox and Google drive are also available.

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

#65

Post by underwater »

cromwellian wrote: post #34
le-mark wrote: 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…

Actually new Google applications being shipped, like Docs and Inbox are using GWT, and its successor, J2CL. J2CL (Java 2 Closure) and J2ObjC together permit cross platform application development to run shared code in the server, Web, Android, and iOS. This is not "write once, run anywhere" UI development, the UI layer is still native JS, (Java for Android), and hand-written Objective-C (iOS), but about 70% of the co…

React Native promote the idea of "learn once, write everywhere", not reusing UI across platforms.

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

#66

Post by cromwellian »

underwater wrote: post #65
cromwellian wrote: post #34

Earlier quoted context omitted.

Actually new Google applications being shipped, like Docs and Inbox are using GWT, and its successor, J2CL. J2CL (Java 2 Closure) and J2ObjC together permit cross platform application development to run shared code in the server, Web, Android, and iOS. This is not "write once, run anywhere" UI development, the UI layer is still native JS, (Java for Android), and hand-written Objective-C (iOS), but about 70% of the co…

React Native promote the idea of "learn once, write everywhere", not reusing UI across platforms.

True, but it is reusing an (alien) middleware on top of that. I like react-native and have used it, but a , , or isn't the same thing as directly using the native widget APIs yourself, or using the native tooling like Android XML files, XIBs, etc. There's a class of apps where you really need the direct access, and currently for React-Native, that means writing native modules and tying them to markup, which invariably leads to people trying to create versions that work on Android and iOS unified by a single .

React-Native works, apps like Discord prove that. But Gmail and Docs tried the approach of running their huge apps business logic 100% in JS on mobile, and the performance and memory usage didn't meet expectations. If you try to do something like run formula recalculations on a 20,000 cell spreadsheet, on a low powered Android device, the performance is much worse than running the same code in Dalvik/ART.

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

#67

Post by jbergens »

neurotrace wrote: post #33
jeffreportmill1 wrote: post #21

Earlier quoted context omitted.

Cheerp really did it the right way - starting with the C++ compiler for the Java native runtime. This implementation of Java in the browser is very similar to a normal Java platform port - only in this case the platform is the browser. Compatibility and functionality is remarkable.

And how's performance? I have a terrible feeling this is really slow.

Some of their demos were very slow and reminded me of old java applets.

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

#68

Post by copperx »

jeffreportmill1 wrote: post #39
neurotrace wrote: post #33

Earlier quoted context omitted.

And how's performance? I have a terrible feeling this is really slow.

I get 40fps+ on my Retina iMac, dragging around composited images, 3D Graphs, and shapes with filter effects. Should only get better as CheerpJ improves (they're only getting started) and when WebAssembly support is fully enabled. It even runs fine on my iPad and phone. But follow the link and judge for yourself.

Swing, with all its warts, is so much saner than frontend frameworks. The existence of CheerpJ almost makes me want to write web apps in Java and then compile them to JS.

I can't wait much longer for WebAssembly.

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

#69

Post by unclebucknasty »

le-mark wrote: 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 referencing all of them.

So, we took a step back and had a bit of a mess with frontend development on the Web, then "solved" some of the problems with new frameworks. They're still miles behind a true event-driven, component-based UI model. We solved this problem long ago with Swing and other native window-based UI frameworks, and none of the current frontend Web frameworks is even close.

Don't know if the subject of this post is the answer, but I do know that one day we'll look back and laugh at the time we thought, say, JSX was a good idea.

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

#70

Post by always_good »

ganonm wrote: post #31
Sharlin wrote: post #26

Earlier quoted context omitted.

Vaadin [1], a fairly popular open-source Java UI framework, is still using GWT on the clientside, but it's more of an implementation detail given that the whole point of Vaadin is that you don't have to care about the clientside that much. And when you do, you can write your frontend stuff in Java. Of course that's less of a selling point than five years ago, and Vaadin has also been moving towards more easily interf…

I worked on a product that used the Vaadin framework for UI. It is a serious, production ready library that is written by some very sane and very intelligent people. The JavaScript hipsters would probably turn their nose up at it, but being purely objective I found it to be a good solution. I have also worked on a project that used React + Redux on the front-end so I believe I have a fairly balanced opinion. pros: -…

>The JavaScript hipsters would probably turn their nose up at it, but being purely objective I found it to be a good solution.

I'd rethink the assumption that you're purely objective and other people are not.

Post reply on HN