CSC/ECE 517 Summer 2008/wiki2 1 tm

From Expertiza_Wiki
Jump to navigation Jump to search

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. However, once the basics of Rails are mastered, you’ll be able to produce robust, fully customized applications more quickly than with any other technology. New developers to Rails who are already familiar with an existing language such as PHP will find that they are more productive sticking with the language that they know in small to medium projects. However, in the design of long-term or large scale applications, tackling the Rails learning curve is worthwhile. [5]

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

When PHP first became mainstream, its ability to scale to large Enterprise sites was questioned when contracted with then mature technologies such as J2EE. We know now that PHP can scale, as evidenced by popular sites such as Digg, Wikipedia, and even Yahoo. Yahoo, for example, is the world's most trafficked web site with over 1.5 billion page views per day. Yahoo choose PHP because of its small memory footprint and performance. [6] Digg is another popular web site successfully scaled their architecture by utilizing technologies such as FastCGI, APC, and MCache. [7]

As Ruby on Rails now enters the mainstream, it faces much the same criticism and skepticism as PHP once did. Scaling in Ruby is not as well understand as in PHP, but as Scribd demonstrated, scaling can be accomplished through techniques such as fragment caching and multi-database connections. [8]. Twitter, on the other hand, initially struggled with scalability problems for nearly two years, and had considered abandoning Ruby on Rails for a PHP solution, but they have now addressed their scalability issues. [9]

Ruby has a reputation as a relatively slow language. However, it is a very rare web application that comes anywhere close to being compute-bound, and database access and network delays are almost always the overwhelming factors. [10] In the rare cases where the performance bottleneck is in Ruby itself, the bottlenecks can be re-written by extending Ruby with C.

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

Tools are an essential part of the development cycle and could greatly hinder or enhance your ability to maintain, debug, test, and edit code. Various projects are underway to level the playing field between PHP/Rails tools and other more developed languages like Java. As you can see from the graph above Tim Bray believes Java is leading the pack as far as tools are concerned. This can be contributed to the age of Java vs PHP or Ruby on Rails, but it is also good to note that things are improving.

On the PHP side we have, Zend Studio, Eclipse with either PHPEclipse or PHP IDE Project plug-ins, Komodo, and PHP Designer.

For Ruby on Rails we can also use Eclipse with the RADRails plug-in, NetBeans, or 3rdRail.

These tools, as well as many others, are making Ruby and PHP development much easier than ever. Your choice between these tools may be more a matter of personal preference or company policy than the individual features they support.

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."

Ruby encourages (forces) the programmer to use the "Model, View, Controller (MVC)" architecture. This coding technique allows the software's data model, interface, and business logic to be seperated in every application designed. From the small to the largest of enterprise applications programmers must use good coding techniques. This makes the application much easier to code, read, maintain, and update.

These principles can also be implmented in a PHP environment but the programmer must commit to the model and stick with it.

Derek Silvers used the knowledge gained from Rails to code cdbaby.com and states:[11]

"It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and and I owe it all to Rails."

http://ask.slashdot.org/article.pl?sid=05/12/21/153252&tid=156 http://www.onjava.com/pub/a/onjava/2005/11/16/ruby-the-rival.html?page=1 http://www.bitwisemag.com/2/What-s-Right-With-Ruby

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

Back to the assignment page


Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Summer_2008/wiki2_1_tm&oldid=14158"