相關文章：

　　HTML5筆記(1) - HTML5的定義

　　HTML5筆記(2) - 為什么需要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也得算一個。