php 與 js 你會選誰？這個問題好像問得比較奇怪，php通常被認為是後端處理的，本站（php是什麼意思）做了比較好的介紹：php是一個基於服務端來建立動態網站的指令碼語言。而JS通常被認為是處理前端的，JS是JavaScript的簡稱，是一種直譯式指令碼語言，是一種動態型別、弱型別、基於原型的語言。
但是 出來後，一切變得不一樣了。
Node 公開宣稱的目標是 “旨在提供一種簡單的構建可伸縮網路程式的方法”。
當前的伺服器程式有什麼問題？我們來做個數學題。在 Java? 和 PHP 這類語言中，每個連線都會生成一個新執行緒，每個新執行緒可能需要 2 MB 的配套記憶體。在一個擁有 8 GB RAM 的系統上，理論上最大的併發連線數量是 4,000 個使用者。隨著您的客戶群的增長，如果希望您的 Web 應用程式支援更多使用者，那麼，您必須新增更多伺服器。當然，這會增加伺服器成本、流量成本和人工成本等成本。除這些成本上升外，還有一個潛在技術問題，即使用者可能針對每個請求使用不同的伺服器，因此，任何共享資源都必須在所有伺服器之間共享。鑑於上述所有原因，整個 Web 應用程式架構（包括流量、處理器速度和記憶體速度）中的瓶頸是：伺服器能夠處理的併發連線的最大數量。
Node 解決這個問題的方法是：更改連線到伺服器的方式。每個連線發射一個在 Node 引擎的程序中執行的事件，而不是為每個連線生成一個新的 OS 執行緒（併為其分配一些配套記憶體）。Node 聲稱它絕不會死鎖，因為它根本不允許使用鎖，它不會直接阻塞 I/O 呼叫。Node 還宣稱，執行它的伺服器能支援數萬個併發連線。
現在您有了一個能處理數萬個併發連線的程式，那麼您能通過 Node 實際構建什麼呢？如果您有一個 Web 應用程式需要處理這麼多連線，那將是一件很 “恐怖” 的事！那是一種 “如果您有這個問題，那麼它根本不是問題” 的問題。在回答上面的問題之前，我們先看看 Node 的工作原理以及它的設計執行方式。
SitePoint 的 PHP vs 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“概念上更簡單” 的進入門檻更高。對此沒有爭議。
第二輪: 幫助和支援
第二輪會考量在兩種語言中，獲得幫助和支援的難易程度。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（）就是其中之一。
第四輪：開發工具
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開發人員可能希望（或需要）在某些場合安裝。反過來不是真的。
第五輪: 環境
第5輪要說的是技術的可用性和部署情況，以及被哪些平臺和生態系統支援。Craig 對於這一點也不十分明確，但是看起來似乎更偏向於 Node。
Bruno:
Craig 說他曾比較 PHP 和 Node 在 web 方面的優勢（常見的 web 開發問題），然後說到處都用到了 JS。首先，我們來比較 ，而不是 JS 本身，其次，我們比較了兩種語言在什麼環境下可以執行。猴子比魚要厲害，因為魚太蠢了不能爬樹，但是猴子和魚都會游泳。那麼我們來比較它們做得怎麼樣吧。
在 web 開發環境中，PHP 獲勝了。這裡是一些基於 PHP 的桌面程式工具——是的，也許你不會使用它們，但你一定會用這些基於 PHP 的命令列程式。
James:
我和 Craig 又一次達成一致。一些特性讓 變得如此流行（速度，可擴充套件性，與 JSON 密切相連，低資源佔用）使它適合於許多其他型別的應用程式，例如強有力的物聯網裝置。我覺得，誰會不喜歡機器人呢？
Node 使得專案獲得了提升，諸如（一個基於 Chromium 和 的應用），它允許你在 HTML 和 JavaScript 上編寫本地 APP。這多令人興奮！
