22 ms·

Show HN: 300k lines of Java UI code running native in browser at desktop speed

_the_inflator 8y ago
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 8y ago
  This was one of the original selling points for Java back ~2000.
  - jeffreportmill1 8y ago
    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.
hbz 8y ago
Seemed to freeze up after I loaded a sample and clicked a few things inside it
- jeffreportmill1 8y ago
  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.
- chvid 8y ago
  Runs quite nice in Safari. I had no troubles loading the samples. Impressive technical feat.
- deleted 8y ago
  [deleted]
jeffreportmill1 8y ago
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
- Klathmon 8y ago
  Those are some incredible stats! Do you have any insight or ideas on where the performance increases and size decreases are coming from? Also, did you have to work a lot to get it working in TeaVM? The last I looked at it (which was admittedly over a year ago), it still required some non-trivial changes for the Java app I was working with at the time.
  - jeffreportmill1 8y ago
    I think the big win is that TeaVM has a lighter runtime and conditionally compiles only what is needed into the final JavaScript. There are tools that let Java do this now, but I think the standard runtime has more cross dependencies. My app cross compiles to JVM and browser easily now, but I did a lot of work on the SnapKit UI framework, which is like Swing but abstracts out graphics and user input. My app used to be all Swing - that would be almost impossible with TeaVM. There is product called CheerpJ which does Swing with almost no modification, but it has a larger runtime.
- soulnothing 8y ago
  Is this using JavaFX or the the noted framework Flavour from teavm?
  - jeffreportmill1 8y ago
    I use something called SnapKit (available on GitHub). It's like Swing and JavaFX had a baby, except that it has an abstraction layer that lets it compile to either JVM or JavaScript.
    - 8y ago
seba_dos1 8y ago
It's cool, but it runs at about 10 FPS at best for me :P
- jeffreportmill1 8y ago
  What browser? I get at least 50 fps on Chrome, Safari. Firefox does seem about half that for me though.
  - seba_dos1 8y ago
    Firefox. It's slightly better in Falkon, but not much.
    - fastball 8y ago
      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 8y ago
        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 8y ago
        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...
  - bzbarsky 8y ago
    I'd love the specific steps to reproduce this. Once I create a new document, then what?
lasagnaphil 8y ago
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.
- jeffreportmill1 8y ago
  I get desktop speed for Chrome, Safari, but FireFox does lag for me. The first run does load various UI files on demand, but once cached, most delays go away.
  - TeMPOraL 8y ago
    Yeah, what's up with that? I use Firefox a lot, and I've noticed it always has poor performance on heavy JS apps. The off time I need one of such apps is the only reason I keep Chrome installed on my system.
    - 93s6oz 8y ago
      Firefox has worse performance than Chrome overall, despite what their synthetic benchmarks might say.
      - ionised 8y ago
        How are you measuring 'overall'?
        93s6oz 8y ago
        I am not measuring it, that's the point. Synthetic benchmarks are useless when real life experience shows the opposite.
        xori 8y ago
saagarjha 8y ago
I went in with low expectations, but this works surprisingly well on iPad.
- jeffreportmill1 8y ago
  It even runs reasonably well on iPhone - though squinting required. And an Apple pencil doesn't hurt, too.
  - xondono 8y ago
    As long as you don’t try landscape..
- snazz 8y ago
  It runs significantly faster on my iPad than my laptop.
random_kris 8y ago
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 8y ago
  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).
chlvsl 8y ago
This is awesome. How does this compare to the Pentaho reporting platform? I see you have a browser-based version as well, how performant is it really? Our company currently uses Pentaho for reporting and it's a nightmare - goes down all the time, code is a black box, impossible to work with. This seems like it's really performant and suited for the task at hand, great work. Do you know if anyone has had success deploying this as a service for multiple users? Could we run this on a cluster and allow individual users to have accounts on the platform?
alexandernst 8y ago
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 8y ago
  We did. It was called GWT and it was aweful. Lets not.
  - Bjartr 8y ago
    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 8y ago
      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.
      - jeffreportmill1 8y ago
        With TeaVM, I can do all my iterative development on the JVM (instant compile time). Compiling to the browser is usually just a one time thing for deployment. Although, TeaVM also have a "dev-server" mode that does iterative compiles, which is apparently much faster for iterative development.
      - Bjartr 8y ago
        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.
mwcampbell 8y ago
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.
- jeffreportmill1 8y ago
  You're right - it would require a bit of work, however, it wouldn't be that bad for a shared UI framework. I also think this kind of thing will be more common as WebAssembly allows other languages to move to the browser.
  - mwcampbell 8y ago
    Did you consider an SWT-like approach, where the toolkit uses each platform's native widgets? Porting SWT to the Web platform might even be feasible.
    - jeffreportmill1 8y ago
      I have gone down this road before - but I think this is why many people saw Java as "Write Once, Debug Everywhere". It's just hard to write an abstraction that fronts for so much different native code on different platforms. Something is always going to break. Whereas if you run the same code everywhere, it might actually run everywhere.
      - mwcampbell 8y ago
        So, I guess you have to either take on the extra work of debugging multiple UI implementations, or take on the extra work of making your own toolkit accessible. Personally, I would have chosen the former.
gadders 8y ago
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 8y ago
  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 8y ago
    Ah, OK. It does seem quite snappy on my system.
1023bytes 8y ago
Interesting as a demo, but nearly unusable in practice.
- macspoofing 8y ago
  I suspect you're right, but explain your reasoning?
gedy 8y ago
Very cool! I used to dev Java desktop UIs and applets, really impressive to see this running on a phone
- halfjoking 8y ago
  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.
drderidder 8y ago
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.
- alvalentini 8y ago
  Amen to that
- jeffreportmill1 8y ago
  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.
  - giornogiovanna 8y ago
    I don't know if such a thing exists yet, but how would Java compare to a shared Electron? [ Found the issue. https://github.com/electron/electron/issues/673 https://github.com/electron/electron/issues/673 ]
  - drderidder 8y ago
    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.
majorexception 8y ago
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?
jimbo1qaz 8y ago
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.
- roywiggins 8y ago
  Looks that way. That said, it's better than a lot of legacy apps that either don't upscale (and are too small), or half-upscale and end up unusable.
- jeffreportmill1 8y ago
  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 8y ago
    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!
  - deleted 8y ago
    [deleted]
collyw 8y ago
Java applets are back?!
- jeffreportmill1 8y ago
  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.
droobles 8y ago
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 8y ago
  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.
catsanddogsare 8y ago
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)
- jeffreportmill1 8y ago
  If you really use an app all day long, you're going to want a dedicated desktop version. The browser app-in-an-app model is convenient for casual use, but not optimal for long stretches and doesn't integrate as well with the desktop for real workflow. When you think about it, iOS and Android apps are desktop apps (in full screen mode), not browser apps. And they may be more popular than web apps, for now (though I hate the toll imposed on them). Maybe someday soon, you'll be able to click on a web app and turn it into a desktop app, with better native platform integration. That might be a reason to stop desktop development.
- vollmond 8y ago
  I think there are a lot of other software categories to add to your parenthetical, but I think you're right that it'll be only those things that require a really rich interface (I'd add music production software, for example). I know for myself (15-ish year Java dev), even if software I'm writing will only ever be used on my local laptop, if I need UI I'm likely to do a Spring Boot app with a web frontend and Bootstrap.
- ben509 8y ago
  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.
jillesvangurp 8y ago
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 8y ago
  >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.
epaga 8y ago
Related would be JWebAssembly (Java to WASM compiler): https://github.com/i-net-software/JWebAssembly https://github.com/i-net-software/JWebAssembly
sparsely 8y ago
Performs better than most websites which intentionally target JS
- chrisco255 8y ago
  You mean the DOM. The web isn't slow because of JS.
  - blotter_paper 8y ago
    Slow is relative, and JS is slow relative to WASM.
    - rat9988 8y ago
      I can't tell what you are trying to refute in your parent comment.
      - blotter_paper 8y ago
        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 8y ago
        No its not. JS is extremely fast. The demo above is Java compiled to JS, NOT webassembly.
        blotter_paper 8y ago
        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-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...
ConcernedCoder 8y ago
So yay? I can write Java again instead of JavaScript? Yuck...
- Roboprog 8y ago
  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 8y ago
    >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 8y ago
      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.
qrohlf 8y ago
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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
DiseasedBadger 8y ago
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.
brabel 8y ago
This is insane. The thing actually runs really well. Can it run pure JavaFX Applications as well?
- jeffreportmill1 8y ago
  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.
thope 8y ago
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/textedit/textedit.html http://example.qt.io/qt-webassembly/widgets/richtext/textedi...
ww520 8y ago
Wow impressive! This runs really well on Firefox on a Ryzen 7 1800X.
allisterb 8y ago
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.
deleted 8y ago
[deleted]
darryl_haye 8y ago
I just threw up in my mouth a little
dreamcompiler 8y ago
Please for the love of god, no. Just no.
benboughton1 8y ago
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?
truth_seeker 8y ago
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.
deleted 8y ago
[deleted]

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 8y ago
This was one of the original selling points for Java back ~2000.
- jeffreportmill1 8y ago
  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.

hbz 8y ago

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

jeffreportmill1 8y ago
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.
chvid 8y ago
Runs quite nice in Safari. I had no troubles loading the samples. Impressive technical feat.
deleted 8y ago
[deleted]

jeffreportmill1 8y ago

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

Klathmon 8y ago
Those are some incredible stats! Do you have any insight or ideas on where the performance increases and size decreases are coming from? Also, did you have to work a lot to get it working in TeaVM? The last I looked at it (which was admittedly over a year ago), it still required some non-trivial changes for the Java app I was working with at the time.
- jeffreportmill1 8y ago
  I think the big win is that TeaVM has a lighter runtime and conditionally compiles only what is needed into the final JavaScript. There are tools that let Java do this now, but I think the standard runtime has more cross dependencies. My app cross compiles to JVM and browser easily now, but I did a lot of work on the SnapKit UI framework, which is like Swing but abstracts out graphics and user input. My app used to be all Swing - that would be almost impossible with TeaVM. There is product called CheerpJ which does Swing with almost no modification, but it has a larger runtime.
soulnothing 8y ago
Is this using JavaFX or the the noted framework Flavour from teavm?
- jeffreportmill1 8y ago
  I use something called SnapKit (available on GitHub). It's like Swing and JavaFX had a baby, except that it has an abstraction layer that lets it compile to either JVM or JavaScript.
  - 8y ago

seba_dos1 8y ago

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

jeffreportmill1 8y ago
What browser? I get at least 50 fps on Chrome, Safari. Firefox does seem about half that for me though.
- seba_dos1 8y ago
  Firefox. It's slightly better in Falkon, but not much.
  - fastball 8y ago
    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 8y ago
      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 8y ago
        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...
- bzbarsky 8y ago
  I'd love the specific steps to reproduce this. Once I create a new document, then what?

lasagnaphil 8y ago

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.

jeffreportmill1 8y ago
I get desktop speed for Chrome, Safari, but FireFox does lag for me. The first run does load various UI files on demand, but once cached, most delays go away.
- TeMPOraL 8y ago
  Yeah, what's up with that? I use Firefox a lot, and I've noticed it always has poor performance on heavy JS apps. The off time I need one of such apps is the only reason I keep Chrome installed on my system.
  - 93s6oz 8y ago
    Firefox has worse performance than Chrome overall, despite what their synthetic benchmarks might say.
    - ionised 8y ago
      How are you measuring 'overall'?
      - 93s6oz 8y ago
        I am not measuring it, that's the point. Synthetic benchmarks are useless when real life experience shows the opposite.
        xori 8y ago

saagarjha 8y ago

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

jeffreportmill1 8y ago
It even runs reasonably well on iPhone - though squinting required. And an Apple pencil doesn't hurt, too.
- xondono 8y ago
  As long as you don’t try landscape..
snazz 8y ago
It runs significantly faster on my iPad than my laptop.

random_kris 8y ago

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 8y ago
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).

chlvsl 8y ago

This is awesome. How does this compare to the Pentaho reporting platform? I see you have a browser-based version as well, how performant is it really? Our company currently uses Pentaho for reporting and it's a nightmare - goes down all the time, code is a black box, impossible to work with. This seems like it's really performant and suited for the task at hand, great work. Do you know if anyone has had success deploying this as a service for multiple users? Could we run this on a cluster and allow individual users to have accounts on the platform?

alexandernst 8y ago

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 8y ago
We did. It was called GWT and it was aweful. Lets not.
- Bjartr 8y ago
  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 8y ago
    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.
    - jeffreportmill1 8y ago
      With TeaVM, I can do all my iterative development on the JVM (instant compile time). Compiling to the browser is usually just a one time thing for deployment. Although, TeaVM also have a "dev-server" mode that does iterative compiles, which is apparently much faster for iterative development.
    - Bjartr 8y ago
      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.

mwcampbell 8y ago

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.

jeffreportmill1 8y ago
You're right - it would require a bit of work, however, it wouldn't be that bad for a shared UI framework. I also think this kind of thing will be more common as WebAssembly allows other languages to move to the browser.
- mwcampbell 8y ago
  Did you consider an SWT-like approach, where the toolkit uses each platform's native widgets? Porting SWT to the Web platform might even be feasible.
  - jeffreportmill1 8y ago
    I have gone down this road before - but I think this is why many people saw Java as "Write Once, Debug Everywhere". It's just hard to write an abstraction that fronts for so much different native code on different platforms. Something is always going to break. Whereas if you run the same code everywhere, it might actually run everywhere.
    - mwcampbell 8y ago
      So, I guess you have to either take on the extra work of debugging multiple UI implementations, or take on the extra work of making your own toolkit accessible. Personally, I would have chosen the former.

gadders 8y ago

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 8y ago
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 8y ago
  Ah, OK. It does seem quite snappy on my system.

1023bytes 8y ago

Interesting as a demo, but nearly unusable in practice.

macspoofing 8y ago
I suspect you're right, but explain your reasoning?

gedy 8y ago

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

halfjoking 8y ago
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.

drderidder 8y ago

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.

alvalentini 8y ago
Amen to that
jeffreportmill1 8y ago
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.
- giornogiovanna 8y ago
  I don't know if such a thing exists yet, but how would Java compare to a shared Electron? [ Found the issue. https://github.com/electron/electron/issues/673 https://github.com/electron/electron/issues/673 ]
- drderidder 8y ago
  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.

majorexception 8y ago

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?

jimbo1qaz 8y ago

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.

roywiggins 8y ago
Looks that way. That said, it's better than a lot of legacy apps that either don't upscale (and are too small), or half-upscale and end up unusable.
jeffreportmill1 8y ago
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 8y ago
  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!
- deleted 8y ago
  [deleted]

collyw 8y ago

Java applets are back?!

jeffreportmill1 8y ago
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.

droobles 8y ago

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 8y ago
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.

catsanddogsare 8y ago

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)

jeffreportmill1 8y ago
If you really use an app all day long, you're going to want a dedicated desktop version. The browser app-in-an-app model is convenient for casual use, but not optimal for long stretches and doesn't integrate as well with the desktop for real workflow. When you think about it, iOS and Android apps are desktop apps (in full screen mode), not browser apps. And they may be more popular than web apps, for now (though I hate the toll imposed on them). Maybe someday soon, you'll be able to click on a web app and turn it into a desktop app, with better native platform integration. That might be a reason to stop desktop development.
vollmond 8y ago
I think there are a lot of other software categories to add to your parenthetical, but I think you're right that it'll be only those things that require a really rich interface (I'd add music production software, for example). I know for myself (15-ish year Java dev), even if software I'm writing will only ever be used on my local laptop, if I need UI I'm likely to do a Spring Boot app with a web frontend and Bootstrap.
ben509 8y ago
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.

jillesvangurp 8y ago

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 8y ago
>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.

epaga 8y ago

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

sparsely 8y ago

Performs better than most websites which intentionally target JS

chrisco255 8y ago
You mean the DOM. The web isn't slow because of JS.
- blotter_paper 8y ago
  Slow is relative, and JS is slow relative to WASM.
  - rat9988 8y ago
    I can't tell what you are trying to refute in your parent comment.
    - blotter_paper 8y ago
      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 8y ago
        No its not. JS is extremely fast. The demo above is Java compiled to JS, NOT webassembly.
        blotter_paper 8y ago
        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-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...

ConcernedCoder 8y ago

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

Roboprog 8y ago
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 8y ago
  >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 8y ago
    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.

qrohlf 8y ago

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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

DiseasedBadger 8y ago

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.

brabel 8y ago

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

jeffreportmill1 8y ago
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.

thope 8y ago

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/textedit/textedit.html http://example.qt.io/qt-webassembly/widgets/richtext/textedi...

ww520 8y ago

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

allisterb 8y ago

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.

deleted 8y ago

[deleted]

darryl_haye 8y ago

I just threw up in my mouth a little

dreamcompiler 8y ago

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

benboughton1 8y ago

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?

truth_seeker 8y ago

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.

deleted 8y ago

[deleted]