作為在此期間出現(xiàn)的新的Web開(kāi)發(fā)人員，事情變得清晰和自然：Perl不再適應(yīng)新的應(yīng)用程序開(kāi)發(fā)環(huán)境。在Perl中，頁(yè)面需要冗長(zhǎng)的，正式的CGI實(shí)現(xiàn)，可以使用基本的默認(rèn)編程在PHP中實(shí)現(xiàn)。 Perl語(yǔ)言充滿了舊時(shí)功能 - 引用，不方便的數(shù)據(jù)結(jié)構(gòu)以及許多其他小的奇怪語(yǔ)法語(yǔ)義。——這使得Web開(kāi)發(fā)變得乏味，不穩(wěn)定且不方便。難怪沒(méi)有一個(gè)用Perl編寫(xiě)的優(yōu)秀的Web應(yīng)用程序，但是使用PHP可以快速輕松地完成它，即使PHP具有當(dāng)時(shí)顯而易見(jiàn)的缺陷。

1999年支持Perl對(duì)PHP有很多論據(jù)：Perl更快，有更多的庫(kù)和驅(qū)動(dòng)程序支持，CPAN是一個(gè)神奇的地方，內(nèi)部預(yù)編寫(xiě)的代碼可以節(jié)省大部分任務(wù)。工作量的百分比。現(xiàn)在看起來(lái)有點(diǎn)荒謬，但“PHP缺乏可擴(kuò)展性”是一個(gè)真正的缺點(diǎn)。但簡(jiǎn)而言之，PHP贏了，因?yàn)樯厦嫣岬降膯?wèn)題并不是這種語(yǔ)言所固有的。 PHP解釋器可以更快，庫(kù)可以開(kāi)發(fā)，PERA和PECL現(xiàn)在非常大，不包括供應(yīng)商希望人們使用其API的非正式庫(kù)。

時(shí)間在推移

十年后，我可以感受到歷史的潮流正在重演。開(kāi)發(fā)人員對(duì)語(yǔ)言的期望正在向前發(fā)展。如果Perl在PHP中缺少令人驚訝的靈活“關(guān)聯(lián)數(shù)組”（即智能哈希表），PHP現(xiàn)在缺少的是lambdas和方法鏈接。同時(shí)，PHP通常用于編寫(xiě)只有20行代碼的網(wǎng)頁(yè)，但現(xiàn)在認(rèn)為如果你不使用類(lèi)似MVC框架的東西，你就不會(huì)認(rèn)為它是正確的。公式化代碼顯示了問(wèn)題：這種語(yǔ)言需要一個(gè)框架來(lái)為人們做這些事情。

回到過(guò)去，我認(rèn)為那些使用Perl進(jìn)行Web開(kāi)發(fā)的頑固人員是愚蠢的。現(xiàn)在，經(jīng)過(guò)10年的PHP開(kāi)發(fā)，我處于同樣的位置。我可以使用PHP在一小時(shí)內(nèi)淘汰一個(gè)好的網(wǎng)站并在一兩天內(nèi)開(kāi)發(fā)出一個(gè)好的網(wǎng)站。 PHP的性能是眾所周知的，我可以無(wú)限擴(kuò)展它。我雇用的每個(gè)開(kāi)發(fā)人員都會(huì)擁有它，并且我集成的每個(gè)系統(tǒng)都有一個(gè)用它編寫(xiě)的打包代碼庫(kù)。我深深沉浸在PHP的便利性中，雖然它不適合我的任務(wù)。

轉(zhuǎn)向Ruby on Rails

在PHP中取得成功的最明顯的潛力是Ruby on Rails。 Ruby是一種新的，干凈的語(yǔ)言，具有現(xiàn)代語(yǔ)言特性，松散，優(yōu)雅的語(yǔ)法（很像Python）。 Rails保存了我們的常見(jiàn)任務(wù)，無(wú)需在集成的Web應(yīng)用程序中進(jìn)行配置，將PHP中的三行和四行習(xí)慣編寫(xiě)轉(zhuǎn)換為一流的語(yǔ)言結(jié)構(gòu)。這看起來(lái)非常像我需要的PHP替代品，以及使開(kāi)發(fā)工作更快的事情。

我每天都使用Rails來(lái)修改由經(jīng)驗(yàn)豐富的Rails專(zhuān)家編寫(xiě)的Rails應(yīng)用程序，他喜歡這個(gè)框架和語(yǔ)言。七個(gè)月之后，我無(wú)法斷言Rails是出于難以表達(dá)的原因的正確選擇。我的文章的目的是試圖說(shuō)明原因。

我必須提到的主要抱怨是表現(xiàn)。之前已經(jīng)說(shuō)過(guò)，這種問(wèn)題不應(yīng)該被視為語(yǔ)言中的致命缺陷，它只是語(yǔ)言實(shí)現(xiàn)中的一個(gè)暫時(shí)問(wèn)題。所以我不能認(rèn)為這是一個(gè)真正的問(wèn)題，即使這是我將當(dāng)前應(yīng)用程序移植到PHP的主要原因之一。我可以讓Rails像PHP一樣快速運(yùn)行，但這需要2到4倍的硬件。我估計(jì)這將在五年后發(fā)生，我可能不必在五年后將程序移植到PHP。但現(xiàn)在，它無(wú)法滿足我的要求。

其次，我討厭Active Record。 Active Record是一種模式，不是Ruby固有的模式。它在最新版本的Rails中是可選的，但它的使用和這種模式已深入到Rails DNA中。我已經(jīng)解釋了為什么我認(rèn)為這個(gè)數(shù)據(jù)庫(kù)上的ORM不是一個(gè)好習(xí)慣，所以我不再重復(fù)，但我需要總結(jié)的一點(diǎn)是你已經(jīng)保存了手動(dòng)寫(xiě)入CRUD并且性能不僅僅是ActiveRecord。失去事實(shí)的有效性，花時(shí)間弄清楚它是如何工作的，符合框架的原則，并防止它做這些事情。

第三，我非常不信任自動(dòng)生成的代碼。工具可以幫助您生成模板式代碼，但是您的程序有很多無(wú)用的代碼來(lái)實(shí)現(xiàn)這些目標(biāo)，這并不好。代碼生成喜歡“魔術(shù)推理”，因?yàn)樯善鞑淮_定代碼的某些特別有用的特征是否是在區(qū)域設(shè)置中專(zhuān)門(mén)編寫(xiě)或固有的。神奇的推理是危險(xiǎn)的。

代碼生成讓我想起Ruby on Rails最基本的問(wèn)題之一，就是它不是一種語(yǔ)言。 Ruby是一種語(yǔ)言。但Ruby解決了PHP的一些基本問(wèn)題，并沒(méi)有解決核心問(wèn)題，即現(xiàn)代Web應(yīng)用程序需要一系列改進(jìn)：例如路由，模型/視圖分類(lèi)，插入功能等等都非常共同。特點(diǎn)。它位于Rails中，但它只是像PHP中的Zend，Symfony和Code Igniter這樣的MVC框架。

那么缺的是什么？

可以取代PHP的語(yǔ)言必須非常擅長(zhǎng)PHP，就像PHP優(yōu)于Perl一樣。它必須承擔(dān)Web應(yīng)用程序的主要實(shí)現(xiàn)任務(wù)。就像PHP一樣，代碼的主要功能是輸出網(wǎng)頁(yè)——。這是一個(gè)有點(diǎn)激進(jìn)的要求，它不適合其他東西，比如shell腳本語(yǔ)言。我希望有一種語(yǔ)言可以承擔(dān)我在開(kāi)發(fā)MVC風(fēng)格的Web應(yīng)用程序時(shí)的所有任務(wù)。所有函數(shù)都內(nèi)置在內(nèi)核中，而不僅僅是一個(gè)包。

問(wèn)題是沒(méi)有這樣的語(yǔ)言。有一段時(shí)間，服務(wù)器端JavaScript似乎是統(tǒng)一Web應(yīng)用程序的前端和后端編程語(yǔ)言的下一個(gè)主要語(yǔ)言。但是這些關(guān)于JavaScript的好主意總是站在行為的一邊，比如nodejs：事件驅(qū)動(dòng)模式是非常積極和強(qiáng)大的，允許你開(kāi)發(fā)高性能應(yīng)用程序，最大限度地利用新硬件，但這是一種方式開(kāi)發(fā)服務(wù)器端應(yīng)用程序，而不是網(wǎng)頁(yè)。你仍然需要寫(xiě)很多可怕的網(wǎng)頁(yè)。其他CommonJS結(jié)果如ejScript開(kāi)始嘗試替換PHP，但仍然沒(méi)有解決框架問(wèn)題。

仍在等待

我必須得出結(jié)論，PHP的替代品還不存在。 Ruby on Rails很棒，但并不比PHP上的類(lèi)似MVC框架好，更不用說(shuō)Ruby本身的低效率以及ActiveRecord的ORM惡搞的雙重打擊。 Python似乎對(duì)下一代Web語(yǔ)言不感興趣，而JavaScript的服務(wù)器端解決方案只是一個(gè)開(kāi)始。