Quick note: this is NOT a flash player reimplementation. It's an API implementation. Thanks to Haxe, OpenFL apps can compile out to C++, HTML5, Flash, etc.
I should also note that people might also be interested in the programming language that OpenFL is built on, Haxe, which has been around for ~10 years, is criminally underrated, and has many, many uses besides OpenFL's Flash API implementation (probably the most popular Haxe library).
For instance, here are some other uses :
- Isomorphic client/server web apps (http://ufront.net/)
- Cross platform UI (http://haxeui.org/)
- Other game frameworks
- (snowkit: http://snowkit.org/)
- (kha: https://github.com/KTXSoftware/Kha)
- (nme: https://github.com/haxenme/nme)
Course I'm a big fan of OpenFL!
Also, for those who don't like the Flash API, OpenFL has a lower-level foundation called LIME that is just the cross-platform abstraction layer, so you can just use that if you hate all things remotely Flash-like.
Haxe is very much underrated. You can write mobile, web, server, system, embedded, game code with the same programming language and deploy on almost whatever you want. Guess Erlang is the one target missing.
It's a nice language and it's mature as is it's toolset. It's very trivial to integrate native libraries.
I believe it's underrated (what people most often say) because of the libraries which are kind of a mix of quality and a lot of them outdated and unsupported. HaxeFlixel/OpenFL are very nice and stable, but that's for a limited audience. Myself and others using Haxe, I believe (but I have nothing but experience to back this up), just integrate what they need themselves because it's easy. And never release it because it's not good enough or release it half-baked (to the point they need it).
I never wrote anything in Flash and so I don't really see OpenFL as anything Flash (while it obviously is); it's just a nice, well documented API for me.
Edit (bit offtopic):
Another underrated language that manages quite a bit of targets quite well is Monkey-x; it's also targeted at games. I wrote a few production games in them and it's nice to work with.
And yet another one, which I really like, is https://mercurylang.org/about/backends.html ; the implementation is very nice but really complex. That makes working with it harder because there are not many people to support it. With Haxe / Monkey I can fix things myself, with Mercury that's just really too much work.
Almost the opposite of that one is Shen which, again, has many languages it compiles to / runs on for which building targets is rather trivial. It's actually the only language of all the above for which implementing a new backend is trivial.
In my opinion part of the reason why Haxe still hasn't got much support outside of game development is an easy, cross-platform way to do native UI. It's definitely something that's needed for it to be a good solution for building most non-game applications.
Edit: Example of hackery I didn't release because it's hackery. But it's stable and it works. I would like to find the time to clean it and release it.
Haxe is awesome but it's not popular because it has a discoverability problem. It's difficult to find what you need. This is getting better though. Bet on Haxe this year.
I realize this is not a reimplementation, but given the similarities of Haxe and ActionScript, and the fact that you can work with both in IDEs such as FlashDevelop - would you say that OpenFL could be a good path for porting legacy Flash application to HTML5 or mobile?
Yes, it definitely is a good path for that, especially if you were using Actionscript 3.0. OpenFL does not support the AIR API on native targets (you can still make AIR games via Haxe, just only on flash target), but on native you'll gain access to anything AIR could do and more through the Haxe standard library's native system stuff.
Tons of people have used OpenFL for exactly this purpose (porting legacy flash games) -- I'm doing it for Defender's Quest (previously a flash game), Cursed Treasure 2 is a good example as well of making the jump from Flash -> Haxe/OpenFL (Cursed Treasure 1 was flash.)
How does Haxe manage impedance mismatches between it and so many target languages? I've never heard of anything pulling that off successfully. Maybe Eiffel? But then, who uses Eiffel?
Another thing is the Haxe standard library, which guarantees certain features across all targets, including features that aren't normally available (like, say, Reflection in C++, if I understand correctly). If the feature is natively available, it falls through to the native implementation, if not, on that target the standard library provides enough code to enable the feature.
Assumably it compiles down to a subset that is easy to port—basically take the VM approach except make it AOT-oriented instead of JIT-oriented, like LLVM.
The haxe target languages aren't very different, other than some superficial syntactical and their standard libraries being somewhat different. Working around those aren't "difficult" (which isn't to say it isn't a lot of work to implement of course).
I'd be surprised if haxe could get a target language such as haskell (unless if they created a specific lib in haskell to emulate an imperative program and mutable state).
Also, pardon me if this smacks of self-promotion (since I wrote the article I'm about to link), but I think it's relevant to mention home game console support is coming soon to OpenFL as well:
Disclosure: I'm one of the developers behind The Masterplan
We've been very happy with Haxe and OpenFL, but for us the most important thing is definitely not the Flash API but a cross platform way for writing games that use OpenGL ES 2.0 for rendering and OpenAL for audio. See Lime (https://github.com/openfl/lime).
We've made a tactical team-based heisting simulator called The Masterplan with this setup. It's finally coming out of Early Access today! The current release runs on Windows, Mac and Linux and hopefully we can release this on many more platforms in the future.
Haxe is fairly interesting to me (and I've used it in the past, but only to target flash), but I have no great love for the flash APIs, so the prospect of writing a game using OpenFL didn't excite me much. Lime looks much more interesting, as it doesn't seem to force you to structure your game a particular way.
So, I'm assuming this includes support for hardware-accelerated vector graphics? There's a real need for this kind of tech on mobile; on my old iPad 3, I can not even animate a single full-screen bezier path at 60fps, whereas using MonkVG, I can suddenly do 20 or more at once! (And that's not even factoring in the "free" matrix transforms that don't require retesselation.)
There's a ton of fascinating apps and games that could be made if only vector graphics performance was better. It's too bad OpenVG never went anywhere.
Haxe allows for compilation to multiple targets and doesn't require Flash in any way. Flash is one of the supported targets but there are many others that work just as well if not better (including HTML5).
I should also note that people might also be interested in the programming language that OpenFL is built on, Haxe, which has been around for ~10 years, is criminally underrated, and has many, many uses besides OpenFL's Flash API implementation (probably the most popular Haxe library).
For instance, here are some other uses :
Course I'm a big fan of OpenFL!Also, for those who don't like the Flash API, OpenFL has a lower-level foundation called LIME that is just the cross-platform abstraction layer, so you can just use that if you hate all things remotely Flash-like.