[cojo]

We used Haxe for a while at my last company for a cross-platform engine that would actually run well on web (browsers couldn't yet handle "real" Unity WebGL builds at that time).

While it "worked" and the resulting engine / suite of games ended up net profitable, and I'm a fan of Haxe's features as a language (I am really missing the pattern matching and macros in Typescript these days), I must say the build pipeline and available tools for OpenFL / Haxe games was lacking at best.

On the plus side being able to fork and fix issues we ran into was a game changer over Unity IMO.

Not sure if the ecosystem has evolved / improved on the build and tooling fronts in the last 18 months since I last interacted with it directly, but that would be the one word of caution I'd offer to anyone after they read this article. Be prepared to roll up your sleeves and get a little dirtier than usual if you really intend to ship on both web and mobile.

[larsiusprime]

OpenFL's matured a bit since then and I quite like it personally, though I should point out that OpenFL is simply one of many libraries, and the rest are worth checking out, too! OpenFL's probably the most well known but the ecosystem has a lot to offer beyond that.

[kevin_bloch]

Not sure of the specifics in the last 18 months on straight OpenFL, but I know that some frameworks built on top of it had nice features like hot reloading. HaxeFlixel has an in-game debugger, too, for example. I guess it depends on the types of tooling you had in mind.

[pier25]

> I must say the build pipeline and available tools for OpenFL / Haxe games was lacking at best

That was my experience as well.

Too many moving pieces going in different directions. When it wasn't a Lime issue, it was Hxcpp, or OpenFL, or a combination of these. That was 3-4 years ago though.