主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃
太守那个还没消化呢，您这一眨眼又扔一篇出来。继续潜水学习之
太守这个丧钟系列，得积极催稿，看样子，他有一肚子话要说呢。
你这几篇都可以独立成文啊。今天晚上得好好消化学习呢
昨天太累，就没有真正回复。所谓认真，不仅是态度的问题，而且也是精力的问题。今天体力回复了，再不认真答复，就是态度问题了。
言归正传，“陌生人”一文洋洋洒洒，内容丰富，简练地概括不容易，但是如果实在要概括一下，或许可以列出以下几点，
1. Palm意识到，在企业用户方面，他们已经输给了BlackBerry。所以他们把注意力转向了Web2.0，试图把Web2.0引入智能手机。
2. WebOS的结构，一个linux内核，一个JVM，一个OSGi，一个AppServer，一个WebServer，然后通过HTML5和扩展的Javascript进行开发。通过这个结构，抹平了本地应用和webapp的界限，而且具有离线能力。
3. Mojo是一个crawler，它的Javascript应用在网上爬来爬去的，比如你的地址本程序也许可以爬到Facebook上去取一些内容下来。
4. WebOS结构，加上Mojo。完成两个在desktop平台上都算的上前卫的两个东西，mashup和offline browsing。目前有两个离线技术，一个是google gear，另一个是adobe的air技术。
5. 本地存储通过HTML5实现，本地应用由Web Server提供，本机资源的访问是通过扩展的Javascript API调用AppServer里的服务。（为什么不用本地Web server？）
6. JVM的设计只考虑了运行时，没有考虑Java程序的部署、版本、依赖性、重用等诸多问题。OSGi容器可以处理这些问题，这对于运营商的软件分发维护来说尤其重要，这也是为什么Sprint会推出自己的OSGi框架的原因。具体在Palm Pre上，OSGi应该是有的，论据是Pre支持Sprint Titan框架。
此文作者的网名叫UGLee，UGLee功力不浅，在他写这篇文章的时候，Palm对于WebOS的技术细节，透露得非常少。而UGLee凭借片言只语的收集，从残片中恢复原型。很多地方他猜对了，但是也有个别地方，似乎和后来Palm陆续透露出来的细节不太相符。
UGlee对于WebOS结构的猜测是这样的，“一个linux内核，一个JVM，一个OSGi，一个AppServer，一个webServer，然后通过HTML5和扩展的Javascript进行开发。”
1. WebOS的内耗的确是借用了Linux Kernel，目前使用的版本是Linux 2.6 Kernel。
2. 应用开发的确是通过HTML5和JavaScript。
3. WebOS目前没有JVM，没有WebServer。
4. 虽然没有用OSGi，没有设立AppServer，但是极有可能延用类似的设计思想，做了一个Application的容器。
微软也不是光模仿不收购吧，就算ie，也是收购其他工作组做的
至少在as2后，flash里可以完全没有frame了
手机浏览器在运营商们杀鸡取卵式压榨之下，能有多popular，还很难讲... 就更别提人们能拿它干什么了...
没有一个明晰的需求，大家只能无头苍蝇般乱闯一气...
有时候在地上撒一把草籽，然后根据踩踏痕迹再来修路，或许是最明智的选择...
该用http+xml的地方就用。可是滥用就很恶心了。
关键是滥用起来还一套一套的。已有的高效好用的东西非得说不“标准”，要改掉。我就奇怪了，谁也没说http一定要是universal的标准。现在还搞个soap，webservice出来妄图统一天下。
为了这个莫名其妙的标准，居然要搞大倒退？
一天到晚在穷乡僻壤种地能种出吨粮田？何不眼界宽一点，去外面广大世界耕耘岂不是更好的办法。
如果总是一味抱残守缺，这个行业也没法发展了。难怪现在投资人也挺鄙视硅谷的公司的。其实的确越来越没有技术含量了。
补充一下Java Applet 失败的主因之一。
Java Applet 失败一是由于JVM不兼容的问题。这其实不止存在于微软的JVM里，也存在于 IBM 的 JVM 里。
但另一个更为重要的原因是当时的硬件技术跟不上。Applet 每次执行都要重新下载。而当时的网络技术还大多是14.4K到33.6K的MODEM。宽带虽然有但远没有现在普及。而当时 Applet 的一个致命缺点是下载时不管有用没用 Applet 里的所有内容必须全部下载。
举例来说，你上网买个东西，结算的时候用个 Applet 来结帐。这个 Applet 必须考虑到各种情况，例如有些客户用信用卡，有些客户用 Paypal,还有些直接用礼卷之类的。这就可能要用3个不同的页面。在 Applet 必须把三个页面的代码都下载。而且还得下载所有的计算程序。而如果用 HTML，则可以根据用户的选择来下载某个页面。
这样，Applet 的实际数据传输量就这个功能来说将是 HTML 的三倍。而很多 Applet 其实比 HTML 的传输量高了几十倍。这样闹到后来，用 Applet 的用户看着别人的网页在同样的 MODEM 上刷刷得出来，而自己的机器还在慢悠悠得下载 Applet。当然不会爽了。
所以当 JSP－SERVLET 一出来，Applet 就基本没戏了。
Applet不够精简，这是一个很重要的原因。
多谢补充。
何不写一篇反驳，谈谈AS2以后，去Frame的Flash的结构是什么？
此段应改为：
到了2003年，Netscape大势已去，第一次浏览器大战就此结束，以微软IE浏览器完胜而告终。但是Netscape变换手法，高举OPEN SOURCE的大旗，为成就今日的Firefox埋下了伏笔。Mosaic，Netscape，Opera，以及IE的6.0以前诸版本，还有史前的其它浏览器，通常被称为第一代浏览器。
JWS和进程交换只能说它生不逢时。现代的Application进程运行中有太多的进程上下文交换（起码要和OS内核），否则Application毫无意义。
与其说JWS的UI渲染风格的失败不如说JWS开发工具的失败，核心问题 --- “所见即所得”（What You See Is What You Get，簡稱WYSIWYG）。JAVA自成体系的窗口成立浏览器上的包袱，成也萧何，败也萧何。
1.
已经按太守的建议修改了原文。多谢。
2. Context Switch和IPC/Message Passing的问题。
譬如说microkernel，从架构上来讲，的确应该有很多好处，但是由于IPC效率比较差。后来虽然有了很大改进，但是热闹一阵子以后，真正用的人仍然并不是很多。
3.
JWS想脱离浏览器母体，搞台独。台独不得人心。
从功能上来看，java applet 和 flash 是很类似的，但是 flash 占据了主要的市场，而 java applet 却热闹了一阵子以后就有点销声匿迹的感觉。
你文中提到的把浏览器作为通道的问题，其实flash应该也存在这个问题。微软的横插一手，可能是一个重要原因。看现在微软对应于flash，也搞出个silver light，不知道会不会把flash给折腾死。
可能性应该不大，因为flash的应用实在是太多了。有了youtube，我敢肯定flash倒不了。
回到 javascript 上来说，在 google map 出来之前，javascript 可以说是雕虫小技，虽然可以弄点特效，但是只能达到效果而已，并不出彩。也就是 google map 的横空出世，让人耳目一新，才发现 javascript 可以做出那么炫的效果来。一时之间，ajax 引领风潮。
说得非常对。Ajax吊起了众人的胃口，不仅Google Map，而且Google Docs也很实用。我最近的文章都是用Google Docs写成的。
Google Docs有类似于Word，Excel和PPT的功能，但是目前缺了Project和Visio。Project还好说，但是用Ajax来做Visio就太难了。当然也有人做这方面的尝试，譬如Gliffy。但是功能与Visio比起来，少得可怜。
Google Chrome浏览器里，带了一个新型的JS engine，叫V8。据说性能比SpiderMonkey好多了。但是奇怪的是Google Android里面，却没有装V8。去问为什么，迟迟疑疑地回答，担心开发者abuse JS。
换句话说，JS处理一些简单的逻辑的确很方便，但是如果应用逻辑越来越复杂以后，JS engine就不堪重负了。Google不敢在手机里面装V8，担心的是万一手机应用开发商大量使用Ajax，让V8负担太重，一系列问题会显现，CPU时间占用，RAM占用，电池消耗，等等等等。
不是说Google会永远把V8隔绝于Android之外，只是暂时没有放进去，但是我看迟早还是会进去的。但是等一等也好，看看还能改进点什么。