FlashDevelop is the most popular IDE for Haxe development, it does not "exclusively target flash/AIR."

Actually, several of the developers are major contributors to open source projects: Here's open-source libraries that are DIRECTLY the result of Defender's Quest development:
http://github.com/HaxeFlixel/f...
http://github.com/HaxeFlixel/f...
http://github.com/larsiusprime...
And here's my open-source report card:
http://osrc.dfm.io/larsiusprim... Nicolas Canasse, developer of Evoland, *created* the Haxe programming language. It's totally open source. Here's his open-source report card:
http://osrc.dfm.io/ncannasse Here's Sean Hogan (Anodyne/Even The Ocean)'s contributions:
http://osrc.dfm.io/seanhogan That's just off the top of my head.

There's a few things here and there, not sure if there's an actual list. If you target flash, obviously you have all flash functionality available, but certain things (such as super-advanced international text field support) still need to be added on various targets. HTML5 is a brand new target so that's the least mature, whereas mobile and desktop targets have really good coverage. A "list of gaps we need to fill" would definitely a good feature to add to the OpenFL site, though.

It already does! You can make native-binary mobile apps for ios and android using OpenFL, RIGHT NOW.

OpenFL supports HTML5: http://www.openfl.org/blog/201... So any improvements to HTML5 will also benefit OpenFL. What OpenFL solves is the issue of "shit, my platform holder's investors got bored and yanked the rug out from under me, time to build my workflow back together from scratch!" By using Haxe, I can preserve my codebase and pivot to whatever the hot next technology is without having to bet on any one platform. I see that as a feature, not a bug.

OpenFL already runs on tons of mobile devices, natively. Clearly, you did not read the article.

Again, you clearly did not read the article. For people who hate the Flash API, there is lime: https://github.com/openfl/lime

Sure, send me an email: http://www.leveluplabs.com/?pa... And let me know what you're dealing with. Chances are it's a haxelibs issue.

You clearly did not read the article.

Correct. I'm not an expert on the Haxe compiler, but I'm pretty sure it also has the ability (via hxlibc or hxcpp libraries) to directly compile Haxe to native binaries, skipping the intermediate C++ source step, but it can also create those too.

Okay, so that's a semantic difference then. If by "native" you mean "original source code written in the original language" than by that definition it's not native. I'm trying to clarify that it's not using a virtual machine, or relying on a plugin, whatever you want to call that.

It does not execute arbitrary C++ code on your machine. Did you even read the article? It's a lifeboat for flash developers to make, say, desktop games. IT IS NOT A NEW VERSION OF THE FLASH PLUGIN.

It seems a lot of people either didn't RTFA or are basically misunderstanding what OpenFL is. OpenFL is NOT an open source version of the flash Flash Plugin, like Gnash. OpenFL is a code library written in Haxe. You use OpenFL, and then you can output a truly native (C++) app, but can still use the flash API. It doesn't embed the flash player, or Adobe AIR, or anything like that, in your generated C++ app. You can use this to create truly native apps for mac/windows/linux/mobile, etc. Very recently they've added the ability to output to HTML5: http://www.openfl.org/blog/201... So you can take your old flash code, port it to Haxe, and then have a 100% Javascript based HTML5 game. And you can take that same Haxe code and make a native C++ app with it. And so on. Hope this helps demystify things.

Maybe because all the code is open source and you can inspect it yourself? http://www.github.com/openfl