PHP 和 Node.js 的10項對比挑戰

在最近 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 論壇經常能看到我。不寫程式碼時我喜歡跑步。