作者：Steve Fulton

我们是从2年前开始密切关注HTML5。对于我们来说，canvas，音频和视频便是HTML5规格中最引人瞩目的部分，因为它们正蓄势待发地准备攻占Flash。Flash是我们在过去十年间一直依赖的工具，因为在大多数情况下它都能够发挥重要的功效。对于公司网站，娱乐，媒体以及游戏网站来说，这都是最佳选择。当然了，它也存在一定的问题，包括安全缺陷，专有API墙，性能漏洞等。不过不管怎么说这都算得上是一个非常简单的平台。开发者只需要编写AS3（游戏邦注：Flash的脚本语言），并将其与设计师基于.fla, export .swf所创造的资产结合在一起便算完成任务了。所以说这一强大的技术具有一个非常简单的执行过程。

HTML5(from W3.org)

与世界同步。

直到去年11月，我们才最终坚定了我们的信念，也就是大多数Flash网页开发者将面向手机iOS浏览器继续坚持着对于Flash的执着。我们幻想着：“Flash将进入iPad 3以及iPhone 5中。”这并不是因为我们认为Flash有多完善，或者我们不喜欢HTML5，而是在过去10年间我们真正品尝到了什么才是真正的“标准”。我们经常会听到“网页标准”这一说法，这的确是一个非常棒的理念，但是因为操作系统，浏览器以及平台公司都有自己对于标准的定义，所以这一理念始终未能成真。但是多年来我们已经习惯了Flash所具有的“一编写便能够运行于任何地方”的标准。

去年十月，当Abobe宣布放弃对手机网页的支持时，天下瞬间大乱了。

当苹果宣称iPad将不再支持Flash时，标准网页开发者顿时拍手叫好，而Flash开发者则只能继续回归他们在2010年所开始的手动操作。似乎再过不久，HTML5即将迎来发展高潮。Flash开发者知道自己必须向前发展，而标准网页开发者则扫除了自己的最后障碍。插入式HTML的复兴正式拉开了序幕。

但是很奇怪的是，当我们提到“HTML5”我们自然会想到canvas，视频，音频，局部存储器，定位以及新标准，但是我们却发现用户并不清楚真正的HTML5规格到底是指什么。当我们向其他游戏开发者提及HTML5时，有的甚至从未使用过任何特定的HTML5功能。他们一般都是使用传统的网页技术，如HTML，JavaScript，DOM，CSS等。实际上，很多情况下他们真正接触到的只是有关“HTML5”的音频标签，但是结果却往往不如他们所想象的那样。尽管像HTML5的canvas功能正在逐渐强大，但是最终对于许多开发者来说，HTML5所具有的功能并不像W3C上所描写的那般强大。

所以真正HTML5到底是怎样的？以下是W3C大会上关于HTML5的描述：

HTML5是免版税许可条款下一个开放性平台。人们可以在两种情况下使用HTML5这一术语：

当提及组成未来开放性网页平台的一组技术时。而这些技术便包含了HTML5规格， CSS3，SVG，MathML，Geolocation，XmlHttpRequest，Context 2D以及Web Fonts（WOFF）等。随着时间的发展这些技术之间所存在的界限也在不断地发生变化。

当提及HTML5规格时，当然了，它也是开放性网页平台的组成部分。

在过去几个月时间里我们在各种交谈与项目开发中了解到，对于那些不熟悉HTML5的人来说，HTML5也就等同于“开放性网页平台”。基于这点，HTML5就像是一个具有明确规格的“理念”，而关于“开放性网页平台”的理念却变成了“野火”般的存在，即使“HTML5”中所包含的界限定义已经非常明确了。但是我们还需要注意的一点是，在“开放性网页平台”的开幕式派对上并未邀请“Adobe Flash”这一技术。

而又有那些技术收到了“开放性网页平台”派对的邀请函呢？其中当然包含了HTML5，CSS，DOM，SVG，Web Workers，Web Storage，Geolocation以及Web Sockets。还有一些候补名单包括Web Audio API以及Media Capture（在W3C上初次亮相）。我们还需要添加JavaScript，WebGL以及WebKit（运行于其它结构，但同样也非常重要）。随后我们还将迎来Modernizr以及JavaScript APIs和JQuery。JQuery非常受欢迎，甚至围绕着这一技术已经形成了一个完整的理念。JQuery将添加JQuery UI和JQuery Mobile。有人曾经跟我们说过，如果我们使用JQuery组合，我们便不需要再使用其它技术了。真的是这样吗？如此我们便可以忽略我们所听到的其它技术，包括MooTools, ExtJS, Sencha Touch,Ripple,  JQMobi, Jo JoshFire, Inuit,  LungoJS和the Dojo toolkit。而这些技术听起来也都很棒，并且同样也能够解决HTML5所存在的跨平台问题。DOM/CSS工具和HTML5Boilerplate,  Initializr,Bootstrap, Crafty.DOM, LESS, 960, Blueprint, 52 Framework, Gravity,  Gridless, Skeleton, G5等模版亦是如此。除此之外，“HTML5游戏”中也有许多值得考虑的技术，像Construct 2，Create JS，Game Maker, KineticJS, Processing.js, ImpactJS, LimeJS, Jaws, Box2SJS, CasualJS,  Cocos2D, EntityJS, GameJS, GMP, Isogenic, PlayN, PropulsionJS, Mibbu, Sprite.js and many more plus WebGL libraries likeSpiderGL, GLGE, Copperlicht以及SceneJS。随后还有JavaScript媒体库，像VideoJS,MediaElementJS,  Kaltura HTML5 Media Library, Jukebox,  Buzz audio library以及Popcorn.js，还有其它像RGraph for graphing,  Mashi for timeline animation, BakerFramework for ebooks或者Pixtastic（实时图像过滤器）等工具。我们同样也不能忘记HTML5应用程序托管和开发平台，如AppMobi, Spaceport.io, FunSockets,Turbulenz和Pixie Engine，或者我们可以将它们整合在一起并使用phoneGap, Appcelerator或Apache Cordova等工具将其带进手机应用中。如果你想要将JavaScript带进服务器端中，那么node.js和Kinvey便非常有帮助。许多技术都宣称自己是“唯一”可行的方法，那么我们该如何进行选择？

我们还需要提及平台和设备。几年前，我们还是面向火狐，IE或者Safari编写应用，而现在已经有更多不同的浏览器摆在我们面前，包括IE，Chrome，Safari，Mobile Safari，火狐，Opera，Silk等30多种浏览器，除此之外还包含了iOS设备和操作系统以及1000多种Android设备和操作系统。更糟糕的是，很多人都认为（至少是用户间）基于“HTML5开放性网页平台”的应用必须能够同时运行于所有的这些平台上。但是事实上却不是这样。就像最流行的HTML5音频和视频功能便不适用于手机浏览器上。这便是为何许多HTML5游戏在面向手机端口时都删除了声音的主要原因。

在过去几个月里，“HTML5开放性网页平台”被时代精神之云深深笼罩着。对于开发者来说这是一种技术爆炸，而与此同时他们还必须想办法应对顾客的期望——迫切希望看到网页和手机开发所需要的最万全的解决方法。关于这一主题所绘制的这张连环画便为我们带来了小小的冲击：

customer and developer（from gamasutra）

这种感觉有可能会继续延伸。在过去几个月里我最喜欢的几篇文章都是来自技术类网站HTML9ResponsiveBoilerStrapJS。它有效地呈现出了HTML5技术的爆炸性发展并通过twitter掀起了一股较大的热潮：

“H9RBS.js (v0.0001)是一个灵活，独立，轻便，不依赖于设备，且带有标准组件的组件框架MVC库，能够帮助你有效地启动基于CSS的响应式应用程序架构。”

似乎每个人都在通过创造各种新技术和工具去解决类似的问题。不得不承认的是，这是一次非常棒的进步。这是伟大的进步与发展，我们很高兴能够成为这一小小的技术泡沫中的一份子，并努力去填补Adobe抛弃手机网页时所留下的裂痕。另一方面，围绕着HTML5的大量“新”元素在描写代码，模版，技术和平台等方面也具有巨大的功效。最好的情况便是只会让用户感到困惑，而最糟糕的情况则是会让他们完全混淆所有内容。此外，大量的“技术泡沫”将一个接一个涌现出来，而与此同时也会出现更多不可避免的失败者（还记得Flash是何时将DHTML，Silverlight，Applets，JavaFX，VRML，Realplayer以及Shockwave等排挤出去的吗？）。也就是对于开发者来说他们需要非常谨慎地挑选能够长存的技术，或者冒险将有限的时间和资源投入于一些不会再次使用的技术。

我们都知道，当人们问及“HTML5”时，他们心中并未明确一个特定的技术，他们甚至不清楚“HTML5”中的W3C标准。他们理解中的HTML5可能也就是CSS3或Webkit，canvas或视频之类，但是事实上这些却不是真正重要的内容。更重要的应该是问题的转化。当他们问及“HTML5”时，他们可能是想要一个能够运行于所有设备或手机上的单一网站或应用，而我们可以将这一意思转化成：

“不要Flash”

对于那些曾将Flash当成跨平台的有力武器的开发者来说，这便意味着他们必须经历“开放性网页平台”的标准，工具和API等才能最终找到最合适的解决方法。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Not Flash! The (Still) Angsty Zeitgeist Of HTML5 Technology Burnout

by Steve Fulton

More than two years ago we (at 8bitrocket.com) 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, audio, 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:

to refer to a set of technologies that together form the future Open Web Platform. These technologies include HTML5 specification, CSS3, SVG, MathML, Geolocation, XmlHttpRequest, Context 2D, Web Fonts (WOFF) and others. The boundary of this set of technologies is informal and changes over time.

to refer to the HTML5 specification, which is, of course, also part of the Open Web Platform.

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  SVG, Web Workers, Web 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 WebGL, WebKit, 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, ExtJS, Sencha Touch,Ripple,  JQMobi, Jo JoshFire, Inuit,  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,Bootstrap, Crafty.DOM, LESS, 960, Blueprint, 52 Framework, Gravity,  Gridless, Skeleton, G5 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 2, CreateJS (now with more Adobe), Game Maker, KineticJS, Processing.js, ImpactJS, LimeJS, Jaws, Box2SJS, CasualJS,  Cocos2D, EntityJS, GameJS, GMP, Isogenic, PlayN, PropulsionJS, Mibbu, Sprite.js and many more plus WebGL libraries likeSpiderGL, GLGE, Copperlicht andSceneJS.   Then there are JavaScript media libraries like VideoJS,MediaElementJS,  Kaltura HTML5 Media Library, Jukebox,  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.io, FunSockets,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. (source:GAMASUTRA)