Comment by PaulHoule | Hacker News Reader

Comment by PaulHoule | Hacker News Reader

JavaFX is not bad at all but changes in licensing haven't helped its cause at all.

It's close to malpractice, however, to develop desktop applications at all in 2022. That is, you can write a web application, upload it to your server and you deployed a web application.

If you write a desktop application that's just the beginning because now you have to do the installer engineering, possibly deal with cross-platform problems, possibly deal with different versions of the same platform, etc.

Another thing we forget is that web browsers are on an entirely different level than other GUI applications because a web browser is designed to stay responsive to the user when loading multiple streams of data over a slow network. Contrast that to desktop applications where the "beachball" or whited-out windows is normal and unavoidable. Browsers are still written in C++ by the most advanced software development organizations because you just can't manage that in a managed language.

If you develop for a browser or a browser-based environment like electron you can take advantage of all that work... Even if it means using a maddening async I/O model.

I too was disgusted with electron's "bloat" but when I went looking for a cross-platform GUI framework I looked at gtk, tk, qt and many others and compared to electron it was like going from 1850s technology to 2050.

> Another thing we forget is that web browsers are on an entirely different level than other GUI applications because a web browser is designed to stay responsive to the user when loading multiple streams of data over a slow network. Contrast that to desktop applications where the "beachball" or whited-out windows is normal and unavoidable.

Agreed that beginners using desktop GUI toolkits often make the mistake of putting long-running code in a button press callback, and then the GUI freezes.

But it's pretty easy to avoid this, so long as you know about it. If you're doing network/IO related stuff, make your callback async and await the data. GUI toolkits often have an event loop built in that can run user-supplied async code. If you're doing CPU intensive work, spawn a thread (maybe in a threadpool), and send data back to the GUI thread over a channel (the GUI thread uses async callbacks to check the channel). Not as easy as async, but often GUI toolkits encapsulate this into some kind of "Task" object for you that can take out some of the boilerplate.

Beginners make that mistake with simple applications.

It's still a chronic problem with major applications from vendors like Microsoft and Adobe because their applications (Office, Creative Cloud) have complex internal state that needs to be managed. The easy way to do it correctly is to put one big lock on the shared data structures which means a minute of beachball at boot and the app locking up periodically.

The counter to that in the asynchronous world (web browsers, electron) is that you search for something and you always see "0 search results" before the search results load. Even when I manage to banish this from an app by putting loading indicators in all the right places somehow this gets lost as soon as another developer patches something. Yet that's what you get when you trade the "dead by default" behavior of desktop UIs for "live by default."

> desktop applications where the "beachball" or whited-out windows is normal and unavoidable

If desktop development is "malpractice", this is actually a clear-cut case of slander and libel.

Beachballs are absolutely avoidable, with some basic thread management - which is fairly trivial in any half-decent modern toolkit.

How come I see them all time, especially with applications from Microsoft, Adobe and other big software firms?

This is like asking why clicking buttons or links in web apps often just does nothing. You don't notice because you "know" the browser is loading the next page, you're waiting for the server and because you know that browsers don't bother displaying beachballs anymore even though the app is busy. But it's not actually any different.

If you like, structure your desktop app as two threads. One does the UI. The other does processing stuff. Exchange only messages back and forth. I've actually written a desktop app this way in the past. However it's not the silver bullet you might expect, largely because expectations users have for desktop apps are significantly higher than on a web app. In particular they expect something obvious to happen when they click buttons or menu items, and they definitely don't expect long delays simply because the backend is busy. So I ended up having to introduce some shared memory and read/write locks back again, as the pure message passing model was occasionally introducing UI stalls. In a web app you'd just ignore them because standards are low. On the desktop it's like on mobile, you have to care about the responsiveness a lot more.

Apart from the argument of different expectations discussed in the sibling comment, there is the fact that those behemoth apps you use are largely not developed with modern toolkits. Most of them are 30-year-old piles of C++ hacks, built to work on operating systems that don't even exist anymore and badly patched, year after year, to keep up with OS vendors' agendas. Unsurprisingly, they screw up from time to time.

The funny thing is that, despite thall this, often those piles of hacks are still compared favourably with Electron apps and browser-based apps.

Reply on news.ycombinator.com