主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃
家园 这个不是AJAX特有的问题 任何需要在手机上运行的web应用，都有这个问题，flash也不例外。
重启炉灶的风险很大，一来那么多应用要重写，这个不是任何一家公司敢于承受的；二来电池的发展也很快，很可能新标准还没流行，电池容量就赶上了。
前店后厂的方式固然有其优势，但是响应速度也是不可忽略的，用户宁可用一个使用时间只有半天的smart phone，也不会去用一个很慢，还要随时依赖网络连接的smart phone。把合适的计算和数据放在合适的地方，很重要。
我个人对电池容量不是很担心，主要是电池容量这块的投入很大，发展很快。如果容量真的成了瓶颈，或许用云生成某种手机可以高效执行的中间格式是个方向。
btw，手机可以生成的数据输入远非照片和视频。
家园 电池的问题在最近今年内是没希望了额 大容量的电池现在不是做不出来，而且安全性还是没有保证。当然笔记本那种体积相对宽松的单说
家园 回复美爹的问题 相信美爹的问题代表了很多人的意见，逐个回答，或许谬误，欢迎拍砖。
1.
重启炉灶的风险很大，一来那么多应用要重写，这个不是任何一家公司敢于承受的。如果是重写WEB应用，我同意美爹的意见。但是对于手机应用而言，它没有这么多反向兼容的问题，历史包袱不重。Google推出Android，手机制造商趋之若鹜，所有手机应用提供商都得根据Android的APIs重写，或者部分重写，美其名曰porting。其它新手机面临的局面也一样。
另外，我们不妨暂时把纯粹技术方案和商务挑战先区隔开来分别讨论，先以理想主义的傻兮兮的态度，讨论唯美的技术方案，然后再以商人的市侩，讨论如何一步一步把技术推向市场。如果把技术和商务混在一起谈，担心扯不清。
2.
电池的发展也很快，很可能新标准还没流行，电池容量就赶上了。。。我个人对电池容量不是很担心，主要是电池容量这块的投入很大，发展很快。我没有那么乐观。重视电池的发展，已经几十年了，现在依然没有即小又猛的电池出现。未来也不看好。当然，这是对未来的预测，每个人都有自己的判断，无法强求，也没必要强求。所以，有人把宝押在如果小而猛的电池出现，什么什么应用会相应火爆，还有悲观主义份子如我之辈，把宝押在如果小而猛的电池遥遥无期，我们应该如何精简应用逻辑的计算量。
3.
前店后厂的方式固然有其优势，但是响应速度也是不可忽略的，用户宁可用一个使用时间只有半天的smart phone，也不会去用一个很慢，还要随时依赖网络连接的smart phone。前店后厂不一定随时依赖网络连接。网络时有时无，不能全覆盖的局面在未来若干年内解决不了。我强调的是，在有网的时候下载半成品数据，这样即便在无网的时候，应用程序能够照样工作。Google手机地图的模式不可取，因为它的前提是，当用户使用Google手机地图时，必须有网。这个前提太苛刻了。
4.
把合适的计算和数据放在合适的地方，很重要。云计算既能存放大数据，也能处理大计算。手机的负担越轻越好。但是手机本地版应用必不可少，原因是不能指望用户使用手机应用的时候，网络一定存在。
5.
手机可以生成的数据输入远非照片和视频。当然还有位置，除此以外还有什么呢？大家提个醒？
家园 有道理，现在手机确实越来越强大了 比如哥们儿推荐一个饭馆儿，我不认识地方，他就传过来一副饭馆儿照片，照片内嵌经纬度信息，然后，GPS就能给我导航了
家园 一花双宝…… 恭喜：你意外获得【通宝】一枚谢谢：作者意外获得【通宝】一枚
家园 【原创】【13】Adobe Flash，向何处去？ 【13】Adobe Flash，向何处去？
前文说到，Adobe Flash的文件格式很多，其中最重要的有三个，SWF，FLV 和AS。前文介绍了SWF和FLV，这一篇谈谈ActionScript。
[3] ActionScript 与 Adobe Flex
虽然Adobe Flash的初衷是制作和播放动画，但是有没有可能利用这个技术，让网页“活”起来？譬如有个网页讲解建筑装修。网页中央反复播放一段动画，显示建筑的各个立面，下方划出一块区域，显示文字注释。当用户把鼠标移动到动画中某一个位置时，注释区就显示相应文字说明。
针对这样的需求，Adobe推出了Adobe Flex。Adobe Flex是Asynchronous Flash and XML的简称。明眼人一看就明白，这个命名方式，与Ajax非常类似。Ajax是以下几个单词的首字母的缩写，Asynchronous JavaScript And XML。比较一下Ajax和Adobe Flex，两者都有Asynchronous，都有XML。Asynchronous指的是，通过异步响应的方式，改善用户体验。问题是，1. 为什么XML这么重要？2. Adobe Flash支持不支持JavaScript?
1. 先说XML为什么重要，借用一段S兄的文字。
如果浏览器的核心是Rendering Engine，那么Rendering Engine的核心就是“DOM”。譬如浏览器从某个网站下载了某个网页，网页不仅包括HTML文件，还包括CSS文件，还有JavaScript，还有 HTML文件中链接的图片，音乐和视频等等。所有这些，统称为网页内容，所有内容中最重要的，是HTML。HTML之所以重要，是因为HTML描述了一个 XML DOM Tree，这棵XML DOM Tree是个框架，是个脉络，是个纲。
纲举目张，Rendering Engine的主要任务就是围绕着这棵XML DOM Tree的生成，表现，维护与撤销。譬如CSS，它定义了DOM树中各个节点，尤其是叶子们的字体，大小，颜色，渲染方式等等。又譬如 JavaScript，它的任务之一是捕捉用户的行为，例如在文本框中输入的文字，点击的按钮，鼠标的位置等等，改变XML DOM Tree的某一些节点的内容，甚至部分改变Tree的结构。
外链图片需谨慎，可能会被源头改Figure 1. The internal workflow of a rendering engine.
Courtesy https://developer.mozilla.org/@api/deki/files/189/=EmbeddingBasicsa.gif
从上图可以看出DOM的重要性。虽然这个图这是Rendering过程的大致流程图，但是DOM模型并没有在这个过程结束时被销毁，而是一直在当前网页的“ 生命期”生存。可以这样说，任何于网页的交互操作都伴随着DOM树的“部分遍历”。 如果能掌握住Render Engine中关于DOM的代码就等于抓住了Render Engine的纲。
问题是，HTML的解析，CSS风格的渲染，这些工作由谁来做，是WebKit还是Flash Player？或者换一句话说，是在WebKit框架内，插入Flash Player，还是在Adobe Flash体系内，插入WebKit的某些功能。这个问题，各个厂家目前各行其道，没有统一规范。Palm WebOS的解决方案，是把Flash Player插入到WebKit框架中去，插入的手段是NPAPI。
外链图片需谨慎，可能会被源头改Figure 2. Palm WebOS architecture
Courtesy http://developer.palm.com/assets/images/book/palm_0112.png
2. Adobe Flash支持不支持JavaScript?
HTML+CSS+JavaScript，人称网页三剑客。JavaScript的专长是解决用户交互的问题。所谓与用户的交互，体现在两个方面，1. 捕捉事件，譬如用户移动鼠标，在文本框里输入文字，点击按钮等等。2. 响应动作，主要是改变页面的内容，以及显示的方式。
Adobe Flash提供了ActionScript。ActionScript与JavaScript相比，无论是功能还是语法，都非常相似。这不奇怪，因为 ActionScript与JavaScript一样，使命都是解决与用户交互的问题。奇怪的是，为什么Adobe Flash不直接使用JavaScript。
外链图片需谨慎，可能会被源头改Figure 3. A not-blessed prophet
Courtesy http://www.creationism.org/images/DoreBibleIllus/h1Ki1324Dore_TheDisobedientProphetSlainByA_Lion.jpg
95% 以上的PC装载了Adobe Flash，这意味着Adobe有可能在Rich Internet Application领域，形成垄断。有垄断的威胁，就有开源的反制。开源项目Gnash致力于取代Flash Player，而开源项目Ajax Animator的目标主要是提供制作SWF的工具。
玩味一下Ajax Animator这个名字，想到一个问题，是不是可以拓展Ajax，来提供所有Adobe Flash的功能？
1. ActionScript与JavaScript，功能和语法都相似，长远来讲，势必合流。
2. SWF格式，是不是可以归并到XML范畴中？SWF以tag作为标示，XML以marker作为标示，两者很容易统一，当然也有代价，marker比tag占用更多空间。
3. 支持Ajax的是浏览器，播放SWF的是Adobe Flash Player。浏览器是否可以与Flash Player融为一体？目前Flash Player作为插件插入浏览器，但是两者功能上有很多重叠。如果把两者融合在一起，重新实现，运行效率必然比插件方式高很多。
总之，Ajax和Adobe Flash有可能合流。技术上的确存在一些障碍，但是主要是优化系统，提高效率，而不是致命的差别。Ajax和Adobe Flash的合流，困难主要来自于商务。
目前在Rich Internet Application领域，是三足鼎立的局面，其中Adobe Flash份额最大，其次是Microsoft SilverLight，最弱的是Sun Microsystems的JavaFX。JavaFX之所以没有受到用户的青睐，一是制作工具不直观，难掌握，二是JavaFX播放器启动时间太长，运行期间也太占用内存。
照这个趋势发展下去，JavaFX前途堪忧。但是也有改变命运的机会，譬如，JavaFX摇身一变，着力于拓展现有Ajax技术，去支持动画和视频。这样一来，JavaFX就有可能蜕变成Ajax的领跑者，而不是RIA的淘汰生。
关键词(Tags): #硅谷评论，家园 ActionScript源自JavaScript 在ECMA-262 specification将JS标准化后，ActionScript的演进也遵照这个标准。按照ECMA规范，这种脚本语言应该叫ECMAScript——"JavaScript"仅指Netscape和Mozilla Foundation的实现。不妨把JS和ActionScript看作ECMAScript的两种方言好了。
家园 未必那么简单 JavaScript和JScript是ECMAScript的两种方言，但是ActionScript短期内是不是能统一到ECMAScript规范内，情况可能会复杂一点。
尤其是ECMAScript的事件的捕捉和传递，是基于DOM Event 机制来处理的，但是Adobe Flash不一定需要DOM。
当然，如果Adobe Flex从Flash独立出来，分道扬镳，那就有可能遵循ECMAScript规范。
- 复 未必那么简单
家园 没DOM如何实现Capturing&Bubbling? 没DOM如何实现Capturing&Bubbling?
另一方面，javascript 最热的 AJAX 里核心的 XMLHTTP object 的onreadystatechange 事件各大浏览器又是怎么处理的？用到DOM了吗？
家园 单独写一篇回答此问题 我之所以对DOM有腹诽，原因之一就是DOM处理event capture&bubbling太麻烦。
- 复 未必那么简单
家园 as也是基于dom的 参考essential actionscript
actionscript目前我看下来是ecmascript的一个超集。但是他乱七八糟写法很多。至今没有一个公开规范。有些能在flex builder2里通过编译的东西flex builder3会报错。
家园 ActionScript3 的确用到了XML ActionScript3 的确用到了XML。但是对于Adobe Flash来讲，我不理解为什么需要引入XML-DOM这种重型机械。所以我前面“未必那么简单”为题的回帖中说，“Adobe Flash不一定需要DOM”。
不仅我质疑为什么非要用XML-DOM这种CPU和Memory负担都很重的数据结构，而且更极端的是，我甚至怀疑为什么要用Script，不管是JavaScript还是ActionScript，还是Ruby，Python等等Script。
回帖中没有解释为什么我有这样不合潮流的想法，打算留给下一篇中详细解释。热诚欢迎拍砖。坦率讲，与其说我想证明自己的分析是正确的，不如说我想知道自己哪里想错了，为什么世界上这么多人，包括许多大牛，与我的想法南辕北辙。
家园 开发快速是其最大商业卖点之一，不用script做不到这一 开发快速是其最大商业卖点之一，不用script做不到这一点
家园 Script的质疑 Shell script之所以流行，是因为方便，具体来讲，programming -> compiling -> linking -> running 这是普通语言如C，Java之类的流程，但是Script的流程被简化为 programming -> parsing -> running， 用parsing替代了compiling 和 linking的麻烦。
如果Script语言写得不大不复杂，这个便利能够体现。但是当Script越写越大越写越复杂，Parsing的成本与Compiling和Linking就不相上下了。
所以，现在browser纷纷用起了JIT Compiler去编译JavaScript，而不是简单parsing。
总之，我的疑问是，当Script庞大到一定程度以后，它的便利已经体现不出来了，在这种情况下，Script的存在意义是什么呢？