在最近 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 不舒服，而且如果你在電腦上安裝了同一個庫的兩個版本的話，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:
錯誤比比皆是。首先，這篇文章 有關於效能的詳細討論， 其中排除了開發者經驗以及應用類型對效能的影響。如果那篇文章依然無法讓你明白拋開上下文談性能有多愚昧，那來我來談談我的觀點：
關於性能的討論現在是，而且以後也將是——平局（除非你用的是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 論壇經常能看到我。不寫程式時我喜歡跑步。
以上就介紹了PHP 和 Nodejs 的10項對比挑戰，包含了面向的內容，希望對PHP教學有興趣的朋友有幫助。
