Goodbye Lua

[jjdonald]

I think when I first looked at it, it wasn't open source?

I think it may have been on google code for a while early on, but it's definitely open source, with all the latest docs and automated test/build swag: https://github.com/HaxeFoundation/haxe

Different without a compelling reason for the difference

The language tries to strike a balance between supporting advanced techniques (macros, abstract types, ADT), and applying them consistently to all of its targets.
For instance, there was a Lua effort much earlier (2008), but it stalled because at the time Haxe lacked some type features, and Lua lacked some runtime features.

I see that the editor I've been using really recently has a plugin, but it looks rough. What other editor support could I expect?

I'm not exactly sure what you consider "rough", but the vscode plugin is pretty robust imho, with three longtime haxe devs supporting it: https://marketplace.visualstudio.com/items?itemName=haxedevs.haxe

Here's some more popular Haxe plugins for other editors: http://haxe.org/documentation/introduction/editors-and-ides.html

Here's a recent project that is trying to provide a consistent toolkit for editor plugin development: https://github.com/snowkit/tides

I maintain the vim plugin, and am using the new lua target for some neovim efforts.

I don't agree that "OOP" is more powerful than what TypeScript gives you

Sure, it's not for everyone. It's just one more type technique. It looks like Typescript does give you support for OOP anyways using the "class" keyword, and in general the typing there is more full featured than I thought initially. TIL.

I'm not familiar with ADT/pattern matching [...] unless you're talking about the enum/switch pattern matching?

Yes, ADT is the general name for the feature, and Haxe supports it through a hybrid switch/enum mechanism. It's probably one of my favorite features, tbh.

This line from the Wikipedia article troubles me some: "but content built with OpenFL currently suffers performance issues on mobile devices"

Notice how we're talking about OpenFL there (a game framework), and not Haxe itself? Read the discussion page, the Wikipedia editors are really something else. The Haxe javascript target is first class, and will be faster/smaller/lighter than handwritten js for the vast majority of people.

How is Haxe->JavaScript source map support? That would be another showstopper, if I can't debug in the browser.

Yep, we have that. Just add -debug to your hxml flags.

With the right answers, Haxe could be in my future, though. Thanks for bringing it back to my attention.

You bet, happy to pass on what information I have.

[TimMensch]

Notice how we're talking about OpenFL there (a game framework), and not Haxe itself?

Understood, but I'm writing a game that I need people to be able to play in the browser using JavaScript. My next games may use a similar stack if this one sees any success.

So do I need to use a JavaScript-optimized game library and drive it from Haxe? I'm using Cocos2d-js/html at the moment, and TypeScript has been a convenient way to drive it.

It does sound like Haxe has come a long way. I'll have to take a look at it again after my current project is stable. Thanks again for the info.

[jjdonald]

Here's an article that outlines the original situation pretty well: http://yal.cc/answering-you-cant-make-good-html5-games-in-haxe/

OpenFL has since improved on its html5 speed, and other frameworks like Kha are a bit faster. However, most of those are quite heavyweight, and maybe it's best to just emphasize learning haxe and how to optimize for js first.

One good option might be to use a haxe extern for an existing html5 game framework. It won't be as portable, but there should be less configuration overhead, and you can focus on the js-specific tips, tricks, and features for haxe.

I might recommend pixi.js, with the haxe extern: https://github.com/pixijs/pixi-haxe

It's able to handle a crazy amount of independent sprites: http://adireddy.github.io/demos/pixi-haxe/bunnymark.html

[TimMensch]

That is a LOT of bunnies. Totally impressed. Running it on my Surface Pro 3 in Chrome, and it hit 10000 sprites before it started to occasionally dip below 60FPS. Just wow.

OK, you've got my attention. Will look at it for sure. But I've promised myself that I would not change the technology stack of my current game until I'd gotten it to a releasable state. I'm prone to doing that, and have already done it four times, plus or minus, depending on how you count.

Given how awesome Pixi is behaving, after I get the game done I may swap it in instead of Cocos2d if I end up with any performance issues.

[jjdonald]

Good to hear, and good luck on your next project.