主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃
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的存在意义是什么呢？
iPhone的刺激可不轻，如果按照以往Samsung，MOTO和Nokia那样缓慢升级，iPhone这样的性能的手机估计还要等2-3年才会出现。
作为Rendering Engine，WebKit当然可以在Canvas上画图，不仅WebKit可以，Gecko，Trident等等都可以。
是否能画图，现在的问题不在于Rendering Engine, 而在于浏览器支持什么语言。现在各家浏览器普遍支持的语言只有JavaScript一家，AJAX的支持者开发了很多JS Code，但是我很怀疑JS能走多远。JS作为一个Script，它的功能先天有局限，而且JS calling native code也十分不便。
要让浏览器画图，首先要拿JS开刀。
回邓兄(没准是邓嫂？你们两口子文风很象)，很多技术上面的发展细节，不是我等可以左右的，所以仅作为饭后闲聊。这里只说一下这个javascript的事情。
一个语言是否是script，是由其运行时间的状态决定的，跟语法无关。我们可以写一个C++的解释器，也可以做一个javascript的编译器，对用户的不同，就是运行速度。其实x86的汇编，也有hotspot runtime translator / optimizer，听起来很java，对不对？
所以我想问：为什么不保留javascript的语法，在后端把它变化成高效率的编译器？其实google V8已经走出了javascript runtime optimization这一步。那么为什么对于手机，不把html+css+javascript用云去进行编译+优化，转化为紧凑高效的中间格式，发给移动终端呢？这样的好处是：
1.保留了大量现存的网络应用。
2.保留了更宝贵的程序员。
3.不必担心新标准叫好不叫座的事情。
对于javascript调用本地代码的事情，主要是一个安全性问题，M$干过ActiveX可以调用本地代码的事情，这倒不是不可为，只要仔细研究了调用本地代码的危险性，并把危险隔离在某个沙盒里，就是可以做的。
其实我对google的某些做法不是很理解，比如当年收购sketchup，放着网络上面那么多VRML的东西不理，去买这么个公司，不是浪费资源么？google是靠梳理网络现有文档起家的，怎么走了这么一步？
同理，对于javascript，我的看法是：支持现有标准，保护众人已有的投资和努力，并发展之。
格外喜欢这个系列。
没DOM如何实现Capturing&Bubbling?
另一方面，javascript 最热的 AJAX 里核心的 XMLHTTP object 的onreadystatechange 事件各大浏览器又是怎么处理的？用到DOM了吗？
script的优点，不仅是省了compiling&linking.
还体现在其弱类型等动态语言特点。开发效率确实高很多，技术门槛也低。要说复杂度，java对比刚出生时，现在也便成了庞然大物。没有办法，遇到复杂问题，复杂度自然会上去。
至于兄台，说的Parsing的成本，我想这和Compiling和Linking的成本本质上是不一样的。Parsing的成本是程序运行时性能的损失，是客户的成本。 Compiling和Linking的成本是开发人员多耗费的开发时间，是程序开发成本。
这里关键地方是：两个成本是由不同的客体承担的。
价值便在这里产生。
兄台误解了,canvas是最新的HTML5标准，以前只有flash的action script有这样类似的能力。WebKit及Gecko都是刚刚支持，Trident还不支持（trident估计是为了自家的VML，故意不支持）。
绘制向量图与rendering是不同的概念，有了绘制向量图的能力理论上说可以用javascript来写一个Rendering Engine---只要你不怕慢。也可以写2d绘图模拟的3d图形引擎--原理上与基于action script上的PV3d等一样。
传统的HTML标签或DOM对象无法解决如：绘制一条斜度60的直线的问题。当然我们可以通过载入一张图片来解决这个问题，但是一些需要即时通过数据决定显示结果的场合就不适用了（如服务器端提供XML数据，客户端根据数据显示）。
这也就是为什么基于HTML4的技术下无法做在线画图板程序而flash下就很多的原因--flash有Graphics对象，可以支持lineTo(x,y)等。
其实，要说HTML4下完全不行也不对，IE下有VML (google maps在IE5.5+以上用的是VML,street view 用的是flash),WebKit及Gecko有SVG。但这都不是HTML标准。到了HTML5，HTML+CSS+Javascipt 的解决方案才有了通一的向量图绘图方案.这点，确实基于flash的方案要强大很多。
但这一切都不是javascript的问题，也可以看到，上面已广泛应用的，及将要广泛应用的方案都没有改变javascript。
另,不知兄台说的“JS calling native code也十分不便”意为何指？
是邓兄在回复，邓嫂这几天在忙别的。刚才晚饭的时候，邓兄把最近的讨论简略地向邓嫂做了汇报。邓嫂边听边剥虾，说，“你们先讨论着，回头我看看”。邓兄把头埋下，不敢正视，咕咚一声很响地喝了一大口汤。。
说正事，
1.
反问一句，如果JS需要编译好了再发到浏览器上去，为什么需要保留JS，而不直接用Java？
换句话说，为什么浏览器一定要死抱着JavaScript，而不内置一个JVM，直接支持Java？
或许有人说，早年浏览器都支持Java Applet，后来没有人用Applet，因为JVM启动慢，版本匹配也经常出问题。启动的问题，在于每个网页的Applet都在一个独立的JVM上运行。如果有个全局的JVM，不管哪个网页都用它，就不存在启动慢的问题。版本的问题，在于浏览器厂商自行决定使用哪个版本的JVM，譬如MS的IE内置的JVM就不同于Sun的JVM。为了解决这个问题，Sun的办法是把JVM移出浏览器，搞了一个Java Web Start。但是这样做，代价是浏览器和外置的JVM之间数据交换的成本高。
所以我的偏激的看法是，美老爹分析得很对，但是结论有疑点，不是JS技术上有什么优点，它存在的理由仅仅是钻了空子，也就是浏览器内置JVM在商务上的纠葛。
2.
对于Google手机而言，它已经有了Android/Dalvik VM，何不把手机上的WebKit和Dalvik联成一体？为什么还要保留JS这个第三者？
3.
我的看法更极端，连Sandbox都不需要，只要规定好哪些native APIs能够被调用，哪些不能即可。
4.
同意，同时我也不理解，为什么Google不去收购一家做Online Visio的公司，丰富Google Docs。
5.
我比较激进，看不到JS存在的强悍理由，未来JS不看好。
观点比较偏激。无知出偏激，估计是有些问题我没有想明白，欢迎美老爹继续斧正。（你的评论很好，但是目前还没把我彻底驳倒。我是那种被按在地上动弹不得才服软认输的家伙。
忙了一天，老眼昏花，脑子也转不动了。
回头再聊，你的诸问题实在很好，容我养足元气再一一回答。老眼昏花，脑子缺氧的时候，回答这些硬骨头问题，是件非常吃力的事情。
linux哦？
web server只为本地服务，tcp/ip低效咯，可是pre是linux内核的，有个很不错的玩意儿叫做socket，呵呵，所以我才敢这么胡扯地
虽然SYMBIAN C++难用了点，但是我们OS的效率很高。看NOKIA的主流机都300M+HZ， 再看看WINDOWS MOBILE和IPHONE的硬件配置，要是NOKIA狠心点搞出同样的配置，我们的OS肯定是最快的。 当然，现在我们被NOKIA收购了，和S60要整合，看整合出的新SYMBIAN FOUNDATION的RELEASE咋样了。
SYMBIAN的历史包袱太沉重，当时C++98还没通过，SYMBIAN自己搞出什么CLEANUPSTACK，描述符等一堆东西，我承认，是对程序员不太友好... 可是也没法改了，LIB里面全是这里LEAGCY CODE， 根本没法动。
GOOGLE IPHONE PALM的系统开发的迟，有后发优势。
不过我们自己觉得 对我们威胁最大的还是GOOGLE 的 ANDROID， NOKIA收购SYMBIAN主要还是为了应对ANDROID开源。
要是比软件资源，S60显然还是大大超过其他系统的～
问题就在这个地方，假如写Symbian，会出现这种情况，写着写着说，Symbian不合理的地方太多了。Symbian的弟兄们回复，我们知道，但是就是改不了。遇到这样的局面，你还有兴致接着写吗？
给Nokia手机锦上添花可以，但是有人会为了S60的某个应用区买Nokia的手机吗？
比如黑莓或者Iphone这样。
NOKIA收购SYMBIAN和QT后将会做一个很大的结构上的调整，LIB也会做相应的变化，虽然老的没法改，但是可能会以新LIB的方式修改原来的不合理的地方。虽然我们为了维护二进制兼容和代码兼容被LEAGCY的东西束缚了手脚，可是要是NOKIA那天决定不管这些了（不是没发生过～）， 搞出一个全新的SYMBIAN也不是没可能～。
SYMBIAN现在内部文化也在变，以前强调的是QUALITY，现在呢？ USER EXPERIENCE， TIME TO MARKET。