在計算機歷史上，1995 年是一段瘋狂的歲月。首先 Java 出現了，隨後 JavaScript 也出現了。Java 和 JavaScript 的名字看起來像是一對雙胞胎，但實際上它們差別巨大，Java 是被編寫和靜態定型的，而 JavaScript 則是被解釋和動態定型的。但這僅僅是這兩個完全不同的語言的技術差別的一個開始，Node.js 的出現使得兩種語言經歷了兩條完全不同的發展軌跡。
如果你比較早的接觸了 IT 技術，那麼你或許記得 Java 曾經風靡一時，每個人都將其視為一項革命，認為它將完全替代計算。但事實證明，這一預測只有一部分是正確的，Java 統治了安卓手機、企業計算和一些嵌入式設備，如藍光光碟。
雖然 Java 取得了一定的成功，但它從來沒有統治過桌面或瀏覽器。人們曾嘗試出售過小應用程式和 Java 工具的強大，但是表現平平。而伺服器成為了 Java 的最佳領域。
同時，之前被程式設計師們錯認為是 Java「雙胞胎」的 JavaScript，如今也能獨擋一面了。在 HTML 和 web 推出 Borg 的幾年間，JavaScript 一直緊隨其後，AJAX 的出現使得 JavaScript 突然之間擁有了力量，打破了之前的局面。
隨後 Node.js 誕生了，大大提高了開發速度。JavaScript 不僅在伺服器上比大多數人預期的要快，甚至與 Java 或者其它工具相比，速度也要快。JavaScript 能夠更加穩定地處理小的、快速的和無休止的數據請求，因此，當網頁變得更加動態時，Node.js 就變得更加常用了。
雖然這在 20 年前可能是無法想像的，但是現在 Java 和 JavaScript 正在爭奪編程領域的「統治權」，它們一個強調以堅固的工程和架構為深層基礎，另一個強調簡潔和普遍性。到底是老式的編譯器驅動的 Java 會立於不敗之地，還是在 Node.js 幫助下的 JavaScript 將所向披靡呢？
看到這個小標題，可能有些開發者會有質疑。當然，我們不否認 Java 還存在一些小 Bug，但是相對而言，Java 已經算是很「堅固」的了，Node.js 想要讓我擁有這樣的信心，還需要許多年。
事實上，要寫出與 Sun/Oracle 在測試 Java 虛擬機時所寫數量相同的回歸測試，JavaScript 開發者或許要花上幾十年。當你啟動 JVM 時，你將獲得來自一個質量可靠的管理者的 20 年經驗，而這個管理者一直決心要統治企業伺服器領域。
不過，JavaScript 也在迅速迎頭趕上。當 web 的大部分依賴於 JavaScript 執行引擎時，開發者的時間大部分花在了打磨邊邊角角上面。然而，所有的創新都有一個缺點，那就是新的功能可能擴散太快，以至於開發者們來不及吸收這些功能。一些老派的開發者經常會對充斥著最新 ECMAScript 句法的增強特性感到困惑。另外，這些新代碼可能還會導致某些舊版瀏覽器崩潰。
創新性的預處理器，如 CoffeeScript 和 JSX 等，源源不斷地出現，對於需要這些功能的開發者來說是件好事，但是對於不需要的開發者來說增加了難度。
儘管 Java 也在不斷推出新的功能和選項，但總體而言，它是一個穩定的平臺，它給那些需要開發更長久的東西的開發者帶來了便利。
多虧了 Node.js，JavaScript 在伺服器以及瀏覽器領域找到了一席之地。你給伺服器寫的代碼很可能在瀏覽器上也能運行。很明顯，比起在 Java 和 JavaScript 中分別寫代碼，直接使用 JavaScript 更簡單。
如果你決定要把 Java 中的伺服器業務邏輯遷移到瀏覽器中，或者老闆會執意要你把給瀏覽器寫的邏輯遷移到伺服器上。在這兩種情況下，Node.js 和 JavaScript 都能讓代碼遷移變得更簡單。
不僅如此，Node.js 的領導地位似乎還在擴大，例如比較複雜的 Web 框架，類似 React，是要把代碼運行在伺服器還是客戶端上呢？另外，還有可能出現這種情況，代碼前一天是運行在客戶端上的，但是後一天可能就運行在伺服器上。某些智能的邏輯將在運行時根據負載、閒置 RAM 容量和其它因素來決定究竟代碼運行在什麼上面。有些框架會把 JavaScript 作為一條查詢，輸入到資料庫，並在那裡執行。你的代碼可能在任何地方運行，所以，你很難了解究竟是在什麼地方，因為代碼根本不會返回任何東西。但是也無需擔心，因為你不需要考慮太多細節。
Java 獲勝之處：更好的集成開發環境 (IDE)Java 開發者擁有三大 IDE，Eclipse、NetBeans 和 IntelliJ，這三個 IDE 是與調試程序、反編譯器和伺服器良好地集成的頂尖工具。每個工具都經過了數年的開發，擁有忠實的用戶、堅固的生態系統和數不盡的插件。
大多數 Node.js 開發者會將文字輸入命令行，再編碼到他們最喜愛的文本編輯器中。誠然，市面上最好的一些文本編輯器，像 Atom，都擁有琳琅滿目且幾乎無所不能的插件，但如果和 Eclipse 進行比較，Node.js 給人的感覺要更老式一些。在不久的將來，Atari 操縱杆將代替我們的滑鼠。
另外，有些 Node.js 開發者會使用 Eclipse 或 Visual Studio。開發者對 Node.js 突然激增的興趣可能會有新工具誕生，例如 IBM 的 Node-RED 給我們提供了一些極具吸引力的方法，但是這些工具還遠未達到像 Eclipse 或 IntelliJ 那樣的完整度和統治地位。
但奇怪的是，開發者好像並沒有使用這些工具。命令行本該在 35 年前 Mac 到來時就消失，但卻沒人把這個消息告訴 Node.js 的開發者們。但是選擇一直都在那裡。例如，WebStorm 就是一個可靠的由 JetBrains 開發的商業化工具，它集成了許多命令行構建工具。
當然，如果你正在尋找一款能夠編輯和調整代碼的集成開發環境，那麼現在支持 Node.js 的新工具已經足夠使用了。但如果你希望集成開發環境能夠讓你一邊操作正在運行的原始碼，一邊編輯代碼，那麼 Java 的工具顯然會更強大一些。
一些較新的資料庫，如 CouchDB 和 MongoDB 的查詢是由 JavaScript 編寫的。將 Node.js 和資料庫調用合併不需要任何換擋，也不需要記住任何句法差異。
而許多 Java 開發者都在使用 SQL。即使是在他們使用 Java DB—前身是 Derby （一種由 Java 編寫的資料庫）時，他們的查詢也是用 SQL 寫的。你可能會以為他們會簡單地調用 Java 方法，但其實沒有，開發者必須要用 SQL 寫資料庫代碼，然後再用 Derby 解析 SQL。 雖然 SQL 是很好的語言，但是它與 Java 完全不同，許多開發團隊需要有不同的人來分別寫 SQL 和 Java。
更糟糕的是，許多 Java 程式設計師使用複雜的庫和模式來將 SQL 查詢數據轉換成 Java 對象，目的是讓自己能夠將這些東西重新導入到模板中。這個過程非常瘋狂，而且非常浪費。
許多入門級的編程課程都使用 Java，因為許多程式設計師都喜歡靜態類型編碼，靜態類型編碼很簡潔而且安全。在編譯器找出了一些明顯的 bug 後，代碼看起來更加嚴謹了。
不過，JavaScript 也在追趕，一些開發者已經轉到 TypeScript。TypeScript 是一個靜態類型的 JavaScript 超集，首先會應用所有的類型檢查手段，然後剔除掉運行在瀏覽器上的 JavaScript 堆棧中的一些東西。
對於喜歡類型的開發者來說，TypeScript 足以讓你喜歡上 JavaScript 了。當然，你可以把 JavaScript 這種模仿視為是對 Java 最真誠的恭維，並且繼續使用 Java，因為 Java 從一開始就是使用靜態類型的。
JavaScript 曾經是一個簡單的語言，用於彈出警示框和雙重檢查輸入表。後來，開發者社區創造了 JavaScript 的許多不同版本，它們能夠被轉編譯為瀏覽器可用的東西。例如，CoffeeScript 提供了一些不同的句法，旨在使標點符號更加清晰。React/Vue 群體將 HTML 和 JavaScript 混合。此外，還有針對類型愛好者的 TypeScript 和針對功能語言信徒的 LiveScript。
而在 Java 中，你會發現有很多創新，但這些創新由於某些原因，並未用預處理器進行表達。還有一些語言如 Kotlin、Scala 和 Clojure，為了 JVM 專門變成了字節代碼，但不知為何，它們可以說是完全獨立的語言。對於喜歡嘗試不同的代碼編寫方式或標點符號的 JavaScript 程式設計師來說，所有的預處理器均使他們的生活變得更加有趣了。
複雜的構建工具如 Ant 和 Maven 使 Java 編程發生了革命。但還是有一個問題，開發者需要將說明用 XML 寫出來，而 XML 並不是一個支持編程邏輯的數據格式。
當然，使用嵌套標籤來表達分支相對而言比較簡單，但是僅僅是為了構建，就要從 Java 切換到 XML，有些令人討厭。有了 JavaScript 後，你就不需要再切換。
之前，Node.js 的構建很簡單，只需要編輯代碼，點擊「運行」就可以了。但是隨著 Node.js 開發者不斷改進流程，添加了一些預處理器來抓取你最喜歡的 JavaScript 方言，並將這種方言轉換成可以運行的東西。然後，Node 包管理器需要找到正確的庫，因為有時可能會找不到，所以需要花時間尋找某個工件正確的版本號，而這個工件必須在單獨的步驟中自行構建。而且，如果你在工件庫中引入了一些錯誤，那麼，這個版本號便無效了，需要重新做。
Java 也有與 Node.js 方法類似的複雜的構建過程，但給人的感覺不會比 Node.js 更複雜，從某種意義上說，Maven 和 Ant 貌似已經成為了 Java 基礎的一部分，許多粗糙的邊角已經被去除了，因此構建的工作成功率更高了。
如果非要對它們的構建難度進行衡量的話，它們可能不分伯仲，但如果從 JavaScript 快速增加的複雜度的角度來看，Java 在這方面獲勝了。
當資料庫給出答案時，Java 需要花費大量時間把結果變成 Java 對象。開發者會就 POJO 映射、Hibernate 和其它工具爭辯上好幾個小時。配置這些東西可耗費數小時甚至數天時間。最終，在所有的轉換之後，Java 代碼獲得了 Java 對象。而來到配置階段時，Java 使用的仍然是 XML，並且提供了 2 個主要的解析器，這給開發者帶來了更多的煩惱。
如今，許多 Web 服務和資料庫都以 JSON 的形式返回數據，JSON 是 JavaScript 天然的一部分。JSON 現在非常常見和有用，以至於許多 Java 開發者都在使用這種格式，而且還有一些非常好的 JSON 解析器可以作為 Java 庫被使用。相比之下，JSON 本身就是 JavaScript 基礎的一部分，不需要庫，直接使用就可以了。
Java 擁有許多非常棒的監控機器集群的工具。JVM 有深層的鉤子和精細的剖析工具來幫助我們識別瓶頸和故障。Java 企業堆棧上運行著全世界最複雜的伺服器，而使用這些伺服器的公司對遙測的要求非常之高，所有這些監控和調試工具都較為成熟，並且可以立即部署它們。
Node.js 獲勝之處：桌面也許有人在使用 Java 小程序，但我仍然保留了一些可以點擊運行的 Java JAR 文件。總體來說，桌面領域大體上是不用 Java 的。另一方面，隨著瀏覽器取代了桌面的大部分角色，JavaScript 的作用也越來越大。當微軟重寫了 Office 並使其能夠在瀏覽器上運行時，一切就註定了。如果你還想了解更多，那麼市面上還有許多有趣的選擇，比如 Electron，它能夠抓取你的 Web 代碼，然後轉換成獨立的桌面 app。
安卓 app 大多都是用 Java 寫的，而且 90% 的新手機都運行著各種版本的安卓系統。很多人根本就不使用桌面了，因為手機已經可以做任何事情了。
許多開發者都在編寫 Node.js Web 應用，這些應用主要用在 iPhone 和安卓手機上的移動瀏覽器上。如果這些應用寫得比較好，性能通常會比較好。但 Java 正以另外的一種方式入侵。最新的 Chromebook 將支持安卓應用，從而給 Java 開發者進入 Chromebook 用戶的桌面開闢了道路。那麼 Java 是否仍有機會徵服桌面呢？
Java 提供了大量的庫，而且這些庫做得都非常好，文本索引工具如 Lucene 和計算機視覺工具包如 OpenCV 都是非常好的開源項目，它們都將成為其它重大項目的基石。JavaScript 程式設計師也在追趕，創造出了很多了不起的項目。
然而，在某些領域，Java 就是一個遠程的存儲器，市場上可能有無數不同的 Web 框架，所以 Java 難以在這個新興市場中參與競爭。
雖然這點很難量化，但是因為 Java 的數據基礎非常強大，許多重大的科學工作中使用的許多複雜的程序包均是用 Java 寫的。Sun 公司花了大量的時間來獲取工具類的詳情。市場上有 BigIntegers、精巧的 IO 例程和複雜的日期代碼，它們均實現了格裡高裡和羅馬儒略日曆。
JavaScript 適合簡單的任務，但是其內部有很多令人混淆的地方。舉一個簡單的例子，JavaScript 針對沒有答案的函數會生成三種不同的答案，分別是：undefined、NaN 和 null。那麼，哪一個是正確的呢？其實每個答案都有各自的作用，其中一個便是驅使程式設計師保持代碼統一。JavaScript 更怪異的方面是雖然它在簡單的表格工作很少出問題，但對於複雜的數學和定型工作而言，JavaScript 並不是一個好選擇。
Node.js 的速度一直很受開發者的歡迎，數據輸入和答案輸出的速度如同閃電。Node.js 不需要單獨設置線程，也沒有上鎖等令人頭疼的問題，也沒有拖慢速度的額外開銷，只需要寫一些簡單的代碼，Node.js 就會快速地採取正確的步驟。
Node.js 的回調模型已經改變了其編程方式，使程式設計師避免同時操作多個任務。JavaScript 引擎能夠確定何時運行什麼代碼。因此，程式設計師可以編寫更短和事件驅動的代碼，並且關注重要的邏輯。
但是 Node.js 也存在一些問題，Node.js 代碼要儘可能的簡單一點且工作正常，因為如果它鎖死了，整個伺服器都可能鎖死。作業系統開發者努力創建了許多安全網來抵抗編程錯誤，但 Node.js 會讓這些安全網失效。
此外，當程式設計師將回調函數如俄羅斯套娃一層又一層不斷地嵌套時，還會出現一個代碼複雜性的問題。一個回調還好，但一系列的回調令人抓狂，好消息是 Promise 模型很容易讀。但你需要記住，在執行代碼行期間，許多事情都可能發生。
代碼速度快雖然好，但更重要的是代碼要準確，而使用 Java 可以享受到一些額外功能：
Java 的 Web 伺服器是多線程的。創建多個線程可能要花費時間和存儲，但這是值得的。因為，如果一個線程鎖死了，其它的還可以繼續用。如果一個線程需要很久的計算時間，那麼其它線程可以分擔。更重要的是，代碼一直在掌管之下，並且能夠進行調整。
如果某一個 Node.js 請求運行速度過慢，其它請求的速度也會降下來。Node.js 只有 1 個線程，因此只有它準備好了，事件才能被處理。或許它看起來超級快，但是本質上它的架構就如同春節的時候，郵局只開一個辦理窗口一樣，即它不能同時處理多個請求。
人們花了幾十年構建智能的作業系統，能夠同時處理許多不同進程的作業系統。那為什麼還要回到那個電腦只能處理單線程的年代呢？的確，處理多個線程意味著要做更多的工作，但是多線程更強大，不是嗎？
看見矽谷的開發者總是積極獻身於最新和最具顛覆性的東西，但有時清理掉遺毒也很重要。Java 有新的 IO 例程，但是它也有一些舊的代碼，例如許多小程序和 util 類會阻擋你前進的道路。Node.js 在 Git 庫中也留下了很多垃圾，但是由於 Node.js 出現的比 Java 晚幾十年，且 Node.js 開發者還在研發許多針對 Web 堆棧軟體的增強功能，所以，Node.js 動力十足。
兩方不分伯仲之處：Java 和 Node.js 之間的交叉編譯伺服器到底是用 Java 還是 Node.js 的辯論可能還會持續很多年，但與其它辯論不同的是，這場辯論可能會是雙贏的局面。Java 可以交叉編譯到 JavaScript 中去，谷歌就經常在 Google Web Toolkit 中這麼做，而且谷歌最受歡迎的網站也運行著 Java 代碼，這些代碼就是從 Java 翻譯為 JavaScript 的。
當然，反過來也是如此。JavaScript 引擎如 Rhino 和 Nashorn 同樣在 Java 應用裡面運行 JavaScript，然後你可以連結到這些應用。如果還不滿足的話，你還可以連結到谷歌的 V8 引擎。所有的 Java 和 JavaScript 代碼都可以和諧地彼此連結，因此，你不需要在兩者之間選擇。
作者簡介：
Peter Wayner 是 16 本涉及不同主題的書的作者，包括《開源軟體（統統免費）》，《自動化汽車（未來出行）》,《隱私增強計算（透明資料庫）》，《數字交易（數字現金）》，《和隱寫術（密碼學的消失）》。他的書定期發布在 InfoWorld 上，並且他還為許多大小型軟體項目提供諮詢。他關於機器人汽車的《未來出行》這本書的第二版已經出版。最後，他還是惠普的技術燈塔營銷網站的作者。
本文最初發布於 Peter Wayner 博客，經原作者授權由 InfoQ 中文站翻譯並分享。
查看英文原文：
https://www.infoworld.com/article/2883328/java-vs-nodejs-an-epic-battle-for-developer-mindshare.html
QCon 廣州站日程上線，部分精彩內容提前劇透：
春晚紅包：應對性能極限挑戰的方案
C 端服務端渲染（SSR）和性能優化實踐
PWA 在企業級項目中最佳性能優化實踐
小遊戲質量保證測試實踐之路
更多大前端、移動開發、程式語言相關實踐領域盡在 QCon 廣州 2019，感興趣的同學抓緊時間向 Boss 申請報名，有任何問題請聯繫小助手魚丸，電話：13269078023 （微信同）。掃描下方二維碼或點擊閱讀原文，提前 get 乾貨信息！