HTML5 与 ”性工会“障碍
日期：2014-05-17 浏览次数：20710 次
HTML5 与 ”性工能“障碍
HTML5 与 ”性工能“障碍
最近看了@王淮Harry 的文章《HTML5的明天--局部有小雨》http://www.nonoidea.com/2012/12/12/html5%E7%9A%84%E6%98%8E%E5%A4%A9-%E5%B1%80%E9%83%A8%E6%9C%89%E5%B0%8F%E9%9B%A8/，由于作者本身并不是专业搞HTML5的技术专家，而且他自己也很坦诚的说了这文章是在【最近对HTML5产生兴趣, 做了粗浅的研究, 并和硅谷的两位玩弄此道多年的技术大佬电话交流】之后写下的，所以我看后第一时间也没有太去较真，只是在微博上说了一句“精神可嘉”。
而且客观来说，这篇文章写的真的很不错，文中的结论（或称作观点）很多我也是非常认可，例如
但是不错的结论 却掩盖不了得出这个结论的过程（论据和原因）中所出现的一些疏漏和错误。
而后来看到很多转发和评论的人在认可结论的时候，连带那些错误的东西也一并认同（甚至主要就是认同那些错误的东西）， 我觉得我不能再沉默了，因为人们对HTML5的误解已经很多，不能再多下去啊。
首先声明，我不是HTML5黑，也绝对不是HTML5红橙黄绿青蓝紫什么乱七八糟的东西，我就是一个靠写代码吃饭的人，什么代码我写着顺手，我就用什么。我用HTML5开发应用或游戏，绝对不是HTML5有多牛逼，而是因为目前我用JS+HTML+CSS这个组合最熟练，仅此而已。另外，我在后面不会详细去区分HTML JS CSS, 都统一叫做HTML或HTML5了,请咬文嚼字党放我一条生路，夹着鸡鸡跪谢了。声明完毕，正文开始。
=============================
《HTML5的明天--局部有小雨》（以下简称 H文，请读者将其和H文学相区分）一文的内容大体如下：
这个基本上是任何介绍、点评、分析HTML5的（或其他任何技术）文章的标准结构，无任何不妥。
但是H文中每一部分都有一些值得商榷的地方。
首先，在HTML5是什么一节当中， 作者无视了HTML5的8大特性，反而把HTML5中微不足道的一些小功能点当做主要内容来写。如果大家真的对HTML5感兴趣，但是又没有时间去仔细的阅读HTML5官方规范，又不相信google和百度的搜索结果，那么至少应该去 W3C官方的HTML5主题页上去看一下，对HTML5的8大特性有所了解，主题页地址：htt://www.w3.org/html/logo/
网页里用很清晰明了的说明了什么是HTML5以及HTML5带来的主要的新特性。
=============================
而在HTML5现状中，作者引用了一个数据“App Store上超过50%的应用已经是用HTML5来开发”，我实在不知道这个统计是怎么来的。但是不可否认的是，最近一年以来App Store上基于Hybrid开发的应用确实越来越多了。我的ios设备里就有几十款HTML5开发的网页向的手机游戏，不过目测在浩如烟海的App当中，HTML5应用应该不到50%，不过我也拿不出证据，在这里就不明确表态了。
在对HTML5优点的表述中，作者主要提及了“跨平台”这个特性，也没什么不妥，只能说不够全面。
=============================
接下来到了H文中篇幅最大，也是问题最多的部分：HTML5的缺点。
作者主要描述了两类问题：一个是性能问题，一个是对HTML5支持度的问题。
H文的作者用大量文字来描写了关于线程的问题， 主要想告诉读者“HTML5性能低，因为不支持多线程”。
关于这点网上已经有很多人指出了问题，作者也在后面加入了补充说明，但是我觉得作者可能还是没有理解到“HTML不支持多线程”的关键。
“HTML 不支持多线程”绝对不是缺点，而是特点。关于HTML的单线程特点 以及工作原理网上有很多介绍文章, 如果大家没时间看相关文档,没时间自己动手体会, 可以看一下这个简短的 slide [url]http://www.slideshare.net/nzakas/high-performance-javascript-capitoljs-2011
[/url] (可以从第19页开始看).
简单来说, 浏览器运行时,就好像(只是好像)下面这个无限循环:
1 2这两项工作,浏览器同一时间只能做一件. 这种单线程模型在满足用户使用需求的同时,也保证了开发方式的最简化,总的说来就是"简单够用".
也许有人会质疑, 怎么可能够用? 可能对于大多数人来说,都会觉得多线程很牛逼，单线程很无力，其实不然，举个简单的例子： 目前大家玩到的大多数游戏（甭管它多华丽）的主体部分都是单线程编写的。事实上，在开发游戏时，很少用到多线程技术。
游戏的核心逻辑其实也是一个循环体:
我们玩游戏时,满屏幕的敌人,乱飞的子弹, 天空飘过的白云...这一切的一切都是在一个线程里,
这个线程同样是同一时刻只做一件事.
华丽流畅的游戏 单线程模型都ok, 一个区区的网页和应用有何不可?
而且,其实很多原生技术在处理数据的更新和渲染时, 用的也是类似的单线程方式(即使这个语言或技术支持多线程)。
所以,HTML5性能确实是低(其实也没想象的低,所以才有那么多的HTML5游戏诞生),但是造成这个问题的原因不是单线程, 而是在主循环体内
这两项的性能还不够高.
我觉得要提高HTML5的性能,不应该靠"引入多线程"来实现, 应该靠"提升单线程内处理每一项时的性能"（以及如何将大量的第一项里的工作分解）来实现.
而WebWorker 的引入, 其实就是为了提高 第1项的性能.
WebWorker 本身并不是传统的Thread模型,虽然底层是多线程实现的,但是它并没有引入同步锁 线程调度一类高级特性, 而是用简单的消息机制尽可能的保持了和单线程之间的匹配度.
换言之, WebWorker 并不是给单线程的 HTML带来的多线程特性, 而是给单线程的HTML带来了后台计算的能力.
有点说远了,回到主题。我的核心观点就是：HTML5性能虽然低，但和多线程 单线程什么的无关，单线程也绝对不是HTML5的致命伤，而是即有好处也有坏处的一个特性。
再来说说HTML5特性的普及度，WebWorker WebSocket （iOS 6 的safari已经支持这两个特性了）一类的HTML5特性其实正在被越来越多的浏览器支持，在移动端也是如此。相信未来这个不会是大的问题。
H文最后关于未来那段说的也没什么问题。但我个人更倾向于“即使这一天到来了, 仍然会有至少10%的APP无法应用HTML5来实现”。
HTML5 与 ”性工能“障碍
最近看了@王淮Harry 的文章《HTML5的明天--局部有小雨》http://www.nonoidea.com/2012/12/12/html5%E7%9A%84%E6%98%8E%E5%A4%A9-%E5%B1%80%E9%83%A8%E6%9C%89%E5%B0%8F%E9%9B%A8/，由于作者本身并不是专业搞HTML5的技术专家，而且他自己也很坦诚的说了这文章是在【最近对HTML5产生兴趣, 做了粗浅的研究, 并和硅谷的两位玩弄此道多年的技术大佬电话交流】之后写下的，所以我看后第一时间也没有太去较真，只是在微博上说了一句“精神可嘉”。
而且客观来说，这篇文章写的真的很不错，文中的结论（或称作观点）很多我也是非常认可，例如
引用
* 在移动端是否采用HTML5技术, 取决于你的产品形态
* 将来可能90%的应用会是HTML5, 而那10%, 可能永远也不适合HTML5
* HTML5性能的提升很大程度上将取决于低耗电高性能CPU/内存的出现, 或者电池技术的极大改善。
* 将来可能90%的应用会是HTML5, 而那10%, 可能永远也不适合HTML5
* HTML5性能的提升很大程度上将取决于低耗电高性能CPU/内存的出现, 或者电池技术的极大改善。
但是不错的结论 却掩盖不了得出这个结论的过程（论据和原因）中所出现的一些疏漏和错误。
而后来看到很多转发和评论的人在认可结论的时候，连带那些错误的东西也一并认同（甚至主要就是认同那些错误的东西）， 我觉得我不能再沉默了，因为人们对HTML5的误解已经很多，不能再多下去啊。
首先声明，我不是HTML5黑，也绝对不是HTML5红橙黄绿青蓝紫什么乱七八糟的东西，我就是一个靠写代码吃饭的人，什么代码我写着顺手，我就用什么。我用HTML5开发应用或游戏，绝对不是HTML5有多牛逼，而是因为目前我用JS+HTML+CSS这个组合最熟练，仅此而已。另外，我在后面不会详细去区分HTML JS CSS, 都统一叫做HTML或HTML5了,请咬文嚼字党放我一条生路，夹着鸡鸡跪谢了。声明完毕，正文开始。
=============================
《HTML5的明天--局部有小雨》（以下简称 H文，请读者将其和H文学相区分）一文的内容大体如下：
引用
1 HTML5是什么
2 HTML5的现状和优劣
3 HTML5的明天会如何
2 HTML5的现状和优劣
3 HTML5的明天会如何
这个基本上是任何介绍、点评、分析HTML5的（或其他任何技术）文章的标准结构，无任何不妥。
但是H文中每一部分都有一些值得商榷的地方。
首先，在HTML5是什么一节当中， 作者无视了HTML5的8大特性，反而把HTML5中微不足道的一些小功能点当做主要内容来写。如果大家真的对HTML5感兴趣，但是又没有时间去仔细的阅读HTML5官方规范，又不相信google和百度的搜索结果，那么至少应该去 W3C官方的HTML5主题页上去看一下，对HTML5的8大特性有所了解，主题页地址：htt://www.w3.org/html/logo/
网页里用很清晰明了的说明了什么是HTML5以及HTML5带来的主要的新特性。
=============================
而在HTML5现状中，作者引用了一个数据“App Store上超过50%的应用已经是用HTML5来开发”，我实在不知道这个统计是怎么来的。但是不可否认的是，最近一年以来App Store上基于Hybrid开发的应用确实越来越多了。我的ios设备里就有几十款HTML5开发的网页向的手机游戏，不过目测在浩如烟海的App当中，HTML5应用应该不到50%，不过我也拿不出证据，在这里就不明确表态了。
在对HTML5优点的表述中，作者主要提及了“跨平台”这个特性，也没什么不妥，只能说不够全面。
=============================
接下来到了H文中篇幅最大，也是问题最多的部分：HTML5的缺点。
作者主要描述了两类问题：一个是性能问题，一个是对HTML5支持度的问题。
H文的作者用大量文字来描写了关于线程的问题， 主要想告诉读者“HTML5性能低，因为不支持多线程”。
关于这点网上已经有很多人指出了问题，作者也在后面加入了补充说明，但是我觉得作者可能还是没有理解到“HTML不支持多线程”的关键。
“HTML 不支持多线程”绝对不是缺点，而是特点。关于HTML的单线程特点 以及工作原理网上有很多介绍文章, 如果大家没时间看相关文档,没时间自己动手体会, 可以看一下这个简短的 slide [url]http://www.slideshare.net/nzakas/high-performance-javascript-capitoljs-2011
[/url] (可以从第19页开始看).
简单来说, 浏览器运行时,就好像(只是好像)下面这个无限循环:
while(true){
1 更新数据和对象状态
2 渲染可视化UI
}
( 而在需要异步的地方,HTML是提供了异步机制的,例如网络传输 事件响应 )
1 2这两项工作,浏览器同一时间只能做一件. 这种单线程模型在满足用户使用需求的同时,也保证了开发方式的最简化,总的说来就是"简单够用".
也许有人会质疑, 怎么可能够用? 可能对于大多数人来说,都会觉得多线程很牛逼，单线程很无力，其实不然，举个简单的例子： 目前大家玩到的大多数游戏（甭管它多华丽）的主体部分都是单线程编写的。事实上，在开发游戏时，很少用到多线程技术。
游戏的核心逻辑其实也是一个循环体:
while(true){
处理用户输入
更新数据和对象状态
渲染游戏画面
}我们玩游戏时,满屏幕的敌人,乱飞的子弹, 天空飘过的白云...这一切的一切都是在一个线程里,
这个线程同样是同一时刻只做一件事.
华丽流畅的游戏 单线程模型都ok, 一个区区的网页和应用有何不可?
而且,其实很多原生技术在处理数据的更新和渲染时, 用的也是类似的单线程方式(即使这个语言或技术支持多线程)。
所以,HTML5性能确实是低(其实也没想象的低,所以才有那么多的HTML5游戏诞生),但是造成这个问题的原因不是单线程, 而是在主循环体内
while(true){
1 更新数据和对象状态
2 渲染可视化UI
}这两项的性能还不够高.
我觉得要提高HTML5的性能,不应该靠"引入多线程"来实现, 应该靠"提升单线程内处理每一项时的性能"（以及如何将大量的第一项里的工作分解）来实现.
而WebWorker 的引入, 其实就是为了提高 第1项的性能.
WebWorker 本身并不是传统的Thread模型,虽然底层是多线程实现的,但是它并没有引入同步锁 线程调度一类高级特性, 而是用简单的消息机制尽可能的保持了和单线程之间的匹配度.
换言之, WebWorker 并不是给单线程的 HTML带来的多线程特性, 而是给单线程的HTML带来了后台计算的能力.
有点说远了,回到主题。我的核心观点就是：HTML5性能虽然低，但和多线程 单线程什么的无关，单线程也绝对不是HTML5的致命伤，而是即有好处也有坏处的一个特性。
再来说说HTML5特性的普及度，WebWorker WebSocket （iOS 6 的safari已经支持这两个特性了）一类的HTML5特性其实正在被越来越多的浏览器支持，在移动端也是如此。相信未来这个不会是大的问题。
H文最后关于未来那段说的也没什么问题。但我个人更倾向于“即使这一天到来了, 仍然会有至少10%的APP无法应用HTML5来实现”。
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
