background image

PHP 与 Ruby on Rails 两大阵营均拥有大量各自的忠实粉丝。拿两者作比较,本身就是难
以取舍。无论谁赢了,都会引来对方粉丝的口水。受此影响,在两者选其一这个问题上,
开发者通常会显得犹豫不决。这篇文章的出发点虽然是比较,但并不是一边倒式地唱盛唱
衰,而是辩证式的综合对比。没有好坏,适合自己的才是最好的。

实际上,拿 PHP 与 Ruby on Rails 比较是个伪命题,是不公平的。相比于 Ruby on Rails
语言加框架的完整性,PHP 仅是一门编程语言。你看,PHP 已经输在起跑线上了。但 PHP
拥有四两拨千斤式的轻巧与灵活,这就意味着它消耗极少的内存资源,性能卓越。另一方
面,PHP 社区是成熟的、稳定的,各种 PHP 扩展插件与工具包百花齐放,百家争鸣。如此
看来,PHP 又扳回了一成。

PHP 具有性能高、插件多的优势,并不意味着它没有缺点。PHP 语法源自脚本风格,却加
入面向对象特性,这种画虎不成反类犬的不伦不类,饱受诟病。这也许可以成为 Ruby 
on Rails 粉丝攻击的软肋。另一方面,如前所述,PHP 作为单一编程语言,不具备 Ruby 
on Rails 的框架特性。这就意味着,除非借助插件与工具,单靠 PHP 从零开始开发应用
程序,需要非常高的编程成本。比如,为取得与数据库的连接,你不得不从头开始写一个
数据库连接器 API。但有时候,缺点其实也是优点。不同于 Ruby on Rails,受限于自身的
框架,PHP 则可以灵活自如的选择成熟稳定的第三方插件与工具。这就好比说,单身的同
志也大可不必太羡慕成双成对的鸳鸯,因为没有选择往往意味更多的选择。不同的是,爱

情鼓励专一,而 脚踏几只船 是 PHP 的卖点,开发人员可以同时选择不同的框架,实现
与各种单一功能特性的最佳匹配。在这一点上,对于没有选择的 Ruby on Rails 来说,只
有羡慕的份儿了。正因如此,相对于 PHP 开放性地支持第三方插件而言,Ruby on Rails
天生的封闭特性,无可避免地要面临性能换取功能的挑战。每当遇到无法满足业务程序需
求的时候,就意味着 Ruby on Rails 需要更多的研发成本投入。这绝对是一大利空。

刚才强调了 PHP 的很多优势,如果就此打住,相信会招来 Ruby on Rails 粉丝的无数口
水。是时候该替这个后起之秀说说话了。Ruby on Rails 作为一个框架,是专为 Ruby 这
门编程语言设计的。Ruby 的设计理念很清晰,就是完全的面向对象,语法非常紧凑,清
晰,代价是损失一定的灵活性。从编程语言的性能对比来看,Ruby 通常会比 PHP 慢,耗
用更多内存。不过,Rails 框架能帮助 Ruby 快速开发出 Web 应用程序,算是一种弥补吧。
这是一个典型的功能换性能的例子。作为一个 Web 框架,Rails 具有许多非常多非常棒的
特性。比如,Rails 的 ActiveRecord 特性能支持数据库表记录与 Ruby 对象的映射,带
来的好处是,Rails 帮助开发人员隐藏繁琐的 SQL 细节,直接使用 Ruby 就轻松实现对
数据库的增删改查。换句话说,Ruby 开发人员无需依赖 SQL,照样玩转数据库。另外,
Rails 支持很多的 HTML 特性,比如 HTML 代码生成器,session 机制等,可以更加轻松
便捷地构建 Web 应用。这也觉得是一大利好。

Rails 众多强大的特性,从另一个角度来说,也是一个弊病。比如,Rails 虽然屏蔽
SQL,同时也意味着 Ruby 开发人员失去了直接操控 SQL 的机会。功能多也未必全是需要
的。这样看来,鱼和熊掌,真是不可兼得。

说了这么多,到底谁赢谁输呢?还是那句话,没有谁好谁坏,只有谁更适合。选择自己熟
悉的领域始终是没错的。从个人的感觉来说,还是偏好 PHP。第一,PHP 先入为主,大量
的网站采用的都是 PHP,尤其是论坛。起码 PHP 提供的工作机会更多一些吧。第二,