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

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

時間在推移

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

回到過去，我認為那些使用Perl進行Web開發(fā)的頑固人員是愚蠢的。現(xiàn)在，經(jīng)過10年的PHP開發(fā)，我處于同樣的位置。我可以使用PHP在一小時內(nèi)淘汰一個好的網(wǎng)站并在一兩天內(nèi)開發(fā)出一個好的網(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中的三行和四行習慣編寫轉(zhuǎn)換為一流的語言結(jié)構(gòu)。這看起來非常像我需要的PHP替代品，以及使開發(fā)工作更快的事情。

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

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

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

第三，我非常不信任自動生成的代碼。工具可以幫助您生成模板式代碼，但是您的程序有很多無用的代碼來實現(xiàn)這些目標，這并不好。代碼生成喜歡“魔術(shù)推理”，因為生成器不確定代碼的某些特別有用的特征是否是在區(qū)域設(shè)置中專門編寫或固有的。神奇的推理是危險的。

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

那么缺的是什么？

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

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

仍在等待

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