HTML5笔记(3) - HTML5现状

 

前言：每一种新技术刚展现在人们面前时，人们总是习惯于从技术特性的角度（而不是用户需求）来考虑，能用它来做些什么。人们会先用它来重写已有的应用，或实现其它技术已经能实现的功能。这是一个必要的探索和积累阶段。有些技术在经历了这个阶段之后会得到蓬勃发展，另外一些技术则像拿到了一把新的锤子到处敲敲打打，结果发现它还是一把锤子，未免失望。

 

1. Demo

 

关于HTML5已经有很多Demo和教程网站了，还有很多基于HTML5创建的开源项目，甚至《纽约时报》也已经有了HTML5版本：http://www.nytimes.com/skimmer/。

 

最早的时候我到 http://html5demos.com/ 这个网站看HTML5的新功能，边看边猜，然后对照着W3C的规范看。 http://diveintohtml5.org/ 是一个版式设计很有意思的网站，假如你对W3C的一些比较简洁严谨的描述存疑的话，在这里或许会找到满意的解释。此外还有 w3school 等数不清的教程网站，提供大量范例。

 

我也玩了一些HTML5编写的网页游戏，包括在桌面电脑和手机上运行的，以及一些比较炫目的HTML5设计（例如网页的模板、控件等），一方面我暗暗惊讶于HTML5的强大，一方面也难免心生些许困惑：Is that all? What else? 或许是因为我还没看见一个杀手级别的HTML5应用，类似iPhone的出现相对于同时代其它整个手机的意义。

 

2. 从技术角度看

 

从技术的角度来看，HTML5所带来的好处是毋庸置疑的，尤其在数量和功能都剧增的移动设备平台（很多机构和分析文章都预测，在不久的将来，移动设备在数量上将超过桌面设备，成为人们互联网接入的第一选择）；在网上搜一搜，各种赞美之声也是“罄竹难书”，那么我们就反过来看一看，想一想，HTML5的这些新特性是否仍有不足之处，或者在使用上有哪些陷阱——尤其是针对移动设备而言。

 

（从这里可以看到一个HTML5相比其前任的增减： http://www.w3.org/TR/html5-diff/。）

 

从HTML5新增的元素开始吧，这一部分貌似最简单。

 

【HTML5新增排版元素】

 

在HTML5以前的岁月里，我们一般通过<div>等标签来给一个网页文档划分不同区域块，HTML5则定义了一些新的、能够望文生义的基本语义来定义一片文档的不同区域：<section> <header> <footer> <nav> <article> <aside> <figure>。这个有点类似高级语言中的基本类库：以前我们需要自己定义什么是header和footer，最麻烦之处还在于每个网站定义的风格都各不相同，现在HTML5统一了语法和语义，一来节省开发者的时间和精力，二来也提供了相对统一的用户体验。

 

随之而来的问题是，开发者们何时可以自由的使用这些新标签？因为用户必须升级自己的浏览器（很多用户甚至不知道如何升级），才能看到设计者所期望的效果。这可不是一件简单的事情，稍有经验的网页开发人员肯定忘不了IE6时代各家浏览器之间的不兼容噩梦，于是你必须得在代码里探测用户使用的是什么浏览器，然后提供不同实现。任何一家有稳定用户流量的网站都不会轻易为了尝试新技术而承担老用户因兼容性问题而流失的后果。

 

或许随着时间的推移（例如Windows 7盗版的流行）这个问题会轻而易举的解决掉，另外也有一些牛x的洋人提供了一些解决兼容性问题的技术方案：“How to get HTML5 working in IE and Firefox 2” http://html5doctor.com/how-to-get-html5-working-in-ie-and-firefox-2/

 

【video/audio】

 

如果投票的话，<video>或许能成为人们最耳熟能详的HTML5新特性之一，因为乔布斯说有了HTML5 Video我们还要Flash干什么？可是可是，还没来得及高兴起来的开发者们一定发现了一堆头疼的问题，其中以视频格式为甚。这是W3C制定规范时，各大浏览器厂商们没法解决的问题，主要因为不同的视频格式涉及到不同的专利费用和版权问题。

 

简单的说有两大阵营：H.264和WebM（或者你更熟悉On2 VP8），Apple和微软属于前者，因为它们部分拥有其版权；Google和Mozilla属于后者，尽管后者也可能存在版权问题，但财大气粗的Google已经将其买断并开源了，同时声称开发者遇到的版权问题都可以交由它来搞定。Google甚至声称在Chrome的 HTML5 <video> 标签中放弃对 H.264 格式的支持。

 

这样一来小站长们就很难决定如何提供视频支持，或者这正是像亚马逊这类提供“云”的巨头公司所乐见其成的吧。用户们更是只有被绑架的份儿了。

 

所以平台的统一一直是人们追求的目标，或许永远只是一个目标。在巴别塔的故事里，上帝不就故意让人们说不一样的语言吗？

 

【canvas】

 

HTML5新增的Canvas接口是一大利器，让开发者们（尤其是在游戏领域）感到欢欣鼓舞，这相当于在浏览器（或HTML5引擎）这一级别向上层应用提供了OS操作系统的绘图接口。尽管不如本地应用直接操作图形库库那样强大，但也足以应付很多用例场景了。

 

性能应该是Canvas绘图面临的最大问题，这与本地应用（例如游戏）应该是类似的。本地应用一般直接调用图形库文件的接口，而在HTML5的世界里，网页应用是需要通过JavaScript来调用绘图API的，理论上性能就会有所下降。好在我们有硬件加速，主流浏览器也正在朝这个方向发展，例如IE9宣扬自己比别的浏览器快多少多少倍，实际上主要是硬件加速的结果。

 

在一些细微的问题上，我们可能还需要为不同浏览器的适配而头疼，毕竟没法保证不同厂商对于canvas的实现效果是完全一致的。如果有一天，我们辛辛苦苦写了一个HTML5游戏，发布之后还得分Chrome版本和IE9版本，那就太有讽刺效果了。

 

另外一个问题是，我们还需要一些性能强、稳定性高的HTML5的JS图形库（或框架），尤其是在移动平台上。毕竟开发者们都不希望自己的代码充满了大量的drawLine、drawText等基础操作。

 

【Web Socket】

 

这也是开发者们津津乐道的新特性之一，客户端可以利用WebSocket协议和主机进行双向通信（支持TLS加密），比XmlHttpRequest更加强大、高效和减少流量，这是因为WebSocket协议在建立连接之后，其交互报文中不再携带HTTP Header这类重复性信息。一个显而易见的好处是，客户端无需轮询就能获得服务器端发起的通知，类似于Push功能。WebSocket的客户端实现在各大操作系统上应该都是基于Socket的，至少在WebKit是如此；它对于服务器端则提出了比HTTP更高的性能上的要求，因为它本质上毕竟是一个“长连接”。

 

很多WebSocket的示例代码里只是简单的和服务器交互了一下几个单词，但这离Web Socket的“强大功能”还差得较远。在实际应用中你需要面对更复杂的网络环境和用例，你需要考虑如何协商超时，如何通过保活（keep-alive ）消息来维持连接，如何应对网络（例如WiFi）的忽然中断，甚至服务器重启...更详细的信息可以看看《Is WebSocket Chat Simple?》一文中提到的问题：http://cometdaily.com/2010/03/02/is-websocket-chat-simple/。

 

所以我们可能还需要一个网络接口库——类似于图形库那样的一个东西，以便让应用开发者们能把精力集中在应用及其功能的实现上，而不是通信层的一些基本的逻辑和错误处理机制。

 

到目前为止似乎还没看到令人耳目一新的WebSocket应用案例，足以配得上它出来之前的千呼万唤。我在想这个新特性其实更多是给服务器端、或是“云”端使用的，也就是那些“大家伙”们。功能和接口定义都在网络侧，而客户端的“强大”不过依赖于云端的功能定义。这倒也十分符合当前SNS、电子商务等开放平台的设计和开发理念。让我们拭目以待吧。

 

【Local Storage 本地存储】

 

这是另外一个被津津乐道的新特性。最早有人向我介绍的时候说的是，浏览器从此可以离线浏览网页了。当时一知半解，似懂非懂，没想明白技术上是怎么一回事。后来才知道，本地存储以key/value的方式实现，实际上由两部分组成：sessionStorage与localStorage，前者用于存储一个会话（session）中的数据，这些数据可供同一个会话中的不同页面访问，并且当会话结束后数据也随之销毁，因此它不是一种持久化的本地存储。 localStorage用于持久化的本地存储，除非应用主动删除，否则数据是是不会过期的。

 

简单的说，前者更注重于保存应用的“状态”，是对Cookie的缺陷的改进；而后者则相当于浏览器（HTML5引擎）对上层应用提供了数据串行化的接口。

 

HTML5网页或应用如果对Local Storage使用不当，就可能会在用户的本地磁盘上留下越来越多的垃圾数据；还得有错误处理机制来处理文件部分损坏的情况；另外可能还有安全性问题，例如某些重要的密码被保存在本地，其它恶意程序就能获取...总之本地存储这一新特性为开发者打开了一扇门，随之而来的肯定会有各种问题，我们只能寄希望于它自身的完善。

 

【Web Worker】

 

在HTML5之前，JavaScript引擎一般都是单线程运行的，浏览器无论在什么时候都只有一个线程在运行JavaScript程序。所以我们可以简单的把Web Worker理解为JavaScript的多线程机制。

 

Web Worker的基本原理就是在当前javascript的主线程中，使用Worker类独开一个新的线程，来执行一段与界面操作无关的代码（通常会占用一定CPU，消耗一定内存），达到不阻塞UI线程的目的，并且提供主线程和新线程之间数据交换的接口。这个貌似比较偏门和高级，所以在各种Demo中露面的机会不如Web Socket和Local Storage。

 

Web Worker一旦滥用就会导致糟糕的用户体验，例如开发者在硬件配置高的机器上开发出来的应用，Worker或许还能在CPU满负荷的情况下正常工作，但换在配置稍低的机器上运行可能就会奇慢无比，“该程序无响应”一类的提示就会如噩梦般时时出现...

 

3. 双刃剑

 

由此我们大概可以看出，随着HTML5功能的增强，它对开发者的要求也就更高；同时由于更大浏览器/HTML引擎厂商对标准的实现也不尽相同，开发者们就会面临多平台反复调试和适配的问题。

 

这是一个普遍性的问题。任何应用或平台提供的功能越多，复杂度就会更高（意味着开发门槛的提高），带来的问题也会更多，趋于稳定的周期就会更长。Flash就是那样一个庞大的跨平台系统，尽管它也有这样那样的问题，但不可否认的是，很多时候其实是Flash应用本身写得太糟糕（很多大公司的Flash应用是既炫又流畅的），占用了过多的CPU和内存，而导致系统缓慢。

 

换句话说，平台的开发复杂度越高，体验糟糕的应用就会越多，系统出现问题的概率就越大——虽然其功能也会越强大。这是一把双刃剑。

 

4. 开发者们在做什么

 

目前网上已经有不少的HTML5演示代码，甚至商用网页了。或许是因为仍处于起步阶段的缘故，我们看到的更多是一些分散的特性，而不是浑然一体的一只大象。HTML技术的奇妙之处就在于，人们永远可以基于现有的、成熟的、分散的技术，来组合实现强大的功能，就好象HTML4+CSS+AJAX+JSON+...这些组合一样，所以我们也有理由相信，几年之后HTML5的成熟应用所展示出来的功能和效果，或许会让人们忘记它和本地应用之间的差别。

 

那么现在开发者们都在做些什么呢？从我接触到的一些身边的一些HTML爱好者，开源社区的开发者，论坛的技术人员...等来看，大致有以下几类（有些分类不太严格，毕竟大家都处于摸索阶段）：

 

1）框架，或者引擎

 

如前所述，HTML5确实定义了不少新接口，但就如同不是任何网络应用开发者都希望自己直接操作Socket一样，开发者们肯定希望基于一套功能强大且性能稳定的库来开发自己的应用。像游戏这类开发，人们就需要一个引擎，从而把更多精力放在内容和逻辑的创建上。

 

HTML4时代就有很多著名的JS框架/库，例如Prototype、jQuery等（虽然都号称轻量级，但在Galaxy I9000这种级别的手机上运行起来仍然气喘吁吁，甚至会crash）。现在很多公司也在提供自己的游戏引擎，或是扩展支持HTML5新接口，或是改写以前用于桌面平台的框架/库，使其更适合移动设备...等等。

 

2）与特定的操作系统整合

 

毕竟HTML5只是一套标准，各个平台实现基本不一样，有些平台还提供自己特有的接口，所以有些公司会在主流操作系统（例如开源的Android）上，做一些适配甚至是改善性的功能，例如一个适合触摸屏的、甚至多点触摸的游戏引擎。

 

3）功能改善和增强

 

我们知道HTML5和JavaScript这类在客户端解释执行的机制与本地二进制应用相比，在执行效率、图形能力等方面都有先天弱势，此外还存在代码知识产权的保护等问题。所以有些公司设计的引擎是在服务器端进行预编译后才嵌入到网页的，这样对执行效率和代码保护都有帮助。

 

4）开发工具，IDE等

 

这个貌似只有微软、IBM、Adobe等大公司才有能力做的事情，但一些开源社区或小组织也在默默耕耘，他们的产品可能不是大而全的，但一定是因为某几个很好的feature而吸引使用者的。

 

5）移植、Demo、再造应用等

 

在初期这部分开发者比例或许是最大的，比如说有人将一些好玩的iOS或Android应用用HTML5来实现，有人用HTML5实现某个著名的街机游戏等。或许有人会说做这些事情意义不大，但至少这些应用让我们见识到了HTML5的强大：我自己也没想到，一些HTML5的游戏这么快就能在我的智能手机上如此流畅的运行起来了。此外在移植和尝试的过程中，你会率先使用新的接口，率先遇到更深层次的问题，并在调试的过程中获得大量经验值和宝贵的解决方案。

 

6）媒体、出版行业

 

其实这是我个人最希望看到：传统媒体和出版行业可以利用HTML5来在互联网领域占领自己的那一片山头，毕竟他们是内容生产者，只要充分利用HTML5这个发布工具，他们就能把传统领域中流失的一部分用户重新又争取回来。而我们（用户）也能在碎片时间中以更好的用户体验（跨平台的、比HTML4更好的），获得更好的内容（而不仅仅是互联网的海量垃圾信息）。

 

当然还有很多开发者在做一些有意思的事情，，没法一一罗列。作为个人而言，尽早的去接触新的技术总是有益无害的。很多人可能会发现，粗略学了一遍HTML5下来，还是不知道自己该做些什么——好的应用往往是从实际需求而来的，不是拍脑瓜空想出来的。有一个趋势是这样的：我发现越来越少有人写一些“孤岛”式的应用（练手、Demo、定制等除外），不论对本地应用还是HTML5应用都是如此。有实力、技术强的公司和团队往往更愿意从事框架、引擎等基础设施，或是与内容产生相结合、与云相结合的研发。

 

5.小结

 

（写到最后发现实在是说的太多了，条理也不甚清楚——因为说的本身就是处于初级阶段的一个技术，所以只好东扯一点西扯一点。因为这个缘故，最后一节也不能叫“结论”了，因为我不是互联网神汉，实在没有什么结论，暂定“小结”吧，以后想起再补充。）

 

1. 现在HTML5的鼓吹者大多集中在移动互联领域，尤其是是智能手机/平板开发领域。自07年以来，iOS、Android、Web OS等主流移动操作系统的流行引发了智能移动设备市场的火爆，开发者们欣喜于这些设备的普及，同时也深受多平台甚至同一平台内版本分裂的困扰，于是HTML5就在天时地利人和中成了救世主，毕竟这些主流操作系统都自带了相当先进的HTML5渲染引擎。
2. 尽管一切都还在起步阶段，各大厂商对于HTML5的实现也不尽相同，但我们似乎有理由相信，HTML5的时代很快就会到来。作为跨平台问题的性价比最高的解决方案，在没有替代方案之前，相信一直会有人不停的克服种种困难，坚持在探索中前行。
3. 相对于桌面操作系统，或许HTML5对于移动平台的意义会更大一些。现在很多HTML5的排头兵公司或组织，多少会将重点放在移动设备领域上。毕竟在桌面设备上，各个主流操作系统都已经建立了良好的软件生态圈，HTML5应用在可预见的一段时间之内应该都不是本地应用（甚至Flash）的直接竞争对手：不论是在功能还是性能上。
4. 相对与HTML4而言，HTML5开发门槛提高了，对其流行也会带来负面影响，别忘了HTML4的流行多少归功于它是一种“只要会copy/paste就能掌握的编程”。但随着时间的推移，随着各种第三方库/框架的逐渐完善，它流行开来的机会还是挺大的。
5. 为什么现在HTML5的鼓吹者（注意这是一个中性词）显得比HTML4时代更加高调：还是因为移动互联产业带来的火爆预期，因为现阶段好的HTML5开发者实在太少了。池子不够大，产业就不够大；只有更多的人参与了，包括做技术的和不做技术的，才能形成良好的生态圈。最后，还因为这是一个高调的时代 :-)
6. HTML5规范目前还在草稿阶段，尤其是接口部分，可能还存在一些变数，所以少有大型商业网站贸然深入使用的，毕竟大部分用户的浏览器还没升级到HTML5版本。
7. 如果技术也有泡沫或喧嚣的话，或许Android算一个，HTML5也得算一个。