主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃
文中提到相对布局的问题，一语中的，恰恰是现有html+css在手持设备上最大的优势，对于不同屏幕分辨率的适应非常有优势。
叉个话题，绝对定位也是有好处的。
为了给自己省事儿，写了一个网站的二次开发平台（就是拙文我就是喜欢html,css,js咋地》说的事儿，结果离题万里，跑的自己都忽悠不回来了
），其中有个功能是把页面区域拖放到位形成页面的所见即所得功能，在实现的过程中，感觉相对定位对于熟练的web前端开发工程师非常方便，他们几乎可以看着设计稿“翻译”出页面代码，但是如果用程序根据拖拽的结果生成相对定位的css代码，麻烦太大，后来的解决方案是对于熟练使用html+css的，提供直接嵌入页面代码的接口，只会用鼠标拖拽的，就牺牲一点效率，用一段js代码获取屏幕分辨率，即时计算每个页面组件的位置，目前看，工作还行。
这件事情上，就看出老兄的观点非常正确，对于开发人员而言，现有的体系是绝对必要的，不过我倒是觉得，往后看web前端开发，还是有待于一个很好的IDE出来，就像VB之类的，拖拽生成界面，至于分辨率的适应问题，自然应当有计算机来完成，当然这是后话，目前还看不到成熟的产品。不过这种看法从根子上面说，还是应和了老兄的看法，开发效率和运行效率，一般而言，我也是更关注前者(开发效率决定挣钱的速度和后期的可维护性，客户端计算性能，目前看不是很大的瓶颈，要不我再开个公司搭配销售硬件？呵呵，邪恶的商业社会)。
开发效率影响市场的开拓。这个观点很重要。
必须承认，我是比较偏重效率的，有点唯美主义倾向。
下一篇接着唯美，说说为什么我不是JS的粉丝。
不过二位的意见我也接受。美感不一定能赢得市场，时间可能更重要。
为什么非要把开发效率和运行效率对立起来呢？
就拿现在我们用的顺手的rails来说，代码行数少，而且易懂，开发效率没得说，我有个朋友，和别的公司的架构师打赌，然后单枪匹马花了一个半月的时间用rails把人家半年写出来的OA框架实现了，而且代码行数少了三分之一，据说还有重构的余地，大笑而归。这种高效的开发，对于一个需要产品快速上线投入运营的公司而言，非常重要，这时候，挣钱的速度决定于开发的速度。
还是同样的例子，在rails开发效率极高的背后，也有运行效率不尽如人意的现实，客户的rails系统，负载上去之后，就需要在架构上进行调整了，应用服务器级别的负载均衡以及memcache都用上了，呵呵，当然这个是另外收钱，构建的时候，讲究开发效率，跑顺了，有钱了，就开始要求运行效率了，这个时候，运行的速度决定挣钱的速度了。
从商人的眼光看，不同的时期，不同的要求，在合适的时候用合适的方法作合适的事情，这个天经地义。但是作为一个技术出身的花岗岩脑袋，还总有一个念想————为什么鱼与熊掌不可兼得呢？
现在很高兴看到ruby在1.9版本引入的虚拟机技术带来的效率的重大提升，这个就要感谢那些秉承着技术完美主义的先行者了，不仅感谢，而且由衷敬佩，计算机的世界里，不能没有这帮永不知足的家伙。
有他们在，早晚有吃上熊掌烩鲈鱼的一天。
明显的例子就是Apple Inc. 一个秉承技术完美的商业公司。Steve Jobs是Geek nerd么，不是。但是他是技术完美主义者，并且把公司商业化的很好。今后鹿死谁手还很难说
1. Lambda function--这个其实大家经常用,但是可能没注意到
如何指定事件源的事件处理过程呢？
javascript中其实就是用Lambda function是实现的。
如下代码大家一定经常写:
<input id='button1' type='button' onclick='alert("hello")' />
查看button1.onclick的值，就会发现是：function(){alert('hello');} (IE下，其他浏览器略有不同但原
理相同。)
当然，也可以写为：document.getElementById('button1').attachEvent('onclick',function(){
alert('hello');
});
在这里javascript用以Lambda function为基础实现的闭包解决了这个问题。
为什么说这是一大优点呢？对比JAVA就可以看出来：
类似的问题JAVA需要内部类/匿名类实现，如：
button1.addActionListener(
new ActionListener()
{
public void actionPerformed(ActionEvent e)
{
// do some work
}
}
);
优点一是显而易见的--省了代码量---至少不用定义一个类。
优点二： 事件处理一般要伴随状态迁移，这就使得事件处理过程一般带有边际效应。这也就使得为作为事
件处理过程的闭包的引用环境的确定格外重要。
java传递的实际上是匿名类的实例，各个事件处理函数的引用环境实际上是相对独立的。
但实际中，复杂的事件处理通常需要多个不同事件处理过程配合完成。一个稳定而共享的引用环境是比要的
。javascript中，通过method绑定就可以使某些事件处理函数中的this始终指向同一个对象。这样便于封装
状态机的实现。
2. dynamic objects
可以运行时改变类的定义,例子：
String.prototype.alert=function(){alert(this);};
从此，这样的代码就会自动弹出hello对话框：
'hello'.alert();
也就是说，你完全可以改造基础的javascript环境。
3.loose typing
这点如果没用，其他强类型语言也不用引入范式了
4.object literals
以此为基础的JSON经常被作为过于沉重的XML的数据交换时的替代品。
说实话，我平时既是与javascript无关的项目也多用它做控制数据交换，中间再嵌套XML来传递大量记录。
其实，我很认同为高人说的，javacsript是一中被误解很深的语言。从来都被人当玩具，都忘了当年
Netscape的server上也是可以跑javscript的。
这点跟早期的java很像，被人挡玩具看，如果不是被IBM看中了，也翻不了身吧？
说到JavaScript开发的易错难改---说实话我认识的很多开发者还不知道如何调试，跟踪javascript程序。
以上言论纯属抛砖引玉，欢迎指正疏漏
处理问题总要面对主要矛盾和次要矛盾,现阶段你给出的假设中,主要矛盾比较简单需要精简的结构,如果这个OS如果出现的话(实际上已经出现了,而且据说跑的不错),在现有硬件基础上能够给出一个比较完美的运行速度和相对简单的开发环境.但开发的人多了以后, 慢慢就会出现 os1.1 os1.2 os 1.3 ..... 各种版本的升级,而且升级的不是别的,可能就是为了适应大多数开发人员的需求而进行的功能性扩充(录入逐步加入 原本为了速度已经抛弃的一些底层功能),而这个过程中硬件也在发展,例如CPU更快了,闪存价格更便宜等等.
所以到头来有可能webos 的三驾马车与PC平台的差异可能会越来越小,这个可能与原始的初衷有异,主要原因我认为就是主要,次要矛盾的不断变更,大家必须妥协的结果.
平台发布->开发人员跟进->应用产生->应用的新需求->开发人员对于架构的新需求->平台的升级 ,我的理解大概也就是这么一条路子了,最后有可能还是走回PC的基本结构之上或者少有差异.
前面说的都同意。但是是不是会回到PC同一个路子上去，我是持悲观态度的。因为手机与PC的三大区别目前看不到有改变的可能，1. 电池，2.网络，3.手机键盘小，输入不便，屏幕小，界面不能太复杂。
所以，这句话是有可能的，
但是这一句可能过于乐观，
读了又读，写得非常好。
1. Lambda Function
优点二很重要，是不是可以展开详细说说？譬如这一句就值得详细说说，
1. 能不能举个例子？
2. 能不能用Java来实现？两者横向比较一下优缺点。
2. Dynamic objects
深入说明一下为什么运行时改变类的定义是必须的？
或者反过来说，如果没有dynamic objects，哪些功能提供不了？
3. Loose typing
Loose typing 可以理解为Template的超集吗？
4. Object literals
与其它object serialization比较起来，JSON好在哪里？
5. JavaScript的跟踪调试。
是不是可以列举几个JS跟踪调试的工具，横向比较一下，然后说明哪一个你最喜欢等等。
多谢T兄这么有深度的分析。
邓兄谬赞了,小弟所知杂而不精，独立成篇恐力有不逮。但邓兄回复中所提几点，过两天复活节的时候一定会仔细回复。
硬件的性能增加和成本下降几乎是可以预期的，以前台式机上了不起的512M内存，现在手机上轻松可以达到。反过来如何提高开发效率对于吸引开发人员在一个较长的时间内是更为重要的。因此从这个角度dom这种方式会继续并最终胜出。
2. 在确定谁去处理事件，什么时候处理的过程中，需要从根节点沿capture path一路访问到目标节点，再沿bubbling path一路返回根节点，事件处理的过程很长。
如果换用链表结构，执行效率会提高很多。
邓兄此处的结论有点绝对了。
第一、数据结构方面，树搜索O(logN)要比链表搜索O(N)快将近一个数量级
第二、树状结构能够更有效的组织UI的各个元素。管理起来综合成本其实是偏低的
第三、链表不过是树结构的一种特例（单叉树），很多毛病还是继承下来了。
这里似乎概念不太清晰。前面的种种讨论都是局限于Object Model，这里讨论的其实是Presentation Layer。Tree一样可以照此办理，而且结果只会比List快，因为可以砍掉完全无关的子树，最终得到的bitmap只怕还要薄上两分。
为了优化UI而引入Bitmap, 为了减小内存的占用反而又去牺牲UI的可用性，这个Tradeoff不划算啊。
这个并不是List带来的好处，而是Bitmap Z轴带来的好处，可以跟上面的观点合并。
我觉得现在的UI系统已经在各个方面做了很大的优化，考虑了方方面面的情况。既要易用，又要防止WCET爆炸，还要兼顾扩展性。这里扩展性既是extensible也是scalable。想要进一步优化不动动用户的奶酪(用户体验)怕是不行啊。
假设有N个characters，每个character都是一个卡通图像，图像与图像之间有重叠。对于这种情形，树结构的表述很麻烦。链表的搜索效率是O（N)，但是树结构的搜索效率不是O（logN），而是几乎要遍历整个树，也就是O（N logN)。
但是兄台的分析也没有错。如果是文字为主的页面，每段文字之间不存在重叠，树的搜索的确是O（logN）。
所以，树结构和链表结构哪一个更好，取决于页面的主要内容是什么。但是，总体上来讲，我觉得链表结构更通用，更节省计算和存储开销。
引入Bitmap不是为了优化UI和图像的展示，而是为了方便捕捉鼠标移动等等事件。换句话说，假设要展示一个有图像的页面，需要两套frames，一套是专供graphics显示用的，另一套是bitmap。用户看到的是第一套frame，bitmap frame是看不见的，只是为了方便捕捉事件。
我是不是说清楚了？
我前面说的想法，不是常规的思路。我也觉得纳闷，为什么业界不去用我描述的这个简单易行的办法，而是用XML-DOM树结构。我不是想推销什么新构想，而是拿它来和XML-DOM比较，说明XML-DOM的弱点。肯定XML-DOM有什么强有力的优点，但是究竟是什么，至今没有看到有说服力的解释。
V和C分开的。
事实上最早的HTML既没有DOM也没有CSS更没有Javascript。BODY下面就是<h1><p><table>等纯粹的内容标签。这里面只有table繁琐了点，但是对付单列表还是有简单的ol ul等标签。可以说设计者根本也没准备让大家拿网页当报纸排。
结果“伟大的”web工作者们抓住了唯一一个可以自定义结构的标签-------TABLE，这一通发挥。当年俺作为菜鸟都苦练过TABLE框架，TABLE拼图，TABLE画竖线等大招。当年哪个网页不是7-8个TABLE套在一起。
你说这结构化、非链表化的DOM是设计者拍脑瓜子拍出来的，还是被广大开发者逼出来的呢？
-------------------------------
再讨论点题外话
假设有N个characters，每个character都是一个卡通图像，图像与图像之间有重叠。对于这种情形，树结构的表述很麻烦。链表的搜索效率是O（N)，但是树结构的搜索效率不是O（logN），而是几乎要遍历整个树，也就是O（N logN)。
这个例子不完整，我们到底要在DOM上找什么？
找对鼠标所在位置负责的那个character？则是树搜索，O(logN)
找对鼠标所在位置负责的所有character？则是树遍历，O(N)
如果我们规定有效元素只是叶子点，内部点都算overhead。那树结构也不过是把O(N)的问题复杂化为O(N+logN)，还是O(N)。
找对鼠标所在位置负责的那个character？则是树搜索，O(logN)
设想，browser现在知道鼠标的位置（X，Y），如何定位鼠标移动这个事件发生在哪个character上？
如果characters之间有重叠，那么就不能简单地从DOM树的根节点一路向叶子节点找，因为中间节点占据的区域有重叠。所以，成本不是O（logN）。
也就是说，用DOM树来表述2D图像是不方便的。对于这种情形，R-Tree或许更强有力。
但是假设我们要做的仅仅是简单页面的结构处理，还不如简单遍历，也就是链式结构。
如果想遍历树的叶子节点，成本是O（N），但是这里有个前提，必须事先用链表把所有树的叶子节点串联起来。如果没有叶子链表，那么要访问每个叶子节点，成本等同于遍历树，也就是O（N logN）。
这样分析对不对？