HTML5 之殇
英文原文：The Pain of HTML5
任何新技术面临的关键问题之一是，要么被采用并且舍弃那些不能接受它的用户；要么错失新的发展机会，最终变成无关紧要的技术。比如，如果你要在 网站开发中使用 HTML5 技术，这就意味着要舍弃那些仍然使用旧版 IE 的用户。不过开发者也可以通过兼容工作，让用户也能体验到 HTML5 的价值，同时也可以利用这个机会，让 HTML5 技术突显出它的重要作用。
然而，并非所有的事情都能如人所愿。HTML5目前还处于发展的初级阶段，部分特性还不能完美的实现。下面列举出了 HTML5 的一些不足之处。
1. IE 浏览器
IE 浏览器是 Web 新技术发展道路上的绊脚石。IE6的辉煌时代已经结束，IE7也是这样，即便是 IE8，也仍然不能称为一款“现代浏览器”。而 IE9 对 HTML5 的支持尚不完全，比如不支持 Web Sockets 和 Web Workers。
由于 IE8 不支持 ECMAScript5，因此开发者必须考虑怎样处理 array.IndexOf、array. each、Date.now ()、获取和设置属性、处理许多有用的 JavaScript 包。
在 IE8 和 IE9 中，用户可以提交跨源请求，但不能使用 XMLHttpRequest。
只有 IE10 可以称得上是“现代浏览器”，但是它不能在任何低于 Windows 8 的系统环境下运行。那么有多少比例的用户正在使用 IE10 呢？
2. 离线存储并不安全
当应用程序出现问题时，需要通过日志对它进行调查研究。但是如果应用程序运行好几天也不能发送一个日志，开发者就需要考虑客户端是否出现了问题。
日志记录会使客户端速度变慢、存储量增长，而且如果在发现问题时才进行日志记录就太晚了。而当前的 HTML5 技术，允许只存储最新的日志信息，使性能影响降到最低，并且当问题再次出现时，用户能够进行恢复。
当然，理想的做法是在后台写入日志来实现某种形式的离线存储（不影响客户端的响应），这样的话，当出现问题甚至是机器突然重启，日志也能恢复。
这个过程可以通过 Webworker 中的 FileSystem API 来实现。然而，当前只有 Chrome 浏览器支持 FileSystem API。
用户可以使用 localStorage 来代替 FileSytem API，可惜 localStorage 是一个同布 API，它的大量的数据将会增加加载时间。
更糟糕的是，实际上不能在本地机器上存储未加密的日志，因为它们可能包含机密信息。然而目前的一些简单的日志记录方案看起来非常混乱，性能也不好，由于 HTML5 中没有针对存储的加密 API，开发者还需要自己对这些日志进行加密。
3. 不能很好的支持窗口间共享
有时候你可能想在不同的窗口中共享同一个服务器的连接信息，现在可以使用 postMessage 来实现，但是你需要有你想发送消息的窗口的句柄。但是如何得知用户当前打开了哪些标签页呢？在 Chrome 中，不同的标签页使用不同的进程，这种功能对于创建长时间运行的应用程序非常有用。
在 Firefox 中不支持这一特性，但可以使用 SharedWebWorker 来代替。
你可以使用 onstorage 事件来对所有其他窗口进行广播，但问题是，并不是所有的浏览器都能提供进行存储事件的窗口的句柄。
4. Web Workers 细节尚未完全实现
通常情况下，当在 HTML 页面中执行脚本时，页面的状态是不可响应的，直到脚本完成。而 Web Workers 是运行在后台的 JavaScript，独立于其他脚本，不会影响页面的性能和操作。
但遗憾的是，Firefox 在 Workers 内部并不支持 WebSockets。
无论是 Chrome 还是 Firefox，都不能很好地解决基于代码位置的 Worker 脚本无法实例化页面本身的问题，因此代码库必须部署在为页面提供服务的同一个 web 服务器上，并且不能包含在不同层级的页面中，也无法在不更改代码的前提下为脚本文件重命名。尽管规范明确指出，worker 脚本应该能够被相关的脚本实例化。
总结
HTML5是美妙的，它让开发者在研究新的、有趣的功能时候更有成就感。但是，当开发者遇到 HTML5 不能实现的功能或者不能很好支持该技术的浏览器时（特别是用户都在使用旧版 IE 时），又会充满挫败感。
HTML5正在快速向前发展，并将逐步实现标准化，相信在不久的将来，本文所列出的这些不足之处都将不复存在，届时，用户将有一个完全不同的互联网体验。