主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃
比如哥们儿推荐一个饭馆儿，我不认识地方，他就传过来一副饭馆儿照片，照片内嵌经纬度信息，然后，GPS就能给我导航了
参考essential actionscript
actionscript目前我看下来是ecmascript的一个超集。但是他乱七八糟写法很多。至今没有一个公开规范。有些能在flex builder2里通过编译的东西flex builder3会报错。
Palm的WebOS的javascript不能完成所有的UI的工作。比如画矢量图。
我想主要是顾及到很多web developer的专业知识的限制，所以palm没有放太多扩展在javascript里面吧。
在pre上面整个本地的webserver，这个在技术上比扩展js啥的要简单多了，而且弄好之后，矢量图、本地存储、操作硬件啥的，都迎刃而解
三驾马车还是做他现在能做的就好了，不要再加大负荷，美人他爹说得好：
确实很重要！
ActionScript3 的确用到了XML。但是对于Adobe Flash来讲，我不理解为什么需要引入XML-DOM这种重型机械。所以我前面“未必那么简单”为题的回帖中说，“Adobe Flash不一定需要DOM”。
不仅我质疑为什么非要用XML-DOM这种CPU和Memory负担都很重的数据结构，而且更极端的是，我甚至怀疑为什么要用Script，不管是JavaScript还是ActionScript，还是Ruby，Python等等Script。
回帖中没有解释为什么我有这样不合潮流的想法，打算留给下一篇中详细解释。热诚欢迎拍砖。坦率讲，与其说我想证明自己的分析是正确的，不如说我想知道自己哪里想错了，为什么世界上这么多人，包括许多大牛，与我的想法南辕北辙。
羊倌儿提的问题很好，逐个回答。
1.
我文中这句话没有指称清楚，“HTML/XML + CSS + JavaScript基本可以满足定义工作流程的结构的需求”，应该表述为，“HTML/XML + CSS + JavaScript是否可以用来定义手机本地工作流程（而不是WEB网页+WEB服务器的工作流程）？如果不考虑运行效率，基本上是可以满足需要的”。
2.
如前所述，文中讨论的是，在没有网络服务器的情况下，JS是否能够承担手机本地状态机的问题。
3.
对，我说的就是这个意思。如果羊倌儿不介意，我是否可以厚颜无耻地把这段文字加入文中，以免指称不明。
4.
前半段说得对，“存储和复用的工作是浏览器来做的”。但是浏览器不等于WebKit，WebKit是浏览器引用的第三方组件。存储和复用不是WebKit做的，是纯粹的浏览器那部分来处理的。
5.
Palm WebOS就是打算这么干的。但是我觉得用HTML来访问本地数据，似乎不是很简便的办法，因为访问本地数据，经常要涉及动态参数的设定。在三驾马车里，动态参数的设定由JS负责。如果参数设定由JS负责，干嘛不直接用JS来访问本地数据？原因是JS没有简便调用native code的法门，下一段接着说。
6.
基本正确，但是不完全。一个迂回的办法是通过NPAPI，把native code作为插件插入浏览器。然后JS就可以调用Native code的Plugin了。
前面提到JS如何访问本地数据，也可以通过这个迂回的办法来实现。但是这毕竟是迂回的办法。简单就是美，这个办法虽然行得通，但是从技术角度看，不够漂亮。
我在题为“ActionScript3 的确用到了XML”的回帖中说到，“而且更极端的是，我甚至怀疑为什么要用Script，不管是JavaScript还是ActionScript，还是Ruby，Python等等Script”。原因就在于JS等等，不符合简单就是美的原则。
相信美爹的问题代表了很多人的意见，逐个回答，或许谬误，欢迎拍砖。
1.
如果是重写WEB应用，我同意美爹的意见。但是对于手机应用而言，它没有这么多反向兼容的问题，历史包袱不重。Google推出Android，手机制造商趋之若鹜，所有手机应用提供商都得根据Android的APIs重写，或者部分重写，美其名曰porting。其它新手机面临的局面也一样。
另外，我们不妨暂时把纯粹技术方案和商务挑战先区隔开来分别讨论，先以理想主义的傻兮兮的态度，讨论唯美的技术方案，然后再以商人的市侩，讨论如何一步一步把技术推向市场。如果把技术和商务混在一起谈，担心扯不清。
2.
我没有那么乐观。重视电池的发展，已经几十年了，现在依然没有即小又猛的电池出现。未来也不看好。当然，这是对未来的预测，每个人都有自己的判断，无法强求，也没必要强求。所以，有人把宝押在如果小而猛的电池出现，什么什么应用会相应火爆，还有悲观主义份子如我之辈，把宝押在如果小而猛的电池遥遥无期，我们应该如何精简应用逻辑的计算量。
3.
前店后厂不一定随时依赖网络连接。网络时有时无，不能全覆盖的局面在未来若干年内解决不了。我强调的是，在有网的时候下载半成品数据，这样即便在无网的时候，应用程序能够照样工作。Google手机地图的模式不可取，因为它的前提是，当用户使用Google手机地图时，必须有网。这个前提太苛刻了。
4.
云计算既能存放大数据，也能处理大计算。手机的负担越轻越好。但是手机本地版应用必不可少，原因是不能指望用户使用手机应用的时候，网络一定存在。
5.
当然还有位置，除此以外还有什么呢？大家提个醒？
大容量的电池现在不是做不出来，而且安全性还是没有保证。当然笔记本那种体积相对宽松的单说
譬如online visio，www.gliffy.com
不清楚他们是怎么做的，猜测是基于JS。但是你看giffy的loading的时间，好可怕，估计是JS量太大，编译时间长。
既然JS Engine不再是简单的parsing，而是compiling，为什么还执着于script？如果对于Web browser来讲，反向兼容的可以理解，但是对于手机来讲，没有这个历史包袱，为什么还要JS？
在手机本地装一个Web Server的想法，我在题为
大纵深的手机应用的旧文中提及过。
当时我说这是不是一个好办法，虽然行得通。主要原因并不在于Web Server本身造成的overhead，而是IPC。同在一个机器上，浏览器与Native Service之间交换数据，通过HTTP的方式，而不是直接的IPC，效率不高。
类似的东西我见过，联想北京研究院的人做的。做的还可以。
可是摩尔定律在手机上似乎失效了。如果不是iphone把高主频高性能的cpu和gpu引入手机，手机的性能似乎还在匍匐前进
工作关系要涉及Adobe AIR方面的内容，而AIR正好支持三种开发方式：
1。纯基于falsh的Flex风格的开发
2。纯基于HTML+CSS+JS的开发（AIR 内置webkit，同时支持通过各种方式向javascript开放AIR的本地API如文件,数据库API）
3。混杂式开发：界面切换，视觉效果可以用FLEX风格，界面布局，生成报表还是用HTML风格。这样效率最高。
其实，传统基于win32桌面的应用程序也经常这样开发：无论vs studio 的MFC 还是 borland VCL都有方法用IE来渲染解析基于html+css+js的内容。
开发快速是其最大商业卖点之一，不用script做不到这一点
webkit 支持canvas标签，可以画图。
firefox， chrome也都可以，就是不知道IE8可不可以