4 ms·

> They were so significant that only one company managed to build a decent-looking app in Swing [IntelliJ IDEA] Also NetBeans. I'm not convinced that JavaFX i

> They were so significant that only one company managed to build a decent-looking app in Swing [IntelliJ IDEA] Also NetBeans. I'm not convinced that JavaFX is too slow for use in real-world GUIs. The article doesn't really back up this claim. It also ignores the SWT toolkit, used by Eclipse.

floriol 6y ago
Not my project but this video seems to imply that it has no problem with performance whatsoever: https://www.youtube.com/watch?v=7Hai7cavmUY https://www.youtube.com/watch?v=7Hai7cavmUY
Cthulhu_ 6y ago
> I'm not convinced that JavaFX is too slow for use in real-world GUIs. I would like to have an opinion on this myself but I've yet to find a JavaFX application in the wild.
- radomir_cernoch 6y ago
  We do use JavaFX in an app for our customer. The application is not public, however. There are many aspects to UI performance. Unlike IntelliJ, our app has only tens of widgets displayed at once - I can't compare in this regard. However, we have very big models, namely tables with >100000 of rows. Scrolling is smooth and initialization as well. From my experience, JavaFX allows you to write elegant code which still caches a lot of components. This is a strong performance benefit. My issue with JavaFX is a very well thought-out philosophy, translated into an API which is far from perfect. Once you go beyond "hello world" examples, you e.g. have to start type-casting. I'd love to see JavaFX v3 where these things would be sorted.
  - ta988 6y ago
    My experience as well. JavaFX proved to be really fast for us (internal tools as well). Used to control equipment (live) or do calculations. And we distribute in a <200MB package jre included (modular builds), installs on a fresh windows or linux with no other download. For people that already have a jdk installed, i think we are around 100MB. There has been a lot of work on making "small" distributable java apps in the recent JDKs.
- frou_dh 6y ago
  I tried JavaFX recently and within seconds all I could notice was jacked up font rendering. By this point, it should be table-stakes that any GUI framework must always be tapped into identical font rendering to native apps on the host platform.
  - shock 6y ago
    Different JVMs have different font rendering settings. Try Zulu.
- geokon 6y ago
  I wrote a JavaFX application in Clojure using CLJFX. It's fantastic and native-speed when you do things right https://github.com/geokon-gh/corascope/ https://github.com/geokon-gh/corascope/ I even managed to make a little SVG backend for it That said - this seems to be more of a " graphics library " while JavaFX is more of a " user interface library ". I'm sure there is a ton of overlap - but I wouldn't be making funky creative coding displays directly in JavaFX My minor annoyance is that it's nearly impossible to make something that runs on Android out of that - which seems like a giant shame given it's all JVM
  - jb1991 6y ago
    The end of the article points out how this graphics library is getting used as part of a UI kit. The article goes full circle, it talks about the three different components of UI technology up front, and then shows the other two components near the end.
- deleted 6y ago
  [deleted]
usrusr 6y ago
The omission of SWT made it very hard to read for me. It's really only relevant for the introduction (on the low level that a skia binding is, SWT is surely just going through AWT), but echoes of the omission still bounced around in my head in the later bits, distracting me. A quick dismissal (good or not) would have made the rest much easier to read. Unfortunately I find the last part a bit confusing: is this the lower level of the stack that beneath Compose Desktop? How is skiko related, or is it unrelated? Apparently Compose Desktop is built on Skijo (the github readme is much less confusing). Apparently the skiko build is also consuming skija as a dependency (in some very interesting ways, apparently planet kotlin still does enough java to lombok it), but the presentation on the blog would benefit a lot from a healthy dose of clear "that uses this" bragging. All in all as a slowly greying java guy, it's amazing to see this entirely unexpected breath of fresh air for the JVM. In this age of new desktop apps having been given up completely to electron and the like, desktop JVM could see a surprising renaissance as a lesser evil.
- MaxBarraclough 6y ago
  > SWT is surely just going through AWT Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI. > desktop JVM could see a surprising renaissance as a lesser evil I'm not convinced that a whole new toolkit is the solution, with all the challenges that brings (lots of widgets to create, internationalisation, accessibility, multiple platforms to test on, etc). I figure the better move would be to work on improving JavaFX. As far as I can tell it's a pretty solid GUI toolkit, albeit one with little adoption. edit Also, I suspect one of the things holding back Java desktop GUIs might be that they're often clumsy to distribute. Expecting the user to install the JVM isn't good enough, the application should bundle a JVM, or use ahead-of-time compilation. The user should never be made aware of what language you built the program in. As I understand it, OpenJDK has been making solid progress on the latter option. (And Excelsior JET no longer exists.)
  - usrusr 6y ago
    > Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI. A right, I forgot that, thanks. What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs? In any case this property of SWT kind of explains the omission, SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop.

floriol 6y ago

Not my project but this video seems to imply that it has no problem with performance whatsoever: https://www.youtube.com/watch?v=7Hai7cavmUY https://www.youtube.com/watch?v=7Hai7cavmUY

Cthulhu_ 6y ago

> I'm not convinced that JavaFX is too slow for use in real-world GUIs. I would like to have an opinion on this myself but I've yet to find a JavaFX application in the wild.

radomir_cernoch 6y ago
We do use JavaFX in an app for our customer. The application is not public, however. There are many aspects to UI performance. Unlike IntelliJ, our app has only tens of widgets displayed at once - I can't compare in this regard. However, we have very big models, namely tables with >100000 of rows. Scrolling is smooth and initialization as well. From my experience, JavaFX allows you to write elegant code which still caches a lot of components. This is a strong performance benefit. My issue with JavaFX is a very well thought-out philosophy, translated into an API which is far from perfect. Once you go beyond "hello world" examples, you e.g. have to start type-casting. I'd love to see JavaFX v3 where these things would be sorted.
- ta988 6y ago
  My experience as well. JavaFX proved to be really fast for us (internal tools as well). Used to control equipment (live) or do calculations. And we distribute in a <200MB package jre included (modular builds), installs on a fresh windows or linux with no other download. For people that already have a jdk installed, i think we are around 100MB. There has been a lot of work on making "small" distributable java apps in the recent JDKs.
frou_dh 6y ago
I tried JavaFX recently and within seconds all I could notice was jacked up font rendering. By this point, it should be table-stakes that any GUI framework must always be tapped into identical font rendering to native apps on the host platform.
- shock 6y ago
  Different JVMs have different font rendering settings. Try Zulu.
geokon 6y ago
I wrote a JavaFX application in Clojure using CLJFX. It's fantastic and native-speed when you do things right https://github.com/geokon-gh/corascope/ https://github.com/geokon-gh/corascope/ I even managed to make a little SVG backend for it That said - this seems to be more of a " graphics library " while JavaFX is more of a " user interface library ". I'm sure there is a ton of overlap - but I wouldn't be making funky creative coding displays directly in JavaFX My minor annoyance is that it's nearly impossible to make something that runs on Android out of that - which seems like a giant shame given it's all JVM
- jb1991 6y ago
  The end of the article points out how this graphics library is getting used as part of a UI kit. The article goes full circle, it talks about the three different components of UI technology up front, and then shows the other two components near the end.
deleted 6y ago
[deleted]

usrusr 6y ago

The omission of SWT made it very hard to read for me. It's really only relevant for the introduction (on the low level that a skia binding is, SWT is surely just going through AWT), but echoes of the omission still bounced around in my head in the later bits, distracting me. A quick dismissal (good or not) would have made the rest much easier to read. Unfortunately I find the last part a bit confusing: is this the lower level of the stack that beneath Compose Desktop? How is skiko related, or is it unrelated? Apparently Compose Desktop is built on Skijo (the github readme is much less confusing). Apparently the skiko build is also consuming skija as a dependency (in some very interesting ways, apparently planet kotlin still does enough java to lombok it), but the presentation on the blog would benefit a lot from a healthy dose of clear "that uses this" bragging. All in all as a slowly greying java guy, it's amazing to see this entirely unexpected breath of fresh air for the JVM. In this age of new desktop apps having been given up completely to electron and the like, desktop JVM could see a surprising renaissance as a lesser evil.

MaxBarraclough 6y ago
> SWT is surely just going through AWT Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI. > desktop JVM could see a surprising renaissance as a lesser evil I'm not convinced that a whole new toolkit is the solution, with all the challenges that brings (lots of widgets to create, internationalisation, accessibility, multiple platforms to test on, etc). I figure the better move would be to work on improving JavaFX. As far as I can tell it's a pretty solid GUI toolkit, albeit one with little adoption. edit Also, I suspect one of the things holding back Java desktop GUIs might be that they're often clumsy to distribute. Expecting the user to install the JVM isn't good enough, the application should bundle a JVM, or use ahead-of-time compilation. The user should never be made aware of what language you built the program in. As I understand it, OpenJDK has been making solid progress on the latter option. (And Excelsior JET no longer exists.)
- usrusr 6y ago
  > Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI. A right, I forgot that, thanks. What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs? In any case this property of SWT kind of explains the omission, SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop.