主题：【原创】新时代新潮流WebOS 【1】 -- 邓侃
家园 也许换个角度看看会有新的想法？ 早先我和老邓看法一样，对于“脚本”挺看不起的，虽然我靠一大堆脚本获得了大量的在网上闲逛的时间
最近这一年半，因为一个项目的关系，一脚踏进了rails的世界，如今有了一些新的感觉。
也许绕开“脚本”的提法，换成“动态语言”的提法，再来看python,ruby,javascript之类的语言，我感觉，计算机编程语言一路早来，从原先的需要人类按照计算机的路子思考，到现在计算机领会人类的思想，是一条清晰的计算机高级语言进化的路子（我还学过几年中文，语言学当中某些研究和计算机高级语言的发展隐隐合拍，甚至还有点未来预测的意思，呵呵好玩）
看看这些动态语言写出来的代码
3.times do
something
end
这个是ruby的代码
还有一段抄来的很酷的javascript代码
var life = {};
for(life.age = 1; life.age <= 3; life.age++)
{
switch(life.age)
{
case 1: life.body = "卵细胞";
life.say = function(){alert(this.age+this.body)};
break;
case 2: life.tail = "尾巴";
life.gill = "腮";
life.body = "蝌蚪";
life.say = function(){alert(this.age+this.body+"-"+this.tail+","+this.gill)};
break;
case 3: delete life.tail;
delete life.gill;
life.legs = "四条腿";
life.lung = "肺";
life.body = "青蛙";
life.say = function(){alert(this.age+this.body+"-"+this.legs+","+this.lung)};
break;
};
life.say();
};
这恐怕就是很多人说的“优雅”的感觉吧，用这样的语言写代码，感觉计算机能理解我在说什么。
具体到实际的开发工作，如果不是对效率有极端的要求，我肯定选择这样的动态语言。
家园 只是想说 Palm的WebOS的javascript不能完成所有的UI的工作。比如画矢量图。
我想主要是顾及到很多web developer的专业知识的限制，所以palm没有放太多扩展在javascript里面吧。
- 复 只是想说
家园 webkit 支持canvas标签，可以画图 webkit 支持canvas标签，可以画图。
firefox， chrome也都可以，就是不知道IE8可不可以
家园 浏览器画图的问题 作为Rendering Engine，WebKit当然可以在Canvas上画图，不仅WebKit可以，Gecko，Trident等等都可以。
是否能画图，现在的问题不在于Rendering Engine, 而在于浏览器支持什么语言。现在各家浏览器普遍支持的语言只有JavaScript一家，AJAX的支持者开发了很多JS Code，但是我很怀疑JS能走多远。JS作为一个Script，它的功能先天有局限，而且JS calling native code也十分不便。
要让浏览器画图，首先要拿JS开刀。
- 复 浏览器画图的问题
家园 兄台误解了,canvas是最新的HTML5标准，以前只有 兄台误解了,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也十分不便”意为何指？
- 复 只是想说
家园 不妨看看online visio，Gliffy 譬如online visio，www.gliffy.com
不清楚他们是怎么做的，猜测是基于JS。但是你看giffy的loading的时间，好可怕，估计是JS量太大，编译时间长。
既然JS Engine不再是简单的parsing，而是compiling，为什么还执着于script？如果对于Web browser来讲，反向兼容的可以理解，但是对于手机来讲，没有这个历史包袱，为什么还要JS？
家园 这不是flash做的么。。。 类似的东西我见过，联想北京研究院的人做的。做的还可以。
- 复 只是想说
家园 如果我是palm，有一个疯狂的想法 在pre上面整个本地的webserver，这个在技术上比扩展js啥的要简单多了，而且弄好之后，矢量图、本地存储、操作硬件啥的，都迎刃而解
三驾马车还是做他现在能做的就好了，不要再加大负荷，美人他爹说得好：
把合适的计算和数据放在合适的地方，很重要确实很重要！
家园 花，很有启发性 不过关于文中工作流程的结构的需求，现在业界不是这么干的。
HTML/XML + CSS + JavaScript基本可以满足定义工作流程的结构的需求。1. 页面与页面之间的前后顺序可以通过HTML里面HREF实现，加上JavaScript来控制在不同状态下，谁是后续的页面。2. 共享的构件，可以单独存放，当页面引用这些共享构件时，用诸如IMG之类的tag来实现。3. 状态机可以通过JavaScript来实现。http://www.ccthere.com/article/2098571一般来说，大家现在认可的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给出的方案在学习难度上的把握直接决定了未来开发人员群落的规模，对于一个新的平台，这足够成为决定生死的重要原因了（想了想，还是加上之一吧
）- 复 花，很有启发性
家园 羊倌儿提的问题很好，逐个回答 羊倌儿提的问题很好，逐个回答。
1.
大家现在认可的web开发的最佳实践并不是由三驾马车包办工作流程，而是MVC的架构，就客户端而言，处理的是视图的渲染工作，而关于模型和控制器。。。这两部分的工作地点应该是在服务器端是没有异议的，大家都认可客户端不应该负担更多的计算工作。我文中这句话没有指称清楚，“HTML/XML + CSS + JavaScript基本可以满足定义工作流程的结构的需求”，应该表述为，“HTML/XML + CSS + JavaScript是否可以用来定义手机本地工作流程（而不是WEB网页+WEB服务器的工作流程）？如果不考虑运行效率，基本上是可以满足需要的”。
2.
js在状态传递的工作中，一般现在倾向于仅仅让他作获取、发送（存储）两项工作，而不是完整的实现状态机，响应事件的活儿js干了，然后把当前状态扔给服务器，事件对应的节点处理函数以及终态判断的事儿由服务器端撑着，不劳js费神如前所述，文中讨论的是，在没有网络服务器的情况下，JS是否能够承担手机本地状态机的问题。
3.
关于共享组件，老邓的文章一笔带过，我还没看的太明白，如果指的是图片，js代码，或者css代码之类的（比较复杂的例如日期选择或者treeview那样的可以看作图片、html和css的组合）对，我说的就是这个意思。如果羊倌儿不介意，我是否可以厚颜无耻地把这段文字加入文中，以免指称不明。
4.
共享组件。。。存储和复用的工作是浏览器来做的，这一块展开说，缓存什么？何时过期，又得是一大篇，webkit的代码里头，这一块好像就挺复杂的前半段说得对，“存储和复用的工作是浏览器来做的”。但是浏览器不等于WebKit，WebKit是浏览器引用的第三方组件。存储和复用不是WebKit做的，是纯粹的浏览器那部分来处理的。
5.
离线应用对应的本地数据存储问题，html5标准倒是有这一说。Palm WebOS就是打算这么干的。但是我觉得用HTML来访问本地数据，似乎不是很简便的办法，因为访问本地数据，经常要涉及动态参数的设定。在三驾马车里，动态参数的设定由JS负责。如果参数设定由JS负责，干嘛不直接用JS来访问本地数据？原因是JS没有简便调用native code的法门，下一段接着说。
6.
本地硬件的控制以及相关的安全问题，之前说过，需要点亮键盘灯怎么办？三驾马车做不到。基本正确，但是不完全。一个迂回的办法是通过NPAPI，把native code作为插件插入浏览器。然后JS就可以调用Native code的Plugin了。
前面提到JS如何访问本地数据，也可以通过这个迂回的办法来实现。但是这毕竟是迂回的办法。简单就是美，这个办法虽然行得通，但是从技术角度看，不够漂亮。
我在题为“ActionScript3 的确用到了XML”的回帖中说到，“而且更极端的是，我甚至怀疑为什么要用Script，不管是JavaScript还是ActionScript，还是Ruby，Python等等Script”。原因就在于JS等等，不符合简单就是美的原则。
家园 多谢 前半段说得对，“存储和复用的工作是浏览器来做的”。但是浏览器不等于WebKit，WebKit是浏览器引用的第三方组件。存储和复用不是WebKit做的，是纯粹的浏览器那部分来处理的。老邓指正的对，是我糊涂了，犯了低级的概念错误
这段时间结合chrome啃webkit，脑袋短路了，呵呵，帖子里面出现这么低级的概念错误，各位见笑了
发帖子还是得白盒黑盒单元集成的水里火里滚上三回才敢ctrl+enter阿