Javascript是一个错误吗？

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