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

31–40 of 75 posts

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

#31

Post by ganonm »

Sharlin wrote: post #26
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…

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:

- Server-side rendering can improve client-side performance, especially since it allows you to avoid N + 1 problems associated with many roundtrips to REST APIs

- Compatibility with all common browsers (Vaadin take responsibility for this basically)

- If your backend codebase is already Java, writing your UI code in Java can save time/reduce complexity (e.g. all your existing static analysis tools can now be applied to your frontend code as well)

- There are simple, well documented ways to wrap 3rd party JavaScript libraries. I was able to integrate VisJS as a custom component quite easily

cons:

- Server-side rendering comes with a non-trivial memory overhead that scales pretty linearly with no. of clients. This may or may not be a concern depending on your requirements

- In terms of writing elegant code, I found the experience much better with React + Redux, as best practices are essentially enforced here (pure functional code)

- You still have to get your hands dirty with CSS, although Vaadin does provide base themes like Valo if you so wish to use them

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

#33

Post by neurotrace »

jeffreportmill1 wrote: post #21
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…

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.

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

#34

Post by cromwellian »

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 code (business logic layer) is shared between platforms as Java. Java is transpiled to heavily annotated Closure ES6 code (in theory it could be TypeScript) and optimized by the Closure Compiler, OR it's transpiled to Objective-C and imported into XCode.

This is not a React-Native approach, teams decided that trying to do "write-once-run-anywhere" UI leads to "uncanny valley" effects as you invariably end up with non-native experiences by trying that approach, instead front end developers who are experts on each platform (Web, Android, iOS) use the best available native tools for those platforms to create the UI 3x, which they wire up to a shared layer which is written once.

The reason to go with transpilation, instead of a low level emscripten/bytecode/VM level approach is performance and optimization. Java classes can be pretty easily translated to ES6 classes, and consumed by Babel, or more importantly, Closure Compiler, with aggressive optimizations to split code, tree shake, etc. This information is lost if you just blindly translate the entire stack at a low level.

It also means the impedance mismatch is very low. For example, Objective-C or JS code can call into J2Cl code very easily. They're just ES6 modules or Obj-C interfaces/classes.

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

#35

Post by switchbak »

malkia wrote: post #28

I won't mind IntelliJ on the web - even if it takes some time to load, or CLion - which targets emscripten/webasm/something Imagine a bit more powerful Chromebook with that..., but then where the files, projects, etc. would get stored?

I've wanted this for a while - have my ThreadRipper box at home, and use a remote IntelliJ on a wimpy laptop that just runs a light UI through the browser. Real latency benefits vs running remotely, especially on a typical coffee shop wifi.

Ahh, but I don't see that happening any time soon.

Edit: or spark up a really powerful instance on something like Hyper.sh when you need it, close it down when you're done. Pay more to get a well provisioned instance when you need real horsepower.

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

#36

Post by favorited »

jimbokun wrote: post #24

Find it amusing this product was originally written in Objective C, converted to Java, now to JavaScript. http://www.reportmill.com/company/

People make fun of WebObjects now, but it was super ahead of its time. EOF was like Rails' ActiveRecord, but in 1994.

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

#37

Post by dillon »

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 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-...

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

#38

Post by switchbak »

jeffreportmill1 wrote: post #20
TheAceOfHearts wrote: post #16

This is really nifty as a proof of concept, major kudos to the authors. However, it completely kills accessibility, so it's probably best to avoid for any serious projects. I've gotta ask, since I've never used Java applets... Wasn't this already possible back in 1995? Have we come full circle?

It was possible, but there were issues with performance, compatibility, security and configuration. Everyone had a different version of the Java plugin implemented with different platform Look-And-Feels (if you had the plugin at all). And then the browser vendors went to war against plugins. CheerpJ is a much better approach - doesn't require a separate plugin, doesn't have version problems, has inherent JS-sandbox s…

One of the biggest impediments was that Microsoft had this crappy implementation of Java on IE that was simply useless. Making a portable (modern at the time) applet that worked in IE was essentially impossible. I have no doubt MS did that on purpose.

All said, I think having a standardized binary ASM model in the browser is the right way to go, even if it is a couple decades later :)

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

#39

Post by jeffreportmill1 »

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.

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.

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

#40

Post by kenoyer130 »

See 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.

Post reply on HN