PHP 和 Node.js 的角摔

在最近 SitePoint 的 PHP vs Node.js Smackdown 一文中，Craig Buckler 對兩種語言就如何應對一系列的10個挑戰進行了比較來決定哪一個總體上更佳。

Craig 在書中講到，這些比較總是有些矛盾。作為一個有意思的隨訪，我們要求 Bruno ?kvorc （SitePoint 的 PHP 開發者）和 James Hibbard （SitePoint 的一個 JavaScript 開發者）對每一輪提供評論。

下面是他們詳細的看法...

第一輪：開始

Round 1 挑戰是看你用每種語言多快可以構建一個“Hello World”的頁面。這個包括搭建服務器環境所花的時間。

據 Craig 估計，PHP 贏得這一輪，部分原因是因為這種語言“概念上更簡單”，并且“對于新的開發者來說不那么嚇人”。

Bruno:

PHP 贏得"開始"這一輪純粹是因為更多的主機支持這種語言因此開始非常簡單。這是拿來就好用了而不需要做額外的事情。如果更多的主機忽略使用 Node 命令行而直接采用文件上傳的方式，并且在控制面板上用一個簡單的 "reload app" 鍵，那么兩者將會一樣。然而就在屏幕上顯示東西的實際語法而言，PHP 是更簡單些——特別是對那些沒有編程經驗的人而言。

James:

當在本地機器上開發的時候，我沒有在兩者之間看到很大的不同。在你的瀏覽器上運行 PHP 腳本，你需要安裝一些服務器軟件；要運行 Node 腳本，你需要安裝 Node， 并且最好安裝一個 web 框架比如express. 然而，正如 Craig 說的， PHP“概念上更簡單”.Node 的進入門檻更高。對此沒有爭議。

第二輪: 幫助和支持

第二輪會考量在兩種語言中，獲得幫助和支持的難易程度。PHP贏得了這一輪，主要因為它出現的更久一些。

Bruno:

關于這個保持沉默。

James:

我同意這個說法。Node是一門新技術，所以目前，幫助會少一些。可是當Node越來越成熟的時候，這方面就不是問題了.

第三輪: 語法

第三輪比較了理解兩種語言語法的難易程度。Craig判定這一輪Node獲勝。

Bruno:

我非常不同意這個觀點。PHP的語法中的確有一些怪象，其中的很多已經被修復了，在新的版本中，還有很多要被移除。另一方面，JS中也有“this”這個問題~ 

 關于bullet 3 (開發的時候，使用js你不需要在client端開發和Server端開發的時候做切換)，我不同意這個觀念。服務器環境和客戶端的開發環境已經完全不通了，大腦中的切換還是需要的。總是有些新的語法你不能再瀏覽器中使用，反之亦然，所以這某種程度上也是語言的切換。

Bullet 4 (理解 JS 會讓你更希望使用它)  這從某種程度上來說我是贊同的。 我在工作中使用 JS 和 PHP多年，使用 JS 的時間更久，但我對它卻喜歡甚少——盡管那純粹是個人傾向。

James:

我愛 JavaScript。我知道它有它的怪癖，并且我知道一些原因，ECMAScript 2015 將會修改掉一些，并給語言帶來一部分令人激動的新特性。JavaScript 是強有力和靈活的，并能適應很多不同風格的編程。與 PHP 對照，我享受使用 JavaScript。Node（Node.js）就是其中之一。

第四輪：開發工具

Round 4：考慮這兩種技術所使用的開發工具，Node 因為有開發工具 npm，所以略勝一籌。

Bruno：

雖然，開發者最初受到 npm 的鼓舞，但是現在有 leaps 和 bounds 比 npm 用著更舒服，而且如果你在電腦上安裝了同一個庫的兩個版本的話，leaps 和 bounds 不會讓你的系統崩潰。而且相對于 npm 而言，leaps 和 bounds 允許設計者使用遞歸思想，而遞歸思想是如此的重要，以至于當開發者準備著手建立一個包管理器時，首先考慮的就是這一點。

npm 還有一個致命的缺點，我把它稱為“開發者協作友好”，npm 不能很好地做到這點，對于 npm 而言只有開發者本身能夠理解自己寫的東西。最后，npm 與 Vagrant 不能很好地兼容，這直接的妨礙了您開始自己工作，就更別說 npm 不關注用戶們的需求了。npm 有一個 bug 已經存在了很多年，它導致該軟件在 windows 上基本不能使用，這可不算是小問題了。當然 PHP 也有很多愚蠢的錯誤，但是這些錯誤并不會與你的系統之間發生問題。

的確，PHP并沒有自帶編譯器，但我不認為它應該這樣做。這樣的便利不應該由一個包管理器或者說是一個獨立的應用來完成。如果將來有一天，有人為 Node 開發了一個很好的包管理器，把它與現有的編譯器替換將會極其困難。讓它相對獨立，人們可以便于切換。此外，安裝它僅需要在終端上輸入一行代碼，或者下載一 個安裝程序。
書中提到的編譯器影響很小的說法，是顯而易見的錯誤。自從PHP開發完成后，編譯器就影響了每一位新加入進來的 PHP 開發者，他們中的一些佼佼者不得不將它添加到現有的流程中。只基于編譯器存在之前就有很多 PHP 用戶的理由，并不能說明它的作用較小。事實上，自從有了它，它就產生了巨大的影響。一些人所說的“對社區造成的影響很少“的言論根本沒有事實依據。
現在，我不能在大多數 PHP 開發者都希望安裝 Node 這個問題上爭論，這是真的事實。可悲的是，很多好的工具都首先基于 Node 下開發，但我仍然希望就像 Node-free 開發環境一樣，也可用于開發BowerPHP。

James:

我很高興有人加入Node。

我喜歡 npm。 它易于安裝，易于使用，并有數以千計的包可用于幾乎任何需要。我也喜歡這樣的事實，npm 可以選擇全球的和本地的程序包（相比之下，一些語言如Ruby，它的標準需要將你的程序包安裝在你的 Ruby 版本的旁邊）。它的工具也很棒。一些工具，例如 Bower 和 Grunt，在我工作流中都有一個固定的位置，它們成倍地提升了我的工作效率。
另外值得一提的是，npm 已經開發出了第3版的 β 版。它解決了 Bruno 提到很多問題，例如嵌套node_modules 方法錯誤等。

下文引用自entire smackdown：

    PHP開發人員可能希望（或需要）在某些場合安裝Node.js。反過來不是真的。

第五輪: 環境

第5輪要說的是技術的可用性和部署情況，以及被哪些平臺和生態系統支持。Craig 對于這一點也不十分明確，但是看起來似乎更偏向于 Node。

Bruno:

Craig 說他曾比較 PHP 和 Node 在 web 方面的優勢（常見的 web 開發問題），然后說到處都用到了 JS。首先，我們來比較 Node.js，而不是 JS 本身，其次，我們比較了兩種語言在什么環境下可以運行。猴子比魚要厲害，因為魚太蠢了不能爬樹，但是猴子和魚都會游泳。那么我們來比較它們做得怎么樣吧。

在 web 開發環境中，PHP 獲勝了。這里是一些基于 PHP 的桌面程序工具——是的，也許你不會使用它們，但你一定會用這些基于 PHP 的命令行程序。

James:

我和 Craig 又一次達成一致。一些特性讓 Node.js 變得如此流行（速度，可擴展性，與 JSON 密切相連，低資源占用）使它適合于許多其他類型的應用程序，例如強有力的物聯網設備。我覺得，誰會不喜歡機器人呢？

Node 使得項目獲得了提升，諸如NW.js（一個基于 Chromium 和 Node.js 的應用），它允許你在 HTML 和 JavaScript 上編寫本地 APP。這多令人興奮！

第六輪: 整合

第 6 輪我們來看一下數據庫和驅動的整合方面，PHP 勝出主要是因為它的年齡比較大。

Bruno:

整合方面其實是平局的，PHP 有年齡的優勢，可以有更多可選項，但是也意味著要照顧很多過時技術，如 mysql 擴展 —— 我們可以升級到 PHP7 來擺脫，但多年來一直不可用。

James:

我當然同意這個觀點，這雖然看起來模糊其詞，而且我很喜歡這個例子：“過時的，更受歡迎的技術”。這也很 好突了 Node一個很大的優點 —— 它原生支持 JSON。JSON 或許是 web 中最重要的數據傳輸格式了，同時也是最新的 NoSQL 數據庫的通用結構。JavaScript 程序中使用 JSON 是非常容易的，意味著當你使用 Node 工作時，數據可以非常簡潔地進行傳輸，不用進行格式轉換了。你可以只使用一種語法（JSON 格式）傳遞在瀏覽器、服務器和數據庫之間。

第七輪：主機和部署

第七輪會看看將新應用部署到 Web 服務器是否容易，在 Craig 看來，PHP 在這方面明顯是贏家

Bruno:

Bruno 再一次保持沉默。

James:

這是 Node 需要努力改進的區域。每個提供 Web 主機的公司，都提供了 PHP 和  MySQL。你想看到輸出，只需要建立一個以“.php”為擴展名的文件，在<?和?>間寫一些有效的代碼，上傳，用瀏覽器訪問。但同樣的方 法不適用于Node。當然，Node 主機有很多選項，但是它們需要更多的設置和命令行方式的訪問，這對于初學者來說可不愉快。毫無疑問，PHP 在這一輪贏了對手。

第八輪: 性能

第八輪 主要關注速度。雖然這項經常依賴于經驗以及開發團隊到底多上心，Craig 注意到 Node 在一些方面的優勢。

Bruno:

錯誤比比皆是。首先，這篇文章 有關于性能的詳細討論， 其中排除了開發者經驗以及應用類型對性能的影響。如果那篇文章依然無法讓你明白拋開上下文談性能有多愚昧，那來我來談談我的觀點：

• PHP 正在嵌入一個多線程服務器。這使得完全繞過外部服務器成為可能，但暫時還不推薦使用。另外也有一些超快速的的服務器（像 Nginx），他們使得整個啟動 PHP、派發請求的過程快到可以忽略。

• PHP 的原生異步 (無阻塞 I/O)支持將在 PHP7 中推出，而且多年前 ReactPHP 就實現了類似的模式，因此這一點也毫無意義。

• PHP single-request 的生命周期模式是最大的負擔。確實，如果你單純的追求速度，但是這條依然可以很容易繞開，不止可以通過 Memcached 和 Craig 說的類似的方法， 而是通過類似；Ajax 的方法。順便說一下——服務端 JS 應用默認也是 single-request的。另外——這種 single-request 的生命周期也是一種優勢，每次請求重新構建應用，避免了很多內存問題，清空垃圾內存，保持苗條干凈。你上次使用一個穩定的長時間運行的的無內存泄露的 Javascript 應用是什么時候，不論前端或后端？

關于性能的討論現在是，而且以后也將是——平局（除非你用的是 Java，那 Java 一定輸）

James:

Node 以高性能低延遲的運行時環境而聞名，而且它也找到了屬于自己的方式來嵌入部分500強公司的代碼棧。由于它的無阻塞 I/O 機制以及 Google Chrome V8 引擎技術，現在 Node 已經成為了“快速”以及“可擴展的”的同義詞。 現在網上有很多故事，像Node 如何讓公司獲取更好的性能提升 以及給開發者提供更高的生產力。我很高興，這回合 node 勝，但我也理解有人質疑這點。

第九輪: 程序員情結

第九輪來看一看 Craig 覺得一般程序員們對于 PHP 和 Node 有多少感情，最后他認為，Node 獲勝了。

Bruno:

你肯定看錯地方了，Craig，PHP 社區令人難以自信地熱情和活躍，每年有超過 20 個大會和非常精彩的主題討論。正是這樣才完成了 HHVM 的 PHP7。

另外，我想說的是我很好奇 Node 的開發者們在使用哪個版本來工作（v0.12.5 已經開始在寫了），即使經過了 6 年的必展。這是不成熟的和危險的（天啊，你使用一個不穩定的技術，你在故意讓你的企業掛掉嗎），加上一點，它忽略了一些操作系統中的舊 bug，將導致一些重要的開發人員從這個語言的生態系統中離開。

一些負面的經歷讓我不喜歡 Node，主要是因為 npm。未來或許會改變，但現在每次使用 Node 都覺得恐懼和失望。我們都有自己的喜好，但保持客觀，選擇正確的工具來工作是很重要的。但同樣重要的是要允許別人試錯，因為人人都是馬后炮。所以不要聽 Craig 的，不要聽 Jim 的，也不要聽我的。大膽去試，看看什么可以用，找些讓你感覺不錯的來使用，最終，那些讓你感覺富有成效的就是最好的，而不是哪些只能節省一些加載時間的。

James:

Node 很火，在 Node 的領域有很多創新，盡管激情是不客觀的，但很高興 Node 贏得了這一局。

第十輪：未來

第十輪著眼于兩種語言的前景，基于兩種語言在現階段看起來都有一個前程強勁的未來，Craig 斷定這一輪的結果是平局。

Bruno：

Bruno 不得不趕快去寫多寫一些關于 PHP 的文章，還要維護那讓人驚嘆的 SitePoint PHP 頻道。

James：

James 也等不及要回到他摯愛的 JavaScript 頻道，但是他留下了這些觀點：

平局對于這一輪來說是公平的。Node 是一顆崛起的明星，但是如果想撼動 PHP 的寶座，他還需要付出巨大的努力。

總 的來說，如果錘子是你唯一的工具，那么每個問題看起來都像一顆釘子。Node 并不會完美適配于每一個方案，當然很多時候不使用 Node 也是非常合理的。然而，Node 能做到的，他可以做得非常好。這完全由你自己來做一個明智的決定，去選擇一個適合自己項目的最好的工具。

既然 Bruno 和 James 都發表了自己的觀點，那么你是怎么看這個問題的呢？

Bruno Skvorc  

克羅地亞的程序員Bruno擁有計算機科學，英語和文學三個碩士學位。他是 SitePoint 網站 php 專欄作家，還是 Diffbot.com 的開發布道者. 他避免像瘟疫一樣的遺留代碼，挑選項目是盡管使用最新技術，他還是一個 treadmill desk enthusiast 和活板玩家，他有一個博客：sometimes blogs.

James Hibbard  

我是一個網站開發者，目前居住在陽光明媚的德國北部。我喜歡使用 JavaScript 和 Ruby 編程，你在SitePoint 的 javascript 論壇經常能看到我。不寫代碼時我喜歡跑步。