I think Swing is a non-goal of this project. It provides good interop with the DOM and core JS methods, and it makes it easy to create your own interop for JS apis that aren't in the core.
A little over 10 years ago, I ran across TeaVM for the first time (probably) on GitHub. We had been looking for a way to port Codename One to the web, but we needed thread support, which wasn't supported by any existing solutions.
I emailed Alexey (the creator of TeaVM) to ask if he had plans for thread support, and he replied that, while "proper" threads weren't possible, he had some ideas for supporting green threads. Over the following 6 months or so, Alexey would share updates on progress he had made on the thread front. In March 2015, he shared that he had found a new approach for async code that wouldn't affect the performance of single-threaded code, and would support natural stack traces.
We released a preview of our web port using TeaVM a month later, and it exceeded all of our expectations, both in how easy it ended up being to do the port (because of TeaVM), and on the performance.
Alexey's solution for supporting threads, was truly a piece of genius. Had he not created TeaVM, and added threading support, I don't think we would have ended up with our web port - or, at the very least it wouldn't have ended up performing nearly as well.
Nice. I haven't used Flavour for anything yet, but TeaVm is awesome sauce! This past year or so, I've noticed an uptick in activity surrounding TeaVM. More contributions from people other than Alexey. Some of this is seems to be related to the growing interest in WASM solutions, and TeaVM is probably the best pathway from Java to WASM right now.
jDeploy developer here. No shenanigans, I swear. npm just simplified things. Some have expressed interest in adding self-hosting options, so I'll likely add support for that. It's open source too, so others could potentially add other hosting options also.
Yeah sorry I didn't mean anything underhanded, it's just a complication that made me reluctant to try it out initially. Honestly if you wanted to offer a whole turnkey commercial service with hosting and analytics and stuff I could imagine being drawn to that.
"Swing suffered from two central weaknesses: the tutorials provided by Oracle were... often insufficient. And you could pick up some bad habits by following them. And then there were the UI builders where anybody could draw up something mediocre."
Agreed. Also, the IDEs would typically give you too much rope - enough for a novice to hang himself. When you create a new project with Xcode, you get a default project with all of the essentials for a native app. The menus, a window, an "About" window. Etc. In most java IDEs you get an empty main() method. Making an app that feels like a first-class citizen requires a lot of work and attention to detail.
Once inherited a 2D graphic editor... so slow it was totally useless. After tinkering a bit I noticed coordinates were sometimes 'long', sometimes 'Long'... gazillions of automatic boxing and unboxing operations resulted in a severe performance penalty. But the original developer didn't figure this out, tried to fix the problem by adding some multithreading on top... and of course botching it.
Introduced some sensible data types, got rid of the multithreading and it really got smooth...
I played with Swing a bit and really liked the control it provides. Is there any book that you recommend other than Filthy Rich Clients by Chet Haase to develop complex Swing application or to pick up good habits?
Is swing still developed and is there any reason I should pick JavaFX over Swing?
Funny you mention that. I co-wrote Swing Hacks for O’Reilly in 2005 and I still get about 50$ A year in royalties. So someone must still be writing Swing Apps.
My experience with many Swing apps is the same. I think a large part of the problem lay with the development tools. When you create a new Cococa project in Xcode, it generates a full app with all the necessary parts to feel native. You build it, you have a functioning hello world app with your "File" menu, etc...
In Java, when you create a new Swing app, the IDE (by default) just creates an empty main() method for you. You're expected to create your own menus and windows. Trying to make the app "native" requires a significant amount of work.
I always found this very confusing. I still do. At one point in time I think I could have explained why there were three tags. But I don't remember the specifics anymore.
I never really understood why, but I can guess. Could have been political/strategic, to try to force developers onto Objective-C. Or his keen attention to detail might have just bristled at some of the performance an UI issues that many of the Java apps had at the time.
