Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 23, 2014
arrowPress Releases
October 23, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Not Flash! The (Still) Angsty Zeitgeist Of HTML5 Technology Burnout
by Steve Fulton on 09/26/12 11:35:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


(Note: I published this a couple months ago on, but after a conversation I had earlier this week I realized that it still true today, so I'm reprinting it here).

More than two years ago we (at started taking a close look at HTML5.  To us, the  HTML5 features like canvas, audio, and video were the most compelling part of the HTML5 spec because they were poised to be a true replacements for Flash.   Flash had been our tool of choice for over a decade because it worked....most of the time.   For the corporate web, 'entertainment, media, gaming web sites, it was second to none.  Sure, it had issues: security flaws, proprietary API walls, performance hang-ups, etc. but it was also a simple platform.  Write your AS3, marry it to assets created by designers in .fla, export .swf, done.   A simple process for a powerful technology.

All was right with the world.

Up until last November, it is our firm belief that most Flash Web developers were holding out for Flash support on mobile iOS browsers.     "Apple will come around" we thought, "Flash will run in the iPad 3 and the iPhone 5" we fantasized.  Not because we thought Flash was perfect, or because we did not like the idea of HTML5, but because, for more than decade we had tasted what a real "standard" might be like.    We've heard about "web standards" for years, and they are a beautiful,  poetic, amazing concept that never quite came to fruition because OS, browser and platform companies had their own ideas on what was standard and what was not.  However, with Flash, we truly had ate from the "write once, run nearly everywhere" table we had been hearing about for so many years.

Then last October, Abobe gave up the mobile web, and all hell broke loose.

Web standard guys applauded it, and Flash guys continued the hand wringing operations they started back in 2010 when Apple announced the iPad would not have Flash support.    Not too long after, It seemed, all at once, the rush was on for HTML5.   Flash developers knew they needed to move on, and web standards people had their last stumbling block removed.  The plug-in-less HTML Renaissance had begun.

But then something weird happened.  Even though, when we said the phrase  "HTML5" we were talking about canvas, video, ausio, local storage, geolocation, and new mark-up standards,   we noticed that when customers asked for HTML5, they had no idea what was part of the actual HTML5 spec.  When we talked to other game developers about HTML5, some had never used any specific HTML5 features.   They were using traditional web technologies like HTML, JavaScript, DOM, CSS.   In fact, in many cases the only true "HTML5" they were incorporating was the  audio tag, and most of the time, it wasn't doing what they wanted it to do.   While features like the HTML5 Canvas are growing in use as mobile browsers get more powerful, it turned out that HTML5 meant many things  to many developers, and that did not always include the actual features of HTML5 once outlined by the W3C.

So then what *is* HTML5?  The W3C HTML5 FAQ  says this about HTML5:

HTML5 is an open platform developed under royalty free licensing terms. People use the term HTML5 in two ways:

What we have learned through conversations and project work in the past few months is that, to the common person who does not follow this closely, (or more likely, the common customer who needs something done right away) it's all HTML5,and therefore they are really referring to the "Open Web Platform".  In this way, HTML5 is just as much and "idea" as it  is a strict specification, and that "idea" of the "Open Web Platform"  has caught-on like wildfire, even if the borders that define what is actually included in "HTML5"  have never been fuzzier.  However, the one thing we do know is that at the kickoff party for the "Open Web Platform", the one technology that was definitely left of the invite list was Adobe Flash.

But who was invited to this "Open Web Platform Party?"  Well of course  HTML5,  CSS and DOM plus  SVGWeb WorkersWeb Storage, Geolocation,  and Web Sockets.  Then experimental stuff like the  Web Audio API,  and Media Capture...and that just scratches the surface at the W3C.   We also need to add  JavaScript and WebGLWebKit, which are run by other organizations but are just as important.  Then we have  Modernizr  and the king of JavaScript APIs, JQuery.  JQuery is so popular, in fact, there appear to be entire religions formed around it.  JQuery adds  JQuery UI and  JQuery Mobile . In fact, Some people have told us that we will never need any thing  else, if we just decide use the JQuery suite.    Really?  That would leave out  all these other technologies we keep hearing about like  MooTools, ExtJSSencha Touch,Ripple,  JQMobiJo JoshFireInuit,  LungoJS  and the Dojo toolkit.  Those seem pretty cool too and they all claim to solve the same  HTML5 cross-platform issues.   But then, so do  DOM/CSS tools and templates like   HTML5Boilerplate,  Initializr,BootstrapCrafty.DOMLESS, 960Blueprint52 FrameworkGravity GridlessSkeletonG5 and many others.    At the same time, if you want to make,  "HTML5 games" there are a whole different set of technologies to consider  like Construct 2CreateJS (now with more Adobe), Game MakerKineticJSProcessing.jsImpactJSLimeJSJawsBox2SJS, CasualJS,  Cocos2DEntityJSGameJS, GMPIsogenicPlayNPropulsionJSMibbuSprite.js and many more plus WebGL libraries likeSpiderGLGLGECopperlicht andSceneJS.   Then there are JavaScript media libraries like VideoJS,MediaElementJS,  Kaltura HTML5 Media LibraryJukebox,  Buzz audio library, and Popcorn.js,   Plus other tools like RGraph for graphing,  Mashi for timeline animation, BakerFramework for ebooks  or  Pixtastic for real-time image filters. And we can't forget the HTML5 app hosting and development platforms like AppMobi, Spaceport.ioFunSockets,Turbulenz and Pixie Engine or the fact that we can package up all this stuff and make them into mobile apps with  phoneGap,  or Appcelerator, or Apache Cordova.   And if you want to take your JavaScript all the way to the server-side, well then node.js  and Kinvey are just for you!  A lot of these technologies claim to be "only" way to go, so which do we choose?

And then we need to mention the platforms and devices.  Just a few years ago, we all wrote apps for Firefox, I.E. and maybe Safari, but only if you were a glutton for punishment.     Now we have to consider multiple versions of Internet Explorer, Chrome, Safari, Mobile Safari, Firefox, Opera, Silk,  the 30 or so combinations of iOS devices and operating systems, and 1000's of Android device and OS combinations.   To further complicate matters the general consensus, at least among customers,  is  that web apps made with  "HTML5 open Web Platform"   should run perfectly across all of them.   But they don't.   In fact some of the snazzier HTML5 features such as audio and video don't work consistently on mobile browsers.  It's the reason many HTML5 games targeted at mobile game portals have done away with sound altogether.

In the past couple months, an angsty zeitgeist has appeared to form like a cloud around the "HTML5 Open Web Platform".    It's the feeling of technology burnout for developers, while at the same time they try to manage the expectations of customers who are clamoring for a one-size-fits-all solution to their web and mobile development needs. Our own cartoon on the subject was a minor hit for us:

And the feeling might be spreading. One of my favorite posts in the past few months, was  the hilarious parody technology site HTML9ResponsiveBoilerStrapJS.  It captures the feeling of HTML5 technology burnout perfectly and scored a sizable hit via twitter:

"H9RBS.js (v0.0001) is a flexible, dependency-free, lightweight, device-agnostic, modular, baked-in, component framework MVC library shoelacestrap to help you kickstart your responsive CSS-based app architecture backbone kitchensink tweetybirds."

To us, the buzzwords are flying left and right, and everyone seems to be trying to solve  similar problems by creating multiple new technologies and tools.    On one side, this is a very cool development.  It's an evolution and revolution, and we are happy to be part of this mini-tech bubble that has moved-in to fill the gulf left by Adobe when they abandoned the mobile web. On the other had,  the sheer amount of "new" around HTML5, be it ways to describe code, templates, technologies and platforms is dizzyingly overwhelming.  The situation is confusing at best, and confounding at the worst.   Furthermore, most " tech bubbles" are inevitably followed by a shake-out where dozens of also-rans fall by the way side (Remember when Flash put DHTML, Silverlight, Applets, JavaFX, VRML, Realplayer and Shockwave off the map?). For developers, this means being very careful to choose technologies that we believe will be around for the long-haul, or we run the risk of investing our limited time and resources into something we will never use again.

All we really know right now, is that when people ask for "HTML5", they don't always have a specific technology in mind and they probably have not read the W3C spec of what is actually in "HTML5".   They might know a bit about things they perceive to be HTML5 like  CSS3 or Webkit, Canvas or video, but that's not really important.  What's important is the translation of the question.  When they ask for "HTML5", they are probably saying they want a single web site or app that runs on all devices, mobile or otherwise and that then translates into this:

"Not Flash"

And to developers who were once comfortable using Flash as a cross platform silver bullet, that could mean wading through a whole lot of specs, tools,  and APIs of the "Open Web Platform" before the proper solution is found for the project.

So, when you call us now and ask for a game, site, app, etc. in HTML5, and there is slight pause in the conversation before we give you an answer, it's not because we are bored,  disinterested or distracted, it's because we have a few extra things to consider these days before we can  formulate a proper response.   If you give us a few minutes to catch our breath, we promise, the end result will be awesome.

We appreciate your patience.

Related Jobs

WB Games
WB Games — Kirkland, Washington, United States

Principal Technical Artist
Demiurge Studios, Inc.
Demiurge Studios, Inc. — Cambridge, Massachusetts, United States

Senior Software Engineer
CCP — Newcastle, England, United Kingdom

Senior Backend Programmer
Guerrilla Games
Guerrilla Games — Amsterdam, Netherlands

Animation System Programmer


Muir Freeland
profile image
As a developer, I've always felt that the hate for Flash is mostly unfounded. Hearing complaints about how it drains battery life on mobile (just like native games!) or how it's bad because it's proprietary (when it's much more open and universal than, say, Cocoa) always made me feel like the whole thing started off political and then somehow reached mainstream awareness without that same mainstream fully understanding it.

k s
profile image
I've never worked in Flash but neither do I hate it nor do I understand some people's hate for it.

Chris Hendricks
profile image
I think that misuse of Flash did a lot to give itself a bad name among the mainstream. For many, Flash is most associated with horrible banner ads that pretend to be entertaining, and due to the distinctive menu that comes up when right-clicking, it's easy to see who the culprit of those ads is.

I agree that Flash's hate is largely undeserved, though.

Chris Melby
profile image
Well said.

@Chris H.,
Don't blame the tool, blame the abuser(s). ;)

Benjamin Delacour
profile image
The specific statements you speak of, being proprietary and draining battery, were spearheaded by Apple. It's in Apple's interest to have proprietary systems, and Flash enabled too much cross platform development (especially of games). While claiming battery life issues and it being a proprietary web technology as a reason to avoid Flash, Apple was able to further increase the proprietary nature of their phones and pads. There was no lack of knowledge that HTML5 isn't a drop-in replacement for Flash. Apple knows it's business and has gained the largest app collection quite deftly.

Luke Lam
profile image
Nicely written.

Lars Doucet
profile image
Preach it. Amen.

Rey Samonte
profile image
No mention of Adobe AIR which I've used to deploy onto iOS and Android devices?

Chris Melby
profile image
AIR has evolved into a very viable and fantastic platform. I'm really happy with the strides Adobe has made with it and shifted back to it(Flash in general.) from iOS and Java late last year.

I've been able to sell it over HTML5 for my enterprise clients, because it lowers the cost of development and by educating them to what HTML5 is and what it isn't.

Steve Fulton
profile image
I love Air, and I use it every day to export to iOS, Android, and Kindle Fire. However, this was specifically about HTML5. Air solves problems, HTML5 seems to create more :)

Eric McQuiggan
profile image
I also use air every day, it's fantastic, though a bit better for android at the moment.

HTML5 had a bunch of people running around here with their hair on fire, it seemed like everything settled down before the ship had to turn.

Steve Fulton
profile image
I'm really impressed with Air on the Kindle Fire too.
Air on the Nook though has been giving me fits.

profile image
I look at it from a consumers point of view (because I'm not in a developers role) and I understand that what you are talking about with the "open web" is a series of tools that are use to solve bottleneck problems that could best be served by just a few tools. I also guess you are also saying that there was a time that many of the problems could be solved in Flash which no longer seems to be a standard of the "open web" suite anymore. So now where you may have had a workforce of a few people that could solve a lot of problems using a few tools, you now have to find and contract lots of different programers that understand one type of tool to solve a series of problems over another. Using all those different types of tools could help solve a problem with one device that will in turn create another problem on a different device. It sounds like a nightmare case for development across multiple devices.

I don't know how your company operates as to say if you are a middle type company that solves problems for much larger companies that make product for cross platforms or if you are a singular company that produces a few products from start to finish on just a hand full of platforms. I'm assuming the former. Would it be to hard to just niche your workforce into smaller teams who can then use and master a few types of tools to create games, sites, etc. or do you have to constantly learn many tool uses to sustain profitability.

Steve Fulton
profile image
We are just a small company that works contracts while we toil on our own apps and games. This issues arises with some of our old customers who relied on Flash, but now are scared of it and want a similar magic bullet from HTML5. It's not easy to get them to understand that while HTML5 may one day replace Flash on the web and mobile web, it's not a drop-in substitute for Flash in any way right now.

Roger Tober
profile image
I think a lot of people are waiting for the html5 engine/development kit that will take care of all the problems associated with html5. Impact looks interesting from a game standpoint to me, since that's all I'm interested in.

Steve Fulton
profile image
I agree. ImpactJS looks good. I hold also hold out hope for Grant Skinner's EaselJS.

Pete Otaqui
profile image
I've written a response to this article (which I'm afraid wasn't especially complimentary) titled "HTML 5 Burnout? Or just a lazy Flash guy?" here:

Steve Fulton
profile image
I like your response, but I think you missed the point of the story. It was not “Flash vs HTML5″ but instead it was about coming to grips with the fact that when customers ask for “HTML5″ they are asking for “not Flash”, and that means we as developers have a whole bunch of choices to make since “HTML5″ is not the drop-in replacement for Flash that customers might think it is.