32 ms·

Graphics for JVM

564 points by agluszak 6y ago

LandR 6y ago
> C# would do, too, but it doesn’t have Clojure. Do you mean .NET would do too?
- spacemanmatt 6y ago
  Probably means CLR. And there is technically some Clojure for CLR but it's not as regularly maintained.
  - harperlee 6y ago
    I have not used CLR but last time someone said here it was abandoned (I know, not what you said!), Alex Miller response was that it was up to date with the JVM version: https://news.ycombinator.com/item?id=21192321 https://news.ycombinator.com/item?id=21192321 Admittedly this was a year ago! Time flies...
    - nlitened 6y ago
      I am pretty sure Clojure is "stable" so nothing changed in the past year.
      - harperlee 6y ago
        This is only incidentally correct (last stable release was June 6, 2019), because clojure is still evolving, just slowly and stably. A new prerelease was announced September 4, 2020 at https://insideclojure.org https://insideclojure.org.
  - joppy 6y ago
    Some Clojure libraries have a hard dependency on Java (or JavaScript, in the case of libraries supporting ClojureScript) - Clojure does not cover all use cases. For example, if you want to do anything more complicated than find-all-matches with a regular expression you need to call the underlying Java classes from Clojure. I expect this is probably the biggest obstacle to getting Clojure on CLR working properly: the language is not the issue, the libraries are.
    - spacemanmatt 6y ago
      Yeah, to that extent, I feel like you need to pick your runtime first with Clojure. Like you said, it dictates quite a lot about your development options.
    - fulafel 6y ago
      What kind of use cases have you had with the regexps that were not covered? (Just curious as I've not hit this). The builting regexp support can do many kinds of advanced regexp things such as having a callback fn return the substitution or precompiling into regexp objects, lazily iterating over matches etc.
MaxBarraclough 6y ago
> 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.
outadoc 6y ago
I'm glad to see this and Compose arrive on desktop. It feels like a potential good middle-ground between a fully native OS toolkit, a cross-platform native toolkit, and an embedded web app. I don't think Java is inherently bad for the job, just that the previous UI toolkits were not what we needed.
agumonkey 6y ago
Ah I wished for something like this for so long. Very nice surprise.
mhd 6y ago
Java had the issue that it was hard to build a consumer desktop app, because Swing etc. were a bit removed from native (L&F, behavior etc.). Those didn't matter as much for desktop apps, which always looked gross. (The issue that they were less usable than the terminal apps they sometimes replaced is another issue) These days, I'm not sure if fixing that is enough. I long for the days when minor UI inconveniences like Borland-ish button icons or that weird Basic thing in the early days of OS X were the worst offenders. Quite often it's _required_ that you deviate from your platform quite a lot, as we've embraced form over function with mobile- and web-like "experiences". Whitespace everywhere, mystery meat navigation and non-conformant widgets and shortcuts that make you long for the skeuomorphic mistakes of the late 90s. Neither Apple nor Microsoft seem to be too much into HIGs these days, and Linux never was. So if this delivers the bricks, what kind of houses would we build with it?
- quanticle 6y ago
  "Those didn't matter as much for desktop apps, which always looked gross." I don't understand what you mean by this. I don't think desktop apps "look gross" at all. Or did you mean that Swing desktop apps looked gross because they didn't conform to the native look and feel of the platform they were running on?
  - mhd 6y ago
    Ooops, very bad typo, totally obscuring my whole point, I meant to say "enterprise apps". Where looking good wasn't a selling point.
tannhaeuser 6y ago
What's wrong with Java 2D, Swing, and SWT specifically, rather than being old? Saying that IntelliJ IDEA is the only Swing app that doesn't suck isn't really an argument to fragment the Java desktop space even further when new desktops apps (Java or otherwise) haven't been developed for well over a decade.
- LoSboccacc 6y ago
  SWT had a lot of weird cross platform quirks which were unbearable to diagnose, it's been 10+ years now so I can't recall all details, but every time I tried under the premise of the better components, as the UI got complex, there was no other solution but escape back to Swing, where the tooling and facilities around where miles better.
- AshamedCaptain 6y ago
  SWT is not even mentioned, being literally the other big elephant in the room (Eclipse). Grosso modo it does not look like due diligence has been done...
- Debug_Overload 6y ago
  The author also lumps AWT, Swing and JavaFX together. They're different, and some were created to solve issues others didn't address, and/or improve them (never mind that JavaFX is its own beast, and is quite different from the other two, which are relatively close). But they're all GUI toolkits, and they all suck doesn't make sense.
grandinj 6y ago
We build all our desktop products using Swing, and it works pretty well. Looks pretty native (if you want it to), is thoroughly battle-tested, reasonably performant, and has a bazillion open-source extras floating around (of varying quality). If you need 3d, we drop into OpenGL and use that (e.g. when integrating WorldWind). Sometimes I feel bad about how easy it is to write desktop UIs in Java - the API is stable, nobody keeps changing it under me, I don't have to wonder what Microsoft is pushing this year, it is (mostly) easy to debug, has open source forms designers (Netbeans), etc, etc.
- MaxBarraclough 6y ago
  Do you plan on trying JavaFX?
  - grandinj 6y ago
    Sigh. I had such high hopes for it, and then Oracle abandoned it. But we are trying it, and opinions (internal to my company) are varied. Some people like it, but I don't. Because (a) it has missing functionality here and there (b) it still has a long road to go to become battle-hardened (c) I don't see any of the current supporters having deep enough pockets to fix (a) and (b) So we're taking a mostly wait-and-see attitude. But we have an existing deep and wide investment in Swing in our products, so our risk profile is probably somewhat different to yours.
    - apta 6y ago
      > Sigh. I had such high hopes for it, and then Oracle abandoned it. As far as I'm aware, it was only pulled from the JVM into a separate dependency, as did several other components, in order to keep the JVM slim. Are you saying development on it stopped altogether?
      - grandinj 6y ago
        Oracle has mostly disbanded the team that was working on it, leaving only one or two staff to manage community contributions. There are however, a couple of small companies, and some individuals using it, and providing contributions.
sgt 6y ago
Skia works really well for Flutter so I think basing it on that is a brilliant choice. Will follow this project.
- oscargrouch 6y ago
  Flutter is what it is because of the quality of the engineering team behind the Dart language. My point being that, Skia is great but is not the most important ingredient at play for Flutter achievements. Also being a good choice will not pay for the bad choice that is choosing JVM as a primary platform for this which targets UI application consumers.
smarx007 6y ago
> Like any other JVM library, it’s cross-platform. It runs on Windows, Linux and macOS. It’s as simple to use as adding a JAR file. Well, not exactly. https://github.com/JetBrains/skija/ https://github.com/JetBrains/skija/ is 30% C++ and of course requires native builds: https://packages.jetbrains.team/maven/p/skija/maven/org/jetbrains/skija/ https://packages.jetbrains.team/maven/p/skija/maven/org/jetb.... If you are lucky, Maven simply hides it from you. UPD: no, it doesn't hide it. See https://github.com/JetBrains/skiko/blob/master/skiko/build.gradle.kts https://github.com/JetBrains/skiko/blob/master/skiko/build.g... and search for 'lin'/'mac'/'win' and see for yourself. UPD2: @-moz-document domain("tonsky.me") { body { /* surovyi background color off */ background-image: none; background-color: hsl(0, 0%, 85.9%); } }
- vbsteven 6y ago
  Is this a problem? We're always going to need native blobs to interface with the OS. The JVM can package these native libraries within the jar so for the application developer it is indeed as simple as adding the jar file to your project.
  - smarx007 6y ago
    Not at all! Desktop apps require platform-specific executables and installers so this is unavoidable. But the author made it sound like a piece of cake for developers used to making JAX-RS services.
  - chrisseaton 6y ago
    > We're always going to need native blobs to interface with the OS. Ideally we won't when the JVM gets an FFI built-in.
    - shock 6y ago
      https://en.m.wikipedia.org/wiki/Java_Native_Interface https://en.m.wikipedia.org/wiki/Java_Native_Interface
saagarjha 6y ago
Ok, so this starts off as “Graphics for the JVM” which sounded promising, but then the first line starts talking about desktop apps and warning bells start going off. If you read the post, it’s totally fine…if you are trying to do fast drawing or something. But no, we’re making desktop apps, with circles and triangles and squares. This just isn’t how it works, and the reason is the same as it always has been: a drawing toolkit is not a GUI toolkit. If you want people to make good apps, you need to give them buttons and checkboxes and text fields. If you don’t, we’ll, they’re going to do it wrong. Time and time again people have tried doing this and the best we’ve gotten out of it are game UIs and Flutter, which are a solid “mediocre” in the UI department. The former probably gets a pass because it’s allowed to be quirky, but the latter is literally run by a megacorp and it’s still struggling to get basic things right. Heck, even Swing and HTML are better than this; at least they give you components that someone actually spent time on implementing and making half-decent. Maybe they suck, but they suck together in a consistent way that is at least partially battle-tested, a must for any GUI toolkit. They’ve gotten to the point where they’re no longer just a middle finger to people with accessibility needs. Look, I don’t want to rain in this author’s work. If you’re going to treat it as an accelerated Graphics2D, go right ahead, this seems like it would be an excellent solution for you. JVM bindings to Skia seem awesome. Just don’t, like, draw something that looks like a GUI in it. (I could go longer about the characterization of mobile apps as constantly being purged from RAM and losing your work and IntelliJ being a good Java UI, but that would probably make this divisive comment longer than it already is.)
- smarx007 6y ago
  Ehmmm, did you actually explore any links? https://www.jetbrains.com/lp/compose/ https://www.jetbrains.com/lp/compose/ shows a code editor prototype.
  - saagarjha 6y ago
    I know Compose exists, and it’s exactly the concern I have: look at the example apps, and compare them with true native desktop apps. Can you really call the result a good desktop UI? Is it not just a mobile UI that was blown up? Actually, it’s difficult to even call it a good mobile UI, because at the moment it certainly falls on the side of “bunch of shapes put together” rather than “UI toolkit”. Of course, while UI is just a bunch of shapes on the screen, it needs to be cohesive, and familiar, and accessible; not to mention the many, many behaviors under-the-hood that don’t show up in a screenshot.
bjarneh 6y ago
> with a lot of quality and performance drawbacks. They were so significant that only one company managed to build a decent-looking app in Swing [Link to JetBrains]. Until I found the J-editor, I sort of agreed. I never understood why that project didn't get any traction; very well made IMO, and it looks good too. https://github.com/gnooth/j https://github.com/gnooth/j
- didibus 6y ago
  Maybe because the repo doesn't even have a readme to tell you what it is?
  - bjarneh 6y ago
    :-) That does not help of course. To be honest it did have a website (he has written a lisp implementation which comes with the editor as well ABCL - [Armed Bear Common Lisp]). I'm pretty sure the build instructions don't work either, and all sorts of other problems. But if you just download the binary distribution from sourceforge, and start it up (java -jar j.jar), you will hopefully see what I mean. It looks nothing like a Java desktop app. He has an excellent icon set, and he overrides the rendering of all sorts of components (scrollbars etc.) making it look superb.
Cloudef 6y ago
>People crave for native apps. Nobody wants to work from the browser. Ah the irony
- Cloudef 6y ago
  Not sure why this is getting downvoted, but JVM is just as native as browser is. The jetbrains IDE mentioned in the article is especially very clunky and slow resource hog. In fact so much, that I would actually prefer using electron app over it.
  - kaba0 6y ago
    Whaat, I would not call intellij unbelievably fast, but it is a resource hog because it does a million thing at once. Compare it to visual studio, which is something that barely works and has inferior auto-complete, etc. An electron app of that complexity would require a supercomputer to even start
    - maynman 6y ago
      For sure. In the case of IntelliJ resource usage, you get what you pay for.
    - deleted 6y ago
      [deleted]
  - PedroBatista 6y ago
    Do you have any idea the complexity and amount of stuff Intellij does behind the scenes?
    - Cloudef 6y ago
      The complexity of getting in the way, melting your computer and not allowing you to write single line of code at the end of the day?
      - 6y ago
dimitar 6y ago
There are lots of fast, usable JVM gui applications. Some OSS examples: http://www.sweethome3d.com http://www.sweethome3d.com - This one has been the one app I've recommended to people outside the tech bubble! It also focuses on graphics and 3d.. really deserves to be showed off more often http://xmind.net http://xmind.net https://dbeaver.com/ https://dbeaver.com/ http://www.mucommander.com/ http://www.mucommander.com/ http://www.jedit.org http://www.jedit.org What they have in common is that they are old project - often more than 10 years old and are not on Github. Goes to show how important hype and trendiness is in our industry. edit: fixed formatting
- bballer 6y ago
  The JetBrains suite (ie IntelliJ, Datagrip etc) while not open source, are a testament to what can be done with JVM based GUI applications. Have you ever used the merge tools? So dang cool.
  - scaladev 6y ago
    https://github.com/JetBrains/intellij-community https://github.com/JetBrains/intellij-community
  - anentropic 6y ago
    The JetBrains merge tools are the best ones I've found! I have it configured as my git mergetool The only problem is it takes absolutely ages to start up, which is maybe a JVM thing I wish there was a way to have git pass all of the conflicting files in a merge to the mergetool at once. Instead of having to wait for JetBrains to load up for each individual file and close after each one :(
    - chrisseaton 6y ago
      > I have it configured as my git mergetool How are you doing this? I haven't seen any merge tool, let alone a standalone one, in the JetBrains toolbox. What am I missing?
loxs 6y ago
The main reason (JVM apps are not more popular) is that the average JVM desktop app does not perform better (or use less resources) than the average Electron app. I know this is not supposed to be that way, but one way or the other, it is. On top of this the web UI developer community is orders of magnitude larger.
- eythian 6y ago
  I don't think that's really true. Years ago, I maintained a Java desktop application, using SWT as the graphics library (not even mentioned by the post author which is weird.) It wasn't a big application, but also not stupidly trivial. It would start fast, run fast, and didn't need much RAM at all. There are of course examples of slow, heavy java applications, but I don't think it has to be that way. I'm not totally sure what I did differently aside from consider my dependencies (e.g. using a lightweight dependency injection framework rather than something like Spring), but it's definitely not a given that Java desktop applications have to use a bucketload of RAM.
  - loxs 6y ago
    Of course it's not "really" true and of course it's not "given"... it's just the sentiment. And the sentiment affects decision making a lot.
- suyash 6y ago
  Java is way faster than JavaScript and the benefits of Java ecosystem including libraries puts it above electron. Native > Web for UX.
chucky 6y ago
> The second is the DOM. It is a horrible collection of hacks that make simple things hard and hard things impossible. I have thought many times “if only was I drawing this control/layout directly, I would’ve finished hours ago.” I think this betrays a lack of understanding on the part of the author of how to write good web components. Yes, the DOM is tricky at first, but that's because it's trying to support things like resizing windows to arbitrary sizes. I don't even understand what he tries to say with "draw the control directly". In component-based library, this is exactly how you would work. Put your component where it needs to be, and boom, you're finished (just like in all frameworks this is a lie, you probably still need to tweak). I don't in general buy the argument that the DOM is low-performant and low-quality. Lots of great and performant UIs have been built on the web platform.
- iovrthoughtthis 6y ago
  Yeah, the whole of the bottom of the post strikes me as off base. I think the author is trying to get to a wonderful future but their heading in totally the wrong direction.
- dmitriid 6y ago
  > I think this betrays a lack of understanding on the part of the author of how to write good web components. Yes, the DOM is tricky at first, but that's because it's trying to support things like resizing windows to arbitrary sizes. This statement betrays the commenter's lack of understanding understanding of both limitations of the Web model and the freedom afforded by almost every single one of UI libs and frameworks. > I don't even understand what he tries to say with "draw the control directly". Aaand here it is: "I don't understand". In a GUI framework/lib you usually have the ability to skip the provided primitives and draw whatever you want directly. A framework/library doesn't provide a control you need? You just draw it yourself. So, instead of re-inventing, poorly, a virtual list, or a calendar, or a customisable drop-down with a few thousand divs, z-index issues and layout thrashing, you can (relatively) easily implement those controls yourself. At easy 60 or 120 fps. > I don't in general buy the argument that the DOM is low-performant and low-quality. Lots of great and performant UIs have been built on the web platform. Name a few, please. And when you look into those "performant UIs", you'll see on or more of: - skipping the DOM entirely and building everything on top of canvas or webgl - going through great pains to: avoid mutating DOM, avoid repaint/reflow (which can happen by simply querying the DOM [1]), reducing the already laughably small amount of updates even further to prevent DOM updates, layout thrashing, JS GC pauses etc. etc. And this will still not come even close to, lets say, displaying a million objects on screen at 120fps (any modern game engine), or any significantly complex UI layout (any professional app). [1] https://csstriggers.com https://csstriggers.com and https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a
geokon 6y ago
Errr, is there some example I can compile both into a Desktop app as well as Android app easily? I never got why we never got convergent Java apps that run everywhere... It's seemingly almost easier to do that with Qt than with Java If I could get an example written in Clojure that'd be even cooler :) I noticed they have this: https://github.com/JetBrains/skija/blob/master/shared/src/main/java/org/jetbrains/skija/Path.java https://github.com/JetBrains/skija/blob/master/shared/src/ma... Is rendering SVG in the pipeline? It seems within the scope of a graphics library.. or maybe not?
cjohansson 6y ago
PR for JetBrains? I think there are plenty of good looking JVM desktop apps which are equally or more good looking as JetBrains stuff. Electron and JVM is bad because they require a lot of resources and that occasionally JVM has security issues
- fastbmk_com 6y ago
  He is an employee of JetBrains in Munich, Germany office.
Darmody 6y ago
I've been using Java mostly for stuff that runs from the terminal and I always wondered why there are almost no games developed with it. I know this submission is not about games but it's related. The very few games that run on the Java platform are very resource hungry, even more than some alternatives made in JS which is supposed to have a worse performance. All that while C# is booming on indie game dev.
- lasagnaphil 6y ago
  C# is better for gamedev for quite a lot of reasons, but most importantly because it has value types (structs) that aren’t boxed. In gamedev you use a lot of small-size types such as Vector3 or Vector4 for all sorts of math, but if you implement them naively in Java you have to always heap-allocate them, which brings severe penalties in terms of cache locality and GC. Modern Java gamedev libraries like JOML tries to avoid this by using NIO buffers (JVM provides some utilities to manually alloc/dealloc memory), but the API is quite finicky as a result. (Plus, there is no operator overloading in Java, which is another bummer.) Project Valhalla is trying to add proper value types to the JVM, but sadly as of today the project seems a bit abandoned... (See https://wiki.openjdk.java.net/display/valhalla/Main https://wiki.openjdk.java.net/display/valhalla/Main)
  - djhworld 6y ago
    > Project Valhalla is trying to add proper value types to the JVM, but sadly as of today the project seems a bit abandoned... The repo seems to have very recent activity, has commits from today! https://github.com/openjdk/valhalla https://github.com/openjdk/valhalla
  - didibus 6y ago
    Agree, and not just gamedev, I think for desktop apps this is an issue as well. The memory profile of a Java app suffer from lots of unnecessary boxing. Also, the GCs are not designed and tuned to desktop apps, but to backend services. So they'll exhibit behavior like never releasing memory back to the OS and hording 100% memory.
- skocznymroczny 6y ago
masa331 6y ago
> People crave for native apps. Nobody wants to work from the browser. Some do, some quite the opposite. Me personally i want to have as few desktop apps installed as possible. They are warranted only in few special cases - browser, video & music player, Excel. Other than that there really is no need to have any desktop app nowadays. > Both of them were recording it on a desktop, in a desktop application, while having a call over another desktop application. Yeah this can be easily done from browser also > it’s hard to select text, hard to search on a page, hard to have multiple tabs, hard to move data between apps excuse me? It's harder to select text or search text in browser than in desktop apps? What? Text search is one ctrl-f away on ANY web page. Switching between tabs in a browser is alt-num. Desktop apps have no tabs and a lot of times you switch between completely different UIs. Moving data between apps depends completely on the app itself. It either offers some kind of data export or does not. It doesn't have to do anything with desktop apps or web apps in general > For example, you are adding an event to the calendar. You need to lookup an address for the event in the mail, which has a link that opens a browser. Yeah in a web apps you at least have some unique link to it. Linking to something on your local computer in some desktop app isn't even possible > Ability to have multiple windows open at the same time is the desktop’s superpower. You know you can have multiple tabs open in one browser right? I like Nikita's articles and if he or anybody prefers desktop over web that's fine. Also the library he is starting - great. But the announcement could really omit the nonsensical comparisons and generalisations of web vs desktop
- d3nj4l 6y ago
  > > it’s hard to select text, hard to search on a page, hard to have multiple tabs, hard to move data between apps > excuse me? It's harder to select text or search text in browser than in desktop apps? What? Text search is one ctrl-f away on ANY web page. Switching between tabs in a browser is alt-num. That is clearly about mobile in contrast to Desktop.
  - masa331 6y ago
    Ah ok, thanks. This makes more sense now. But on a seconds thought - there are people who really "work" on phone? I just can't do anything serious from phone be it native app or web app. The experience is so much worse for me that it didn't even cross my mind it's about phones.
jmartrican 6y ago
This is a great idea. Can't wait to try it out. In a past life I created a video game in JavaFX. Its on Steam. It was hard to do, but I really didn't know what I was doing when I started. I also do not know if JavaFX was missing any features that would be desired for video games, that maybe other libraries have. Nonetheless, for selfish reasons more libraries in this space is welcomed.
unnouinceput 6y ago
Thank Mozilla for Firefox reader mode. This site is horrible to look at. And because of that, dear Nikita, I haven't looked at your repository. Remember the rule "first impression matters"?
- therealasdf 6y ago
  Your loss
  - unnouinceput 6y ago
    Nah, I'm good. Java and its related technologies can die for all I care. I really hate Java. I use it every day because that's where my money come from, supporting legacy crap from 90's but I really hate it.
- vijaybritto 6y ago
  Looks like some css issue. But the content was great
deleted 6y ago
[deleted]
speps 6y ago
Instead of Skia bindings, probably the effort of building a C++ UI toolkit that has the features he needs and THEN do Java bindings for it would prove more useful for the community instead of tying the UI toolkit to Java. That's kind of what's missing in my opinion, something that does the hard part of UI, integration with native OS controls (eg. open dialogs, etc.), accessibility even with custom UI drawn using 2D primitives, etc. and that would be a great project that would also benefit the author as long as it has Java bindings.
cromwellian 6y ago
> WASM implies Rust or C++ Nope, there are lots of languages that compile to WASM. In fact, Kotlin compiles to WASM, and you get the best of both worlds, able to interop with the JVM, and compile to WASM (and C++/ObjC, and JS)
- oscargrouch 6y ago
  Your comment makes me think how WASM will go through this hype phase where people will think is a panacea to build things for the browser.. Hype gold rush all over again, but applications built on native or even javascript ones in the web or Electron will perform better in most cases. Of course companies will think its great for them to have only one codebase for every platform, but applications built with Javascript or Typescript for the web, with eventual WASM module here and there will be a better fit, so it will be risky to try to cut expenses and development there. WASM will be awesome to bring great tech that is only available in native platform to the web, like FFMPEG, or to accelerate some code that uses a lot of math. But i think that people that are going way down into this WASM rabbit hole will have a wake-up call pretty soon. WASM will open some blue-seas for sure, but they are limited to some niche scenarios and using WASM for application development for the web, desktop and mobile wont be one of them.
  - cromwellian 6y ago
    I don't think of WASM as web specific, I think of it as a portable compiler IR format, and from an untrusted third party code, isolation standpoint, running code in WASM has nice security properties. This is why you see it starting to be used for "serverless" deployments.
    - oscargrouch 6y ago
      > This is why you see it starting to be used for "serverless" deployments. For cloud like scenarios WASM probably will be a hit, given its safer and a good target for providers to let developers to create customized apps in any language they want. Also there's centralized decision on which tech should be used. And this make the adoption of new tech much faster. Sure its a portable IR, but is a very limited one and therefore it will be sub-optimal in a lot of scenarios compared to the traditional native applications. In the web alone it will be sub-optimal to the state-of-the-art optimized javascript of today in a lot of cases, even having a much better performance in some special cases. And in the case of desktops, mobile, etc, this will make it even better for javascript applications, which will profit the most in this scenario, with hybrid apps (javascript + WASM). Of course, the FAANG that control the platforms would love to limit more and have absolute control over the platform which will probably be the only native app allowed or that people will run. But the day WASM take the world and we are not allowed to run native applications anymore except the ones the walled gardens allow us to, will be a dark future compared to the freedom we once had. Clean-room monopolized innovation and big tech mammoth's..
marktangotango 6y ago
The author totally misses the real problem with jvm desktop apps, deployment. Either the jvm is bundled with the app or some other (platform dependent) hack has to be employed to ensure a correct version of jre is on the machine. Microsoft manages this nicely with .net btw.
- _old_dude_ 6y ago
  The author is an employee of JetBrain. I believe JetBrian is using jlink [1], a tool that let you embed the modules of the JDK you need with your application, for all their products since they have migrated to JDK 11. [1] https://docs.oracle.com/en/java/javase/11/tools/jlink.html https://docs.oracle.com/en/java/javase/11/tools/jlink.html
- hderms 6y ago
  Is bundling the JVM with the app really such a huge deal on desktops? I know it would add a bunch to the binary size but what are the other issues?
  - krzyk 6y ago
    It is the recommended way since Java 11 (no JRE there) - using jlink can build smaller packages and app developer doesn't depend on the JDK/JRE on the system.
- ptx 6y ago
  Isn't Microsofts solution, starting with .NET 5, essentially the same as Java's jlink/javapackager – i.e. minify and bundle the whole runtime with the app?
altrunox 6y ago
"Wasm can be fast but implies C++ or Rust." Oh BTW, you can do WASM with Blazor (C#) now. https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
x87678r 6y ago
There was a thread on /r/Java about Java GUIs. Seems Jetpack Compose is a potential new player that looks promising. No one seems to know if JavaFX or Swing is the recommended route. https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-1-released/ https://blog.jetbrains.com/cross-post/jetpack-compose-for-de... https://www.reddit.com/r/java/comments/jrqjex/whats_being_used_nowadays_for_java_desktop_apps/ https://www.reddit.com/r/java/comments/jrqjex/whats_being_us...
vijaybritto 6y ago
I am a web developer and I'm only used to developing in JavaScript and a complete beginner in Java. I had an idea for a desktop app and wanted to try out something in javafx as that's what google pointed me to. The build setup for java projects seems to be incredibly complex and I don't find any sort beginner friendly tutorials related to javafx that work on windows without any issues. Then I looked at Android development setup and it's even more insane in size and complexity. I think if the entry into java app development was as easier as electron it would be amazing! I get that it's a well mature platform with a massive ecosystem but it needs to be have something like npm or yarn for javascript development. And importantly are there any thin and light JVMs that can be bundled with this? I'm thinking AdoptOpenJDK openJ9. It seems to be well suited for this use case. would it be efficient in the RAM and CPU usage? If not I'm not sure why this would be any good since we can develop stuff much faster with electron at the moment.
viach 6y ago
When one wants to implement a new desktop UI framework there is an elephant in the room - the rich text editor. You can implement your own layout engine, styling, fonts rendering but production quality feature-rich text editor is another level of complexity.
- rmorey 6y ago
  evidenced by Raph Levien running out of steam on xi :( https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
  - vamega 6y ago
    I don’t believe xi was a rich text editor. Just a regular text editor, with some interesting design decisions.
ajuc 6y ago
I just want qt on java working as well as pyqt.
znpy 6y ago
There used to be qt Jambi...
exabrial 6y ago
What would make a great Java UI toolkit is CDI integration. Things like event busses and injection would really simplify things and be very powerful.
fotad 6y ago
Is there any benchmark between Graphics2D vs Skia?
munro 6y ago
I love the night mode setting on the top right of this site. Totally useless, but amazing lol. It feels like I'm reading the site in the dark with a flashlight.
munro 6y ago
> Patience, I think. We are so used to things we can hack together in a week, nobody is thinking in terms of years. And good UI requires years of work. It’s a big commitment. Lol what? After years, Apple is already on to the next user interface. All the "good UI" happens in Figma, you're just programming it, hopefully fast & without bugs, what is taking so long? And as a fellow programmer, no thanks, I would not like to spend years developing a UI that could be done in weeks. We had an engineer that said it was going to take 3 months to add a sticky header to the site, because he needed to do it "right", using his home grown state machine library on Github with 3 stars. He was shortly let go.
- vonnieda 6y ago
  The author is referring to writing a UI library, not writing an application or UI using an existing UI library.
  - munro 6y ago
    Yea I hope so, I can see how you're interpreting it like that. It's really hard to comprehend the true meaning, the more I reread it.
dethos 6y ago
> The desktop might be less trendy, but only because it’s harder to sell useless crap here. There is some truth in this sentence.
- joseluisq 6y ago
  and also that one: >Why not Electron? > The first reason is performance. JS is a great language for building UI, but it is much slower than JVM. Wasm can be fast but implies C++ or Rust. > The second is the DOM. It is a horrible collection of hacks that make simple things hard and hard things impossible. I have thought many times “if only was I drawing this control/layout directly, I would’ve finished hours ago.” > That means there’s a very low ceiling, performance-wise and quality-wise, of what a web app can do. I believe we can, and should, do better. > Electron taught us two good things, though: > People crave for native apps. Nobody wants to work from the browser. People don’t care if apps don’t look native to the platform as long as they look good. Regarding Electron, I think we "should" start to talking about more like "Browser Apps for Desktop" instead of just "Desktop Apps" which is broad term.
gosukiwi 6y ago
I don't normally comment on the website design but my god, that yellow background burned my eyes. I literally couldn't finish reading the article.
- acomjean 6y ago
  If you are running firefox, there is a little icon at the right side of the url bar "reader mode?" that fixes it. Though did anyone else notice the little "sun" slider at the top of the page for the spotlight in html? Useless but fun.
- tasuki 6y ago
  Is it burning your eyes more than a white background would? Can you explain how? I like yellow, and I like this website: it is simple and to the point.
- suyash 6y ago
  interesting, I found it refreshing and with enough padding, the focus was right on the content (text).
lewisjoe 6y ago
I'm studying how to rewrite our online word-processor in a stack that allows us to render documents to android/iOS/desktop natively. Skia stands out as the obvious choice as a rendering library, Our team though is essentially a JS/Java workshop and writing C++ will be shooting our own foot. I found Skija a while back but it looks like we need JVM and the JVM story on iOS is complicated (non-existent even?) Fluttter does a good job at abstracting away Skia and exposing Dart APIs that is truly cross platform (Web/Desktop/iOS/Android) – but Flutter will never expose low level Skia APIs because that's not their goal. The abstraction is too high to write a word-processor. I'm yet to find a reasonably iOS friendly abstraction over Skia that targets both iOS/Android and desktop platforms.
- jcaguilar 6y ago
  C# is not hard to do after knowing Java, here is an option in DotNet: https://github.com/mono/SkiaSharp https://github.com/mono/SkiaSharp
jillesvangurp 6y ago
We're currently in an era where UI mostly means doing react type stuff or IOS/Android native, for whatever very loose definition of native you wish to use. A trend that is interesting here is jetpack compose and swift UI, which are both inspired by react but better in the sense that they make full use of their respective type systems to make things like data bindings a lot less painful than they are in react. At least that being painful must be a reason why they keep changing how that works in every major release. Add internal DSLs to the mix and you are basically looking at a nicer way to do UIs. That's only covering mobile currently unfortunately. However, Jetbrains just announced Compose Desktop which brings this to the desktop as well. If they figure out how to target web and IOS with this, they could very well have a winner. For the web there is currently something called Fritz2, which runs via kotlin-js and basically adds very similar style bindings to a react like component framework. It's fully written in Kotlin and I've been meaning to give it a try so I can use my multi platform kotlin libraries there as well without having to figure out react and how to make that play nice with things like co-routines, data classes, etc. For me the trend here is new UI frameworks originating outside of the javascript world gaining traction and eventually ending up running in a browser as well. IMHO it's that that is ripe for disruption.
- PaulDavisThe1st 6y ago
  From TFA: -------- Is desktop still relevant? I believe it is! I watched an interview recently, between an Android developer and an iOS developer. One was asking: “Does someone still writes desktop apps?” To which the other answered: “I have no idea… Maybe?” Both of them were recording it on a desktop, in a desktop application, while having a call over another desktop application. Multiple other desktop apps were probably used for post-production. None of those were written by magic elves or left to us by a mighty ancient civilization. The desktop might be less trendy, but only because it’s harder to sell useless crap here. ----------- "react type stuff" and iOS/Android do not cover this, but you probably knew that.
  - jillesvangurp 6y ago
    I've not encountered a single desktop application project in the last 15 years in this industry. Very different from my first 10 years when I was even involved in that kind of thing a couple of times. I'm on Linkedin. Recruiters seem to have a fine talent to ask me for just about anything involving software spanning the entire spectrum of frontend, backend, embedded. Most of it is for stuff I don't even have on my CV. Based on that, I don't think I've seen even a single request for anything desktop based in the last ten years. Plenty of react and other web based stuff. Plenty of Android, IOS, and even Symbian when that was still a thing. Lots of backend in all flavors (even got a haskell one the other day). But not things like Swing, JavaFX, etc. That just doesn't happen. Not even rarely. I'm sure there's a parallel world where enterprises still run JVMs on ancient windows XP boxes that are no longer supported where they feel compelled to commission new applications. Just haven't come across any such project. It's not just less trendy from my point of view but dead as a doornail. Not a thing anymore that people actively recruit for. What little UI I come across on my own desktop tends to be either web based (electron) or native (I'm on a mac so mostly objectiveC and swift these days).
touisteur 6y ago
"Why hasn’t it been done yet? Patience, I think. We are so used to things we can hack together in a week, nobody is thinking in terms of years. And good UI requires years of work. It’s a big commitment." That's quite an observation, thinking of the hundred thousands of man-hours probably spent on both Swing and JavaFX and SWT, and they power a huge lot of high-quality, highly polished applications, including real-time graphics. I'm sure this work is great, but no need to put the competition down...
mtnygard 6y ago
I'll take a minute here to plug Defold (https://www.defold.com https://www.defold.com). It's a game engine with a dedicated IDE for building games. The IDE is built mostly with Clojure and JavaFX. Of course I'm biased, because I helped build the IDE, but I think it looks and feels great. It has a 3d modeling view that does pan, rotate, dolly, all at somewhere between 30 and 60 fps.
- vips7L 6y ago
  It looks good, but the pictures are a bit hard to see :)
blablabla123 6y ago
I really liked Processing [1] It's possible to create practically every thinkable visualization from scratch with surprisingly little design knowledge/programming effort. Not only is it far more intuitive and flexible than d3.js but also it can be directly called as Java program. Apparently the Arduino UI is a fork of its editor. FWIW it's hard to tell that the Arduino IDE is not a native app. [1] https://en.wikipedia.org/wiki/Processing_(programming_language) https://en.wikipedia.org/wiki/Processing_(programming_langua...
- suyash 6y ago
  Processing is getting an update Processing 4 and it would be nice if they incorporate this library.
didibus 6y ago
I've found apps made with JUCE https://juce.com/ https://juce.com/ always look great and have really good responsiveness. Now on the JVM front, I think one problem it has for desktop apps is the memory usage of the JVM is just terrible for desktop apps. It's clearly optimized for backend services assuming they are the only app running trying to squeeze all performance out. But a desktop app needs to be lean, and currently I'm not sure the JVM is tuned to those use cases, and Java is missing a few features for lightweight objects that could help as well with memory usage.
tomcam 6y ago
First of all... WOW! This is an exciting project. Second of all, the blog is beautifully designed and has a hilarious author portrait at https://tonsky.me/projects/ https://tonsky.me/projects/. He appears to be from either Florida or Okinawa, not sure which.
suyash 6y ago
sounds pretty bold, I'd love to try, how about integrating with openGL, is that a possibility, specially running GL/SL shaders ?
lvh 6y ago
Happy to see new developments here, though FWIW, I've mostly had a good time with JavaFX, especially in Clojure, where there's a neat Reagent-style (a React wrapper) library called cljfx[0]. It's true that Oracle has mostly divested here but I'm excited to see what teams like Gluon do with it, especially for mobile development. It's nice (though perhaps a mixed blessing) to be spoiled for choice in Clojure land, since you also have great access to the React Native ecosystem. [0]: https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx
pier25 6y ago
> The first reason is performance. JS is a great language for building UI, but it is much slower than JVM. Is it? Looking at these benchmark they seem to be in the same ballpark for most results: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- mumblemumble 6y ago
  The picture I'm seeing is that it would seem that they're in the same ballpark, and v8 may even be a smidge faster, for general purpose business object flogging type stuff, but Java is significantly faster for straight-up number crunching. The one where there's the starkest difference, k-nucleotide, Java gets to take advantage of a fastutil collection. I don't think an equivalent to that hash map could be built in JavaScript. Those benchmarks don't cover this, but I wouldn't be at all surprised to discover that Electron can does actual UI drawing more efficiently than Java can. In Electron, that whole layer is a bunch of (presumably) carefully optimized C++ code, while in Java the bulk of it's still going to either be managed code, or be taking a lot of marshalling hits if it's calling into OS APIs. Long story short, it would appear that, based on those benchmarks (which, we all realize benchmarks are a lie, but still) the only spot Java clearly beats JavaScript is in applications where someone who cares all that much about performance would choose neither Java nor JavaScript, anyway.
  - pier25 6y ago
    I agree. Also, when you look at UI benchmarks for web frameworks replacing/updating thousands of DOM elements per second, I have serious doubts the problem of web-based UIs is performance. I agree Electron is a cancer, but not because it uses web-based UIs, but because every app ships its own version of Node + V8. A couple of years ago I built a cross platform app using the native web view on each platform (WKWebview on macOS/iOS, WebView on UWP, Chrome web view on Android and ChromeOS). The app for macOS was like a 4MB download from the Mac App Store and it consumed like 15-20MB or RAM.
  - lmm 6y ago
    > Long story short, it would appear that, based on those benchmarks (which, we all realize benchmarks are a lie, but still) the only spot Java clearly beats JavaScript is in applications where someone who cares all that much about performance would choose neither Java nor JavaScript, anyway. The performance of a non-memory-safe language is usually 0; if you don't care about the time to get a correct result rather than just any "result" then why would you use a programming language at all?
nahuel0x 6y ago
So we will see something like Flutter but from JetBrains and Kotlin (native/jvm) based?
diegof79 6y ago
The article doesn’t mention SWT :( I used SWT to create desktop UI prototypes. The biggest issue of SWT is the distribution channel: to use the usual Maven repo you need a non-official package (this was around 2017). But other than that is a decent UI lib: it uses native widgets, it supports HiDPI, the layout using attachments are easier than Swing. I wonder why SWT is not popular in the JVM (my guess is the decision to distribute it using Eclipse p2 by default, and the lack of visibility outside Eclipse)
- ptx 6y ago
  They finally have official[1] Maven packages[2] now! I have no idea what the version numbers are supposed to mean though. Or what's a good way to choose the correct platform-specific JAR in your build. [1] Links under "Maven Artifacts": https://www.eclipse.org/swt/ https://www.eclipse.org/swt/ [2] https://mvnrepository.com/artifact/org.eclipse.platform/org.eclipse.swt.gtk.linux.x86_64 https://mvnrepository.com/artifact/org.eclipse.platform/org....
brunoluiz 6y ago
I wonder where Qt sits today as a desktop framework. I remember it was quite cool to use it and be able to run it in multiple OS.
uDontKnowMe 6y ago
I'm continually impressed by the stuff that comes out of the Clojure community. They really seem to punch above their weight in terms of useful output, novel ideas, interesting projects/products. Much more so than say Scala or Kotlin which enjoy a lot more industry adoption.
- arijun 6y ago
  Tonski specifically has always wowed me with his work, I'm eager to delve deeper into his take on UI.
acomjean 6y ago
How does this compare with what the "processing" language does with a javalike language that seems to use JVM and a display layer? Its pretty fun. Also its javascript cousin p5.js I'm thinking this is more UI focused. https://processing.org https://processing.org
galaxyLogic 6y ago
I would like to have a JavaScript version of JavaFX, that runs in the browser. Is there such a thing?
dpedu 6y ago
It seems like most graphical applications written in java and running on macOs adhere to the system's look and feel. In fact, you use good ol' Swing with the mac look and feel slapped on top. Whether or not the app behaves like a native app comes down to how it's written. Is this a windows/linux specific problem?
markhahn 6y ago
you lost me at JVM. what a tragedy of the 90s...
- echelon 6y ago
  The JVM powers a large percentage of tech. Don't decry it. You have other choices if you want them.
ddeeo 6y ago
What are the problems with JavaFX exactly? I think it looks great but i don't have loads of experience with it, it's easily more customizable than Swing too and has a nice WYSIWYG graphical editor.
5mixer 6y ago
I've been building a map editor using Kha [1] and Haxe UI [2]. Kha does cross platform, hardware accelerated graphics like Skija (it abstracts OpenGL, Metal, and Vulkan). Haxe UI adds a DOM, standard components, CSS styling, etc. I've found it good (the small Haxe community makes author interaction brilliant), though not perfect. Great for the number of people behind it. Using Haxe, the apps can be compiled for native or run in JS. That probably lands it in about the performance category of JVM or above, not that performance is the key factor here. I worked awhile ago on Haxe UI's text field emulation, and there are many tiny details that are easily missed. Line wrapping, text selection, keyboard controls (Home and End), everything. I think those details being spot on are as important as UI styling for most real users. [1] https://github.com/Kode/Kha https://github.com/Kode/Kha [2] http://www.haxeui.org/ http://www.haxeui.org/
htor 6y ago
ah, the old web vs java discussion. "why does the browser not come with all the components i want built-in, having the exact look n feel that my OS has?". "i have to actually write code to get a popup?". "markup language? style sheets?? bollocks!". "surely, java is more mature and will enable me to make better apps, in less time". "it's running on a JVM, didn't you know?". "so it's more performant". ok. js css html won the web platform. and they have an increasing piece of native. oops! this is not a random trend, but for a good reason. java for GUIs is not going to be popular again. it's already been tested and it failed the test. the old timer java mindset still wants the web but it does not want to learn web. working with the web is not a "hack", nor is the DOM only suitable for representing "documents". you left in 1995 and failed to catch up with modern standards. it's a flexible system, but does not come with all the batteries. but to counterweigh that it has a massive ecosystem, a package manager with plenty of off the shelf parts, if you want them. performancewise, the browser engines are getting faster and faster every day, optimised for rendering. v8 is hugely successful natively. the DOM is very suitable as a generic GUI model to work with. back in 1995 it was not. wake up Java devs. your arguments are getting increasingly flaky..
boobsbr 6y ago
> Aren’t all Java UIs cursed? That gave me a chuckle
nairodd 6y ago
Awesome initiative. I'm currently building a video game on libgdx. I wonder if I could rewrite the 2D UI using this (like, if they could be integrated at the InputProcessor and SpriteBatxh levels)

Graphics for JVM

564 points by agluszak 6y ago

LandR 6y ago

> C# would do, too, but it doesn’t have Clojure. Do you mean .NET would do too?

spacemanmatt 6y ago
Probably means CLR. And there is technically some Clojure for CLR but it's not as regularly maintained.
- harperlee 6y ago
  I have not used CLR but last time someone said here it was abandoned (I know, not what you said!), Alex Miller response was that it was up to date with the JVM version: https://news.ycombinator.com/item?id=21192321 https://news.ycombinator.com/item?id=21192321 Admittedly this was a year ago! Time flies...
  - nlitened 6y ago
    I am pretty sure Clojure is "stable" so nothing changed in the past year.
    - harperlee 6y ago
      This is only incidentally correct (last stable release was June 6, 2019), because clojure is still evolving, just slowly and stably. A new prerelease was announced September 4, 2020 at https://insideclojure.org https://insideclojure.org.
- joppy 6y ago
  Some Clojure libraries have a hard dependency on Java (or JavaScript, in the case of libraries supporting ClojureScript) - Clojure does not cover all use cases. For example, if you want to do anything more complicated than find-all-matches with a regular expression you need to call the underlying Java classes from Clojure. I expect this is probably the biggest obstacle to getting Clojure on CLR working properly: the language is not the issue, the libraries are.
  - spacemanmatt 6y ago
    Yeah, to that extent, I feel like you need to pick your runtime first with Clojure. Like you said, it dictates quite a lot about your development options.
  - fulafel 6y ago
    What kind of use cases have you had with the regexps that were not covered? (Just curious as I've not hit this). The builting regexp support can do many kinds of advanced regexp things such as having a callback fn return the substitution or precompiling into regexp objects, lazily iterating over matches etc.

MaxBarraclough 6y ago

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

outadoc 6y ago

I'm glad to see this and Compose arrive on desktop. It feels like a potential good middle-ground between a fully native OS toolkit, a cross-platform native toolkit, and an embedded web app. I don't think Java is inherently bad for the job, just that the previous UI toolkits were not what we needed.

agumonkey 6y ago

Ah I wished for something like this for so long. Very nice surprise.

mhd 6y ago

Java had the issue that it was hard to build a consumer desktop app, because Swing etc. were a bit removed from native (L&F, behavior etc.). Those didn't matter as much for desktop apps, which always looked gross. (The issue that they were less usable than the terminal apps they sometimes replaced is another issue) These days, I'm not sure if fixing that is enough. I long for the days when minor UI inconveniences like Borland-ish button icons or that weird Basic thing in the early days of OS X were the worst offenders. Quite often it's _required_ that you deviate from your platform quite a lot, as we've embraced form over function with mobile- and web-like "experiences". Whitespace everywhere, mystery meat navigation and non-conformant widgets and shortcuts that make you long for the skeuomorphic mistakes of the late 90s. Neither Apple nor Microsoft seem to be too much into HIGs these days, and Linux never was. So if this delivers the bricks, what kind of houses would we build with it?

quanticle 6y ago
"Those didn't matter as much for desktop apps, which always looked gross." I don't understand what you mean by this. I don't think desktop apps "look gross" at all. Or did you mean that Swing desktop apps looked gross because they didn't conform to the native look and feel of the platform they were running on?
- mhd 6y ago
  Ooops, very bad typo, totally obscuring my whole point, I meant to say "enterprise apps". Where looking good wasn't a selling point.

tannhaeuser 6y ago

What's wrong with Java 2D, Swing, and SWT specifically, rather than being old? Saying that IntelliJ IDEA is the only Swing app that doesn't suck isn't really an argument to fragment the Java desktop space even further when new desktops apps (Java or otherwise) haven't been developed for well over a decade.

LoSboccacc 6y ago
SWT had a lot of weird cross platform quirks which were unbearable to diagnose, it's been 10+ years now so I can't recall all details, but every time I tried under the premise of the better components, as the UI got complex, there was no other solution but escape back to Swing, where the tooling and facilities around where miles better.
AshamedCaptain 6y ago
SWT is not even mentioned, being literally the other big elephant in the room (Eclipse). Grosso modo it does not look like due diligence has been done...
Debug_Overload 6y ago
The author also lumps AWT, Swing and JavaFX together. They're different, and some were created to solve issues others didn't address, and/or improve them (never mind that JavaFX is its own beast, and is quite different from the other two, which are relatively close). But they're all GUI toolkits, and they all suck doesn't make sense.

grandinj 6y ago

We build all our desktop products using Swing, and it works pretty well. Looks pretty native (if you want it to), is thoroughly battle-tested, reasonably performant, and has a bazillion open-source extras floating around (of varying quality). If you need 3d, we drop into OpenGL and use that (e.g. when integrating WorldWind). Sometimes I feel bad about how easy it is to write desktop UIs in Java - the API is stable, nobody keeps changing it under me, I don't have to wonder what Microsoft is pushing this year, it is (mostly) easy to debug, has open source forms designers (Netbeans), etc, etc.

MaxBarraclough 6y ago
Do you plan on trying JavaFX?
- grandinj 6y ago
  Sigh. I had such high hopes for it, and then Oracle abandoned it. But we are trying it, and opinions (internal to my company) are varied. Some people like it, but I don't. Because (a) it has missing functionality here and there (b) it still has a long road to go to become battle-hardened (c) I don't see any of the current supporters having deep enough pockets to fix (a) and (b) So we're taking a mostly wait-and-see attitude. But we have an existing deep and wide investment in Swing in our products, so our risk profile is probably somewhat different to yours.
  - apta 6y ago
    > Sigh. I had such high hopes for it, and then Oracle abandoned it. As far as I'm aware, it was only pulled from the JVM into a separate dependency, as did several other components, in order to keep the JVM slim. Are you saying development on it stopped altogether?
    - grandinj 6y ago
      Oracle has mostly disbanded the team that was working on it, leaving only one or two staff to manage community contributions. There are however, a couple of small companies, and some individuals using it, and providing contributions.

sgt 6y ago

Skia works really well for Flutter so I think basing it on that is a brilliant choice. Will follow this project.

oscargrouch 6y ago
Flutter is what it is because of the quality of the engineering team behind the Dart language. My point being that, Skia is great but is not the most important ingredient at play for Flutter achievements. Also being a good choice will not pay for the bad choice that is choosing JVM as a primary platform for this which targets UI application consumers.

smarx007 6y ago

> Like any other JVM library, it’s cross-platform. It runs on Windows, Linux and macOS. It’s as simple to use as adding a JAR file. Well, not exactly. https://github.com/JetBrains/skija/ https://github.com/JetBrains/skija/ is 30% C++ and of course requires native builds: https://packages.jetbrains.team/maven/p/skija/maven/org/jetbrains/skija/ https://packages.jetbrains.team/maven/p/skija/maven/org/jetb.... If you are lucky, Maven simply hides it from you. UPD: no, it doesn't hide it. See https://github.com/JetBrains/skiko/blob/master/skiko/build.gradle.kts https://github.com/JetBrains/skiko/blob/master/skiko/build.g... and search for 'lin'/'mac'/'win' and see for yourself. UPD2: @-moz-document domain("tonsky.me") { body { /* surovyi background color off */ background-image: none; background-color: hsl(0, 0%, 85.9%); } }

vbsteven 6y ago
Is this a problem? We're always going to need native blobs to interface with the OS. The JVM can package these native libraries within the jar so for the application developer it is indeed as simple as adding the jar file to your project.
- smarx007 6y ago
  Not at all! Desktop apps require platform-specific executables and installers so this is unavoidable. But the author made it sound like a piece of cake for developers used to making JAX-RS services.
- chrisseaton 6y ago
  > We're always going to need native blobs to interface with the OS. Ideally we won't when the JVM gets an FFI built-in.
  - shock 6y ago
    https://en.m.wikipedia.org/wiki/Java_Native_Interface https://en.m.wikipedia.org/wiki/Java_Native_Interface

saagarjha 6y ago

Ok, so this starts off as “Graphics for the JVM” which sounded promising, but then the first line starts talking about desktop apps and warning bells start going off. If you read the post, it’s totally fine…if you are trying to do fast drawing or something. But no, we’re making desktop apps, with circles and triangles and squares. This just isn’t how it works, and the reason is the same as it always has been: a drawing toolkit is not a GUI toolkit. If you want people to make good apps, you need to give them buttons and checkboxes and text fields. If you don’t, we’ll, they’re going to do it wrong. Time and time again people have tried doing this and the best we’ve gotten out of it are game UIs and Flutter, which are a solid “mediocre” in the UI department. The former probably gets a pass because it’s allowed to be quirky, but the latter is literally run by a megacorp and it’s still struggling to get basic things right. Heck, even Swing and HTML are better than this; at least they give you components that someone actually spent time on implementing and making half-decent. Maybe they suck, but they suck together in a consistent way that is at least partially battle-tested, a must for any GUI toolkit. They’ve gotten to the point where they’re no longer just a middle finger to people with accessibility needs. Look, I don’t want to rain in this author’s work. If you’re going to treat it as an accelerated Graphics2D, go right ahead, this seems like it would be an excellent solution for you. JVM bindings to Skia seem awesome. Just don’t, like, draw something that looks like a GUI in it. (I could go longer about the characterization of mobile apps as constantly being purged from RAM and losing your work and IntelliJ being a good Java UI, but that would probably make this divisive comment longer than it already is.)

smarx007 6y ago
Ehmmm, did you actually explore any links? https://www.jetbrains.com/lp/compose/ https://www.jetbrains.com/lp/compose/ shows a code editor prototype.
- saagarjha 6y ago
  I know Compose exists, and it’s exactly the concern I have: look at the example apps, and compare them with true native desktop apps. Can you really call the result a good desktop UI? Is it not just a mobile UI that was blown up? Actually, it’s difficult to even call it a good mobile UI, because at the moment it certainly falls on the side of “bunch of shapes put together” rather than “UI toolkit”. Of course, while UI is just a bunch of shapes on the screen, it needs to be cohesive, and familiar, and accessible; not to mention the many, many behaviors under-the-hood that don’t show up in a screenshot.

bjarneh 6y ago

> with a lot of quality and performance drawbacks. They were so significant that only one company managed to build a decent-looking app in Swing [Link to JetBrains]. Until I found the J-editor, I sort of agreed. I never understood why that project didn't get any traction; very well made IMO, and it looks good too. https://github.com/gnooth/j https://github.com/gnooth/j

didibus 6y ago
Maybe because the repo doesn't even have a readme to tell you what it is?
- bjarneh 6y ago
  :-) That does not help of course. To be honest it did have a website (he has written a lisp implementation which comes with the editor as well ABCL - [Armed Bear Common Lisp]). I'm pretty sure the build instructions don't work either, and all sorts of other problems. But if you just download the binary distribution from sourceforge, and start it up (java -jar j.jar), you will hopefully see what I mean. It looks nothing like a Java desktop app. He has an excellent icon set, and he overrides the rendering of all sorts of components (scrollbars etc.) making it look superb.

Cloudef 6y ago

>People crave for native apps. Nobody wants to work from the browser. Ah the irony

Cloudef 6y ago
Not sure why this is getting downvoted, but JVM is just as native as browser is. The jetbrains IDE mentioned in the article is especially very clunky and slow resource hog. In fact so much, that I would actually prefer using electron app over it.
- kaba0 6y ago
  Whaat, I would not call intellij unbelievably fast, but it is a resource hog because it does a million thing at once. Compare it to visual studio, which is something that barely works and has inferior auto-complete, etc. An electron app of that complexity would require a supercomputer to even start
  - maynman 6y ago
    For sure. In the case of IntelliJ resource usage, you get what you pay for.
  - deleted 6y ago
    [deleted]
- PedroBatista 6y ago
  Do you have any idea the complexity and amount of stuff Intellij does behind the scenes?
  - Cloudef 6y ago
    The complexity of getting in the way, melting your computer and not allowing you to write single line of code at the end of the day?
    - 6y ago

dimitar 6y ago

There are lots of fast, usable JVM gui applications. Some OSS examples: http://www.sweethome3d.com http://www.sweethome3d.com - This one has been the one app I've recommended to people outside the tech bubble! It also focuses on graphics and 3d.. really deserves to be showed off more often http://xmind.net http://xmind.net https://dbeaver.com/ https://dbeaver.com/ http://www.mucommander.com/ http://www.mucommander.com/ http://www.jedit.org http://www.jedit.org What they have in common is that they are old project - often more than 10 years old and are not on Github. Goes to show how important hype and trendiness is in our industry. edit: fixed formatting

bballer 6y ago
The JetBrains suite (ie IntelliJ, Datagrip etc) while not open source, are a testament to what can be done with JVM based GUI applications. Have you ever used the merge tools? So dang cool.
- scaladev 6y ago
  https://github.com/JetBrains/intellij-community https://github.com/JetBrains/intellij-community
- anentropic 6y ago
  The JetBrains merge tools are the best ones I've found! I have it configured as my git mergetool The only problem is it takes absolutely ages to start up, which is maybe a JVM thing I wish there was a way to have git pass all of the conflicting files in a merge to the mergetool at once. Instead of having to wait for JetBrains to load up for each individual file and close after each one :(
  - chrisseaton 6y ago
    > I have it configured as my git mergetool How are you doing this? I haven't seen any merge tool, let alone a standalone one, in the JetBrains toolbox. What am I missing?

loxs 6y ago

The main reason (JVM apps are not more popular) is that the average JVM desktop app does not perform better (or use less resources) than the average Electron app. I know this is not supposed to be that way, but one way or the other, it is. On top of this the web UI developer community is orders of magnitude larger.

eythian 6y ago
I don't think that's really true. Years ago, I maintained a Java desktop application, using SWT as the graphics library (not even mentioned by the post author which is weird.) It wasn't a big application, but also not stupidly trivial. It would start fast, run fast, and didn't need much RAM at all. There are of course examples of slow, heavy java applications, but I don't think it has to be that way. I'm not totally sure what I did differently aside from consider my dependencies (e.g. using a lightweight dependency injection framework rather than something like Spring), but it's definitely not a given that Java desktop applications have to use a bucketload of RAM.
- loxs 6y ago
  Of course it's not "really" true and of course it's not "given"... it's just the sentiment. And the sentiment affects decision making a lot.
suyash 6y ago
Java is way faster than JavaScript and the benefits of Java ecosystem including libraries puts it above electron. Native > Web for UX.

chucky 6y ago

> The second is the DOM. It is a horrible collection of hacks that make simple things hard and hard things impossible. I have thought many times “if only was I drawing this control/layout directly, I would’ve finished hours ago.” I think this betrays a lack of understanding on the part of the author of how to write good web components. Yes, the DOM is tricky at first, but that's because it's trying to support things like resizing windows to arbitrary sizes. I don't even understand what he tries to say with "draw the control directly". In component-based library, this is exactly how you would work. Put your component where it needs to be, and boom, you're finished (just like in all frameworks this is a lie, you probably still need to tweak). I don't in general buy the argument that the DOM is low-performant and low-quality. Lots of great and performant UIs have been built on the web platform.

iovrthoughtthis 6y ago
Yeah, the whole of the bottom of the post strikes me as off base. I think the author is trying to get to a wonderful future but their heading in totally the wrong direction.
dmitriid 6y ago
> I think this betrays a lack of understanding on the part of the author of how to write good web components. Yes, the DOM is tricky at first, but that's because it's trying to support things like resizing windows to arbitrary sizes. This statement betrays the commenter's lack of understanding understanding of both limitations of the Web model and the freedom afforded by almost every single one of UI libs and frameworks. > I don't even understand what he tries to say with "draw the control directly". Aaand here it is: "I don't understand". In a GUI framework/lib you usually have the ability to skip the provided primitives and draw whatever you want directly. A framework/library doesn't provide a control you need? You just draw it yourself. So, instead of re-inventing, poorly, a virtual list, or a calendar, or a customisable drop-down with a few thousand divs, z-index issues and layout thrashing, you can (relatively) easily implement those controls yourself. At easy 60 or 120 fps. > I don't in general buy the argument that the DOM is low-performant and low-quality. Lots of great and performant UIs have been built on the web platform. Name a few, please. And when you look into those "performant UIs", you'll see on or more of: - skipping the DOM entirely and building everything on top of canvas or webgl - going through great pains to: avoid mutating DOM, avoid repaint/reflow (which can happen by simply querying the DOM [1]), reducing the already laughably small amount of updates even further to prevent DOM updates, layout thrashing, JS GC pauses etc. etc. And this will still not come even close to, lets say, displaying a million objects on screen at 120fps (any modern game engine), or any significantly complex UI layout (any professional app). [1] https://csstriggers.com https://csstriggers.com and https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a

geokon 6y ago

Errr, is there some example I can compile both into a Desktop app as well as Android app easily? I never got why we never got convergent Java apps that run everywhere... It's seemingly almost easier to do that with Qt than with Java If I could get an example written in Clojure that'd be even cooler :) I noticed they have this: https://github.com/JetBrains/skija/blob/master/shared/src/main/java/org/jetbrains/skija/Path.java https://github.com/JetBrains/skija/blob/master/shared/src/ma... Is rendering SVG in the pipeline? It seems within the scope of a graphics library.. or maybe not?

cjohansson 6y ago

PR for JetBrains? I think there are plenty of good looking JVM desktop apps which are equally or more good looking as JetBrains stuff. Electron and JVM is bad because they require a lot of resources and that occasionally JVM has security issues

fastbmk_com 6y ago
He is an employee of JetBrains in Munich, Germany office.

Darmody 6y ago

I've been using Java mostly for stuff that runs from the terminal and I always wondered why there are almost no games developed with it. I know this submission is not about games but it's related. The very few games that run on the Java platform are very resource hungry, even more than some alternatives made in JS which is supposed to have a worse performance. All that while C# is booming on indie game dev.

lasagnaphil 6y ago
C# is better for gamedev for quite a lot of reasons, but most importantly because it has value types (structs) that aren’t boxed. In gamedev you use a lot of small-size types such as Vector3 or Vector4 for all sorts of math, but if you implement them naively in Java you have to always heap-allocate them, which brings severe penalties in terms of cache locality and GC. Modern Java gamedev libraries like JOML tries to avoid this by using NIO buffers (JVM provides some utilities to manually alloc/dealloc memory), but the API is quite finicky as a result. (Plus, there is no operator overloading in Java, which is another bummer.) Project Valhalla is trying to add proper value types to the JVM, but sadly as of today the project seems a bit abandoned... (See https://wiki.openjdk.java.net/display/valhalla/Main https://wiki.openjdk.java.net/display/valhalla/Main)
- djhworld 6y ago
  > Project Valhalla is trying to add proper value types to the JVM, but sadly as of today the project seems a bit abandoned... The repo seems to have very recent activity, has commits from today! https://github.com/openjdk/valhalla https://github.com/openjdk/valhalla
- didibus 6y ago
  Agree, and not just gamedev, I think for desktop apps this is an issue as well. The memory profile of a Java app suffer from lots of unnecessary boxing. Also, the GCs are not designed and tuned to desktop apps, but to backend services. So they'll exhibit behavior like never releasing memory back to the OS and hording 100% memory.
skocznymroczny 6y ago

masa331 6y ago

> People crave for native apps. Nobody wants to work from the browser. Some do, some quite the opposite. Me personally i want to have as few desktop apps installed as possible. They are warranted only in few special cases - browser, video & music player, Excel. Other than that there really is no need to have any desktop app nowadays. > Both of them were recording it on a desktop, in a desktop application, while having a call over another desktop application. Yeah this can be easily done from browser also > it’s hard to select text, hard to search on a page, hard to have multiple tabs, hard to move data between apps excuse me? It's harder to select text or search text in browser than in desktop apps? What? Text search is one ctrl-f away on ANY web page. Switching between tabs in a browser is alt-num. Desktop apps have no tabs and a lot of times you switch between completely different UIs. Moving data between apps depends completely on the app itself. It either offers some kind of data export or does not. It doesn't have to do anything with desktop apps or web apps in general > For example, you are adding an event to the calendar. You need to lookup an address for the event in the mail, which has a link that opens a browser. Yeah in a web apps you at least have some unique link to it. Linking to something on your local computer in some desktop app isn't even possible > Ability to have multiple windows open at the same time is the desktop’s superpower. You know you can have multiple tabs open in one browser right? I like Nikita's articles and if he or anybody prefers desktop over web that's fine. Also the library he is starting - great. But the announcement could really omit the nonsensical comparisons and generalisations of web vs desktop

d3nj4l 6y ago
> > it’s hard to select text, hard to search on a page, hard to have multiple tabs, hard to move data between apps > excuse me? It's harder to select text or search text in browser than in desktop apps? What? Text search is one ctrl-f away on ANY web page. Switching between tabs in a browser is alt-num. That is clearly about mobile in contrast to Desktop.
- masa331 6y ago
  Ah ok, thanks. This makes more sense now. But on a seconds thought - there are people who really "work" on phone? I just can't do anything serious from phone be it native app or web app. The experience is so much worse for me that it didn't even cross my mind it's about phones.

jmartrican 6y ago

This is a great idea. Can't wait to try it out. In a past life I created a video game in JavaFX. Its on Steam. It was hard to do, but I really didn't know what I was doing when I started. I also do not know if JavaFX was missing any features that would be desired for video games, that maybe other libraries have. Nonetheless, for selfish reasons more libraries in this space is welcomed.

unnouinceput 6y ago

Thank Mozilla for Firefox reader mode. This site is horrible to look at. And because of that, dear Nikita, I haven't looked at your repository. Remember the rule "first impression matters"?

therealasdf 6y ago
Your loss
- unnouinceput 6y ago
  Nah, I'm good. Java and its related technologies can die for all I care. I really hate Java. I use it every day because that's where my money come from, supporting legacy crap from 90's but I really hate it.
vijaybritto 6y ago
Looks like some css issue. But the content was great

deleted 6y ago

[deleted]

speps 6y ago

Instead of Skia bindings, probably the effort of building a C++ UI toolkit that has the features he needs and THEN do Java bindings for it would prove more useful for the community instead of tying the UI toolkit to Java. That's kind of what's missing in my opinion, something that does the hard part of UI, integration with native OS controls (eg. open dialogs, etc.), accessibility even with custom UI drawn using 2D primitives, etc. and that would be a great project that would also benefit the author as long as it has Java bindings.

cromwellian 6y ago

> WASM implies Rust or C++ Nope, there are lots of languages that compile to WASM. In fact, Kotlin compiles to WASM, and you get the best of both worlds, able to interop with the JVM, and compile to WASM (and C++/ObjC, and JS)

oscargrouch 6y ago
Your comment makes me think how WASM will go through this hype phase where people will think is a panacea to build things for the browser.. Hype gold rush all over again, but applications built on native or even javascript ones in the web or Electron will perform better in most cases. Of course companies will think its great for them to have only one codebase for every platform, but applications built with Javascript or Typescript for the web, with eventual WASM module here and there will be a better fit, so it will be risky to try to cut expenses and development there. WASM will be awesome to bring great tech that is only available in native platform to the web, like FFMPEG, or to accelerate some code that uses a lot of math. But i think that people that are going way down into this WASM rabbit hole will have a wake-up call pretty soon. WASM will open some blue-seas for sure, but they are limited to some niche scenarios and using WASM for application development for the web, desktop and mobile wont be one of them.
- cromwellian 6y ago
  I don't think of WASM as web specific, I think of it as a portable compiler IR format, and from an untrusted third party code, isolation standpoint, running code in WASM has nice security properties. This is why you see it starting to be used for "serverless" deployments.
  - oscargrouch 6y ago
    > This is why you see it starting to be used for "serverless" deployments. For cloud like scenarios WASM probably will be a hit, given its safer and a good target for providers to let developers to create customized apps in any language they want. Also there's centralized decision on which tech should be used. And this make the adoption of new tech much faster. Sure its a portable IR, but is a very limited one and therefore it will be sub-optimal in a lot of scenarios compared to the traditional native applications. In the web alone it will be sub-optimal to the state-of-the-art optimized javascript of today in a lot of cases, even having a much better performance in some special cases. And in the case of desktops, mobile, etc, this will make it even better for javascript applications, which will profit the most in this scenario, with hybrid apps (javascript + WASM). Of course, the FAANG that control the platforms would love to limit more and have absolute control over the platform which will probably be the only native app allowed or that people will run. But the day WASM take the world and we are not allowed to run native applications anymore except the ones the walled gardens allow us to, will be a dark future compared to the freedom we once had. Clean-room monopolized innovation and big tech mammoth's..

marktangotango 6y ago

The author totally misses the real problem with jvm desktop apps, deployment. Either the jvm is bundled with the app or some other (platform dependent) hack has to be employed to ensure a correct version of jre is on the machine. Microsoft manages this nicely with .net btw.

_old_dude_ 6y ago
The author is an employee of JetBrain. I believe JetBrian is using jlink [1], a tool that let you embed the modules of the JDK you need with your application, for all their products since they have migrated to JDK 11. [1] https://docs.oracle.com/en/java/javase/11/tools/jlink.html https://docs.oracle.com/en/java/javase/11/tools/jlink.html
hderms 6y ago
Is bundling the JVM with the app really such a huge deal on desktops? I know it would add a bunch to the binary size but what are the other issues?
- krzyk 6y ago
  It is the recommended way since Java 11 (no JRE there) - using jlink can build smaller packages and app developer doesn't depend on the JDK/JRE on the system.
ptx 6y ago
Isn't Microsofts solution, starting with .NET 5, essentially the same as Java's jlink/javapackager – i.e. minify and bundle the whole runtime with the app?

altrunox 6y ago

"Wasm can be fast but implies C++ or Rust." Oh BTW, you can do WASM with Blazor (C#) now. https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

x87678r 6y ago

There was a thread on /r/Java about Java GUIs. Seems Jetpack Compose is a potential new player that looks promising. No one seems to know if JavaFX or Swing is the recommended route. https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-1-released/ https://blog.jetbrains.com/cross-post/jetpack-compose-for-de... https://www.reddit.com/r/java/comments/jrqjex/whats_being_used_nowadays_for_java_desktop_apps/ https://www.reddit.com/r/java/comments/jrqjex/whats_being_us...

vijaybritto 6y ago

I am a web developer and I'm only used to developing in JavaScript and a complete beginner in Java. I had an idea for a desktop app and wanted to try out something in javafx as that's what google pointed me to. The build setup for java projects seems to be incredibly complex and I don't find any sort beginner friendly tutorials related to javafx that work on windows without any issues. Then I looked at Android development setup and it's even more insane in size and complexity. I think if the entry into java app development was as easier as electron it would be amazing! I get that it's a well mature platform with a massive ecosystem but it needs to be have something like npm or yarn for javascript development. And importantly are there any thin and light JVMs that can be bundled with this? I'm thinking AdoptOpenJDK openJ9. It seems to be well suited for this use case. would it be efficient in the RAM and CPU usage? If not I'm not sure why this would be any good since we can develop stuff much faster with electron at the moment.

viach 6y ago

When one wants to implement a new desktop UI framework there is an elephant in the room - the rich text editor. You can implement your own layout engine, styling, fonts rendering but production quality feature-rich text editor is another level of complexity.

rmorey 6y ago
evidenced by Raph Levien running out of steam on xi :( https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
- vamega 6y ago
  I don’t believe xi was a rich text editor. Just a regular text editor, with some interesting design decisions.

ajuc 6y ago

I just want qt on java working as well as pyqt.

znpy 6y ago

There used to be qt Jambi...

exabrial 6y ago

What would make a great Java UI toolkit is CDI integration. Things like event busses and injection would really simplify things and be very powerful.

fotad 6y ago

Is there any benchmark between Graphics2D vs Skia?

munro 6y ago

I love the night mode setting on the top right of this site. Totally useless, but amazing lol. It feels like I'm reading the site in the dark with a flashlight.

munro 6y ago

> Patience, I think. We are so used to things we can hack together in a week, nobody is thinking in terms of years. And good UI requires years of work. It’s a big commitment. Lol what? After years, Apple is already on to the next user interface. All the "good UI" happens in Figma, you're just programming it, hopefully fast & without bugs, what is taking so long? And as a fellow programmer, no thanks, I would not like to spend years developing a UI that could be done in weeks. We had an engineer that said it was going to take 3 months to add a sticky header to the site, because he needed to do it "right", using his home grown state machine library on Github with 3 stars. He was shortly let go.

vonnieda 6y ago
The author is referring to writing a UI library, not writing an application or UI using an existing UI library.
- munro 6y ago
  Yea I hope so, I can see how you're interpreting it like that. It's really hard to comprehend the true meaning, the more I reread it.

dethos 6y ago

> The desktop might be less trendy, but only because it’s harder to sell useless crap here. There is some truth in this sentence.

joseluisq 6y ago
and also that one: >Why not Electron? > The first reason is performance. JS is a great language for building UI, but it is much slower than JVM. Wasm can be fast but implies C++ or Rust. > The second is the DOM. It is a horrible collection of hacks that make simple things hard and hard things impossible. I have thought many times “if only was I drawing this control/layout directly, I would’ve finished hours ago.” > That means there’s a very low ceiling, performance-wise and quality-wise, of what a web app can do. I believe we can, and should, do better. > Electron taught us two good things, though: > People crave for native apps. Nobody wants to work from the browser. People don’t care if apps don’t look native to the platform as long as they look good. Regarding Electron, I think we "should" start to talking about more like "Browser Apps for Desktop" instead of just "Desktop Apps" which is broad term.

gosukiwi 6y ago

I don't normally comment on the website design but my god, that yellow background burned my eyes. I literally couldn't finish reading the article.

acomjean 6y ago
If you are running firefox, there is a little icon at the right side of the url bar "reader mode?" that fixes it. Though did anyone else notice the little "sun" slider at the top of the page for the spotlight in html? Useless but fun.
tasuki 6y ago
Is it burning your eyes more than a white background would? Can you explain how? I like yellow, and I like this website: it is simple and to the point.
suyash 6y ago
interesting, I found it refreshing and with enough padding, the focus was right on the content (text).

lewisjoe 6y ago

I'm studying how to rewrite our online word-processor in a stack that allows us to render documents to android/iOS/desktop natively. Skia stands out as the obvious choice as a rendering library, Our team though is essentially a JS/Java workshop and writing C++ will be shooting our own foot. I found Skija a while back but it looks like we need JVM and the JVM story on iOS is complicated (non-existent even?) Fluttter does a good job at abstracting away Skia and exposing Dart APIs that is truly cross platform (Web/Desktop/iOS/Android) – but Flutter will never expose low level Skia APIs because that's not their goal. The abstraction is too high to write a word-processor. I'm yet to find a reasonably iOS friendly abstraction over Skia that targets both iOS/Android and desktop platforms.

jcaguilar 6y ago
C# is not hard to do after knowing Java, here is an option in DotNet: https://github.com/mono/SkiaSharp https://github.com/mono/SkiaSharp

jillesvangurp 6y ago

We're currently in an era where UI mostly means doing react type stuff or IOS/Android native, for whatever very loose definition of native you wish to use. A trend that is interesting here is jetpack compose and swift UI, which are both inspired by react but better in the sense that they make full use of their respective type systems to make things like data bindings a lot less painful than they are in react. At least that being painful must be a reason why they keep changing how that works in every major release. Add internal DSLs to the mix and you are basically looking at a nicer way to do UIs. That's only covering mobile currently unfortunately. However, Jetbrains just announced Compose Desktop which brings this to the desktop as well. If they figure out how to target web and IOS with this, they could very well have a winner. For the web there is currently something called Fritz2, which runs via kotlin-js and basically adds very similar style bindings to a react like component framework. It's fully written in Kotlin and I've been meaning to give it a try so I can use my multi platform kotlin libraries there as well without having to figure out react and how to make that play nice with things like co-routines, data classes, etc. For me the trend here is new UI frameworks originating outside of the javascript world gaining traction and eventually ending up running in a browser as well. IMHO it's that that is ripe for disruption.

PaulDavisThe1st 6y ago
From TFA: -------- Is desktop still relevant? I believe it is! I watched an interview recently, between an Android developer and an iOS developer. One was asking: “Does someone still writes desktop apps?” To which the other answered: “I have no idea… Maybe?” Both of them were recording it on a desktop, in a desktop application, while having a call over another desktop application. Multiple other desktop apps were probably used for post-production. None of those were written by magic elves or left to us by a mighty ancient civilization. The desktop might be less trendy, but only because it’s harder to sell useless crap here. ----------- "react type stuff" and iOS/Android do not cover this, but you probably knew that.
- jillesvangurp 6y ago
  I've not encountered a single desktop application project in the last 15 years in this industry. Very different from my first 10 years when I was even involved in that kind of thing a couple of times. I'm on Linkedin. Recruiters seem to have a fine talent to ask me for just about anything involving software spanning the entire spectrum of frontend, backend, embedded. Most of it is for stuff I don't even have on my CV. Based on that, I don't think I've seen even a single request for anything desktop based in the last ten years. Plenty of react and other web based stuff. Plenty of Android, IOS, and even Symbian when that was still a thing. Lots of backend in all flavors (even got a haskell one the other day). But not things like Swing, JavaFX, etc. That just doesn't happen. Not even rarely. I'm sure there's a parallel world where enterprises still run JVMs on ancient windows XP boxes that are no longer supported where they feel compelled to commission new applications. Just haven't come across any such project. It's not just less trendy from my point of view but dead as a doornail. Not a thing anymore that people actively recruit for. What little UI I come across on my own desktop tends to be either web based (electron) or native (I'm on a mac so mostly objectiveC and swift these days).

touisteur 6y ago

"Why hasn’t it been done yet? Patience, I think. We are so used to things we can hack together in a week, nobody is thinking in terms of years. And good UI requires years of work. It’s a big commitment." That's quite an observation, thinking of the hundred thousands of man-hours probably spent on both Swing and JavaFX and SWT, and they power a huge lot of high-quality, highly polished applications, including real-time graphics. I'm sure this work is great, but no need to put the competition down...

mtnygard 6y ago

I'll take a minute here to plug Defold (https://www.defold.com https://www.defold.com). It's a game engine with a dedicated IDE for building games. The IDE is built mostly with Clojure and JavaFX. Of course I'm biased, because I helped build the IDE, but I think it looks and feels great. It has a 3d modeling view that does pan, rotate, dolly, all at somewhere between 30 and 60 fps.

vips7L 6y ago
It looks good, but the pictures are a bit hard to see :)

blablabla123 6y ago

I really liked Processing [1] It's possible to create practically every thinkable visualization from scratch with surprisingly little design knowledge/programming effort. Not only is it far more intuitive and flexible than d3.js but also it can be directly called as Java program. Apparently the Arduino UI is a fork of its editor. FWIW it's hard to tell that the Arduino IDE is not a native app. [1] https://en.wikipedia.org/wiki/Processing_(programming_language) https://en.wikipedia.org/wiki/Processing_(programming_langua...

suyash 6y ago
Processing is getting an update Processing 4 and it would be nice if they incorporate this library.

didibus 6y ago

I've found apps made with JUCE https://juce.com/ https://juce.com/ always look great and have really good responsiveness. Now on the JVM front, I think one problem it has for desktop apps is the memory usage of the JVM is just terrible for desktop apps. It's clearly optimized for backend services assuming they are the only app running trying to squeeze all performance out. But a desktop app needs to be lean, and currently I'm not sure the JVM is tuned to those use cases, and Java is missing a few features for lightweight objects that could help as well with memory usage.

tomcam 6y ago

First of all... WOW! This is an exciting project. Second of all, the blog is beautifully designed and has a hilarious author portrait at https://tonsky.me/projects/ https://tonsky.me/projects/. He appears to be from either Florida or Okinawa, not sure which.

suyash 6y ago

sounds pretty bold, I'd love to try, how about integrating with openGL, is that a possibility, specially running GL/SL shaders ?

lvh 6y ago

Happy to see new developments here, though FWIW, I've mostly had a good time with JavaFX, especially in Clojure, where there's a neat Reagent-style (a React wrapper) library called cljfx[0]. It's true that Oracle has mostly divested here but I'm excited to see what teams like Gluon do with it, especially for mobile development. It's nice (though perhaps a mixed blessing) to be spoiled for choice in Clojure land, since you also have great access to the React Native ecosystem. [0]: https://github.com/cljfx/cljfx https://github.com/cljfx/cljfx

pier25 6y ago

> The first reason is performance. JS is a great language for building UI, but it is much slower than JVM. Is it? Looking at these benchmark they seem to be in the same ballpark for most results: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

mumblemumble 6y ago
The picture I'm seeing is that it would seem that they're in the same ballpark, and v8 may even be a smidge faster, for general purpose business object flogging type stuff, but Java is significantly faster for straight-up number crunching. The one where there's the starkest difference, k-nucleotide, Java gets to take advantage of a fastutil collection. I don't think an equivalent to that hash map could be built in JavaScript. Those benchmarks don't cover this, but I wouldn't be at all surprised to discover that Electron can does actual UI drawing more efficiently than Java can. In Electron, that whole layer is a bunch of (presumably) carefully optimized C++ code, while in Java the bulk of it's still going to either be managed code, or be taking a lot of marshalling hits if it's calling into OS APIs. Long story short, it would appear that, based on those benchmarks (which, we all realize benchmarks are a lie, but still) the only spot Java clearly beats JavaScript is in applications where someone who cares all that much about performance would choose neither Java nor JavaScript, anyway.
- pier25 6y ago
  I agree. Also, when you look at UI benchmarks for web frameworks replacing/updating thousands of DOM elements per second, I have serious doubts the problem of web-based UIs is performance. I agree Electron is a cancer, but not because it uses web-based UIs, but because every app ships its own version of Node + V8. A couple of years ago I built a cross platform app using the native web view on each platform (WKWebview on macOS/iOS, WebView on UWP, Chrome web view on Android and ChromeOS). The app for macOS was like a 4MB download from the Mac App Store and it consumed like 15-20MB or RAM.
- lmm 6y ago
  > Long story short, it would appear that, based on those benchmarks (which, we all realize benchmarks are a lie, but still) the only spot Java clearly beats JavaScript is in applications where someone who cares all that much about performance would choose neither Java nor JavaScript, anyway. The performance of a non-memory-safe language is usually 0; if you don't care about the time to get a correct result rather than just any "result" then why would you use a programming language at all?

nahuel0x 6y ago

So we will see something like Flutter but from JetBrains and Kotlin (native/jvm) based?

diegof79 6y ago

The article doesn’t mention SWT :( I used SWT to create desktop UI prototypes. The biggest issue of SWT is the distribution channel: to use the usual Maven repo you need a non-official package (this was around 2017). But other than that is a decent UI lib: it uses native widgets, it supports HiDPI, the layout using attachments are easier than Swing. I wonder why SWT is not popular in the JVM (my guess is the decision to distribute it using Eclipse p2 by default, and the lack of visibility outside Eclipse)

ptx 6y ago
They finally have official[1] Maven packages[2] now! I have no idea what the version numbers are supposed to mean though. Or what's a good way to choose the correct platform-specific JAR in your build. [1] Links under "Maven Artifacts": https://www.eclipse.org/swt/ https://www.eclipse.org/swt/ [2] https://mvnrepository.com/artifact/org.eclipse.platform/org.eclipse.swt.gtk.linux.x86_64 https://mvnrepository.com/artifact/org.eclipse.platform/org....

brunoluiz 6y ago

I wonder where Qt sits today as a desktop framework. I remember it was quite cool to use it and be able to run it in multiple OS.

uDontKnowMe 6y ago

I'm continually impressed by the stuff that comes out of the Clojure community. They really seem to punch above their weight in terms of useful output, novel ideas, interesting projects/products. Much more so than say Scala or Kotlin which enjoy a lot more industry adoption.

arijun 6y ago
Tonski specifically has always wowed me with his work, I'm eager to delve deeper into his take on UI.

acomjean 6y ago

How does this compare with what the "processing" language does with a javalike language that seems to use JVM and a display layer? Its pretty fun. Also its javascript cousin p5.js I'm thinking this is more UI focused. https://processing.org https://processing.org

galaxyLogic 6y ago

I would like to have a JavaScript version of JavaFX, that runs in the browser. Is there such a thing?

dpedu 6y ago

It seems like most graphical applications written in java and running on macOs adhere to the system's look and feel. In fact, you use good ol' Swing with the mac look and feel slapped on top. Whether or not the app behaves like a native app comes down to how it's written. Is this a windows/linux specific problem?

markhahn 6y ago

you lost me at JVM. what a tragedy of the 90s...

echelon 6y ago
The JVM powers a large percentage of tech. Don't decry it. You have other choices if you want them.

ddeeo 6y ago

What are the problems with JavaFX exactly? I think it looks great but i don't have loads of experience with it, it's easily more customizable than Swing too and has a nice WYSIWYG graphical editor.

5mixer 6y ago

I've been building a map editor using Kha [1] and Haxe UI [2]. Kha does cross platform, hardware accelerated graphics like Skija (it abstracts OpenGL, Metal, and Vulkan). Haxe UI adds a DOM, standard components, CSS styling, etc. I've found it good (the small Haxe community makes author interaction brilliant), though not perfect. Great for the number of people behind it. Using Haxe, the apps can be compiled for native or run in JS. That probably lands it in about the performance category of JVM or above, not that performance is the key factor here. I worked awhile ago on Haxe UI's text field emulation, and there are many tiny details that are easily missed. Line wrapping, text selection, keyboard controls (Home and End), everything. I think those details being spot on are as important as UI styling for most real users. [1] https://github.com/Kode/Kha https://github.com/Kode/Kha [2] http://www.haxeui.org/ http://www.haxeui.org/

htor 6y ago

ah, the old web vs java discussion. "why does the browser not come with all the components i want built-in, having the exact look n feel that my OS has?". "i have to actually write code to get a popup?". "markup language? style sheets?? bollocks!". "surely, java is more mature and will enable me to make better apps, in less time". "it's running on a JVM, didn't you know?". "so it's more performant". ok. js css html won the web platform. and they have an increasing piece of native. oops! this is not a random trend, but for a good reason. java for GUIs is not going to be popular again. it's already been tested and it failed the test. the old timer java mindset still wants the web but it does not want to learn web. working with the web is not a "hack", nor is the DOM only suitable for representing "documents". you left in 1995 and failed to catch up with modern standards. it's a flexible system, but does not come with all the batteries. but to counterweigh that it has a massive ecosystem, a package manager with plenty of off the shelf parts, if you want them. performancewise, the browser engines are getting faster and faster every day, optimised for rendering. v8 is hugely successful natively. the DOM is very suitable as a generic GUI model to work with. back in 1995 it was not. wake up Java devs. your arguments are getting increasingly flaky..

boobsbr 6y ago

> Aren’t all Java UIs cursed? That gave me a chuckle

nairodd 6y ago

Awesome initiative. I'm currently building a video game on libgdx. I wonder if I could rewrite the 2D UI using this (like, if they could be integrated at the InputProcessor and SpriteBatxh levels)