Anyone that bothered to read "Filthy Rich Clients" or followed the respective Sun blog, knows how to take advantage of Swing APIs and make it a Good Thing.
Not to mention that I rather do Swing than web development, if given the option.
Compared to the entire JS world of UI frameworks that come bundled with a 200M "runtime" for desktop applications? Yes, yes it definitely is a good thing.
For comparison, the entire JVM for Desktop, including Swing, AWT, Themes, JavaFX, the entire stdlib, three separate optimizing JITs, profilers, graphical tracers, etc, combined, is below 64MB.
The entire Android OS, every part of it, including all toolings required to build apps, is still below 200MiB. This includes libraries, default apps, UI, compilers, tools, stdlib, firmware, etc.
My point is that if Electron was provided by default just like .NET or one of the apple frameworks you would not mind it that much and you will think apps built with it are lean when in fact to create a UI rich standalone executable you will require a lot of things to get up and running.
Back in the days I was against frameworks not using native widgets. So I tend to use wxWidgets where I can (say instead of MFC). I shied away from Qt only for that petty reason. I'm not visually/hearing impaired, but thought for a long time that unless you use the native widgets, your apps won't be accessible to people with such conditions. So maybe I was half-right, but then I've found out that Windows provides API for one to expose widget contents in a way that the system can assist with reading the text, enhancing this and that, etc.
Same with Eclipse, which relies on native toolkit, vs. Swing.
But then if you compare Eclipse and IntelliJ - the difference is huge. Eclipse is clumsy, the widgets even though they are supposed to be native - somehow look baroque, oversized, while in IntelliJ/CLion things can be customized (Darcula+font settings) and look pretty sweet.
Same with Qt. With good stylesheet you can make an artist, a game scriptor, or level builder happy. They won't even care that you haven't used the native toolkit.
Then as it goes, it's more easier to expose/subclass/customize non-native toolkit compared to native, or even native which was wrapping internal widgets and exposing them other way. In a previous company I worked, we ported our game level editor (Radiant) from MFC -> Qt and saw burst of development going on, as people from all backgrounds were able to add more things in the UI. Collaboration was thriving, while with MFC you had to spent years learning how to do bits and pieces. Same with wxWidgets btw, as we also used in projects.
And at last, some rather specific story about wxWidgets on Windows - I think we had an editor, or a launcher of sorts, and it was tracking/showing log of operations. If you wanted to jump/search to a line it was rather slow, and limited... Turns out wxWidgets on Windows would use some native control, and the implementation of "give me the current line" in the editor would scan the log from begining to end, counting all \n\r, until it came to your buffer position and tell you the number. The GTK version, which someone else used for other tool did not had this problem... TL'DR'... Leaky Abstraction!
I did four years of Swing development and while it has it's difficulties, it was possible to deliver on every feature the client required. It was flexible and (if you pay attention) performant as well.
It can be difficult to find the right place to insert your code to get what you want done, but that's the case with most UI toolkits. The easy stuff is easy and the custom stuff can be a real headache.
I wish we had a variation of Deplhi's VCL for web/java/etc. instead of all these monstrosities that make life miserable instead of taking 5 minutes to make a solid UI.
For real. Cakewalk to do these sort of "responsive" applications in Swing, and Swing is hardly the most elegant native GUI framework (though well known).
Hang on, he's saying it's like Java Swing as if that's a good thing?