I guess Simn has said everything that should be relevant to you.
As for some community members disappearing, I cannot speak for Franco. I have not definitely moved to TypeScript, but I am currently using it and have also started creating TS libraries (so far only one), because it turns out that most of the npm packages are really quite low quality 
My focus is on web development and I’ve been fighting the uphill battle of using Haxe for that for some 15 years now. After all that time, I would always recommend Haxe over any other compile-to-js language if you care about performance, robustness and long term maintainability. No alternatives come even close and even if Haxe’s development stopped immediately and permanently, I don’t see the other languages catching up any time soon.
That said, early this year I started a new project and Haxe was not an option, for reasons. So I gave in to trying TypeScript. I am quite deeply disappointed, for a whole number of reasons, but bashing TypeScript here is besides the point.
My story of being forced away from Haxe will be extremely familiar to anyone who’s ever used Haxe for web development. And so what you do see is a relative decline in buzz around Haxe, which has had its moments of fame when FlashPlayer died, because many people jumped over to Haxe (and OpenFl). The game developers largely stayed, the rest essentially moved on, not necessarily of their own will. That’s why you’ll find a whole chunk of the community gone. Even Shiro doesn’t use Haxe for its website, when MotionTwin still did.
Still, it’s a bit sad to see Haxe retreating into a niche. I think it’s a wasted opportunity.
I guess the question would be what other instruments you’d consider and before that actually, what your ultimate goal is. There’s already quite a bit of stuff out there, so I’ll have to assume what you really want is the joy of building it yourself? In that case I would definitely recommend Haxe 
If you’ll forgive me for going off a tangent: I’ve always thought that it would be great to have two separate toolchains for creating native mobile apps with Haxe, with externs to all the native APIs - added bonus for integrating cppia/hscript (or something) for hot reloading in dev, quite likely achieving better iteration speed than the native toolchains.
From there, it’s comparatively straight forward to define some abstraction that allows writing code against both, for people who want that. And even then, I wouldn’t bring in declarativeness at that level.
I would say that most of the cross platform native solutions (React Native, NativeScript, Slint, HaxeUI) share two common issues:
- they abstract away too much
- they are too opinionated (they often bring their own way of describing UI layout and style and often their own framework too)
There is of course something to be said for tight integration, but in my experience, if any part of such a big solution is a problem, than the solution as a whole becomes that problem.
In an attempt to try to avoid that, let’s imagine there are hx-android and hx-ios toolchains. Then HaxeUI could for example depend on those directly to finally get its iOS target (and perhaps even rebuild its Android target to use hx-android). Coconut could also get a backend for each (so one would use native ui components with their full APIs such as they are, but drive them through coconut). You (or whoever) could proceed to build a hx-xui that abstracts over hx-android and hx-ios and comes with a web implementation of those abstractions. And then, again separately, on top of that build out your vision of what a declarative UI lib would look like.
Anyway, those were just some random thoughts on the side. In any case, good luck with your endeavors
Best,
Juraj
