Why Flash Isn’t Totally Irrelevant


It’s no surprise that many people have been bashing Flash for a good while now. There’s lots of talk about “HTML5” out there, and how it’s an all-encompassing, standards-compliant replacement for Flash. True, a number of new capabilities of HTML5 do act as a sufficient replacement for Flash. However, a recent project of mine proved the relevance of Flash via the shortcomings of HTML5 browser support.

The Problem with HTML5

Don’t get me wrong. I like using the new capabilities offered by HTML5. They’re great for building sites for modern browsers, specifically for tablet and mobile devices that never had (or will have) a chance to use Flash. My biggest beef is the fact that everyone thinks it already solves all of the Web’s problems. Everyone seems to think that if you “build something with HTML5”, it’ll automatically push Flash further and further toward irrelevance. Well, I’m here to tell you that this is not (presently) accurate. The truth is that not all browsers support the new features offered by HTML5. And until all of the browsers that don’t support it are phased out, Flash is still relevant and can prove to be very helpful.

The Problem with Flash

I’d be remiss if I didn’t talk about Flash, and point out some of its problems. After all, I’m not arguing that Flash is still the answer, or that you should never use the new capabilities of HTML5. As you’ll see, I believe Flash is still relevant for certain scenarios, probably the foremost being as a backup in browsers that do not handle the new HTML5 elements.

My biggest problem with Flash is how obtrusive it can be on a page. As mentioned in my post Websites Giving Flash a Bad Name, Flash ads have the annoying capability to expand and literally take over a web page. Some expand on mouse click or mouse over, while others auto-expand when the page loads. Either way, it’s annoying, and is one of the main reasons why I stop visiting certain sites.

Along with its obtrusiveness in taking over a page, Flash has become annoying and problematic because so many amateurs learned how to make crappy animated banners with it. We’ve all seen these kinds of banners – dancing babies on an ad for refinancing a mortgage, horribly photoshopped wrinkles on a woman’s face disappearing to advertise a miracle cream, etc. Like many cheap ads (on- and offline), quality and taste are often thrown out the window for noticeability. And while online ads are not all Flash ads, it’s the Flash ones that are the most annoying, largely because they’re animated and can be obtrusive.

The last problem with Flash isn’t even the fault of Flash. It’s the fault of new technologies that don’t support Flash. Any site that relies on Flash for even part of it’s content needs to be reworked (or at least reviewed) to work on tablet and mobile devices that don’t support Flash. While there are ways to handle “no Flash” scenarios, any content that is integral to the page needs to be addressed to work across all browsers and devices.

I can’t say I blame any of the new technologies for not supporting Flash. After all, there’s a strong case for not supporting it based purely on the aforementioned issues with Flash. But as mentioned above, since there are browsers that do not support the new features offered by HTML5, Flash is still very relevant and can prove to be very helpful.

Case in Point: My Web-based Photo Editor

Recently, I have been working on a photo editor utility that includes the ability to load an image (from your local device or an authenticated website), display it for the user, and allow them to scale, rotate, and move the image to crop it before uploading it to a server. HTML5 to the rescue, right? Not quite…

The build initially began with using the <canvas> tag to draw the image. It was great because <canvas> has a lot of cool features that allowed me to rotate and offset the image in the tag. Easy peasy. Problem solved…until Internet Explorer was used.

Once we started integrating my work into full-fledged websites and began cross-browser testing, we immediately noticed that IE was giving us a huge headache. Actually, it was giving us two headaches.

  1. Pre-IE9 browsers don’t support HTML5’s <canvas> tag. And given the need to read the image data from the <canvas> so we could pass it along to the server for upload, using a solution like ExplorerCanvas wasn’t plausible (since image data methods aren’t supported).
  2. IE lacks support of the File API, which was needed for the use of FileReader, which allows web applications to read the contents of a local file. Without the ability to read a local file from a user’s device, we had no way to display the image for the user, other than temporarily uploading the image and then loading the uploaded image (not a great solution by any means).

With these two big technical hurdles in front of the team, we really only had one choice: Use Flash as a backup for loading and displaying the image for the user, when <canvas> or the File API weren’t available.

Within a couple of hours, I was able to build a quick Flash file that used the FileReference class to successfully load a local image and display it for the user, allowing for complete scale, rotate and move capabilities just like the <canvas> version. Then, I added in some JavaScript logic that either displayed the <canvas> version of the photo editor, or the Flash version, all based purely on the capabilities of the user’s browser. As an added bonus, the custom controls I had created for scaling and rotating the image were still able to be used for the Flash backup version, through the use of Flash’s ExternalInterface class and the ability for JavaScript to communicate with Flash and vice versa.

HTML5 is Great, but Flash is Still Useful.

HTML5 elements provided a great way to implement my photo editor utility in most browsers, but thanks to Internet Explorer, the “Flash killing” capabilities of HTML5 were rendered utterly useless for an across-the-board solution. In the end, the best solution was to use Flash as a backup in older browsers that didn’t support the capabilities we needed. And you know what? It works like a charm.

So until the day when all browsers support the same standard set of capabilities, at least regarding some of the most useful HTML5 ones, Flash shouldn’t be the enemy. It can still be a very useful ally in the fight for complete cross-browser control.

Until next time, happy coding!

There are no comments yet, add one below.

Leave a Comment