主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃
家园 从开发效率和运行效率比较，长远来看总是前者胜出 硬件的性能增加和成本下降几乎是可以预期的，以前台式机上了不起的512M内存，现在手机上轻松可以达到。反过来如何提高开发效率对于吸引开发人员在一个较长的时间内是更为重要的。因此从这个角度dom这种方式会继续并最终胜出。
家园 树性结构有其必要性:要开发速度还是效率? 兄台主张的方案效率很高,但是不便于设计人员开发---主要是界面布局上会有困难。
传统的WEB开发个人认为最大好处是支持元素的相对定位式的布局。
而丧失包含关系的方案下，仅能绝对定位式布局。
这两种方式的工作量相差是很大的---尝试把所有元素的style的position属性设为absolute后，用HTML+CSS设计一个页面就会明白两种方式的差距。
这也就是为什么同样基于flash的Adobe Flex要搞个MXML出来。
MXML最终还是要先转化为action script代码再编译成swf flash文件的。
看似MXML是多余的，但是它使得开发人员可以进行相对定位式的布局。
效率和开发便捷度应该那个优先？
这个问题很难有定论，但如果讨论的是webos的话，恐怕还是应该开发便捷优先。因为这是web os的出发点。如果追求效率个人认为不如用C+java。
家园 老兄肯定是实战派的 文中提到相对布局的问题，一语中的，恰恰是现有html+css在手持设备上最大的优势，对于不同屏幕分辨率的适应非常有优势。
叉个话题，绝对定位也是有好处的。
为了给自己省事儿，写了一个网站的二次开发平台（就是拙文我就是喜欢html,css,js咋地》说的事儿，结果离题万里，跑的自己都忽悠不回来了
），其中有个功能是把页面区域拖放到位形成页面的所见即所得功能，在实现的过程中，感觉相对定位对于熟练的web前端开发工程师非常方便，他们几乎可以看着设计稿“翻译”出页面代码，但是如果用程序根据拖拽的结果生成相对定位的css代码，麻烦太大，后来的解决方案是对于熟练使用html+css的，提供直接嵌入页面代码的接口，只会用鼠标拖拽的，就牺牲一点效率，用一段js代码获取屏幕分辨率，即时计算每个页面组件的位置，目前看，工作还行。这件事情上，就看出老兄的观点非常正确，对于开发人员而言，现有的体系是绝对必要的，不过我倒是觉得，往后看web前端开发，还是有待于一个很好的IDE出来，就像VB之类的，拖拽生成界面，至于分辨率的适应问题，自然应当有计算机来完成，当然这是后话，目前还看不到成熟的产品。不过这种看法从根子上面说，还是应和了老兄的看法，开发效率和运行效率，一般而言，我也是更关注前者(开发效率决定挣钱的速度和后期的可维护性，客户端计算性能，目前看不是很大的瓶颈，要不我再开个公司搭配销售硬件？呵呵，邪恶的商业社会)。
家园 Time to market 开发效率影响市场的开拓。这个观点很重要。
必须承认，我是比较偏重效率的，有点唯美主义倾向。
下一篇接着唯美，说说为什么我不是JS的粉丝。不过二位的意见我也接受。美感不一定能赢得市场，时间可能更重要。
家园 和个稀泥，最近一些新的看法 为什么非要把开发效率和运行效率对立起来呢？
就拿现在我们用的顺手的rails来说，代码行数少，而且易懂，开发效率没得说，我有个朋友，和别的公司的架构师打赌，然后单枪匹马花了一个半月的时间用rails把人家半年写出来的OA框架实现了，而且代码行数少了三分之一，据说还有重构的余地，大笑而归。这种高效的开发，对于一个需要产品快速上线投入运营的公司而言，非常重要，这时候，挣钱的速度决定于开发的速度。
还是同样的例子，在rails开发效率极高的背后，也有运行效率不尽如人意的现实，客户的rails系统，负载上去之后，就需要在架构上进行调整了，应用服务器级别的负载均衡以及memcache都用上了，呵呵，当然这个是另外收钱
，构建的时候，讲究开发效率，跑顺了，有钱了，就开始要求运行效率了，这个时候，运行的速度决定挣钱的速度了。从商人的眼光看，不同的时期，不同的要求，在合适的时候用合适的方法作合适的事情，这个天经地义。但是作为一个技术出身的花岗岩脑袋，还总有一个念想————为什么鱼与熊掌不可兼得呢？
现在很高兴看到ruby在1.9版本引入的虚拟机技术带来的效率的重大提升，这个就要感谢那些秉承着技术完美主义的先行者了，不仅感谢，而且由衷敬佩，计算机的世界里，不能没有这帮永不知足的家伙。
有他们在，早晚有吃上熊掌烩鲈鱼的一天。
家园 妙论 T兄所言，在下无一字不同意。
是否认同Palm WebOS的设计，首先是价值观的问题，其次是假设前提是否成立的问题。
CPU更快了，内存硬盘更大了，硬件发展了以后，是减低开发的难度，还是提高产品的性能？就像给一个人一笔钱，他是当即大吃大喝一顿，还是攒着去投资？
很多人认为后者是当仁不让的选择，可是，事实上更常见的是前者。
价值观以外就是我那个前提假设，手机页面简单，不需要复杂结构。如果这个前提假设错了，后面一切一切都跟着错。
- 复 妙论
家园 俺们也来"瞎想"一下 处理问题总要面对主要矛盾和次要矛盾,现阶段你给出的假设中,主要矛盾比较简单需要精简的结构,如果这个OS如果出现的话(实际上已经出现了,而且据说跑的不错),在现有硬件基础上能够给出一个比较完美的运行速度和相对简单的开发环境.但开发的人多了以后, 慢慢就会出现 os1.1 os1.2 os 1.3 ..... 各种版本的升级,而且升级的不是别的,可能就是为了适应大多数开发人员的需求而进行的功能性扩充(录入逐步加入 原本为了速度已经抛弃的一些底层功能),而这个过程中硬件也在发展,例如CPU更快了,闪存价格更便宜等等.
所以到头来有可能webos 的三驾马车与PC平台的差异可能会越来越小,这个可能与原始的初衷有异,主要原因我认为就是主要,次要矛盾的不断变更,大家必须妥协的结果.
平台发布->开发人员跟进->应用产生->应用的新需求->开发人员对于架构的新需求->平台的升级 ,我的理解大概也就是这么一条路子了,最后有可能还是走回PC的基本结构之上或者少有差异.
家园 除了最后一句都同意 平台发布->开发人员跟进->应用产生->应用的新需求->开发人员对于架构的新需求->平台的升级 ,我的理解大概也就是这么一条路子了,最后有可能还是走回PC的基本结构之上或者少有差异.前面说的都同意。但是是不是会回到PC同一个路子上去，我是持悲观态度的。因为手机与PC的三大区别目前看不到有改变的可能，1. 电池，2.网络，3.手机键盘小，输入不便，屏幕小，界面不能太复杂。
所以，这句话是有可能的，
到头来有可能webos 的三驾马车与PC平台的差异可能会越来越小但是这一句可能过于乐观，
最后有可能还是走回PC的基本结构之上或者少有差异.
家园 花,是否用XHTML的效率会比HTML高一点 家园 没什么区别 或许XHTML在验证语法的步骤会比HTML快一点点，最多是一点点而已。
家园 爆了~ 惊喜：所有加你为好友的，在本帖先送花者得【通宝】一枚鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望】
家园 沙发 轮到俺了。