Is haxe alive or dead?

1

Hello, guys!
I would like to set the record straight about haxe development state.
This post is not about blaming someone or pressure on.
It’s more about getting a sense of the current situation.
I am developing declarative multiplatform(js, objC++, jvm) ui lib with haxe and I want to find out should I invest further my time in haxe language or switch to another instruments.
I’ve had some concerns as I am seeing rare commits in haxe github repo. And I’ve noticed some of active haxe users like @back2dos or @fponticelli moved to typescript(could be wrong, sorry, if they didn’t).

So my questions:

  1. Is HaxeFoundation planning to develop and support haxe in the near future? if yes, where can I find a roadmap and its implementation period?

  2. Does HaxeFoundation have enough resources for active development now?

  3. Who is working on the compiler on regular basis now?

I would appreciate for any haxe user answers or opinions on this topic. And I am particularly interested in hearing the views of @Simn , @kLabz, @ncannasse, @back2dos, @fponticelli

Thanks in advance!

5 Likes
2

Haxe is doing fine. There’s indeed not much going on with the Haxe Foundation itself, but that’s also not necessary because Shiro Games is in a good position to support Haxe for years to come. That’s also why so much of the focus has been on boring stability stuff, though I expect some of the technical curiosity to be reignited once we get coroutines working properly.

8 Likes
3

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 :person_shrugging:

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 :wink:

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:

  1. they abstract away too much
  2. 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 :wink:

Best,
Juraj

11 Likes
4

Simon, thanks for your feedback!

1 Like
5

Juraj, thank you for reply. I read your message with great interest. Many things have becоme clear to me.

what your ultimate goal is.

Ironically, I think haxe is most suitable not even for games development(GC is a bottleneck for modern performant games, though it’s another topic) but for creating multi target user interfaces. Declarative way is suitable modern approach for building ui(react.js, vue.js, swiftUI, Jetpack Compose etc)
I agree with you we should have proper native toolchains and API externs to implement it or modify existing libs.

2 Likes
6

I’m jumping into Haxe with both feet. I love the language, libraries and community, so to me it’s not dead.

4 Likes
7

“should I invest further my time in haxe language or switch to another instruments.”

Are you sure you are going to make money investing your time in one or the other ? If the answer is “yes” then go for it, invest your time where the money is then, it’s worth it I guess. If the answer is “no” then don’t expect one or the other to be nothing more than a hobby. Nothing wrong with a hobby, it’s just probably not worth spending too much on it that’s all.

2 Likes
8

Haxe is very much alive to me ! And I think it is fantastic - so I use it for almost everything i do - it’s very flexible and you can do almost anything, since integrating with native languages is so easy and powerful. I work in a company that makes interactive exhibits for museums, science centers and physical spaces. And for this Haxe is perfect! I wish the user base and community was bigger, but still i highly recommend people to dive in. Also i find it to be a real joy to work with! :slight_smile:

6 Likes
9

Appreciate your comments @simn and @back2dos

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

Lol, glad to read that… that’s basically my story too! TypeScript isn’t a completely awful language… well, trying to slap types onto JavaScript may be a misguided goal… But the larger TS/JS ecosystem is a disaster. It’s moving and changing so quickly, with so much legacy - the fragmentation is wild. It’s like a black hole, collapsing under the weight of its own popularity. Most often experience in “typescript” ends up being experience in “framework-X” … And personally, I’m not super interested in being a framework (react, svelte, vue, etc) specialist.

By contrast, Haxe is a lovely, thankfully slower-moving, fascinating and fun-to-use, broadly useful software engineering tool.

9 Likes
10

You should check out https://github.com/jeremyfa/wisdom which is a pretty cool new library for web/ui dev in haxe. Ian does have a new version of haxeui-android on the shelf, just not released, ios is not on the table afaik

One thing to add on to here, is that a lot of activity is on the discord these days which may be a reason as to why things may seem “hidden”, not by intention, its just a convenient way to communicate and share projects

1 Like
11

I am a completely new user (as you can see by me creating my forum account literally to write this message), and at least from what I’ve seen when I last looked at Haxe (like almost a year ago) it looked very interesting, though I did not find the resources needed to get started. A few days ago I re-discovered Haxe, and now I’ve gotten my dev environment set up (hello world already compiled and run) and want to actually learn Haxe, by implementing an interpreter in it for my own esolang Stackowey. And if I actually end up liking it (which seems likely from what I know now) I’ll write more serious stuff in it, like e.g. my own VTubing software that I have the idea to create since I-dont-really-know-when. Or a terminal pet. Or parts of my online operating sim. I have many ideas. And if I e.g. write the parser for the executable file format for my OS sim in Haxe I can more easily have it both work as a compatibility layer (almost WINE-style) for running stuff on Linux as well as (with the same code) running the stuff inside the OS sim.

2 Likes
13

Haxe doesn’t live from the hype like various more mainstream languages, but as a now long time haxe user, I can tell it is very versatile and capable. It’s not all perfect of course, but it works reliably. I shipped a ton of production code with it, and it didn’t have more issues than any other supposedly more mainstream technology you might use.

It’s even better when you start to really understand how it works under the hood because that becomes easier to improve it or adapt it to your own needs.

So Haxe is definitely not dead in my opinion. It is probably very slow-paced regarding its evolution, and it’s no magic in the sense that you would still need to have some knowledge of the target language you are transpiling to using haxe, but that’s not necessarily a bad thing.

It’s very likely that in 10 years from now, I’ll still be making Haxe programs.

3 Likes
15

In a sense, I agree. OTOH there are features which Haxe sports for a decade which are only now making it into more popular languages. Haxe’s evolution pace is not what it used to be, but compared to the average production ready language, is Haxe really that slow? That said, seeing even Java add features that were rejected as too fancy does make me miss the “because we can”-days of Haxe language “design” ^^

3 Likes
16

Hello Community, it’s been a while :slightly_smiling_face: I only noticed this thread a couple of days ago, so apologies for the late reply.

Yes, I did move on. My last serious Haxe work ended in 2018. Since then, I’ve leaned toward TypeScript for most projects. Which is ironic, because not long before that I gave a talk in Boston arguing that Haxe was a superior choice to TypeScript.

Is that still true? In some ways, probably yes. Haxe’s type system and certain features still feel unmatched, especially now that TypeScript positions itself as a superset of JavaScript rather than a language fully standing on its own.

Would I go back to Haxe? I honestly don’t know.

I miss many of its features. I also miss the community. As a consultant, choosing Haxe was often a no-brainer. But when you’re managing a team, or embedded in one, the calculus changes. In one role I mentioned, I had full decision power and convinced three senior developers to adopt Haxe. We built a very successful codebase. But I was able to push that decision. In other contexts, that’s been much harder … and I doubt it would be easier today.

On a more personal note, I do think there are some DX improvements that would make the language more enjoyable. This brings back memories of the long debates around short lambdas. Would those changes make Haxe mainstream? Probably not. But they might make day-to-day use more pleasant.

If I had to point to what feels like the biggest missed opportunity for the community, it’s simply keeping the Haxe blog up to date. Right now, that page unintentionally signals abandonware, regardless of the real progress happening in the language, coroutines, or Haxe 5. I understand that writing posts and maintaining updates is a chore. But an outdated blog can be worse than none at all.

For years, I regularly checked that page hoping for new content. I still do.

Would that make Haxe mainstream? Probably not. But at least it wouldn’t look dormant.

This reminds me of Gleam (https://gleam.run/). I’ve never used it in production, but I genuinely like what they’re doing. I check their news page periodically, and I get a small thrill when I see updates. Their cadence may not be appropriate for a more stable language like Haxe, but there are many interesting Haxe projects that could help fill that visibility gap.

Happy to chat more if there is interest, stay in touch :wink:

19 Likes
17

Hello, Franco! Thanks for your feedback:)

1 Like
19

Curious to know what you have in mind! Would you mind elaborating? Maybe the plugin system could be used to implement some of them?

1 Like
20

I fell in love with Haxe many years ago and even developed some applications with it, but limited job opportunities led me to move on. Nonetheless, I still appreciate its idea and potential, so I occasionally check for any new developments.
IMHO, Haxe has a steep learning curve because you must master both the language and the target, along with its runtime. This makes it particularly challenging for juniors to get started. I believe Haxe’s potential in mobile development is enormous, but unfortunately, its low popularity prevents me from using it in my current work.

3 Likes
23

Here is it :slight_smile: … in no specific order:

  • let to replace final var (immutable by default)
  • Int? as an alternative to Nullable<Int>
  • make function and var keywords optional when defining class members
  • public as the default visibility (I know this is quite debatable)
  • make new optional when instantiating classes (Enum already does this, why not classes?)
  • simplified getter/setter syntax (JS style)
  • optional semicolons (JS style)
  • optional parentheses for switch and maybe other constructs
  • proper JSX like syntax support
  • pipeline operator
  • nullish coalescing operator (not sure if this landed already)
  • optional chaining operator (not sure if this landed already)
  • simplified switch/case syntax (no case keyword at all :smiley: )
4 Likes
24

I still think Haxe is the bees knees. The design, to my mind, hits a sweet spot of complexity, and the fact it’s rooted with a proper macro system puts it ahead of anything.

Like, maybe if I were learning from scratch Haskell / Scala etc would tempt with JS implementations, but this grew up with a bunch of different considerations that mean that it’s set of features are small and principled.

I really like 5 so far, the code-completion is especially pleasing. It’s more tolerant and it’s snappy.

Coroutines are hard to implement so there’s been a hella work in the background to get that straight looks like.

my 2c

3 Likes
25

For an adjustment, there’s already ??/?. operators, optional switch parentheses and inline xml syntax with macro processing. There’s no final var, only final/var like const/let. New property syntax is also already decided, i think.

I agree that Int? would be a finishing touch for a nullsafety sugar instead of Null<Int>, probably most annoying thing to write for me (working on a codegen feature when typing ? char in a vshaxe tho).

Other things are nice too, but don’t bother me much personally, since there is @:publicFields class meta and missing field code generation. There’s also an autofix feature in vshaxe, that will fix missing semicolons on ctrl-s for lazy people like me :slight_smile:

2 Likes