I commented about Haxe at a HN TypeScript thread and linked to Andy’s excellent “TypeScript vs Haxe” post from 2015. Not sure what may have changed with both languages since then though.
Mentioning it here in case there’s questions there about Haxe and anyone here wants to chime in.
Would be cool if someone writes a 2019 version of Haxe vs Typescript! Since Haxe now has short arrow functions and function type syntax and quite multiple things have changed in both languages.
Unfortunately, IMHO, Andy’s article doesn’t really bring any useful argument, beside demonstrating that the Haxe syntax is unsurprising.
If an average JS dev has decided to “add types” to ES6 there is little point to using Haxe, or he will probably suffer more than necessary and give Haxe a bad rep.
Choosing Haxe is a deliberate decision to not be hype-driven, to use only absolutely necessary JS libraries and being ready to write externs for what you need. Also you suspect that you can do interesting stuff using macros.
Syntax or type subtleties differences with Typescript are a moot point. However dealing with tens (or hundreds indirectly) dependencies is exhausting and confusing (especially when types and libs are separate modules). “Proper” Typescript typing is in fact outrageously difficult even for solid developers and many devs just give up.
Reasonably one way to “sell” Haxe would be to offer something like Angular: batteries included (code, toolchain and patterns) and with world class documentation.
Couldn’t agree more.
And we already have pretty much all the components for such framework. In fact, I’d go as far as to say that MVCoconut (and tink suite of libs) is the best candidate to be the killer web / mobile / desktop app solution for Haxe.
The devil is in the details though. At the moment, it’s not trivial to integrate Haxe in the TS toolchain. It is easier if you fallback to plain js/ES6, as there’s already a webpack loader, etc, but it’s far from obvious and it’s all scattered around. Another option is to let go of webpack etc and embrace Haxe (keeping the js build tool(s) / boilerplate to a minimum). I’m not very fond of that because then it becomes harder to integrate with other js components, if the need arises, and build tools like webpack are very powerful and there are tons of resources online about it, so why not embrace it?
Also, the documentation for coco and the tink libs is very basic at best (I can understand why, there are only 3-4 people working on them and again it’s quite niche). The good thing is that people are mostly always willing to help you on gitter.
The hard truth is that in the bigger scheme of things, the features Haxe offers - as awesome as they are - end up not being enough motivators if people have to spend too much time tinkering with Haxe to leverage the js ecosystem in a productive manner. Specially when one can find so many articles and good boilerplates for js/ts/react/etc online.
You also have to take into consideration that Typescript is evolving fast. It’s actually a very neat language and there are actually features in it that are ahead of Haxe in some ways. I recently found fp-ts which provides some of the functional aspects Haxe provides, for TS. I miss the everything’s an expression aspect of Haxe, but there’s already a proposal that solves that for ES6 and should arrive in TS in the next years (and already available for babel), although I find it a bit awkward in its design.
But this seems cyclical subject. We’ve had similar convos many times in the past. I also think it’s gradually getting better (we have short lambdas, finally!), although I wish some of the evolution proposals were accepted and implemented in a more straightforward manner, I can understand why it takes long (except perhaps the short lambda drama :D).
To be honest @fullofcaffeine the effort you’re deploying to integrate TS and “cool JS libs/frameworks” and Haxe is exactly what one shouldn’t be doing: this is convoluted and fragile.
It’s good to be able to use a tiny bit of JS as an escape route but you should either go all in TS or Haxe. If you want to use all the latest popular react/mobx/css-in-JS/etc. you’re in for a painful journey with Haxe.
You can check my Haxe tools and React sample projects - it’s Haxe first, and Webpack. If you take my approach to Haxe Redux it’s attempting to be idiomatic to Haxe, using enums for actions.
Now I’d advise using Cononut as “the Haxe way”.
I understand it’s tempting to use React components but it comes often with more friction than value.
Yes, I get your point. But from a newbie’s perspective, this can be a blocker. I wish Haxe could borrow a bit from TS philosophy of gradual adoption (you can mix and match freely in your project, and gradually adopt TS as you feel more comfortable with it).
It’s somewhat possible today (with custom generators), but it kinda conflicts with Haxe’s design, so there’s a lot of friction. Also, we have to consider that unlike TS, Haxe is not a superset of JS.
My efforts are just learning experiments, not meant for production (atm), so I agree with you there.
If you’re a newbie you’ll depend on a boilerplate and/or someone senior. Whatever the language you use.
There is no possible gradual adoption, there are many subtle syntax differences which trip beginners, especially when advanced ES syntax and Babel transforms are involved.
I don’t necessarily see boilerplates only as a tool for newbies. They provide a framework that can be based upon/modified and save valuable time and cognitive effort.
Of course, there’s no silver bullet and I’m taking a more product/business-oriented approach here, where you want to leverage what’s already out there and focus on the 20% that matters. That resonates with what you said about a “batteries-included” framework for Haxe. Having good boilerplates/templates/generators*[0] is a way to achieve that (and not mutually exclusive to it).
*[0] as in yeoman(ish) generators
© 2018-2020 Haxe Foundation - Powered by Discourse
