对 Web 标准的修订做得越多,Web 开发的正确方向越值得怀疑。InfoWorldNeil McAllister 对 Web 开发的现状与未来做了很好的思考。

最近, ECMAScript 4 标准被弃用 (请参阅:Javascript 2 前途尘埃落定),统一为 ECMAScript 3.1,如果任 ECMAScript 4 发展,Javascript 将带来巨大变化,Adobe 的 Ed Rowe 告诉作者,大部分人对 Javascript 一类语言存在障碍,这是为什么 Adobe 当初加入 ECMAScript 4 阵营的原因,Adobe 以及 ECMAScript 4 希望带来一些适于大规模程序的概念。

然而,尽管大规模程序的开发对 Adobe 可能是好的,可以肯定它未必对任何人都可行,传统程序语言就是一个例子。

对任何 Java 程序开发正规军来说,强类型,包装,以及命名空间尽管对维护大型程序来说可能很容易,但对 Web 程序员来说几乎没有什么用处,Web 程序员仅仅想通过编程对 UI 搞一点花样。

事实上,ECMAScript 委员会想创造一种万能编程语言的初衷非常值得置疑,曾经,有一群非常聪明的人联合起来,想写一个终极语言,这种语言非常安全,有活力,且非常标准化,几乎没有需要解释的地方,这就是 Ada,现在没有人还记得 Ada,因为这种语言非常严格,缺乏灵活,人们宁愿使用 C。

既然没有人能够创造一个终极的,完美的传统编程语言,又怎么能指望我们可以为 Web 创造一个这样的语言?我们越多讨论大规模 Web 程序,越应该知道,单一的编程语言将永远无法适合任何工作。

作者非常喜欢 Model-View-Controller 设计模式,然而这个模式并不适合于任何场合,不过这个模式可以为程序开发提供一套指南,总体上说,Model-View-Controller 的核心是从数据层,业务逻辑层,分离展示层。浏览器可以算作 View (展示层),我们不应强迫它同时成为业务逻辑层。

自从有了 Javascript,我们对它的指望越来越多,企图用它来创建整个程序,事实上,Javascript 不可能适合任何任务。我们不应该将越来越多的业务功能硬塞进浏览器,应该让浏览器专心作展示,而在其它地方展开业务逻辑。

比如,插件。当然,很多 Web 开发者会告诉你插件不是好东西,每次你强迫用户下载安装插件,都相当于在你的代码前面设置了障碍,事实是这样吗?

早期的插件绝大多数用来提供多媒体功能,很快就成为在线营销工具,那时,人们使用拨号上网,但很少有人怀疑人们对插件的耐心。

现在的例子是 Google Gears,一次性安装 Google Gears,任何基于 Google Gears 的程序都获得额外的功能。目前,基于 Google Gears 的站点不仅包含 Goolge Docs 与 Google Reader,也包含 MySpace, Picasa 甚至 Wordpress。

人们倾向于 Google Gears 的离线运行 Web 程序的能力,却忽视了 WorkerPool 模块,WorkerPool 允许 Javascript 在后台执行,独立于网页代码。WorkerPool 是独立的代码执行引擎,只不过刚好象普通浏览器那样运行相同的 Javascript 代码。

为什么要用 JavaScript,而不是 Python, Lisp 或其它。如果有一种应用有足够的说服力,就有足够的动力将它设计成插件,尤其是在现在的宽带世界。这样的例子已经存在,Adobe 的 Flash 插件就可以执行  ECMAScript 4 标准的脚本,其它平台还包括 Curl 与 REBOL。

作为 Web 开发者,我们羞于选择其它道路,只是在无休止地对 JavaScript 进行改进和标准化。因为那是 Web 标准,我们告诉自己,JavaScript 是一个纯净的选项。

但如果只拘泥于单一的方式,我们为什么还要费这番力气?我们已经拥有一个功能齐备的客户端做任何事情,从数据库,到 e-mail,它已经安装到成千上万的企业,这就是 Lotus Notes。

这就是我们前进的方向?这就是将来的浏览器模型?或者,对 Web 开发界来说,我们是否应该跳出这个圈子思考问题?

 

本文国际来源:http://weblog.infoworld.com/fatalexception/archives/2008/08/was_javascript.html
中文翻译来源:COMSHARP CMS 官方网站







  发送给朋友| 打印友好
7 x 12 小时服务热线
0532 - 83669660
微信: comsharp
QQ: 13885509
QQ: 592748664
Skype: comsharp