shannah78

What do you mean be centralized service? It allows you to publish to GitHub releases or npm. Do you mean "central" like "GitHub"?

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.

"at the cost of some npm shenanigans"

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.

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

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.

Neat. I hadn't heard of either of those before (though I'm not a Clojure developer). Thanks for sharing.

100% agree. The "distribution" step has always taken way more time than I expected. And, I almost always had to compromise on certain platforms just because it couldn't get the square peg in to the round hole.

The goal of jDeploy is to sand off as many of these rough edges as possible to make cross-platform distribution as easy as cross-platform development.