Hacker News Reader

Comment by le-mark | Hacker News Reader

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/

View on HN

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.

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 <Text>, <View>, or <ScrollView> 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 <Element>.

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.

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

The web is fundamentally different from every desktop UI framework that has come before. The address bar and back button change everything. Swing doesn't handle it, SWT doesn't, Qt, gtk, cocoa, none of them. So yeah, there has been a lot of development, but the web is different.

>The address bar and back button change everything.

>the web is different

It's not specifically the desktop UI framework model that's discordant with the Web; it's SPAs in general.

The browser was built around a document model, not a SPA model. Hence, 99% of what you really want to do with the back button in a SPA is try to prevent it from having deleterious effects. You enable it for navigation only because you have no choice (well, you do, but it wouldn't meet user expectations, especially on mobile where the back-button in apps and the browser are the same). Likewise, beyond locating the app, the address bar is really of little use.

So, let's hold that constant. You have to manage it regardless and it's just as easy to build URL-based view-resolution into any framework. Point being that, once the view is resolved, there's absolutely no reason you can't use a Swing-like model to render and manage it.

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 interfacing with native JS code without GWT wrappers. (Disclosure: I'm a former Vaadin employee and core devteam member.)

https://vaadin.com/ [1]

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

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

> the world moved on.

I also tought that, long before Google shipped some new GWT applications in 2017. I think that GWT is still in big use, but it's probably not trendy, that's why you probably won't see much talk about it.

I think that transpired ANY Language is actually the future of most web applications. yes there will still be a lot of javascript users, but I guess other languages will soon have ways to build web application with a shared code base. And actually I think there is a benefit in doing so, well sharing everything is maybe not the best idea, even GWT made integration with JavaScript stuff better in the last releases. But Models and Utilities are a big win if they can be shared.

Actually in my company we use a lot of Scala, and it would be really cool to share the models, but sadly it's really hard to get a good toolchain (ScalaJS works, but integration in our "legacy" tooling sucks). that's why we still duplicate a lot of code in typescript, besides the fact that most models are just 1:1.

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.

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.

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

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 of their Swing to Angular conversion, angular will finally be deprecated (or dart-only, lulz) and you can set yourself up with a new and improved consulting company which will convert Angular to React as soon as the Java to Angular contract finishes up!

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

Consultants: people who borrow your watch to tell you the time.

and charge you for it

They also have something called Cheerp, which is an Emscripten-like C++ to JS compiler based on LLVM: https://www.leaningtech.com/cheerp/

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

This is impressive! Are they using WebAssembly here?

This version is all JavaScript - the WebAssembly version should be truly amazing. Though probably next year, when WebAssembly matures (adds threading and improved memory model, GC and more).

all our products are using GWT and they are super awesome, on the bleeding edge of technology! check it out: https://www.animatron.com

all this GWT bashing is from hipsterish kids who don't know anything else besides latest javascript frameworks.

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

There is a reason for the “Open” in the name of “OpenJDK”.

This is 100x more responsive than Reddit Mobile, if that's what "modern frontend development" is I hope it dies very soon.

Reply on news.ycombinator.com