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 方法錯誤等。

下文引用自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。這多令人興奮！