
Show HN: 300k lines of Java UI code running native in browser at desktop speed - jeffreportmill1
http://reportmill.com/snaptea/RM15/
======
jeffreportmill1
This uses TeaVM to compile Java to JavaScript. Launches faster in browser than
the desktop (once cached). Download is 1.2mb (compressed) - much smaller than
desktop version. Runtime speed seems the same as desktop.

[http://teavm.org](http://teavm.org)

~~~
arendtio
> compile Java to JavaScript

If we would travel back in time to the nineties and tell them we have
technology that compiles Java to JavaScript they would put us straight to a
psychiatric hospital :D

~~~
debaserab2
The technology has been around for over ten years - I believe Google Web
Toolkit (GWT) was available in the mid 2000's, which also compiles Java source
to Javascript.

~~~
macspoofing
GWT is a little different in that it didn't use HTML Canvas to render the UI,
but rather the DOM.

~~~
pklee
I believe the GWT was aimed at AWT rendered on the web and I am also not sure
it was "compiling" it as much as it was translating it.

~~~
javajosh
The first statement is false. GWT defines it's own widgets, not AWT or Swing.
The second statement is true - GWT is a transpiler. It would be very
interesting if GWT could operate on bytecode but that's probably a very
different project.

------
mwcampbell
This is an impressive feat of engineering. But unfortunately, the resulting UI
is completely inaccessible to blind users with screen readers, and probably
users with some other disabilities as well.

This will not be easy to fix. AFAIK, if you're using Canvas or WebGL, the only
way to make the application accessible is to construct a parallel accessible
HTML tree that's completely covered by the canvas via CSS. Note: Don't use
"display: none" to hide the accessible HTML tree, because then screen readers
will ignore it.

I'm reluctant to rain on your parade, because as I said, this is an impressive
piece of engineering. But for the best accessibility and performance, I
believe it's better to accept that the Web platform won, and target it
directly with a UI that's native to that platform.

~~~
fsloth
Um, you can't make paintings accessible to blind people nor can you make
downhill skiing accessible for four-limb paraplegigs.

There is a public domain within which most disabilities should be catered for
but you can't expect that every non-private thing is made public so it's
usable by all.

Just because something is 'in the web' doesn't mean it's a public service,
access to which is a basic right.

It's good to be reminded to take into account disabilities, of course, since
those are not obvious to people who do not have disabled people nearby.

~~~
bzbarsky
"can't" is a pretty strong term. Up until recently, people would have said
that you can't make Olympic sprinting accessible to someone with no feet, but
it turns out in fact you can, with sufficient application of technology.

So the real question is always whether the technology to make something
accessible exists and whether it can be deployed reasonably in the particular
instance involved.

~~~
atomicUpdate
They didn't change the race though, they changed the person running it by
giving them pseudo-feet. To continue your analogy, in order for a bling person
to use this we just need to give them pseudo-eyes.

~~~
bzbarsky
That's a worthwhile goal in itself, sure. But I think you're reading too much
into what I said. I never claimed the two situations were identical or
analogous, just that "can't" is something that needs to be periodically re-
evaluated.

But if you do want to press on with sprinting events, note that they have been
using start signals with both an audible and a visible component for a while,
to accommodate people who may not be able to perceive one or the other. Back
until we had electronically-triggered lights, you "couldn't" have a deaf
competitor compete, modulo smoke from the starting gun. Now you can.

------
drderidder
Compile-to-JavaScript technologies have come a long way and seem well-suited
to porting certain legacy applications to the web as proof-of-concept
projects, but I think an API-first approach supporting a lightweight,
HTML/JavaScript web framework would have required a justifiable, moderate
additional effort, and would not only run faster, look and feel more
contemporary, and be easier to maintain, test and deploy, but would put you in
a better position to add new functionality going forward.

~~~
jeffreportmill1
I would agree if the goal is just to build a web app, however, if you want to
run natively on multiple platforms, Java still has its good points. If you
really run a particular app on a daily basis, it can be nice to have an option
for a dedicated desktop app.

We may see more of this with WASM. And JavaScript can get a little unwieldy
beyond 100k lines of code.

~~~
drderidder
It's those multi-client scenarios for which the API-first approach is a
perfect fit, actually. Once the API is hammered out, it forms the common
foundation for building gui's, cli's and even machine-to-machine interfaces.
As a stepping stone, web applications can be deployed as hybrid mobile apps
using something like Apache Cordova, even as fully native apps for Android and
iOS are under development. Once you've implemented something like this, it's
hard to go back to monolithic codebases. Caveat: this is predicated on having
an API server and requiring an Internet connection. Writing a connectionless
app this way would require some additional effort, though still quite do-able.

------
qrohlf
This reminded me of the talk "The Birth and Death of JavaScript" (2014) by
Gary Bernhardt, where he goes into some of the more absurd possible
implications of what happens when applications cross-compiled to JS approach
or surpass traditional desktop performance:
[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

------
lasagnaphil
No, this is definitely not running at desktop speeds. I have a Ryzen 7 2700,
and this thing lags often even with basic UI operations (clicking buttons and
menus, dragging objects). Now imagine someone with a dual-core laptop CPU...
this will be even worse. It certainly feels like this is a web app rather than
a native one.

~~~
dziulius
Well, it's written in Java, so desktop app probably lags as much. So title
does not lie :D

~~~
jeffreportmill1
Now that hurts :-). Java has been pretty amazing for many years. Many Java
desktop apps ran poorly because they were written poorly.

I used to give demos of the Swing version of this app 15 years ago, and people
would try to convince me that my app was written in C, because a Java app
can't run that fast. Those were weird conversations. I'm not even that clever
- I just try to write simple code.

~~~
ixtli
This is my experience with java > 7\. The JVM with default settings is pretty
excellent these days (see JetBrains IDEs: they're MASSIVE but they run just as
well as any other native desktop app.) The issue as far as i see it is that
the "enterprise" way of thinking that has and still does dominate the majority
of development that results in java code is so bad that it starts to seem like
its the language/runtime.

~~~
garaetjjte
>they're MASSIVE but they run just as well as any other native desktop app

Not for me. They're starting up long, UI is laggy. In comprasion to native IDE
like Qt Creator they're really slow.

------
saagarjha
I went in with low expectations, but this works surprisingly well on iPad.

~~~
jeffreportmill1
It even runs reasonably well on iPhone - though squinting required. And an
Apple pencil doesn't hurt, too.

~~~
xondono
As long as you don’t try landscape..

------
benboughton1
This is fantastic. I tried it out and works very well. I am self taught python
and a bit of javascript to put front end to python servers. I have not really
ventured outside that landscape as it has worked well for last 4 years or so
for me so please excuse ignorance.

My understanding is in this high performance CPU landscape Java apps should
work well on all popular desktop platforms and to have it compiling to a web
UI like this makes it even more powerful.

How does including existing Java libraries like GeoTools
[http://docs.geotools.org/](http://docs.geotools.org/). What are good
resources to read to understand the limitations of TeaVM?

------
seba_dos1
It's cool, but it runs at about 10 FPS at best for me :P

~~~
jeffreportmill1
What browser? I get at least 50 fps on Chrome, Safari. Firefox does seem about
half that for me though.

~~~
seba_dos1
Firefox. It's slightly better in Falkon, but not much.

~~~
fastball
Firefox always has lacklustre performance on JS-heavy apps.

That's why I still haven't made the switch despite all the claims of "it's
just as fast as Chrome in benchmarks!"

~~~
Spivak
Yep. We have Atlassian at work and it's pretty much unusable on Firefox
because of this. Buttery smooth on the same system with Chromium.

Installed an "app shortcut" with Chromium and couldn't be happier.

~~~
bzbarsky
Is there some public URL that would show that issue? I'm happy to take a look
at what's going on with Firefox here, but could really use something to work
with...

------
thope
this makes me think of Qt in a web browser using WebAssembly [0]

I find it really impressive that desktop applications can now run quite
smoothly in a web browser. In like 15 years we've made it from phpbb forums
through 56k modem, to this.

Congratulations

[0] [http://example.qt.io/qt-
webassembly/widgets/richtext/textedi...](http://example.qt.io/qt-
webassembly/widgets/richtext/textedit/textedit.html)

------
hbz
Seemed to freeze up after I loaded a sample and clicked a few things inside it

~~~
jeffreportmill1
I just got it running in the last couple weeks - still doing some QA to find
issues, but in general they have been easy to resolve.

------
sparsely
Performs better than most websites which intentionally target JS

~~~
chrisco255
You mean the DOM. The web isn't slow because of JS.

~~~
blotter_paper
Slow is relative, and JS is slow relative to WASM.

~~~
rat9988
I can't tell what you are trying to refute in your parent comment.

~~~
blotter_paper
I'm saying that the web _is_ slow because of JS, not just the DOM (though I'm
not contending that the DOM isn't the bigger issue).

~~~
chrisco255
No its not. JS is extremely fast. The demo above is Java compiled to JS, NOT
webassembly.

~~~
blotter_paper
Again, slow is relative, and JS is slow relative to WASM. That should be
obvious, but here's a source.[0] A demo working smoothly does not mean that a
language is not slow compared to another. Besides this point, there are some
very processing heavy tasks that we're throwing in browsers these days; this
demo is not representative of everything we expect browsers to run. And if you
read the other comments here, some people were having lag issues with the demo
anyway.

[0]: [https://hacks.mozilla.org/2017/03/why-webassembly-is-
faster-...](https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-
asm-js/)

~~~
konsoletyper
No, WASM is slow. As a developer of TeaVM I can claim this. First of all, JS
engines been developed for many years, while WASM is a new technology and
browser engines don't optimize it well. Another reason is WASM _was not
designed to run languages like Java_ , at least in version 1.0. Here are the
reasons:

* To make GC work properly you have to maintain GC roots. GC roots are static fields + variables in stack. _There 's no way in WASM to walk the stack!_ You have to maintain your own shadow stack, losing performance. In case of generating native code (e.g. x86/64) you can access native stack freely and finding GC roots produces no overhead (which is already done by JS engines).

* To make exceptions work properly, you need to walk the stack, and not only read it, but also write to it (in case of x86, update RSP direcly). _This is not supported by WASM_. But JS engines already do it natively, with no overhead for exceptions, until you throw then. With WASM you have to check after each call whether the exception was thrown or not, and that affects performance.

* In native environment you can do memory protection magic for different runtime things, e.g. to detect null pointer access, and that's not possible with WASM.

* In WASM you can't mutate code, so it makes impossible to implement lazy initialization logic without some overhead. JavaScript engines can detect that certain function got changed and de-optimize calling function, then optimize it again.

So, according to my experience and my benchmarks, compiling Java to JavaScript
is a better option, both from performance and code size standpoint. WASM team
is working on GC and exception handling, but they do it slowly and current
design is far from perfect. I failed to convince them to _just give access to
stack_ , perhaps in some limited way (for security reasons).

And yes, the lack of access to stack even affects C code. For example:

int i = 23; foo(&i);

------
truth_seeker
TeaVM and DukeScript looks pretty cool.

Similar effort in Clojure or ClojureScript - [https://github.com/oakes/play-
cljc](https://github.com/oakes/play-cljc)

It's more intended towards Game development though.

------
epaga
Related would be JWebAssembly (Java to WASM compiler):
[https://github.com/i-net-software/JWebAssembly](https://github.com/i-net-
software/JWebAssembly)

------
catsanddogsare
Serious question, Are the days of native applications UI (be it
Windows/Mac/Linux) are numbered? Does it make sense to develop a native
application now days? (games and heavy CAD software aside)

~~~
ben509
Cross-platform UIs have been around for ages; QT goes back 30 years.

The pattern that Electron and such are continuing is that they do a base set
of things well, but then integrating with OS services is non-existent, even
though for any given OS it's relatively trivial.

Don't be too impressed that it can run anywhere at acceptable speeds; Java
solved that 20 years ago.

Rather, it's more fundamental: as you add in all the functionality provided by
various OS's you have to model all that functionality and it has to be
comprehensible to your users and maintainable by you.

Some of that functionality is flatly contradictory and much of it is peculiar
to a small audience. You can theoretically engineer around it, but in
practice, you won't be able to maintain it and no one will want to use it.
That's an intractable problem.

That's why I think cross-platform framework authors have consistently been
leaving various bits of functionality out for decades. They'd rather deliver
"second class" applications than nothing at all, and that's a smart trade-off.

But that does leave a lot of space for native apps.

------
jimbo1qaz
This doesn't support native high DPI rendering. I think it's rendered at low
DPI, and upscaled/blurry on my laptop. Other commenters have stated that it
uses canvas.

~~~
jeffreportmill1
It uses HiDPI on my retina MacBook on Chrome/Safari/FireFox. I haven't tested
HiDPI on Windows yet, maybe I'm missing something there.

~~~
sccxy
Windows 10 with 125% it is little bit blurry, but so are most of the apps
which does not use vector graphics.

Anyway for me it looks good and very fast!

------
allisterb
This is pretty awesome. The UI load time and responsiveness are vert
impressive. I hate web dev with a passion and I've been looking for something
like this.

------
majorexception
Hmm. I have 4-core i7-4770, but the UI on this thing lags a lot, all widgets
generally feels sluggish. Such graphics operations don't require a lot of CPU,
though, remember that we used to have 200 MHz Pentiums?

On Firefox it's even worse, looks like it was rendered by 4 MHz Apple II. :|

But if it allows easy porting of a Java app to a browser, then this is still
great stuff. Not the most responsive UI, but in case of emergency, why not?

------
droobles
This is awesome! Great work. How does this work on older browsers? It would
have a leg up on current web assembly if it's backwards compatible.

~~~
jeffreportmill1
I haven't done much testing on older systems. I'm looking forward to WASM,
though. TeaVM has an option to compile there, but I haven't tried it. There's
a bit of code that should benefit from WASM - and when threading is standard,
that will be a big advance as well. Also WASM's ability to compile while
downloading should be nice.

------
_the_inflator
This is fun. So basically the web browser becomes a sandbox for Java.

Maybe we can get Spring Boot running in TeaVM instead of Docker. ;)

~~~
collyw
This was one of the original selling points for Java back ~2000.

~~~
jeffreportmill1
I suppose the plug-in/Applet approach is why it didn't fly - same reason Flash
has gone away.

It's unfortunate Oracle hasn't adopted the approach of treating the browser as
a target platform. TeaVM and CheerpJ have just a couple engineers working on
this and they've done great things. A fully supported effort could really make
this take off.

------
gedy
Very cool! I used to dev Java desktop UIs and applets, really impressive to
see this running on a phone

~~~
halfjoking
I made a game as an applet a long time ago. This makes me want to find that
old code and try it in TeaVM.

------
brabel
This is insane. The thing actually runs really well. Can it run pure JavaFX
Applications as well?

~~~
jeffreportmill1
No - this app uses a UI kit called SnapKit (available on GitHub). It's kind of
a composite of Swing and JavaFX. Like those, it abstracts drawing and user
input, so that on the JVM it uses Java2D/Swing and in the browser it uses DOM.

There's a product called CheerpJ that compiles Swing apps to the browser. I'm
not sure when/if we'll see JavaFX.

------
ww520
Wow impressive! This runs really well on Firefox on a Ryzen 7 1800X.

------
DiseasedBadger
It runs slightly worse than most java UIs for me on a Dell + i7 + Chrome, for
me.

I also could not use any keyboard shortcuts, and the edit menu options did
nothing at all.

Despite that, it really exceeded my expectations.

------
jillesvangurp
Cool as a demo but not really something I recommend other than as a way of
salvaging low value legacy java applications (of which there are a lot) where
the UX is secondary to the ability to keep the application in a functioning
state and where it is not feasible to build a replacement.

OpenJdk in wasm might become a thing actually. The download size is not going
to be very nice of course but might be acceptable for an intranet type thing
that people want to keep alive for whatever reason.

Wasm might soon enable a lot of things that are currently hard and make them
both feasible and common again. Flash, silverlight, and shockwave could be
kind of nice back in the day and it used to do a lot of things (some of which
hopelessly misguided) that are still quite hard to pull off with modern web
applications. Most games have better looking and more responsive UIs than many
websites. Stuttering laggy divs with broken animations, hover effects, etc.
are not a substitute.

I recently got involved in some front end work as I inherited some of that
when one of our people left. I must say I find this stuff super tedious to
deal with and disappointingly primitive after basically not having done any
serious UI work for most of this millennium (usually stick to backend). I suck
at this obviously but it seems things could be improved in many ways by
rethinking a few things.

IMHO, some native UI kits adapted to WASM combined with modern yet powerful
languages like Kotlin, Swift, C#, or Rust should be running circles around
most frontend teams in terms of performance, productivity, and quality once
this stuff matures a bit.

Scriptable DOM trees as a side effect of browsers exposing their internals to
a hacked together bit of scripting language seems to have snowballed into this
everything is a document but not really paradigm where you have this unholy
mess of nodes and events tied together by a language that is continuously
patched up to make this less painful but hopelessly stuck in its own history.

Apologies for the Friday afternoon rant but I've been staring at some example
of modern web development the whole day and have a stiff neck from shaking my
head in disgust.

~~~
coldtea
> _Cool as a demo but not really something I recommend other than as a way of
> salvaging low value legacy java applications (of which there are a lot)
> where the UX is secondary_

Are we talking about the same app?

The UI here is better than most web SPAs (and where it's not, it's not because
of the libraries used), and indicative how more uniform, streamlined, and
familiar web apps could be if we had gone with a rich widget set and layout
engine (like Java has and this uses) from the get go.

~~~
icedchai
Absolutely. Doing "UI's" with the DOM (HTML / CSS / JS) was a big step
backwards. We've spent two decades trying to graft an application platform
onto a document delivery system.

------
random_kris
is it possible to port other java project to web version? at my work we are
heavy users of jaspersoft Ireport. but anyone working with it can verify that
working with ireport is quite a hell... - problems with different versions of
java, different jars, problems running report on production etc.... So I got
an idea of creating a web based ireport where everyone editing it would be
working on the same version of software.

~~~
jeffreportmill1
It's a bit of work for a typical Swing app using this technology (TeaVM) which
has a small runtime. However, there is another Java-to-JS compiler called
CheerpJ which handles many Swing apps without much work. The only downside is
a larger runtime, so apps can take a bit to launch.

I'd love to hear more about your idea for web based ireport. Send me a note at
jeff at reportmill if you want to chat (or call the main line).

------
alexandernst
I have mixed feelings about this. Is that a good thing? Should we now get back
to writing Java UIs and then just compile them to javascript?

~~~
Illniyar
We did. It was called GWT and it was aweful. Lets not.

~~~
Bjartr
GWT has its strengths (it's been doing the equivalent of tree-shaking and dead
code elimination since 2006).

I use it daily at work. It's an impressive feat of engineering with a
lackluster ecosystem and inconsistent documentation. Although it's not dead
yet (at least technically) as it still has (slow) active development
happening.

~~~
tudelo
What is your opinion on the compile time though? No matter how I feel about
what it actually can do I just can NOT get over the compile time.

~~~
Bjartr
In my day to day there's about 30 seconds for a cold compile (which is rare,
only when I clear byte caches) and maybe 5 seconds usually, less if I've just
changed one line or something small like that.

That said we're not using GWT for CSS, so that reduces iteration time where
it's most noticable.

------
dreamcompiler
Please for the love of god, no. Just no.

------
collyw
Java applets are back?!

~~~
jeffreportmill1
This is really a Java desktop app compiled to the browser. Oracle/Sun probably
made a mistake by not thinking of the browser as just another target platform
(in full-screen mode). The separate Applet concept probably added an
unnecessary layer of complication.

------
1023bytes
Interesting as a demo, but nearly unusable in practice.

~~~
macspoofing
I suspect you're right, but explain your reasoning?

------
ConcernedCoder
So yay? I can write Java again instead of JavaScript? Yuck...

~~~
Roboprog
Yeah, I hear you. Replacing 10s of thousands of JS lines with 100s of
thousands of Java lines doesn’t feel like progress. Most Java (only)
programmers look at JS as an “inferior, weird” language, but it’s actually
much more powerful and concise if you dig into it.

However, there are other, better (than vanilla Java) languages that generate
class files for the JVM which this tool can apparently convert to WASM. Might
have some redeeming features. Clojure to WASM maybe???

It’s not like CSS is all that fun — this approach gets rid of DOM manipulation
for use-cases where a more pure graphical layout is appropriate.

~~~
macspoofing
>Replacing 10s of thousands of JS lines with 100s of thousands of Java lines
doesn’t feel like progress.

In no way is that true.

~~~
Roboprog
Compare something like Java Spring dependency injection of “service” classes
to code using partial function application and higher order functions.

E.g. - [https://ramdajs.com/docs/#partial](https://ramdajs.com/docs/#partial)

Of course, I’m assuming that the JS programmer is exploiting FP and dynamic
types, and not just transliterating Java style static OOP code.

------
gadders
OP posted the same story two years or so ago:

[https://news.ycombinator.com/item?id=15357394](https://news.ycombinator.com/item?id=15357394)

~~~
jeffreportmill1
True, but this version is a game changing update - takes seconds to load
instead of minutes, runs much faster and is much more complete.

~~~
gadders
Ah, OK. It does seem quite snappy on my system.

