主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃

不过关于文中工作流程的结构的需求，现在业界不是这么干的。

一般来说，大家现在认可的web开发的最佳实践并不是由三驾马车包办工作流程，而是MVC的架构，就客户端而言，处理的是视图的渲染工作，而关于模型和控制器的分工，尽管现在还有争执，比如业务逻辑究竟应该放在模型层还是控制器层，但是这两部分的工作地点应该是在服务器端是没有异议的，大家都认可客户端不应该负担更多的计算工作。

具体到老邓提到的那三点，现在大伙儿的玩儿法是：

首先，后续页面的问题：后续页面用超链体现，超链的目标由服务器端根据客户端操作状态决定，而不是由js的计算结果决定。

其次，状态机：js在操作状态上确实有工作要做，操作状态的传递有URL参数，cookie,session三种方法，url参数（get）对应小于254个字符长度的短参数传递，比如google的搜索查询关键字传递，url参数（post）一般应用于应用程序类型的参数提交，比如注册，登录，填写订单；cookie存储在客户端，用来表述用户的状态，比如google分析大量使用了cookie存储用户数据；session则完全是服务器端维护，在服务器端，可以存储在db中，也可以表现成file形式，也可以放在内存里面。

因为http协议的无状态特点，用户状态的传递必须分门别类的使用这三种方式实现，实事求是的说，现有的解决方案并不令人满意，比如网站大了，需要水平延展了，那麻烦就来了，无共享架构说起来就是五个字，实现起来，在参数传递方面就会遇到比较大的问题，这是不少架构师安身立命的本钱，也是羽羊到处忽悠赚取不义之财的路子。

js在计算方面的低效是个头疼的事情，所以js在状态传递的工作中，一般现在倾向于仅仅让他作获取、发送（存储）两项工作，而不是完整的实现状态机，响应事件的活儿js干了，然后把当前状态扔给服务器，事件对应的节点处理函数以及终态判断的事儿由服务器端撑着，不劳js费神，服务器处理完了传给客户端，再次渲染页面，然后打完收工。当然，现在的web应用越来越复杂，比如googlemap，js的工作也愈加繁重，ajax的短板就在js上，各种浏览器都在js解释器方面做出努力就可见一斑。

最后，关于共享组件，老邓的文章一笔带过，我还没看的太明白，如果指的是图片，js代码，或者css代码之类的（比较复杂的例如日期选择或者treeview那样的可以看作图片、html和css的组合），那么存储和复用的工作是浏览器来做的，这一块展开说，缓存什么？何时过期，又得是一大篇，webkit的代码里头，这一块好像就挺复杂的，当然webkit的代码我看的不深，半瓶子水，就不多扯了，所以共享组件说错了大伙尽管拍砖。也请老邓指正。

上面拉拉杂杂扯这么多，都是web开发行里头的事情，webOS肯定和现在的web开发有不同，这一点同意老邓的看法，palm用三驾马车的路子，肯定对与现在web程序员是个巨大的吸引力，不过我也觉得这就好像vb->vb.net的过渡一样，看起来很美，因为web加上OS之后，就我看至少有如下几个方面超出了传统web开发的论域。

1、离线应用，仅仅从省电来说，同样性质功能的在线应用应该拼不过离线应用，信号的发射和接收是耗电大户。更极端一点说，internet掉线了，我连个通讯录就查不了了？另外还有个离线应用对应的本地数据存储问题，html5标准倒是有这一说，但是，就凭w3c?肯定赶不上pre的进度。

2、本地硬件的控制以及相关的安全问题，之前说过，需要点亮键盘灯怎么办？三驾马车做不到。

综上，web开发走到今天，基本上是飘在天上的级别，和本地没啥大关系，如果想要在pre上应用，那么就必须解决好落地的问题。对palm来说，铁了心用三驾马车，那么落地的问题就非常有看点，拭目以待，对于传统的web开发人员来说，这些都超出了他们传统的技术领域，palm给出的方案在学习难度上的把握直接决定了未来开发人员群落的规模，对于一个新的平台，这足够成为决定生死的重要原因了（想了想，还是加上之一吧）