主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃
举一个实际的例子，一个基于Java的产品很成功，但下一个版本最终决策投入大量人力物力用.Net重做。理由很简单，微软不再做Java。
曾经认为Flash是方向，但这么多年过去，似乎还没有到打动决策层的地步。大公司选择.Net，因其来自微软。小开发选择Javascript，因其门槛低。Flash有高不成低不就的感觉。当然，这只是个人感觉。
WebKit的功能很强大，光用来做浏览器，实在太可惜了。应该充分挖掘，去做更多的事情。
WebKit很强大，可惜文档太少，所以潜力没有充分被挖掘。
如果有详细的文档，就会帮助更多的人熟悉WebKit，就会开发出更多的应用，而不仅仅是浏览器。
WebKit的DOM和Rendering Trees，限制了它的应用领域。Flash相对于WebKit之类，就是在数据结构方面，又大大拓展了一步。
我先讨论WebKit的数据结构，然后分析它的不足，这时候再引申一步，讲Flash在这个大的背景之下，好处在哪里。
有此事否，谁知道详情？
技术上的优劣倒在其次，话说又不是“rocket science”，谁怕谁啊。但java的最大优势就是那个跨平台，到了微软这，半壁江山的平台在微软手中，还跨个什么劲。说穿了，java不过就是非微软们对抗微软的手中一杆旗子，执旗的是IBM。微软则是兵来将挡，你不让我掺和java，我就照抄，然后改个名叫Csharp，但跟java却分得泾渭分明。
实际上几个大头之间的这场戏，就如皇帝新衣，没谁真把他们口中的技术长短当回事，都是为了做技术市场的，不忽悠做技术的忽悠谁。到了企业中主管那里，他才不管什么技术呢，只看投入产出，再到了用户手上，更不管技术了，只看UI与攻能。因此，这中间做技术的人其实很尴尬，忽悠掏钱的人又不成，只能忽相之间对着PK，最后一看都不过是给大厂商当打手，时代向前一迈步，这些PK多年的陈年旧事就都给扫到历史垃圾堆去了。
用java在浏览器中替代JS，这事还是别当真了。java都这么legacy的东西了，实在想的慌，改个名字，也能让人兴奋一把，否则真让人以为软件业没人了，是不是还要把cobol也抄起来呢。
天下东西不过是揉开了，掰碎了，再放在一起；然后再揉开了，掰碎了，再再放在一起；.....如此反复，反复无穷。
做技术市场的要为企业主管，为企业主管的客户考虑；企业主管也要为做技术市场的，为自己的客户考虑；做客户的难道不要为企业主管，为做技术市场的考虑？就为自己的钱袋子考虑？
于是乎，俺听到了PM对VP的抗议之声：Cost/Time/Quality(features or functionality) - pick any two.
这都哪是哪，还是老百姓的大实话说的明白 --- 要想马儿跑的好，就要给马多吃草。就象西西河，要想读原创，河友就要多跳坑。
不过Adobe 的CEO 是个印度人。
所有静态语言请一边肃立。
动态语言有几个能嵌到浏览器里，编到flash里，跟windows服务打交道，还能指挥指挥acrobat、photoshop，顺道还跟Java虚拟机套套近乎？
所谓的浏览器不过是语言的支持库而已。javascript语言本身还是蛮精致的。除了正则表达式用起来没有perl痛快。
我自己用Javascript做过一个小东西，05年在Yahoo Widget平台上写的一个3500行代码的Widget，名字没啥创意，就叫Infobar
因为widget的JS引擎取自mozilla，所以和firefox完全一致
写这个程序都碰上哪些问题了呢？
一、JS没有包装事件委托的Context，而是就地运行。换句话说，某object把自己的一个方法a()提交出去，当a()被第三方callback时，这个方法根本就不知道自己的爹是谁。为了解决这个问题很是费了一通脑筋。因此，我认为没有闭包是JS的一大缺点，而不是优点。Java做的就不错，nested class除了语法麻烦点，语义还是很清楚的。C#的lambda算子我很喜欢，但是语义过于动态了。
二、我对动态改变class定义没有啥深刻的认识。但是在做设计时常会碰到要把两个完全不相关的类型树融合，对于单根继承的C# java, 这种情况痛苦无比。要是换成动态语言，允许直接改动基础类的定义，那就简单的多了。
三、弱类型在小范围使用时非常高效。在大项目中使用就是灾难。这个infobar后来不再维护，起因就是一个窗口的属性会随机乱变，无从跟踪，弄了几周都搞不好，不知道是谁干的。加上vista出来啦，侧边栏这块儿有了替代品，就停止更新了。相比之下我更看好自动类型推导
四、JSON比普通的序列化语义性好，比xml清爽得多。也没有big little endian，16bit/32bit integer等问题，在JS环境下可以简单的eval，自然就流行了。
五、调试的大牛要数firebugs，当年要是有这类东西，我这个infobar绝对不会做到一半就废了，嘿嘿。
管它什么语言，到了后台，还不是一样变成汇编去跑。chrome里面加了js的JIT，以后肯定还会有js的hotspot runtime optimizer。语法是什么有什么关系，到了runtime都给优化了，变成本地代码，要我说，给BASIC加点跟DOM有关的扩展，一样跑。
这个时候，争的就是不是语法了，是程序员的接受程度。至于是那种语言？WallE里面的auto有句名言：
Irrelevant, Sir...
写得言简意赅。没有实际动手的经历，写不出这样的文字。
【19】走进WebKit
1. 总体结构
Webkit是开源项目，它的源代码可以去这里下载，http://webkit.org/building/checkout.html。Webkit是一个相当复杂的软件系统，打开源代码，可以看到里面有众多文件夹。但是Webkit的源代码组织得很好，虽然程序多，但是结构清楚。相对而言，Firefox浏览器使用的Gecko渲染机的源代码，个人的感觉比较乱，不容易理出头绪。
毛主席教导我们，“我们的方针是路线决定一切，人多，枪多，代替不了正确的路线。路线正确就有一切，路线不正确有了也可以丢掉。路线是个纲，纲举目张”。对于软件工程，主席的教导依然具有指导意义。不妨把主席的教导改动一下，“软件工程的方针是结构决定一切，代码多，功能多，代替不了正确的结构。结构正确了，不断改进以后就有一切，结构不正确，有了也可以丢掉。结构是个纲，纲举目张”。现代软件工程的语汇里，结构多半特指object-oriented的结构。Webkit源代码十分严格地遵循object-oriented的原则来组织，这样做的好处不仅仅有利于后续开发和维护，而且也便于研读源代码。
Webkit 源代码由三大packages组成，1. WebCore，2. WebKit，3. JavaScript。当输入一个HTML文件，WebCore的职责是解析每个HTML Tag，以及它们之间的从属关系，生成一棵树状的数据结构（DOM Tree），然后结合HTML文件中指定的CSS定义，确定DOM Tree中每个节点的在整个页面中的位置，以及颜色字体等等。布局与渲染效果的确定，以属性和属性值的形式，存放在另一棵树状数据结构中，这另一棵树称之为Rendering Tree。通常情况下，Rendering Tree的结构与DOM Tree大致相同，基本上DOM Tree里面每一个节点，在Rendering Tree里都有对应的节点。
这里有两个疑问，1. 为什么既有DOM Tree，又有Rendering Tree，两者合一不是更省内存吗？2. Rendering Tree为什么要与DOM Tree保持一致？不一样又如何？这两个问题，我们稍后讨论。
Rendering Tree只是确定了该如何渲染HTML页面，有点像司令部里的参谋们制订作战计划。但是具体的渲染，包括画点画线字体等等，在不同的OS，甚至不同的硬件环境下，实现的方式各不相同，这就像真正冲锋陷阵，还得靠前线将士。Webkit源代码中的WebKit package，里面包含的程序，就是这些前线将士。WebKit package中有 win/, mac/, gtk/, qt/, wx/ 等等 subpackages，就是针对各个不同OSes，以及各种不同的跨平台的图形库，所采取的因地制宜的渲染手段。与各个不同的OSes相关的，不仅仅是渲染，还有鼠标移动和键盘点击等等用户触发的UI事件的捕捉。所有这些与具体Oses相关的程序，通通被放置在WebKit package中。
Webkit源代码中第三个主要部分，是JavaScript engine。JavaScript engine用来解析JavaScript代码，并执行。这个系列里不展开介绍JavaScript engine。
2. DOM Tree 与 Rendering Tree 是否必须一致？
“ 天下文章一大抄”，这话说来难听，但是却是实情。很少有文章从头到尾，字字原创，而绝大多数都是在消化整理前人和他人的知识基础上，添加自己的一点点发挥和创造而成。人类的文明进步，就是这样一点一滴，逐渐积累起来的。既然文章离不开引经据典，旁征博引，阅读文章的时候，也就免不了需要查阅相关文献。
在 Web出现以前，查阅文献是一件费时费力的事情。1989年3月，在欧洲原子能研究组织（CERN）工作的Tim Berners-Lee，提议在TCP/IP协议基础之上，建立一个相互链接的信息系统。这个建议很快发展成为万维网（World Wide Web，简称Web），极大地方便了文献的查阅。Web的核心，是hyperlink。在撰写网页时，可以对于某些词句，设置隐含的 hyperlinks。当读者点击这些词句时，计算机就会根据词句背后隐含的hyperlink，自动打开另一个网页。请注意“隐含的”这个词，这意味着文章的显示（Presentation），与文章的内容（Content）并不完全一致。
Tim Berners-Lee考虑到这一问题，于是建议给每个Web网页制订一个规范，这个规范就是“超文本标识语言”，简称HTML。最初的HTML制订了 22个标识，标注两方面的功能，1. 内容，包括引用，2. 显示格式。在同一份HTML文件，把内容和格式混杂在一起，这是一个设计错误。20年过去了，现在的HTML文件，基本上是以内容为主，格式被分离出去，由CSS定义。除此之外，还增加了与读者互动的动作，这些互动动作，通常由JavaScript定义。
为什么分离比合并好？同一份内容，针对不同的读者，可以通过不同的CSS，改变显示的方式，举几个例子。针对新人类，可以用卡通图标替代某些特定文字。针对老派读者可以换用大号字体，从上往下，从右往左排版。对于正在开车的听众，可以用朗诵替代文字显示。
内容与格式分离，并不等同于DOM Tree与Rendering Tree并存。假如内容由HTML承载，格式由CSS定义，我们可以只用一棵树，不仅存放内容，也存放格式属性。DOM Tree与Rendering Tree分离，好处在于同一棵DOM Tree，可以对应多棵Rendering Trees，也就是同一个内容，可以由多种不同的方式来布局和渲染。在当今的浏览器里，一棵DOM Tree对应多棵Rendering Trees的情况不常见，因为同一个页面，通常只有一种风格的布局和渲染。但是在电子游戏中，同一个场景会有多个不同视角，譬如枪战游戏中，有枪手本人视角，有旁观者视角，还有俯瞰视角等等。换句话说，Webkit不仅满足了当今浏览器的普通需要，而且提供了一些尚没有被广泛利用的潜在的功能。把DOM Tree与Rendering Tree分离的做法，虽然浪费了一些内存空间，但是着眼于未来，Webkit这样的结构设计，为未来的发展埋下了伏笔。
目前而言，Rendering Tree的结构基本上与DOM Tree的保持一致，DOM Tree里每一个节点，在Rendering Tree都有对应节点，父子节点之间的继承关系也保持一致。但是Webkit的代码，给Rendering Tree结构的异化，也埋下了伏笔。Rendering Tree的结构，不一定与DOM Tree保持一致。举个例子，或许未来的网页可以提供个性化的编辑方式。当读者第一次打开某个页面的时候，看到的是标准的页面，也就是Rendering Tree与DOM Tree保持一致的页面。读者可以摘录网页中某些段落，删除不感兴趣的段落，改变着色，改变字体，甚至重新布局。以后再次造访这个页面时，这位读者就可以看到个性化的页面，而所谓个性化的实现方式，其实就是构筑另一棵Rendering Tree。假如他想恢复标准的网页，只需要重新调用标准的Rendering Tree，重新渲染一遍网页即可。在这个例子里，我们可以看到个性化的Rendering Tree，与DOM Tree保持一致的标准的Rendering Tree，两者并存的场景。
再举一个例子，通常的地图，都是俯瞰图，也就是同一种透视角度。能不能在同一张地图中包含多个透视视角？听起来匪夷所思，但是有人尝试了这种新奇大胆的设想。如果套用DOM Tree和Rendering Tree的概念，可以解释为DOM Tree与Rendering Tree不完全一致。上半段的俯瞰视角的地图，对应的Rendering Tree的子树，与DOM Tree相关子树一一对应。但是下半段的平视视角的地图，对应的Rendering Tree的子树，是DOM Tree相关子树的一个子集，因为有些楼宇和道路，被前方的楼宇遮挡住了。
Figure 1. Here-and-there map of Mahanttan
Courtesy http://farm3.static.flickr.com/2464/3545962330_8bc666f68e_o.jpg