CSC/ECE 517 Summer 2008/wiki2 1 tm

Rails vs. PHP

While Ruby is fast growing in popularity, there are still more PHP Web applications communicating with MySQL databases. Compare Rails with support for Web applications in PHP. Which are the advantages of each for the developer? For the finished application?

Introduction

This document seeks to enlighten programmers who are deciding between using PHP or Ruby on Rails for their next web application. We will take a look at the differences which matter most in determining just which language is right to your project. Please note that this document does not plan to blindly promote one language over another, it seeks to give you the information needed to decided which language is right for your next application. You may use this information each time you begin a new project and decide on a different language each time.

Fixed Metrics

Fixed metrics will likely affect all projects and programmers making a choice between Ruby on Rails or PHP.

General Installation

Standard PHP deployments in the majority of web hosts consist of Linux, Apache, MySQL, and PHP. This application stack is popular enough to be known as LAMP, and it is the platform of choice for the development and deployment of high performance web applications. PHP also works well in a shared hosting environment, which may explain its popularity, particularly with smaller web sites. And since LAMP is a mature application stack, competitors to this stack must fight inertia, as many developers have made significant investments in PHP.

Being a relatively new framework, Rails deployment can be tricky. Deploying Rails applications to production is constantly changing and improving, but the installation is nowhere near as simple as PHP. For instance, the Ruby on Rails configuration is far more varied, with no dominant configuration having yet emerged. Rails will run under Apache (via FastCGI), lighttpd, or nginx by proxying to Mongrel. Because of these complexities, Rails developers recommend VPS solutions, rather than shared hosting, for Rails applications. The author of Rails, David Hansson, had the following to say on shared hosts in Ruby:

"Most Rails contributors are not big users of shared hosting and they tend to work on problems or enhancements that'll benefit their own usage of the framework. You don't have to have a degree in formal logic to deduce that work to improve life on shared hosting is not exactly a top priority for these people, myself included."

Dreamhost, a popular shared hosting service, offers Ruby on Rails in their application stack, but their deployment has not come without difficulty. Dallas Kashuba of Dreamhost comments: [1]

"That suggestion shows either a complete lack of understanding of how web hosting works, or an utter disregard for the real world. It’s all good and fine to recommend that users use higher end dedicated server hosting for their commercial applications but you simply cannot ignore the fact that nearly everyone will want to use lower cost shared hosting for getting started. It’s just simple economics. Additionally, people who use systems like Ruby on Rails want to spend time programming and not time setting up servers. Recommending technologies that are not widely used or supported by any major web hosting company is putting too much of a burden on your users."

Comments such as the above serve to explain the slower adoption rate of Rails, as well as the comparatively larger numbers of PHP hosts than Rails hosting companies.

Package Management

Often, the programmatic features provided with a language are incidental to the frameworks and set of libraries that they offer their developers. A rich language can become largely ineffective for rapid development if it lacks in necessary built-in or third-party functionality critical to the application. It is in this area that package management comes into play.

In PHP, extensions as a way to extend the core language. These extensions are written in C, compiled, and then loaded as dynamic libraries by modifying the php.ini startup file. These are a large number of such extensions, ranging from compression and archival to image processing and generation. Because these extensions are natively compiled, they tend to have relatively fast execution speeds, and provide a mechanism for adding functionality to PHP in a way that would otherwise not be practical in the PHP language itself.

For reusable components written in PHP, the PHP Extension and Application Repository (PEAR) is available. PEAR is a framework and distribution system for reusable PHP components. Through the combination of PECL and PEAR, an enormous repository of reusable extensions and components are available for general developer use.

Rails, on the other hand, offers plugins to extend the Rails frameowork. A Rails plugin is either an extension or a modification of the core framework, and provides a way for developers to share bleeding-edge ideas without hurting the stable code base. Ruby also offers the RubyGems package management system, which Rails can take advantage of. The differences between plugins and gems is a subtle one, but it can be summarized as follows: Plugins are installed for specific Rails applications and extend their functionality, while Gems are installed within Ruby and become available to all applications that use the interpreter.

In general, the set of extensions and components offered by PHP far exceed those offered by Ruby on Rails. As the Rails framework matures, this gap will steadily close.

Learning Curve and Development Speed

PHP development is relatively simple for newcomers to learn the basics. More advanced developers are also using PHP development because there is almost no limit to what can be done when it is used properly. [2] PHP's primary strength is in rapid development of dynamic web pages. Developers without heavy programming experience can leverage PHP to complete tasks otherwise cryptic or obtuse in alternative languages. [3] Productivity in PHP can be accomplished with just a few basic syntax and language features, but at the expense of maintainable depending on the experience of the developers [4]

While creating simple, toy applications in Rails can be done in under an hour, there is a steep learning curve in developing real-world projects. Rails development is actually difficult without having a mastery of the underlying Ruby language and Rubyisms.

http://www.edpci.com/Articles/Learning_Ruby_on_Rails_2007-11-08-A.pdf http://thinkingdigitally.com/archive/rails-has-a-low-learning-curve-hardly-you-need-to-know-ruby/ http://www.buildingwebapps.com/articles/7-understanding-ruby-on-rails

Variable Metrics

Variable metrics must be considered each time a project is taken on. These will likely change between each of your projects. It would be a good idea to evaluate them each time you must choose to use PHP or Ruby on Rails.

Scalability

Filler text goes here http://www.scribd.com/doc/49575/Scaling-Rails-Presentation http://www.techcrunch.com/2008/05/01/twitter-said-to-be-abandoning-ruby-on-rails/ http://www.buildingwebapps.com/articles/13-can-rails-scale-absolutely

Development Speed

Filler text goes here http://www.cmswire.com/cms/industry-news/php-vs-java-vs-ruby-000887.php http://www.radwin.org/michael/blog/2005/10/php_at_yahoo_presentation_.html

Development Tools

Filler text goes here

Maintainability

The simplicity of PHP comes with a cost: maintainability. The unstructured nature of PHP development, in the hands on inexperienced programmers, can lead to write-once or spaghetti code. While writing quick and dirty applications is easy within PHP, such applications can quickly become large in size and scope, fraught with embedded business logic and HTML, and difficult to maintain in the long term. The language has been described as "Spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML, replicated in slightly-varying form in dozens of places."

Other Factors

Development Model

Ruby on Rails is a full stack framework, and includes components such as ActiveRecord , an object-relational mapper, to interface with databases. In general, Rails places a large emphasis on coding standards and convention when designing Rails applications. PHP, on the other hand, provides a large set of core libraries, with many third party add-ons for additional functionality. For example, databases in PHP may be connected to with low-level API database-specific calls, or through higher level APIs such as Pear::DB, ADOdb, and even MDB2.

Similarly, templates for views in Rails are specified in an MVC design pattern. In PHP, programmers can opt not to use templating at all, instead embedding their business logic directly within their view. Alternatively, they can use a variety of templating frameworks such as Smarty, or PHPLIB, just to name a few. Indeed, some would argue that PHP itself is a templating language, and requires no additional templating engine on top of it.

Both PHP and Ruby have their advantages. PHP provides a greater amount of flexibility in the architecture of your application, at the expense of dealing with multiple, sometimes fragmented frameworks. The Rails' strict adherence to convention allows for more uniform development across applications within an organization, but applications with unique requirements that do not fit cleanly into the Rails MVC framework may require additional resources to code around the framework's limitations.

Support and Documentation

Zend offers extensive support through books, mailing lists and newsgroups. Rails help is not as centralized, though the Ruby on Rails Forum and the newsgroup comp.lang.ruby can provide assistance. A large part of the development in Ruby on Rails is sponsored by 37 Signals.

With respect to documentation, PHP developers rely on the searchable PHP Manual. The Rails Documentation is also comprehensive but has fewer code examples, and lacks the ability for users to provide their own comments as additions to the documentation.

External Links

• 7 Reasons I Switched Back to PHP After 2 Years on Rails.
• Rails for PHP Developers
• PHP vs. Ruby: Practical Language Differences
• http://www.robbyonrails.com/articles/2007/01/23/announcement-new-ruby-on-rails-deployment-group

Back to the assignment page