对Web标准的修订做得越多Web开发的正确方向越值得怀疑InfoWorld的NeilMcAllister对Web开发的现状与未来做了很好的思考
最近ECMAScript标准被弃用统一为ECMAScript如果任ECMAScript发展Javascript将带来巨大变化Adobe的EdRowe告诉作者大部分人对Javascript一类语言存在障碍这是为什么Adobe当初加入ECMAScript阵营的原因Adobe以及ECMAScript希望带来一些适于大规模程序的概念
然而尽管大规模程序的开发对Adobe可能是好的可以肯定它未必对任何人都可行传统程序语言就是一个例子
对任何Java程序开发正规军来说强类型包装以及命名空间尽管对维护大型程序来说可能很容易但对Web程序员来说几乎没有什么用处Web程序员仅仅想通过编程对UI搞一点花样
事实上ECMAScript委员会想创造一种万能编程语言的初衷非常值得置疑曾经有一群非常聪明的人联合起来想写一个终极语言这种语言非常安全有活力且非常标准化几乎没有需要解释的地方这就是Ada现在没有人还记得Ada因为这种语言非常严格缺乏灵活人们宁愿使用C
既然没有人能够创造一个终极的完美的传统编程语言又怎么能指望我们可以为Web创造一个这样的语言?我们越多讨论大规模Web程序越应该知道单一的编程语言将永远无法适合任何工作
作者非常喜欢ModelViewController设计模式然而这个模式并不适合于任何场合不过这个模式可以为程序开发提供一套指南总体上说ModelViewController的核心是从数据层业务逻辑层分离展示层浏览器可以算作View(展示层)我们不应强迫它同时成为业务逻辑层
自从有了Javascript我们对它的指望越来越多企图用它来创建整个程序事实上Javascript不可能适合任何任务我们不应该将越来越多的业务功能硬塞进浏览器应该让浏览器专心作展示而在其它地方展开业务逻辑
比如插件当然很多Web开发者会告诉你插件不是好东西每次你强迫用户下载安装插件都相当于在你的代码前面设置了障碍事实是这样吗?
早期的插件绝大多数用来提供多媒体功能很快就成为在线营销工具那时人们使用拨号上网但很少有人怀疑人们对插件的耐心
现在的例子是GoogleGears一次性安装GoogleGears任何基于GoogleGears的程序都获得额外的功能目前基于GoogleGears的站点不仅包含GoolgeDocs与GoogleReader也包含MySpacePicasa甚至Wordpress
人们倾向于GoogleGears的离线运行Web程序的能力却忽视了WorkerPool模块WorkerPool允许Javascript在后台执行独立于网页代码WorkerPool是独立的代码执行引擎只不过刚好象普通浏览器那样运行相同的Javascript代码
为什么要用JavaScript而不是PythonLisp或其它如果有一种应用有足够的说服力就有足够的动力将它设计成插件尤其是在现在的宽带世界这样的例子已经存在Adobe的Flash插件就可以执行ECMAScript标准的脚本其它平台还包括Curl与REBOL
作为Web开发者我们羞于选择其它道路只是在无休止地对JavaScript进行改进和标准化因为那是Web标准我们告诉自己JavaScript是一个纯净的选项
但如果只拘泥于单一的方式我们为什么还要费这番力气?我们已经拥有一个功能齐备的客户端做任何事情从数据库到email它已经安装到成千上万的企业这就是LotusNotes
这就是我们前进的方向?这就是将来的浏览器模型?或者对Web开发界来说我们是否应该跳出这个圈子思考问题?
