seldo.com网站上曾发表过一篇文章《php needs to die. what will replace it?》，文中提到php将亡，而最明显有潜在能力继任php的是ruby on rails。外刊it评论对此文进行了翻译全文如下：
是到了php落幕的时候了。就在我这个顽固的php分子正要把一个现有的ruby on rails代码库转换成php时，我要说这样的话。
历史在重演
我认为php将亡，因为我以前见到过。大概十年之前，php灭掉了perl。当然了，并不十分彻底；它还坚守在某些环境里，它还有相当可观数量的顽固粉丝，遗留下来的应用程序也需要维护，持续几十年。但这种语言对于新一代的人，特别是web开发者，它在1999年就开始灭亡了，到2005年左右几乎完全死了。
作为在那个时期出现的新的web开发者，事情显的很明白而且水到渠成：perl已经不适应新的应用开发环境了。在perl里，页面需要冗长的公式化的cgi方式实现，而这些在php里却可以用基本的、缺省的编程方式实现。perl语言里到处都是旧时代的特征 — 引用，不方便的数据结构，还有其他许多的小的古怪语法语义 —— 这使得web开发冗长，不稳定，不方便。无怪乎没有一个出色的web应用是用perl写成的，而用php你却能做的又快又简单，尽管php存在着在当时就显而易见的缺陷。
在1999年支持perl反对php的争论有很多：perl要快的多，有更多的程序库和驱动支持，cpan是个神奇的地方，里面预先写好的代码能让你绝大部分任务省去80%的工作量。现在看起来这些就有点可笑了，但“php缺乏可扩展性”却是个真正的缺点。但总之php赢了，因为上面所说的这些问题并不是这种语言固有的。php解释器可以变得更快，程序库可以被开发出来，pera和pecl目前已经变得相当庞大，这还不包括各种厂商希望人们去使用他们的api而提供的非正式的程序库。
时间在推移
十年之后，我可以感觉到历史大潮正在重演。开发人员对语言的期望在前进。如果说perl最缺乏的是php里令人惊讶的灵活的“关联数组”(也就是智能哈希表)，那么php现在缺乏的就是lambdas和方法链(method chaining)了。同时php往往是用在只要20行代码就能写出一个网页的地方，而如今却是如果你不使用什么mvc框架之类的东西就会被认为没有把事情做对。公式化的代码表明了问题所在：这种语言需要一个框架来替人们做这些事情。
退回到以前，我认为那些顽固的使用perl来做web开发的人很傻。现在，经历了十年的php开发，我处在相同的位置上了。我可以在一个小时里用php敲出一个不错的网站，在一两天里开发出一个优秀的网站。php的性能众人皆知，我可以无限的扩展它。我雇佣过的每个开发人员都会它，我集成过的每个系统里都有一个用它写出的打包的代码库。我深陷于php的方便性，尽管它对于我的任务并不是一个合适的语言。
转向ruby on rails
最明显有潜在能力继任php的是ruby on rails。ruby是一个新的、干净的语言，具有现代的语言特征，松散、优雅的语法(很像python)。rails省去了我们常见的任务，省去了集成web应用里的公式化的做法，把php里三、四行的习惯写法变成了first-class语言结构。这看起来极其像我需要的php替代品、能让开发工作再一次提速的东西。
我每天使用rails，修改一个喜爱这种框架和语言的有经验的rails专家所写的rails应用，七个月后，我却不能断言rails是一个正确的选择了，原因很难表达。我这篇文章的目的就是想试图把原因说清楚。
我的主要的抱怨，必须要提的，就是性能。我之前就说过这种问题不应该被当作一种语言的致命缺陷，它只是语言实现中的暂时的问题。所以我不能把这当作一个真正的问题，尽管它是我把现在的应用移植到php的最主要的一个原因。我可以让rails跑的跟php一样快，但那需要提供2到4倍高的硬件条件。我估计五年内将还会这样，五年后我也许不必把程序移植到php。但现在，它不能满足我的要求。
第二，我讨厌active record。active record是一种模式，并不是ruby固有的，在rails的最新版本里是可选择的，但是对它的使用和这种模式已经深入到了rails的dna里了。我之前曾解释过为什么我认为这数据库上的orm不是个好做法，所以我不会再重复解释,但有一点我需要总结的就是你省去了手工写crud所获得的效能要大于activerecord做傻事所损失的效能，要花时间搞清楚它是怎么工作的，顺应框架原则，防止它做这样的事情。
第三，我十分的不信任代码自动生成。工具能帮你生成模板式的代码很有用，但你的程序了却多出了成堆的毫无用处的代码来实现这些目的，这就变的不好了。代码生成喜欢“神奇推理”，因为生成器并不确定代码某些特别有用的特征究竟是专门写出的还是语言环境固有自带的。神奇推理是危险的。
代码生成让我想到了ruby on rails的一个可能是最根本的问题，就是它并不是一种语言。ruby是一种语言。但ruby，它在解决了php上的一些基本问题外，并没有解决核心问题，那就是现代web应用需要一系列的改进：像routing,model/view分类，drop-in功能性等都是很常见的特征。rails里有，但这跟php里的zend，symfony 和 code igniter之类的mvc框架一样只是绑上去的绷带。
那么缺的是什么?
能够取代php的语言必须十分优秀于php，就如同php优秀于perl一样。它必须承担起web应用的主要实现任务，就像php那样，你的代码的主要功能就是输出网页——一个有点激进的要求，它要不适合去做其它的事情，例如当中shell脚本语言。我希望有这样一种语言，它能够承担起我开发一个mvc式的web应用时的所有的任务，所有功能都是核心内置的，不能仅是一个程序包。
问题是，没有这样的一种语言。有一段时间服务器端javascript看起来将会成为下一个重要的语言，它能统一web应用前端和后端的编程语言。但是这些javascript上的伟大思想总是徘徊在一些跑题的行为上，比如nodejs：事件驱动模式非常的激进和强大，能让你开发出高性能的应用程序，最大化的使用新式硬件，但这是一种开发服务器端应用程序的思路，不是web页面。并且你仍然需要去写一大堆可怕的web页面。另外一些commonjs的成果例如ejscript开始尝试着取代php，但仍没有解决框架问题。
仍在等待
我不得不做出结论，php的替代者还不存在。ruby on rails很好，但并不比一个php之上的类似的mvc框架强多少，更别提由于ruby自身的效率不高和activerecord的orm恶搞带来的双重打击。python看起来并不感兴趣于作为下一代的web语言，javascript的服务器端解决方案还刚刚只是个开始。
我等待下一个大目标的出现。我希望能从php上转走，真的。我可不想成为perl式的古董。但不管怎样，这种语言看起来还不存在。我判断错了吗？
php needs to die. what will replace it?
译文链接：http://www.aqee.net/2010/10/11/php-needs-to-die-what-will-replace-it/