[[160272]]

圖片來源：Flickr用戶Tsutomu Takasu拍攝作品

縱觀整個計算機發展史，1995是瘋狂的一年：這一年Java語言誕生，緊跟其后的是JavaScript。后者雖然含有java二字，實際和java并不沾親帶故。Java屬于靜態編程語言，需要編譯；而JavaScript只是一個簡單的解釋性腳本語言，屬于動態語言。

如果經歷過早期java發展，我們不難忘記它曾經的空前巔峰：鋪天蓋地的推廣，超大規模的JavaOne會議。很多人都認定，這種新型的編程語言必將不惜一切代價稱霸計算機領域。然后這一預測最終證實只是部分準確。而今，安卓應用、企業級服務器應用程序和類似藍光光盤的嵌入式空間中，java仍然保持著統治地位。 縱使java有著極為廣泛的實現領域，但桌面應用程序和瀏覽器編程卻始終是它的弱點。Java創立的基于html的小應用程序，還有基于java的開發工具，都是開發人員極力推崇的。但復雜的場景或實際需求，往往會打破這種固有的組合。值得慶幸的是，早期服務器端開發成為了java揚眉吐氣的領域。

同時，先前被很多程序員誤解為Java好姐妹的JavaScript也開始在自己擅長的領域一展雄風。不得不承認，曾有一段時期，HTML和Web大張旗鼓發展的時候，JavaScript像一個小博格人一樣，隨波逐流。但AJAX的出現，徹底改變了這一現狀。

接著，Node.js的橫空出世，吸引了業內眾多開發者的追捧。與Java或其他編程語言相比，基于JavaScript的Node.js平臺在服務器端的表現更為出色——快！更快！Web端動態化發展，對數據請求次數和響應速度的要求，Node.js均可以滿足。

放在20年前，這些都是不可想象的。如今等待這對雙J兄弟的是一場硬戰，輸贏將決定誰會坐上編程界頭把交椅。一方是在工程應用和體系結構領域根基牢固的靜態編程語言；另一方是更加輕量級簡易化的動態編程語言。老派編譯性語言Java會堅守住自己的陣地嗎？高速靈活的Node.js會為JS清除霸權道路上的一切障礙嗎？

Java的優勢：堅如磐石的應用基礎

提到這點，我放佛都聽到了開發者魔性的笑聲。是的，Java自身存在著一些小的缺陷和bug，但相對而言，它絕對是編程界的直布羅陀巨巖(haha，乃們能聽出我對其頂禮膜拜的夸贊吧)。Node.js如要達到這個境界，估計還要再努力上幾年。不僅如此，事實上，當初Sun開發java虛擬機所做的回歸測試數量級，JavaScript預達到這個水準，沒個幾十年根本做不到。 如果你啟動了一個java虛擬機，那么恭喜你，您獲得了一個掌控企業版服務器的資深管理者20年的經驗值！如果你毅然決定要是用JavaScript，這將意味著，您可能遇到了一個脾氣壞難相處的工作伙伴：這家伙時而能與你友善相處；時而又要拿出自己那套做人準則(JS標準)bibi，向你發起被動侵犯性的攻擊。

Node的優勢：無處不在的可應用性

正是由于Node.js的出現，JS終于在網絡服務平臺找到自己的歸屬位置。Node采用異步編程達到處理并發事件的效果。雖然它的可靠性還有待提高，但其在業內表現已經堪稱不俗。傳統的web編程，Java實現后臺服務，JS完成前端功能；而Node.js可以讓JS一人輕松搞定客服端和服務器，特別是當我們想把邏輯層從服務器移植到瀏覽器層面時，Node簡直就是熠熠生輝?；蛘叱C情的老板又想讓我們把邏輯層移回服務端，反反復復，不管怎么個玩法，總之Node.js讓代碼移植更加簡化。

Java能贏在何處：更優秀的IDE

Eclipse,NetBeans和IntelliJ，集調試、編譯和服務為一體，這是Java開發人員公認的三大頂尖IDE。他們發展至今，潛心專注用戶體驗，擁有堅實的相關配套插件。而node.js開發人員可以在命令行下編寫代碼，或者使用文本編輯器。也有一部分人會選擇Eclipse和Visual Studio，這二者也是支持node開發的。Node.js在全球范圍內掀起的熱浪，勢必會孕育出一些新的工具和資源。比如IBM團隊開發的Node-Red，它允許用戶通過組合各部件來編寫應用程序。然而，這種新的開源IDE，若要達到Eclipse的水準，尚有一大段距離。再比如前端開發神器WebStorm，這是jetbrains公司旗下一款JS開發工具，可支持多命令行開發。

當然，僅從代碼的編輯和簡單開發功能出發，這些新型的輕量級工具綽綽有余。但，如果你希望在執行源代碼時，IDE可以給開發者更多的指引(好比一場開胸手術中，手握手術刀的大夫希望得到更多的協助)，強悍的java開發平臺可以直接秒殺那些蝦兵蝦將——無處不在的java！

Node能贏在何處：簡化進程

諸如Ant和Maven此類復雜的軟件構建工具，對java編程帶來的改變意義非凡。然后，始終存在一個問題。比如，開發者在xml中寫出的代碼，其規范和語法在其他編譯環境下得不到支持。的確，可以使用嵌套標簽來展示分支，但java與xml之間惱人的互轉問題，仍不好解決。

Java：遠程調試

能夠遠程監控服務器集群性能，一直是java引以為豪的。JVM本身的一些特點，加之性能測試工具的輔助，使得程序可以輕松探測出服務端瓶頸和失敗。Java堆棧企業版上可以運行極為復雜尖端的服務器，而使用這些服務器的公司可以在遙測過程中獲得最好的用戶體驗。上述提到的監測調試功能，發展至今已相當成熟，我們在部署服務時會深受其益。

Node.JS：直訪數據庫

類似CouchDB這種新型數據庫，可以通過編寫JS腳本直接對其進行訪問。Node.js和CouchDB語句可以混合使用，不存在互轉問題，頭疼的語法差異也可以拋在腦后。

同樣的情況，許多java程序開發人員在工作中也需要寫一些sql語句，此時就要使用java編寫的數據庫(比如Derby)，到這一步你以為就萬事大吉，那么只能說：你想多了！開發人員寫好的sql語句，需要進一步經過Derby解析，方可加載在java程序中編譯執行。所以，java確實是一門不錯的語言，但其語法無法與sql互轉，導致開發團隊需要明確分工：你來寫java，我來寫sql。

Java：豐富的資源庫

javat提供了一套龐大的工具包集合，這些資源在日常開發中發揮著極為重要的作用。例如，全文檢索引擎Lucene和計算機視覺庫OpenCV，是最典型的兩個開源項目，他們在一些重要的基礎工程中扮演著中流砥柱的角色。目前也有用javaScript開發的一些開源共享工具庫，其中也有讓人眼前一亮的函數和方法，但與Java這套成熟的資源庫相比，這一環節java勝出。

Node：JSON

當數據庫反饋出結果后，java程序將其轉換為一個個java對象。這一環節，開發人員會采用POLP或者Hibernate等映射框架來處理數據，期間的配置和轉化耗時是非常大的。最終，java程序才會接受這些java對象。

其實大部分web服務端和數據庫，返回的數據類型是以JSON形式封裝的(這是JS自帶的一種數據交換格式)。這種數據格式被廣泛應用于Java開發中，那么問題顯而易見嘍，開發者需要使用眾多JSON解析器或庫函數來進行數據的再處理。而JSON是JavaScript原生格式，這意味著在JS中處理JSON數據不需要任何特殊的API或工具包，用戶可以簡單粗暴直接使用。

Java：堅固的引擎

究竟有多少復雜組件基礎開發包是基于java強大的數學函數庫，一百個，一萬個，這個已經很難去量化了。當初Sun為研發java這套實用工具類，也是消耗了大量的時間和人力。現在被廣泛使用的有大數處理BigIntegre，精細復雜的IO庫，基于Gregorian和Julian的開源時間/時間庫。

在處理簡單任務方面，JavaScript的表現還算差強人意，但其實現機理卻混亂不堪。一個最常見的例子，JavaScript中定義的函數方法當返回結果是“無”時，可以有三種表現方式：undefined, NaN,以及 null。那么哪一種結果是正確的？其實這三者都是JS語言的數據類型，作用是為了保證程序的嚴謹性和邏輯性。乍一看，這種怪異的語法在程序運行中一般是不會出錯，但與java那些個高大上的庫函數一比，又被秒成渣。

Node.JS：速度

node.js速度棒棒嗒，用過的人多說好。數據一來一往，就像閃電一般。它不會作死去盲目設置帶有死鎖風險的單線程；也不存在內部自檢環節，因為這有可能會降低執行速度。總而言之，手起鍵落，node已然在執行你的代碼了。

當然，這種優勢下暗藏隱患。代碼盡量要寫的簡單，這樣Node.js可以保你事事順利。一旦某段復雜的代碼死鎖，整個服務會掛掉。可以這樣理解，操作系統開發人員抓耳撓腮費死勁建立起來的系統自保機制，是可以容忍部分程序錯誤的。但Node.js完全瞧不上這套保護網。這也是node活該的地方。

Java：多線程

執行速度快，固然好。但健壯優良的代碼，會更勝一籌。這一輪，java贏得無可置疑。

Java框架開發的web服務器是多線程的。縱使多線程會占用大量時間和內存，但這種內耗是值得的。因為，一個線程死鎖，至少還有其他線程扛著；即便一個線程需要長時間占用cpu，至少其他線程不會饑餓等待。

以上情形放到Node.js下，結局慘不忍睹：一個線程慢下來，所有一切慢下來。所以，Node.js僅適用于單線程。

無數程序猿揮灑汗與淚，花費幾十年心血，致力于建立一個處理并發事件的智能操作系統。Node在此點上卻無法與時具進，玩起了倒退到上個世紀60年代的單線程。

Node：續航能力

祖輩對我們耳提面命：節儉是美德，要做不浪費不索取的好孩子。看著硅谷那幫傻缺用自己的行為在詮釋“創新”和“顛覆”，我們確實痛心疾首。但回頭靜心一想，去其糟粕才是一件意義非凡的啊。Java仍可寶刀未老，先輩們撰寫的骨灰級Java老代碼無處不在。誠然，Java也在孜孜不倦提供著新的IO接口，但那些已與時代脫軌的老接口將何去何從？小型應用程序和基礎實用類也將面臨這種抉擇。

雙贏的局面？混合編程

服務器姓J還是姓JS，這個討論還會持續很長時間。有一種中庸的方法，可以避開這些喋喋不休的爭論—Java和JS的混合編程，將Java類轉換為與瀏覽器兼容的JS。GWT框架把這事做的就很漂亮，很多知名網站就采用了此方法。

嘿嘿，其實還有另外一條小路可以走：像Rhino這種使用Java語言編寫的JS的開源實現，程序猿可以直接把Java代碼植入其中。如果你夠牛逼，還可以在當前比較火的googleV8引擎上搗鼓這個事情。

總之，不要打打殺殺，和諧共處是王道！