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.
http://blogs.sun.com/arungupta/entry/totd_6_difference_between_ruby
Learning Curve and Development Speed
Filler: Compare and contrast the barriers to entry into either language including object oriented design in PHP 5 and the MVC pattern in Ruby. Also covered textbooks, classes, and online resources available between the two languages. What languages you already know often affects what language is best for your new project, especially if deadlines are looming.
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.radwin.org/michael/blog/2005/10/php_at_yahoo_presentation_.html
Development Tools
Filler text goes here
Maintainability
Filler text goes here
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.
The Bottom Line
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