Node 近年來風卷殘云，在世界各地風起云涌。進入新公司后，陰差陽錯作為一個后端工程師開啟了猛攻node的進程。不想，進展神速，現在已在node技術棧上開發出了公司的即時消息系統。在安營扎寨的那些日夜里，穩打穩扎、挑燈夜戰的經歷讓我想把其中的所想所得記錄下來，這個想法在心里扎根兒頗久了。

這其實是我從業以來的第一篇正正經經的技術博客。初入行時，曾經在博客園開墾了第一鋤頭，當時的疑似站長還跑來我的博客樹立典型示例性地鼓勵了一下，我原本以為自己會在那里搭起枝繁葉茂的花園，結果，剛轉行的我實在干涸枯竭，不敢東拼西湊生拉硬扯。

沒成想，今天查找資料的時候，突然進到這篇文章，在對比node & opa。文章底下還沒有任何人點贊，作為一對 counterpart，我覺得它們顯然被輕視了。對比的做法已經顯示了生態視角。開博的沖動瞬間成苗。此文作為培養自己的開始。是為武夫提筆志。

原文：http://www.csdn.net/article/2012-03-05/312756

? ? ? 導讀：一個標準的網絡項目包括在網絡框架下的服務器編程語言、客戶端的JavaScript代碼和帶查詢語言的數據庫（如SQL）等等。要掌握、裝配和整合的技術真是不少。難怪很多開發者在他們輸出“Hello world”之前就已經厭倦了。很多工具開發者都意識到這樣是行不通的，他們開始尋求更全面地整合其中的一些方面（Google的Web Toolkit就是此類努力的成果）。在動態編程和敏捷開發主導的領域， Node.js和Opa是兩種現代典型的全面Web解決方案。兩者都具有事件驅動的特性使得它們非常適合編寫實時網絡應用。讓我們來仔細分析比較一下這兩種技術的區別吧。

1.Node.js vs Opa：網絡框架終極PK

Opa和Node.js：區別在哪兒？

Node.js是建立在Google V8 JavaScript引擎之上的網絡服務器框架。它是事件驅動的，采用異步輸入輸出來最小化其成本并最大化其可擴展性。Ryan Dahl在2009年開始研發它，盡管目前有整個團體在貢獻力量，但它仍是團隊的主要力量。Node.js讓開發者能夠用客戶端使用的語言JavaScript在服務器端編碼，目前由一家叫做Joyent公司提供贊助。

Opa是一個開發網絡應用的平臺。它既是編程語言，同時也是將所有特性高度整合起來的runtime engine。它用的異步模型和Node.js類似，但卻采用了全新的靜態類型、編譯方式和函數語言，是專門為Web設計的。它的開發工作始于2007年，由MLstate公司贊助。

這兩種技術有一些共同點：它們都是開源的；編寫“Hello world”這個網絡應用只需幾行代碼（實際上在Opa中只要一行）；都致力于Web而不是泛型編程；語法很相近，標準庫也非常有可比性。

同樣的特性，同樣的用例，難道Node.js和Opa就真的相似嗎？其實不是的，這篇文章將帶領大家挖掘這兩者之間“不小”的差別。

Opa vs Node.js：網絡聊天測試程序

為了說明和比較這兩種語言，我們用一個實例，它也正成為一個網絡框架或語言的標準測試程序，那就是Web聊天。它非常合適，因為它包含了大量的客戶機——服務器通信。

下面我們分別展示用Node.js和Opa編寫的聊天程序的截屏，前者是由Node.js作者Ryan Dahl親自編寫，后者是Opa開發者Frederic Ye編寫。Node.js chat app是展示這種語言的典型的例子，而Opa chat app則是純粹為做比較而寫的。

Opa vs Node.js：生產效率

開發者生產效率是選擇一種語言非常重要的考慮因素。如果你能快速開發的話，你就能做一些改革創新了。你可以很快創造出原型并保持對市場和用戶需求的快速反應。

用SLOC（軟件代碼行數）作為標準比較生產效率有很多弊端，但它可以粗略估計出編寫一個程序需要花多少精力。我們不看生硬的數字，而是展示出這兩個程序源代碼的全景圖（去掉注釋之后的）。其中Node.js寫的程序我們只展示了client.js和server.js，剩余的文件可以參考標準庫。左為Opa編寫，右為Node.js編寫。?

（圖片沒找到－－武夫）

很明顯，Opa要簡潔得多，這歸功于它比Node.js更貼近于自然語言。例如，Opa分布模型提供的是分布對話的原語，這使得在客戶機之間或客戶機與服務器之間建立異步通信變得非常簡單。

Opa vs Node.js：構建用戶界面

Node.js和Opa都用(X)HTML和CSS來構建用戶界面。當然，兩者都可以在那層之上構建庫和抽象物，但它們都不強制這樣，允許直接、完全控制標記。

Node.js對HTML沒有任何特殊支持，僅僅是字符串之間的連接（就像這個）。這種方法存在一些問題。首先開發人員無法驗證其正確性，如未封閉的標簽、錯字，只有在測試時才會被發現。但更重要的是，這可能暗藏著嚴重的安全隱患。由于HTML被作為字符串處理，這就要求開發者非常小心，不允許XSS的侵入。

另一方面，Opa中的HTML是一種數據類型（不是基本類型，被當做語言標準庫的一部分來開發），對語法有特殊支持并使開發者更容易編寫。盡管表面上看起來它只是很符合審美，但它的內涵卻遠不止這些。實質上，上述的問題都已經被解決了：不合語法的語句會被編譯器檢測出，語言本身提供了內置保護以防止XSS通過規避HTML中的某些值侵入。

下面，我們展示一下從兩種語言中截取的相同片段。

Opa vs Node.js：服務器/客戶機端的區分和通信

由于Opa和Node.js都能同時用在客戶機和服務器端的編程，看看它們怎樣處理客戶機和服務器之間的通訊應該是一件非常有趣的事情。

Node.js提供了一種直接的方法。服務器和客戶機的區分在源代碼階段就已經確定了，一些文件包含在用戶端的網頁上，另一些在服務器上被Node解釋。因此，聊天程序同時包含了server.js和client.js這兩個文件。

在Opa中，客戶機和服務器端的代碼之間沒有明確的區分。開發者只管寫程序代碼就行，Opa編譯器會分辨出哪部分代碼發給客戶機，哪部分發給服務器。當然，開發者可以通過預設函數來影響這一結果。因而，在客戶機和服務器之間交換代碼就像增加或更改一些指令那樣簡單。這就是為什么Opa的聊天程序只包含一個文件：main.opa（本例中，為了清楚，所有的函數都加上了注釋）。

由于Opa提供了這樣的位置透明度，它的通信就建立在一個更高的抽象層次。開發人員所要做的就是依據呼叫方和被叫方的位置來簡單調用函數和Opa編譯器，并把它們當做本地函數調用或遠程過程調用來實施。

這是Node.js聊天代碼的片段和Opa中對應的部分。

2.Opa vs Node.js：出現錯誤了怎么辦？

Opa vs Node.js：出現錯誤了怎么辦？

眾所周知，寫代碼并不是編程的最后一步——有趣的事往往發生在測試和調試的時候。因此，只有看看這兩者在此情況下的對比才算真正公平。實際上，我們需要考慮三方面的問題：語言如何檢測錯誤；對調試的支持；對測試的支持。本文中我們不看測試方面，因為兩者在這方面實在太接近了。下面我們從調試功能入手。

在Node.js中開發者用JavaScript同時為客戶機和服務器編寫代碼。而在Opa中，客戶機端的JavaScript是從更簡潔的Opa代碼自動生成的。用戶可以選擇node-inspector或V8 debugger——Eclipse中Google Chrome開發者工具的一部分，來調試Node.js程序。Opa的情況更加復雜一點，因為現在還沒有一款專用的調試工具。而且客戶端的代碼是自動生成JavaScript，因而，代碼的可讀性會更低（盡管編譯器中有緩解這一問題的選項）。

另一方面，多虧它的編譯器提供的靜態類型（和很多不需要程序員注釋的靜態類型不同，Opa有完整的類型推斷）和靜態分析，Opa才能就錯誤檢測作出承諾。原則上，那意味著它要能夠在運行程序之前就檢測出大量的錯誤。為了實際檢驗，我們在Node.js和Opa的代碼上做了很多試驗。我們添加了一些常見的錯誤并觀察發生了什么。

我們從函數名這種簡單錯誤開始。Node.js程序中，我們在一個顯示當前在線用戶數的函數中用lenght代替了length。然后我們重新運行了這個程序，發現直到代碼被執行時錯誤才被檢測出來——本例中是當用戶進入或離開聊天室調用上述函數時才出現。我們由此可以聯想到在不常被調用的函數中，這樣的錯誤是不容易被發現的。錯誤在JavaScript調試器中只顯示為：

GET http://localhost:8001/join?_=1327952561187&nick=akoprowski 400 (Bad Request)

并指向相應Ajax請求發生的地方。要想將這個錯誤和錯誤代碼聯系起來不花點時間，沒有一定調試經驗的人恐怕是難以完成的。

接著我們又在Opa的代碼中安排了同樣的錯誤，Opa不讓我們運行這個有錯誤的程序并報告了如下錯誤：

File "src/main.opa", line 152, characters 21-28
Expression has a record type incompatible for access to field lenght. […]
Hint: Perhaps you meant length or merge?

我們又試了一些用戶自定義數據類型，在Node.js和Opa定義的聊天信息中用txt代替text。結果是一樣的：在Node中顯示運行錯誤，沒有指出錯誤所在；Opa中卻是詳細的錯誤信息。

然后我們決定看看錯誤的HTML會發生什么，這是兩種語言在界面上的重要構件。在Node.js顯示聊天信息的表格中，我們用“,”代替第二個封閉標簽，結果程序照樣工作但顯示卻出現偏差（現代的瀏覽器非常善于“修復”標記錯誤）。我們還嘗試了其他類似的標記錯誤，其中的一些在輸出結果中很難找到缺陷。

在Opa的例子中，我們沒有用表格，但卻在服務器/客戶端區分和通信這段代碼中植入了這個錯誤，得到了一下清楚的錯誤信息：

Hint: File "src/test.opa", line X, characters X-X
Open and close tag mismatch

在嘗試其他變量錯誤時也得到了類似的編譯時期錯誤。

最后，我們試了一下算術錯誤。在Node.js和Opa中都有計算內存使用的函數，簡單起見，我們將第二次出現的數字1024用字符串“1024”代替。結果很類似，Ajax中不確定的運行時期錯誤和Opa中如下的編譯錯誤：

File "src/main.opa", line 91, characters 28-41.
Function was found of type 'a, 'a -> 'a but application expects it to be of type int, string -> 'b.
Types int and string are not compatible.

盡管對于從未使用過Opa的人來說上面的錯誤信息也許還不夠明確，但對于熟悉的人來說，簡直就是清楚地不能再清楚了。

總的來說，我們認為這些結果是很令人吃驚的。一大類Node.js中需要花大精力去測試和調試的程序錯誤在Opa中都被自動檢測出來了，并且都報告出有用的錯誤信息（大部分時候）。我們還只是停留在表面，因為Opa實際上可以檢測出更多除了上面討論過的錯誤。

這點不應當被忽略，因為它可能是區分Opa最重要的特性。它還反應了Haskell程序員多年前就知道的事實：采用一種設計完善的語言可以一次性就寫出幾乎全對的代碼，并在測試和調試環節省下大量的時間。

3.結論

Node.js和Opa都統一了客戶機和服務器編碼，它們的持續流行表明現在的Web實在是太復雜了，編程模型需要重新定義和簡化。盡管Node.js是在現存流行的JavaScript語言上的創新，但Opa給那些想要花時間學習一門新語言的人提供了幫助。

文章出自：developer.com

注：本文未經授權或允許，不得轉載。

總結

以上是生活随笔為你收集整理的武夫提笔——席卷世界Nodejs之初步对比：与opa各占几分春色？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。