對 Web 標準的修訂做得越多，Web 開發的正確方向越值得懷疑。InfoWorld 的 Neil 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 官方網站