It's that time of year again! Flash is dying, dying, doomed. I said the same thing last year, though my formal accusation for the ongoing murder was: "Adobe Systems, in the Internet, with the toxic-mixture-of-incompetence-and-neglect."
In any case you can tell it's serious this time because even Homestar Runner is weighing in:
As everyone seems to gleefully pile on the embattled multimedia plugin, I'd like to say a few words in memorial as we move on to the future.
Flash was cool
I'll be brief.
There's a very black-and-white nature to most "Flash is dead/dying" articles. HTML5 advocates represent "team security and web standards" (not to mention "team glorious future"), and Flash advocates represent the knuckle-dragging neanderthals who just can't get with the times and want everyone to be subjected to terrible battery life, annoying ads, and cliched websites designed by companies who can't be bothered to learn CSS.
But it has to be said that for all its faults (and they certainly are many) Flash had a lot of redeeming qualities. Obviously it was great for web games and cartoons. It was lightweight, it loaded fast, and it ran just about everywhere. But most importantly it was a tightly integrated set of tools that made it easy to mix code, layout, and art, including a powerful animation editor that proved so popular that to this day, it retains a significant following among animators despite the fact that it's scarcely been updated in years.
But I come to bury Flash, not to praise him.
Back in 2010 when this meme first started to gain steam, clueless web devs loved to say things like "Anything you can do with flash, you can do with HTML5 Canvas + SVG."
At the time this was totally inane, as there was terrible cross-browser support for HTML5 features, and given the dearth of competent multimedia frameworks, it was functionaly equivalent to "Anything you can do with a paintbrush you can do with a toothpick and an infinite amount of time."
Nowadays things look a lot better, and with WebGL's maturation, HTML5 is very close in feature parity to Flash's capabilities. But all that gives us is a compatible list of checkmarks. This is a very natural way for developers to think -- "hey, you've got vector graphics, scripting, a tweening library or two, 3D capabilities, what more do you want?"
Well, coherence for one. Going from a tightly packaged experience like Flash to HTML5 is a big step. Coders switch over without too much trouble, but the designers, animators, and layout artists have a much harder time. And to their credit, Adobe is slowly repackaging their tools to be HTML5-compatible, though there's plenty of inconsistencies and incompatible features.
Now don't get me wrong, I think HTML5 is the future of the web. That said, it won't replace Flash by itself. Instead, the flash player will be replaced by more powerful tools built on top of HTML5, and Flash (the tool) may well hang around for another decade or more. SWF files themselves will still probably stick around, albeit as asset files for HTML5 apps rather than standalone executables themselves.
I'm not going to try to make too many specific predictions, just talk about some of the options that are currently on the table, as well as make a particular case for my own favorite toolset, Haxe.
Flash - what was it good for?
There are five main things that Flash was used for back in the day:
- Full-flash websites
- Rich Internet Applications (RIA's)
Full-flash websites are pretty much a distant memory these days. These were sites where the entire web page was a flash program, complete with text, images, links, etc, all run through a SWF file or files in the flash player plugin, often with over-designed transitions, filters, and effects. Needless to say this was a usability and SEO nightmare and the only one I can even think of today is HomestarRunner.com, which is a bit of special case.
Rich Internet Applications are now just known as "Web Apps" and have been nearly entirely replaced by popular HTML5 frameworks. It was convenient to be able to mock things up in Flash Builder and use Flex UI components like buttons, dropdowns, scrollbars, textareas, and the like, but without a way to reach the mobile web they're a no-go these days. These applications were pretty code-heavy anyway, so it was less of a jump for the developers.
Cartoons are interesting because a shockingly large number of them are still completely animated in plain ol' Flash, even if the export target is something else. One thing that was really nice about the SWF format was its low file size, crisp rendering, and fast download speeds. We (mostly) have broadband now, but it still makes me cry to see gorgeously animated vector cartoons churned into a bloated video file and stuck on youtube with compression artifacts. At the very least we should have some kind of vector animation player.
Video seems like it would be simple but remains surprisingly elusive. Remember, Youtube pretty much wouldn't exist if it wasn't for Flash making it easy to embed and stream video across platforms. There's been heroic efforts underway to make seamless video part of the HTML5 standard. For years this effort was hobbled by bickering over codec support, but things have mostly shaken out by now, though flash fallbacks are still required if you want 100% coverage (source):
Until recently, the biggest challenge with HTML5 video was the split support for video codecs. Some browsers supported H.264, others supported VP8 (commonly known as WebM). Firefox resolved this standoff by rolling out H.264 support across Windows (22+), Linux (26+) and Mac (35+). This means H.264 can now be played everywhere, when using a Flash fallback for Opera and IE8.
For next-generation codecs, the situation is reversed. Here, the open-source VP9 is already supported on several browsers, while HEVC doesn’t play anywhere yet. Since VP9/HEVC generate the same video quality as H.264/VP8 at half the datarate, a dual H.264+VP9 strategy could reduce costs for companies where bandwidth drives the bills.
Which brings us to GAMES, which is my personal stomping ground. Fortunately, there's a lot of exciting new opportunities here, and as a bonus there's a lot of cross-over for web app developers.
Game & app development, post-Flash
There are three big dogs in the fight for mindshare among "flash refugees:"
First on the docket there's Unity. Popular game portals like Kongregate have had Unity web player support for a long time now, and given its massive success on consoles and desktop, it's a great fit for lots of people. C# is a comfortable high-level, garbage-collected language, so it's not too different from ActionScript. The major barriers are the jump to a fundamentally component-based structure, and the 3D paradigm driving the whole system. Unity has recently rolled out improved 2D support, which is great, but 3D is still the foundation and it shows.
The big blow to Unity is that its web compatibility has traditionally depended on a browser plugin, which is now being made to walk the same plank as Flash. (Ironically, back before the Flashpocalypse, Unity even toyed with releasing a Flash Stage3D export target). Fortunately, they've got an HTML5 export target in the works.
I am however a bit skeptical about that. I can't see the Unity runtime being any less than several megabytes at least, and from the looks of it their HTML5 pipeline looks like this:
C# --> MSIL --> C++ --> LLVM --> asm.js
Now, I'm a big fan of cross-compilers, but that's four transformations across five different language formats. That's just asking for all sorts of obscure bugs and instability, and a tangled mess of human-unreadable code at the end of the pipeline.
Don't get me wrong, I think Unity will remain a juggernaut in this industry for years to come, and a great boon for developers small and large alike, but I just don't see it taking over the web.
Of all the HTML5 game frameworks, PhaserJS is the biggest one on my radar. Phaser is an entirely open-source game framework developed by Richard Davey, aka "Photon Storm", who was one of the major contributors to the one of the most popular Flash game engines, Flixel. Phaser is inspired by (but not beholden to) Flixel, and is powered by Pixi.js, a powerful WebGL renderer with a Canvas fallback. It also seems to be the most popular JS game engine on Github. Seeing as JS is the most popular language on Github, that's saying something.
Although Phaser doesn't have all the features Flash did (vector animation, 3D), it has a lot of appeal to flash developers used to Flixel and other 2D workflows, particularly for retro-styled pixel games (though Phaser can obviously be used for much more).
I don't know how much appeal PhaserJS has outside of the web, but there's a lot to be said for "do one thing, do it well."
There are many other HTML5 game frameworks as well, such as Construct2, and countless more, but the one I keep hearing about from former flash developers the most is Phaser.
Haxe is the emerging disruptive force in cross-platform game development, and web dev in general. (Full disclosure: I'm a Haxe developer, a core contributor to both OpenFL and HaxeFlixel).
The best-known Haxe framework is undoubtedly OpenFL, which I have talked about at length. But there's a lot of other frameworks too, each with their own best use cases. The five major frameworks are OpenFL, Luxe, Kha, NME, and Flambe.
|OpenFL||Win, Mac, Linux,
|Flash, HTML5: Canvas, DOM, WebGL||Android, iOS, Blackberry, Tizen||PS4, PS3, PSVita, XBox One, WiiU
|Re-implements the Flash API, originally a fork of NME.|
|Luxe||Win, Mac, Linux||HTML5: WebGL||Android, iOS||Focuses squarely on Native & WebGL, departs from the Flash paradigm entirely|
|Kha||Win, Mac, Linux||
Tizen, Windows Mobile
|Unity3D, PSM, XNA, WiiU (soon)||Super portable and flexible|
|NME||Win, Mac, Linux||Flash||Android, iOS,
||OpenFL's predecessor, a re-implementation of the Flash API that focuses on stability and native targets.|
|Flambe||Flash, HTML5||Android, iOS (via Adobe AIR)||A web and mobile-focused framework .|
All of the above are free and open source cross-platform game/app frameworks that support some combination of web, mobile, and native platforms. Each has its own focus and particular strengths. I'll briefly discuss each of them, and finish up with some Haxe developer testimonials.
OpenFL and NME
OpenFL and NME are the most similar and are often confused, so I'll start with them.
Both libraries are Haxe re-implementations of the Flash API. This means that they let you use things like "flash.display.BitmapData" and "flash.geom.ColorTransform" even though you're using, say, a C++ target and not the Flash Player. Both libraries support flash, mobile, and native desktop targets. NME came first, and OpenFL forked from it as design goals diverged over time.
AFAIK, OpenFL maintains the broadest support for the Flash API, though NME remains very similar and in many cases one can switch between the two frameworks with minimal changes. OpenFL can even integrate with the Flash Professional IDE tool.
NME focuses more on native targets, with custom backends and performance-heavy logic written directly in C++, while OpenFL has moved much of that logic to Haxe so that it can be re-used across targets that depend on other languages, especially HTML5. NME thus has no HTML5 targets, and OpenFL supports DOM, Canvas, and WebGL rendering modes (I believe canvas works the best as of this writing). That said, given the extremely similar API's, it wouldn't take much for an NME user to use OpenFL for their HTML5 targets and NME for their native targets.
As far as I know, OpenFL leads the pack in terms of the largest number of supported platforms, with game console support soon to be added to the list.
Popular Haxe game engines like HaxeFlixel, Away3d, HaxeStarling, HaxePunk, etc, are all built on top of OpenFL, with HaxeFlixel in particular becoming increasingly popular in the Ludum Dare game jam.
The award-winning Papers, Please, perhaps the most well-known Haxe game, was originally developed in NME and is currently using OpenFL to reach the PSVita.
Flambe is a major "flash replacement" library, but takes a slightly different approach than OpenFL/NME. It's API is roughly similar to Flash's, but not intended to be a 1:1 mapping. Also, whereas OpenFL and NME make use of the swf library for rendering Flash vector animation content, Flambe is built around FLUMP, a toolset built around exporting Flash animations as texture atlases with associated animation metadata.
Flambe is squarely focused on web and mobile, with support for HTML5 WebGL, Canvas, and Flash. Mobile support is faciliated through the flash target by using Adobe AIR, since Flambe has no native C++ targets. Flambe seems to be quite popular in the web & mobile games crowd, boasting high-profile clients like Nickelodeon and Disney.
Luxe is the crowning achievement of the Snowkit collective, which like OpenFL, is a free and open source cross-platform game engine that supports web, native, and mobile targets. The key difference is that Luxe dispenses with the Flash API altogether, with web support built squarely around HTML5 using WebGL (no flash target). Luxe's design philosophy focuses on simplicity and providing a set of powerful common tools without putting too many restrictions on the developer.
Kha is the most recent of the Haxe frameworks to emerge, but is built on mature technology going back years. Kha's specialty is a focus on lightweightness and flexibility, with an eye towards maximum portability. Kha was the first framework to support last-gen home game consoles (The XBox 360 via XNA and the PSVita via Playstation Mobile), and can even run on top of Unity3D, through which it can access current-gen consoles. Kha supports HTML5 using WebGL and Canvas, as well as Flash.
Talking to Developers
I did a quick public web survey of other flash developers now using Haxe and the vast majority echoed practical sentiments rather than any particular ideological or linguistic commitments. OpenFL and HaxeFlixel were far and away the most popular libraries, though all the ones I've mentioned in this article made an appearance, including some I'd never heard of before. Chief on everyone's list of complaints, however, was the relatively small size of the Haxe community and a need for better documentation. Momentum has been building on this front -- (compare the new Haxe website to the old one, for instance), but there's still plenty of work to be done.
For this reason and more I was recently pleasantly surprised to find that two prominent Flash developers had started using Haxe: Terry Cavanagh (VVVVVV and Super Hexagon), and Bennett Foddy (QWOP, Sportsfriends). Not only are they well-known for their games, they're also well-known for being extremely helpful to newbie game developers.
Bennett has begun using Luxe, and speaks about his experience porting QWOP here on the Snowkit community blog.
Likewise, Terry has begun developing his own beginner-friendly Haxe framework built on OpenFL, which at the time of this writing bears the temporary name "TerryLib".
I contacted them both about why they started using Haxe, and here's what they had to say.
I was drawn to flash because of it's accessibility - I loved the idea of making games that people could play without having to download anything. Also, I'd just gone indie, and making flash games for sponsorship seemed like a realistic way to pay the bills while making the kind of stuff I wanted to make.
Flash's real strength is that it's fantastically accessible and consistent across browsers and computers - you can be pretty sure that whatever you made on your computer will look and run the same on everyone elses.It's weaknesses are mostly to do with what happens when you want to make something that doesn't run in a browser. Which is becoming a real problem now that the future of flash in browsers is in trouble. This is why I finally made the switch to Haxe this year.On Haxe:
I started using Haxe this year, and I wish I'd done it sooner. So far I've used it for two short free games and a bunch of unfinished projects.
Haxe is magical! The idea behind it is really wonderful - by design, it literally has all the advantages of flash, and solves all its problems by having different targets for different needs. I love it.
Haxe's main weakness might be tools on non-windows systems: specifically, that it doesn't have FlashDevelop on Mac and Linux. FlashDevelop (which I use on windows) is a wonderful IDE, easily the best one I've ever used. In writing this beginners programming tutorial, I've had to write variations for people working in other operating systems, and it's just a huge hurdle to not have something as good as FlashDevelop on those systems. I think this is keeping beginners from discovering Haxe.
Before I made the switch from actionscript, I had a perception of Haxe as a hackers programming language, difficult and obscure and inaccessible. I no longer think that's true, which is why I'm writing about Haxe for my beginner's tutorial - I actually thing it's a great place to start if you've never coded before.
The primary strength of the Flash platform is just that Flash runs in a universal(ish) virtual machine. You don’t need to worry about the browser doing anything weird to your game, or the game working differently in different browsers. Any desktop computer running Windows or OSX would run your game in the exact same way. It doesn’t perform well, of course, but that became less and less of an issue as computers got faster.The Flash IDE is nice in its own way. It’s extremely good at producing tiny little files, which matters a lot for web games which often get insane traffic. It has a light vector-animation system that still hasn’t really been surpassed in terms of usability, power and file size. And although it wasn’t designed for making games, it makes a pretty nice visual IDE for designing games very quickly. The downside of the IDE is that it’s an awful environment for writing code in, and it’s a typical bloated Adobe app.
I’m not a real programmer, so I don’t have strong opinions about language strengths and weaknesses. If I can make arrays and iterate over them, and if I can make functions and structs and static variables, I’m completely happy. It’s a nice plus that haxe works reasonably fast and it builds to all the platforms I want to build to. But I don’t really care that much about technical aspects of the language.
Snowkit/Luxe has what I’m looking for in a lightweight engine right now. I want to stick to proper multi-platform engines, and the most popular one is Unity. But there are a lot of projects for which it doesn’t make sense to use Unity—for example, if you’re building to the web or if you’re making a very simple iOS game, or if you care about whether the code still works in a year or two. Luxe fits my needs for all the times I don’t want to use Unity.
Haxe had nothing to do with the decision, but it wasn’t a problem—going from C# to Haxe is extremely easy, as most of the syntax and functionality are the same.
Flash will take a long time to totally die off. Five years hence I bet there will still be flash player content on some major websites. But the transition is well under way.
The good news for developers is that the choice today is nothing like it was five years ago. HTML5 is way more mature, Unity3D has been stomping around on all the major native platforms for years now, and Haxe takes Flash's original cross-platform promise to heights we never even dreamed of before.
My money's personally on Haxe, but in 2015 there's more choices than ever before, and that's the best news of all.
Two things people keep bringing up on twitter:
- Flash isn't dead yet! It's still used in lots of places online.
- Why didn't you mention Adobe AIR?
To which my responses are:
- I agree? Flash is in a slow but steady decline, but it's not gone yet. Still, every signal from Adobe tells me they are no longer invested in the platform.
- Adobe AIR is a great desktop and mobile target -- I used it for Defender's Quest, after all. However, this article is primarily focused on what's happening on the *web*. Also in my mind AIR still counts as Flash, and it seemed obvious to me that developers who are still using flash -- are still using Flash? Those are the two reasons I didn't mention it much in the article. Sorry if that seems like I left something out!