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.
Die you bastard die!!!
How can we make sure it doesn't come back from the dead. Zombie Flash.
Take off and nuke Adobe headquarters from orbit... It's the only way to be sure.
If I were God, wouldn't I protect my churches from acts of me?
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.
(I missed part of a sentence in there ; windows apps can compile "to native" as well using WINE)
For every problem, there is at least one solution that is simple, neat, and wrong.
It looks like if you don't want to deal with Flash, you have basically two options: Qt's QML for non-web-pages or HTML for web-pages.
Soon though, thanks to QMLWeb, you'll be able to use QML-to-JS in the browser.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
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.
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.
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.
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.
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.
My point is that with modern VMs and JITs and partial nativisation and other systems/PL technologies, you no longer should care whether something "runs native", and that that's a distinction that is so blurred anyhow that it barely makes sense to talk about it. It may have once been important and simple, but nowadays it is neither.
For every problem, there is at least one solution that is simple, neat, and wrong.
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.
OpenFL already runs on tons of mobile devices, natively. Clearly, you did not read the article.
Can OpenFL handle something like Stage3D and wrappers like Starling?
I've used Haxe in the past, but found it lacking in support of things like sound and sprite animation for writing mobile games.
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.
As long as employers (game devs, in particular) are willing to keep paying people to write it, I'm pretty sure it's going to stay popular.
File under 'M' for 'Manic ranting'
on the other hand, who really cares about getting access to your machine if you can get access to all the browser-based info through some js exploit?
How do we know this isn't an NSA front organization?
Maybe it's time for yet another reminder that the entire Internet can be viewed as a "front" for the US military, via (D)ARPA, the 100% military-funded organization that paid for almost all of the Internet's early development. (Yes, a bit of money did come from independent sources, mostly in academia, but this was < 1% of the funding until around 1985 or so.)
What makes this irrelevant is that the Internet's standards and almost all of its low-level code have long been open-source, and easily available online. This fact was the main reason it won out over OSI. In the 1980s, I worked on a number of projects that were primarily aimed at OSI, but there were delays caused by all the paperwork required for purchase orders for the official standards, and even longer waits for copies of the libraries and compliance-testing code, so while waiting, we built some prototypes on top of IP. By the time all the purchasing bureaucracy gave us what we needed, the IP version was working, so our clients took that, and the rest is history. ;-)
So even if the NSA is funding this work, if the code is all open (and we can compile it ourselves), that doesn't much matter. The problem then is the proprietary code that will be piled on top of it. History tells us that this will continue to be secret, and the major source of security problems. Code designed to collect "marketing" data about customers is inherently easy for people interested in other kinds of spying to take over and redirect for their own purposes.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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.
You got that reversed. The lunatics are the people whose alarms dont go off at the notion of a browser that just runs whatever program the website hands it.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.