Show HN: 300k lines of Java UI code running as JavaScript in browser | Hacker News Reader

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

reportmill.com

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/

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/

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

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.

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

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.

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

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

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

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

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.

Find it amusing this product was originally written in Objective C, converted to Java, now to JavaScript.

http://www.reportmill.com/company/

WASM is the next logical step.

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

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

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

I don't disagree it's not for general web pages, but it's more than fine for any non-trivial app. Downloads less data than 60 seconds of YouTube. The runtime is CDN shared, so the more apps that use it, the less it will matter.

That'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

it's impressive, granted. But it feels like a parody, the long loading-time, the horrible UI, the weird scrolling. It just screams Java.

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?

Yes, around 1996-97 there was a lot of hype around desktop applications delivered as applets. E.g. Corel Office for Java:

http://www.edm2.com/index.php/Corel_Office_for_Java

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 security, uses the same look-and-feel and performs great (after initial download).

For a large project, it's nice to have all the benefits of desktop development with a strongly typed language, but still have the ability to publish to the browser.

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 :)

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.

For the second point, I've had a lot of success doing this with a Jupiter notebook. It's not an IDE by any means but it's very productive for exploratory work, and when you need horsepower you just spin up the kernel on a beefier cloud machine.

Try https://c9.io/ or https://shiftedit.net/

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.

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/

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

I'd imagine it's a large codebase and they're trying to maximize the number of people that can access it while minimizing the number of supported browsers. There are very few platforms where firefox is available and Chrom(e|ium) is not.

FWIW, it actually does work on Firefox Quantum; it's just not guaranteed to work.

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.

Congratulations! Sounds like the 90s Java applet experience to me.

Yes. Yes it is.

I mean as a technical feat it's impressive (in the same way as running Linux in the browser via JavaScript [0]).

At the same time I'm horrified that someone would seriously do it (though I can understand the business reasons for wanting to do so).

0: https://bellard.org/jslinux/

Seems to perform pretty well. Much more usable than I was expecting.

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.

runs on my iphone, but text input doesn't seem to trigger the appearance of the keyboard.

Other than that, it's pretty impressive.

Even on a browser, not taking in inputs, until I realised I needed to press on the "A" to insert text. So probably just a UX thing...

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.

Is there anything like this for php?

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

This is exactly the thought I had. Applets were always a crashy mess. Who knew Java would eventually get into the browser via transpiler (if that's what this is...)

Anyone have a thought on how one might pronounce CheerpJ?

Reply on news.ycombinator.com