HTML5 与 ”性工能“障碍HTML5 与 ”性工能“障碍最近看了@王淮Harry 的文章《HTML5的明天--局部有小雨》http://
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产生兴趣, 做了粗浅的研究, 并和硅谷的两位玩弄此道多年的技术大佬电话交流】之后写下的，所以我看后第一时间也没有太去较真，只是在微博上说了一句“精神可嘉”。
而且客观来说，这篇文章写的真的很不错，文中的结论（或称作观点）很多我也是非常认可，例如
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来实现”。
=============================
说了这么多我对H文的看法， 那么我再补充两句，来说说我个人对HTML5技术的看法吧。
简单说来，我觉得HTML5面临的主要问题就是： ”性工能“障碍。所谓“性工能”即：【性】能、【工】具、【能】力。
性能低下，这个事情基本上大家能够达成共识，至少和各种强大的Native展现层技术相比，确实有差距。但是这个问题不是致命的根本性问题。
当年Doom3 孤岛危机1 这些游戏出来时，也都是当时的硬件杀手，但是后来随着硬件的提升，性能问题也渐渐不再是核心问题了（这两个游戏在FPS游戏里，是真不好玩啊）。
换言之，当市场上对性能要求高的 好的产品和应用越来越多时，那些底层（浏览器 os 硬件）厂商不会坐视不理的，因为这对于他们来说 也是机会。
所以作为HTML前端工程师，我们所要做的就是尽可能的优化自己的代码，但不要被性能束缚了产品的手脚，同时在保证自己代码质量和算法没问题的情况下，行动+呼吁+等待就OK了。
当然,不要强迫HTML5去做不应该它来做的事情。
工具匮乏，从开发调试到测试维护整个过程中，确实缺少强有力的工具。这个问题在可预见的未来，应该还是比较难解决，不过对成熟的HTML开发团队而言，似乎也不是大问题，因为大家已经比较习惯和适应现在的开发环境和方式了。但是对于围绕上层应用所需要的辅助工具确实欠缺。拿HTML5游戏来说：地图编辑器、精灵编辑器、粒子效果、游戏脚本编辑器、音效管理工具、性能监控...等等,虽然理论上开发这些并不难,很多公司也都在尝试开发自己的基础架构,但是和unity3d flash这些比起来,还是太弱了.期待 cocos2d-x能够为我们带来不一样的局面(此处为植入广告,请林顺 王哲自行考虑所需费用)。
总之，HTML5为web应用带来了更多新的形式，不过围绕这些新形式的相关辅助工具确实还很欠缺。但是，未来可期。
能力不足，这个主要是指HTML5本身的定位和它的原则导致有很多事情是它根本做不了的。举个极端点的例子，你希望在网页里借助HTML5技术来格式化你的U盘、刻录一张CD几乎是不可能的（谁知道 HTML6789时会不会提供一组Disk API呢？）。因为很多事情根本就不在HTML的发展蓝图里。而且浏览器根本的目的是为了保证用户可以高效便捷安全的网上冲浪，这个根本目的导致了浏览器本身会存在一些制约，例如安全性上的。所以，指望HTML5能完全取代Native是不可能的，至少我觉得在我退休之前是不可能的。
在一些WebOS里，js似乎很强大，能做很多底层的事情，但是其实这些东西本质上已经不是标准化的HTML技术了，而是通过WebOS厂商定制的特殊环境和专有API实现的，这些东西显然超出了本文的讨论范围之内。
以上不难看出， 当未来性能和工具都不是问题时， ”能力“依然会是制约HTML5应用的一道枷锁，而且是最顽固的一个。
JS作为一种脚本语言, 本身对使用场景并没有什么限制, 它可以出现在浏览器里, 也可以出现在server后台,甚至有一天出现在智能电器 嵌入式设备里也都完全正常, 但是这不意味着HTML(HTML CSS JS)就能做所有事情,就能够取代Native.
所以我个人反复强调过我的一个观点： Hybrid技术绝对不是过渡技术, 它的生命力会很强.因为它是一个兼容并包的技术,是一个真正可以沟通起HTML和Native的桥梁. 只要Native和HTML不完全相同,那么Hybrid就有存在的价值.
=============================
我发现这篇文章我又写散了, 主题凌乱, 难以总结出中心思想，那我自己来总结一下吧：
HTML5技术本身确实还有很多问题，但是未来值得期待————只是这种期待要适当，否则最后的失望不可避免。HTML5是一场伟大的技术变革，也许真的可以改变世界，但是在改变世界之前，先试着改变自己，而改变自己，先从改变自己对待HTML5的态度开始吧。
-- OVER --
平台差异也很愁人啊
小胖咋还用鸡眼的博客啊... 2 楼 fins 2012-12-13 懒得自己搭建博客啊 呵呵. 不过这个博客的功能现在看来真的太弱了.
支持markdown 和潜入js html css代码就好了 (类似博客园那种) 3 楼 luolonghao 2012-12-13 能力不足是无解啊，又想安全，又想什么都想做。 4 楼 80houzhu 2012-12-13 看看这个养养眼http://119.57.100.27:8888/第四个连接。战斗吧，兄弟们 5 楼 cuixiping 2012-12-14 纯运算量偏大的web应用中，多线程比较有用。
我做一个在线绘图的应用，打开文件时，是从服务端取回压缩数据，用js解压，保存时用js压缩再传上服务器，不用多线程的情况下，上兆字节的压缩文件就很卡了。还有一些几何运算， 图元多了也有压力。
至少百分之八九十的游戏，不用多线程都可以无障碍的。
你在杭州上次D2上讲的那个HTML5现状的文，也可以分享到这里来，贴个链接啥的吧至少。 6 楼 cuixiping 2012-12-14 80houzhu 写道看看这个养养眼http://119.57.100.27:8888/第四个连接。战斗吧，兄弟们
有点意思，解放思想，提高生产力 7 楼 乐邪鬼 2012-12-14 我们客户还真提出格式化优盘的功能 8 楼 shadowninja 2012-12-17 多线程不是有web work么.....
http://www.ibm.com/developerworks/cn/web/1112_sunch_webworker/
不过还是得说html5跨平台开发还是很烦,,至于性能啥的,js真的要费很多事去优化,说实话.....和mozilla hacks上的一篇文章一样,的确是一种方案,但这方案不一定就简单.....,不过更希望大大你分享一些游戏编程的东西(比如等角地图游戏的排序问题之类的....
