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."
Flash was one of the few holdouts of the Plugins era of the Netscape vs. IE Browser War. It came out because There wasn't a standard between the two for vector based graphics.
Flash worked in different browsers and across many different OS's so it got well accepted. Then Adobe for the most part didn't let go easily and created more and more stuff to it, to make it rather full featured, killing off Active X and Java Applets for standard web pages.
That said. HTML 5 is not perfect, however it does give us a lot of features that we think we should use flash for, and we really should follow the standards that comes part of the browser then rely on plugins.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
So what? Perl can compile to C too, by bundling the interpreter into your target binary. Windows apps can compile "to native" as well. Neither makes it exactly native, similarly to having your app interpreted by a native HTML5 engine is.
The most native way something can be for a platform is to be written directly for its platform, bound directly to its APIs. Anything but that gets very conceptually fuzzy. And if you're worried about this for performance reasons, you should look at the Quakelikes that have been ported to HTML5.
For every problem, there is at least one solution that is simple, neat, and wrong.
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.
Since you're a big HaxeFlixel guy, can you point me in the right direction to actually getting a working dev environment going on Windows? I tried a couple of times, but gave up because even the example projects would throw incomprehensible error messages when I test compiled. Only information I've been able to find on the errors was other people having the same problem, but no actual solutions.
Flash became dominant because it filled many real needs. Vector graphics is just one. It also brought creation tools so artists could work with it, it brought a scripting environment fast enough to use in a browser. Like you say, it also brought commonality to all the different browsers. This means that Flash brought a lot of features to the masses:
- browser games. These were known as Schockwave or Flash games.
- usable online multimedia. Yes there were video sites, but they became far more usable and reliable with Flash video.
- rich design. As much as we hate them for all their inherent problems (and I do too), the fact is that before HTML+CSS caught up the only way to implement a crazy design was with Flash.
- rich typography. We've only got proper font support very recently. That means the website can define its own font, not simply choose among the handful of Web fonts one could assume were available on the client.
Yes you could do video with native plugins like WMPlayer. Do you remember how terrible that was? Half the videos wouldn't play because of some unknown problem with codecs or such. When FLV came in it was great. Despite its problems, it brought reliability. I don't think YouTube would have become as successful as it is without Flash. Same with audio.
Despite its many problems, Flash brought a rich, standard interface to the web when nobody else could.
boldly going forward, 'cause we can't find reverse
Flash is no more native than HTML5. At this point it doesn't make sense to "place bets" on Flash at all, unless like the article author you've spent many years on Flash and are not interested in change.
Flash can create a 'native' PC or OS X app (OK, it consists of a standalone Flash player bundled with your flash App, but the practical upshot is the same unless some strange permutation of misconceptions has led you to expect 'bare metal' efficiency from something like Flash).
Flash was actually a great system if you wanted something to write relatively small, animated, resolution-independent applets that can be embedded on web pages and downloaded as pseudo-native PC/Mac apps (Java was obviously better at coping with substantial projects - but its been getting a bigger and bigger pain for non-techie end users to install). Of course, it got abused as a way to add gratuitous animation to websites, and its only merit as a video player was that it was less annoying than RealPlayer...
The real killer, though, is that it doesn't run on tablets... however, when it was briefly available on Android I tried some existing Flash stuff and it quickly turned out that Jobs was right - apart from the bloat and security nightmare, lots of existing Flash stuff just broke on a touch screen.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
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.
The Binding of Isaac disagrees.
Great game!
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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.
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.