毫無疑問，在目前的腳本語言中，PHP、Ruby以及Python是開發(fā)者最受歡迎的三種語言，特別是PHP，其在Web開發(fā)領(lǐng)域的應(yīng)用最為廣泛。然而歷史證明，PHP總有落幕的一天。

公司主營業(yè)務(wù)：網(wǎng)站設(shè)計、成都網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴(yán)謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)公司推出全州免費做網(wǎng)站回饋大家。

歷史在重演

PHP將亡？就像大概十年之前，PHP滅掉了Perl一樣。當(dāng)然了，并不十分徹底；它還堅守在某些環(huán)境里，它還有相當(dāng)可觀數(shù)量的頑固粉絲，遺留下來的應(yīng)用程序也需要維護，持續(xù)幾十年。但這種語言對于新一代的人，特別是Web開發(fā)者，它在1999年就開始滅亡了，到2005年左右?guī)缀跬耆懒恕?/p>

[[16047]]

作為在那個時期出現(xiàn)的新的Web開發(fā)者，事情顯的很明白而且水到渠成：Perl已經(jīng)不適應(yīng)新的應(yīng)用開發(fā)環(huán)境了。在Perl里，頁面需要冗長的公式化的CGI方式實現(xiàn)，而這些在PHP里卻可以用基本的、缺省的編程方式實現(xiàn)。Perl語言里到處都是舊時代的特征 — 引用，不方便的數(shù)據(jù)結(jié)構(gòu)，還有其他許多的小的古怪語法語義 —— 這使得Web開發(fā)冗長，不穩(wěn)定，不方便。無怪乎沒有一個出色的Web應(yīng)用是用Perl寫成的，而用PHP你卻能做的又快又簡單，盡管PHP存在著在當(dāng)時就顯而易見的缺陷。

在1999年支持Perl反對PHP的爭論有很多：Perl要快的多，有更多的程序庫和驅(qū)動支持，CPAN是個神奇的地方，里面預(yù)先寫好的代碼能讓你絕大部分任務(wù)省去80%的工作量?，F(xiàn)在看起來這些就有點可笑了，但“PHP缺乏可擴展性”卻是個真正的缺點。但總之PHP贏了，因為上面所說的這些問題并不是這種語言固有的。PHP解釋器可以變得更快，程序庫可以被開發(fā)出來，PERA和PECL目前已經(jīng)變得相當(dāng)龐大，這還不包括各種廠商希望人們?nèi)ナ褂盟麄兊腁PI而提供的非正式的程序庫。

時間在推移

十年之后，我可以感覺到歷史大潮正在重演。開發(fā)人員對語言的期望在前進。如果說Perl最缺乏的是PHP里令人驚訝的靈活的“關(guān)聯(lián)數(shù)組”(也就是智能哈希表)，那么PHP現(xiàn)在缺乏的就是lambdas和方法鏈(method chaining)了。同時PHP往往是用在只要20行代碼就能寫出一個網(wǎng)頁的地方，而如今卻是如果你不使用什么MVC框架之類的東西就會被認為沒有把事情做對。公式化的代碼表明了問題所在：這種語言需要一個框架來替人們做這些事情。

退回到以前，我認為那些頑固的使用Perl來做Web開發(fā)的人很傻?，F(xiàn)在，經(jīng)歷了十年的PHP開發(fā)，我處在相同的位置上了。我可以在一個小時里用PHP敲出一個不錯的網(wǎng)站，在一兩天里開發(fā)出一個優(yōu)秀的網(wǎng)站。PHP的性能眾人皆知，我可以無限的擴展它。我雇傭過的每個開發(fā)人員都會它，我集成過的每個系統(tǒng)里都有一個用它寫出的打包的代碼庫。我深陷于PHP的方便性，盡管它對于我的任務(wù)并不是一個合適的語言。

轉(zhuǎn)向Ruby on Rails

最明顯有潛在能力繼任PHP的是Ruby on Rails。Ruby是一個新的、干凈的語言，具有現(xiàn)代的語言特征，松散、優(yōu)雅的語法(很像Python)。Rails省去了我們常見的任務(wù)，省去了集成Web應(yīng)用里的公式化的做法，把PHP里三、四行的習(xí)慣寫法變成了first-class語言結(jié)構(gòu)。這看起來極其像我需要的PHP替代品、能讓開發(fā)工作再一次提速的東西。

我每天使用Rails，修改一個喜愛這種框架和語言的有經(jīng)驗的Rails專家所寫的Rails應(yīng)用，七個月后，我卻不能斷言Rails是一個正確的選擇了，原因很難表達。我這篇文章的目的就是想試圖把原因說清楚。

我的主要的抱怨，必須要提的，就是性能。之前就說過這種問題不應(yīng)該被當(dāng)作一種語言的致命缺陷，它只是語言實現(xiàn)中的暫時的問題。所以我不能把這當(dāng)作一個真正的問題，盡管它是我把現(xiàn)在的應(yīng)用移植到PHP的最主要的一個原因。我可以讓Rails跑的跟PHP一樣快，但那需要提供2到4倍高的硬件條件。我估計五年內(nèi)將還會這樣，五年后我也許不必把程序移植到PHP。但現(xiàn)在，它不能滿足我的要求。

第二，我討厭Active Record。Active Record是一種模式，并不是Ruby固有的，在Rails的最新版本里是可選擇的，但是對它的使用和這種模式已經(jīng)深入到了Rails的DNA里了。我之前曾解釋過為什么我認為這數(shù)據(jù)庫上的ORM不是個好做法，所以我不會再重復(fù)解釋,但有一點我需要總結(jié)的就是你省去了手工寫CRUD所獲得的效能要大于ActiveRecord做傻事所損失的效能，要花時間搞清楚它是怎么工作的，順應(yīng)框架原則，防止它做這樣的事情。

第三，我十分的不信任代碼自動生成。工具能幫你生成模板式的代碼很有用，但你的程序了卻多出了成堆的毫無用處的代碼來實現(xiàn)這些目的，這就變的不好了。代碼生成喜歡“神奇推理”，因為生成器并不確定代碼某些特別有用的特征究竟是專門寫出的還是語言環(huán)境固有自帶的。神奇推理是危險的。

代碼生成讓我想到了Ruby on Rails的一個可能是最根本的問題，就是它并不是一種語言。Ruby是一種語言。但Ruby，它在解決了PHP上的一些基本問題外，并沒有解決核心問題，那就是現(xiàn)代Web應(yīng)用需要一系列的改進：像routing,model/view分類，drop-in功能性等都是很常見的特征。Rails里有，但這跟PHP里的Zend，Symfony 和 Code Igniter之類的MVC框架一樣只是綁上去的繃帶。

那么缺的是什么？

能夠取代PHP的語言必須十分優(yōu)秀于PHP，就如同PHP優(yōu)秀于Perl一樣。它必須承擔(dān)起Web應(yīng)用的主要實現(xiàn)任務(wù)，就像PHP那樣，你的代碼的主要功能就是輸出網(wǎng)頁 —— 一個有點激進的要求，它要不適合去做其它的事情，例如當(dāng)中shell腳本語言。我希望有這樣一種語言，它能夠承擔(dān)起我開發(fā)一個MVC式的Web應(yīng)用時的所有的任務(wù)，所有功能都是核心內(nèi)置的，不能僅是一個程序包。

問題是，沒有這樣的一種語言。有一段時間服務(wù)器端JavaScript看起來將會成為下一個重要的語言，它能統(tǒng)一Web應(yīng)用前端和后端的編程語言。但是這些JavaScript上的偉大思想總是徘徊在一些跑題的行為上，比如nodejs：事件驅(qū)動模式非常的激進和強大，能讓你開發(fā)出高性能的應(yīng)用程序，最大化的使用新式硬件，但這是一種開發(fā)服務(wù)器端應(yīng)用程序的思路，不是Web頁面。并且你仍然需要去寫一大堆可怕的Web頁面。另外一些CommonJS的成果例如ejScript開始嘗試著取代PHP，但仍沒有解決框架問題。

仍在等待

不得不做出結(jié)論是，PHP的替代者還不存在。Ruby on Rails很好，但并不比一個PHP之上的類似的MVC框架強多少，更別提由于Ruby自身的效率不高和ActiveRecord的ORM惡搞帶來的雙重打擊。Python看起來并不感興趣于作為下一代的Web語言，JavaScript的服務(wù)器端解決方案還剛剛只是個開始。

我們等待下一個大目標(biāo)的出現(xiàn)。我希望能從PHP上轉(zhuǎn)走，真的。我可不想成為Perl式的古董。但不管怎樣，這種語言看起來還不存在。我判斷錯了嗎？

原文鏈接：http://www.aqee.net/2010/10/11/php-needs-to-die-what-will-replace-it/

【編輯推薦】

1. 關(guān)于PHP你可能不知道的10件事
2. PHP資深開發(fā)者談：緣何放棄PHP改用Python
3. PHP將成為最受開發(fā)人員歡迎的語言嗎?
4. 腳本語言排行榜 PHP、Ruby和Python領(lǐng)先
5. PHP成為中國應(yīng)用最廣的Web開發(fā)語言

分享標(biāo)題：PHP將死，何以為繼？
標(biāo)題路徑：http://uogjgqi.cn/article/cooosge.html