php通常被認爲是後端處理的，JS通常被認爲是處理前端的，但是 出來後，一切變得不一樣了，我們該如何作出選擇呢?下面小編帶大家學習一下。
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 方法錯誤等。
PHP開發人員可能希望（或需要）在某些場合安裝。反過來不是真的。
第五輪: 環境
第5輪要說的是技術的可用性和部署情況，以及被哪些平臺和生態系統支持。Craig 對於這一點也不十分明確，但是看起來似乎更偏向於 Node。
Bruno:
Craig 說他曾比較 PHP 和 Node 在 web 方面的優勢（常見的 web 開發問題），然後說到處都用到了 JS。首先，我們來比較 ，而不是 JS 本身，其次，我們比較了兩種語言在什麼環境下可以運行。猴子比魚要厲害，因爲魚太蠢了不能爬樹，但是猴子和魚都會游泳。那麼我們來比較它們做得怎麼樣吧。
在 web 開發環境中，PHP 獲勝了。這裏是一些基於 PHP 的桌面程序工具——是的，也許你不會使用它們，但你一定會用這些基於 PHP 的命令行程序。
James:
我和 Craig 又一次達成一致。一些特性讓 變得如此流行（速度，可擴展性，與 JSON 密切相連，低資源佔用）使它適合於許多其他類型的應用程序，例如強有力的物聯網設備。我覺得，誰會不喜歡機器人呢？
Node 使得項目獲得了提升，諸如（一個基於 Chromium 和 的應用），它允許你在 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。你想看到輸出，只需要建立一個以“”爲擴展名的文件，在<?和?>間寫一些有效的代碼，上傳，用瀏覽器訪問。但同樣的方 法不適用於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 專欄作家，還是 的開發佈道者. 他避免像瘟疫一樣的遺留代碼，挑選項目是儘管使用最新技術，他還是一個 treadmill desk enthusiast 和活板玩家，他有一個博客：sometimes blogs.
James Hibbard
我是一個網站開發者，目前居住在陽光明媚的德國北部。我喜歡使用 JavaScript 和 Ruby 編程，你在SitePoint 的 javascript 論壇經常能看到我。不寫代碼時我喜歡跑步。
