Javascript 是一個錯誤嗎？

對 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 官方網站