Slashdot Mirror
Flash Is Dead; Long Live OpenFL!
First time accepted submitter lars_doucet writes "I am a 15-year Flash veteran and nobody hates to say this more than me: Flash is dying, and the killer is Adobe. Where to now? HTML5 doesn't help me with native targets, and Unity is proprietary just like Flash was — 'don't worry, we'll be around forever! And so sorry about that neglected bug report — we're busy.' I'm putting my bets on OpenFL, a Haxe-based, fully open-source implementation of the Flash API that might just please both Flash refugees and longtime Flash haters alike. My article discusses my experiences with it and gives a brief overview for newcomers. In short: I can keep making Flash games if I want, but with the same codebase I can also natively target Win/Mac/Linux desktops, mobile, and more, without having to mess with Adobe AIR or other virtual machines."
OpenFL supports HTML5: http://www.openfl.org/blog/201...
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.
If I'm not mistaken Haxe "compiles to C++" by interpreting the code into actual C++ source, which then gets compiled into a native binary with a standard C++ compiler.
Native vs. interpreted vs. JITed discussion is a moot. (They are all fast enough. On one side. On the other side, many code generators/translators add enough cruft for the code to often lose performance compared to the JITed/interpreted execution.)
The problem is with the libraries required by the run-time. One can compile Java application into a native app (using GCJ), but it is of little use since you still need the Java run-time. IOW, you are still poised to run into run-time deployment issues (version conflicts, local configuration, paths, etc).
Compilation to native code has value only if it allows you to create an application which doesn't have external dependencies or the external dependencies are very easy to manage.
All hope abandon ye who enter here.
I think the verb you're looking for is confirm, not report.
Indeed, instead of using a plugin, author it in OpenFL and "compile" it as JavaScript. You get the nice Flash API and can use the Flashdevelop IDE if you want, without needing the Flash plugin.