
Show HN: 300k lines of Java UI code running as JavaScript in browser - jeffreportmill1
http://reportmill.com/cj/RMStudio/
======
le-mark
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/](https://www.leaningtech.com/cheerpj/faq/)

[2] [http://www.gwtproject.org/](http://www.gwtproject.org/)

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

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

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

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

[http://www.reportmill.com/company/](http://www.reportmill.com/company/)

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

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

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

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

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

------
slig
That's impressive. Now it's only a matter of time for the Java app compiled to
JS running on Electron.

~~~
JBiserkov
...Electron x86 running on Windows-on-ARM.

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

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

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

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

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

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

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

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

------
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...](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-
abstractions/)

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.

~~~
rpeden
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](https://github.com/GWTReact/gwt-react-examples) [2]
[http://www.jsweet.org/](http://www.jsweet.org/)

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

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

------
yuchi
This is… actually not bad. :shocked:

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

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

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

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

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

Other than that, it's pretty impressive.

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

------
fenesiistvan
How file and network I/O works here?

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

------
wolco
Is there anything like this for php?

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

~~~
topspin
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?

