A comparison between the #5 language (ranked popularity by Tiobe on Jan/07) and the #1 framework (ranked lovability by me!).

When it comes to programming, more specifically the development of web applications, it is important to consider all the tools of the trade before using the one that is going to be used for the job.

For some background, I have been programming web applications since I was 13 years old, over 11 years ago today. I started with a simple language called HTML, which evolved into experience with JavaScript mouseovers, then PHP counters and include files, after that onto the MySQL to store the data from the forms for dynamic input, and then into CSS. In retrospect, learning CSS was likely the most difficult thus far to learn out of all of technologies as it required a significant unlearning of the firmly committed <table> tag from my memory. After CSS had been installed, I got equipped with XHTML 1.0, and started looking at more “enterprise” level languages and came across Java, .NET, and even a bit of Perl.

We need to pause here, because this was a major decision in my career. This was now 3 years along my path of web development, and I was working at a company called Tantalus. A major Java shop on Mainland Street in Yaletown that was run by the late Patrick Whelan. It was here that I got my first cup of Java knowledge, and I must say it was hard to swallow.

My brother Martin also worked at Tantalus as a Systems Administrator, managing all their amazing Sun servers and making elegance out of the hosting required for the Java and Oracle apps they were deploying for companies such as Future Shop and other major organizations. Martin continued to push Java as my saviour, saying that if I took a 2 year course at BCIT I could be starting at 45k-60k a year right out of school (which was actually true at the time). He even gave me free books, which I still have on my book shelf (collecting dust). Even more importantly, he gave me a class map of the Java tree and I was amazed. Looking over it in amazement at all the libraries, you could do everything with Java.

Here in lies the problem. Java is a swiss army knife in your web development toolkit, if you ever do decide to learn it. You can pretty much build everything from a cell phone app, to a full on desktop application. It is an amazing language, but it’s just that. Huge. I kept the poster on my wall for months, probably even close to a year if I time-stamped it.

While considering the advice provided by my brother, I decided to take a workshop taught by one of the Tantalus Java gurus and was interested. I learned some C and C++ back in high school in a Computer Science AP (advanced placement), which was a first year university course in high school, and found some very similar characteristics.

I continued along with my PHP development and self-taught education, seeing that Java was a better language at the time, but just didn’t feel my experience at the time (which now I see as really my interest itself in Java) wasn’t solidified enough to begin learning such a massive and complex language. Concepts such as Objects, inheritance, and other OOP terminology was quite foreign. So I held off learning it, and felt once I learned PHP well enough, would upgrade.

PHP was great. With the release at the time of PHP 4 and it’’s initial object functionality I started to get up to speed with many of the OOP principles. I was building some pretty amazing Content Management Systems, Digital Asset Management Systems, even Web Top Publishing Systems. My previous commitment to learn Java was fading as my experience grew with PHP was growing, seeing that I could build all the amazing things with what I had originally felt was a subordinate language.

I continued to expand my knowledge of PHP, get into the core of the internals and sparked a desire to write some core functionality. I eventually got to meet the creator of PHP (Rasmus Lerdorf) at a Vancouver conference I helped organize back in 2004.

When I started seeing the release candidates and beta code of PHP5 I was really excited. The principles of objects which I had grown to love, were being fully supported and embraced by the language I had gained enough knowledge with to realize there was few things, if any, I could actually do with it. This shelved Java way back on the list of technologies to learn at this point. One of the only things that I can see a use for Java is a drag and drop uploader residing within the browser to avoid the one file upload field plagued by today’s forms.

In any case, PHP was my tool of choice. At this point, it had an enormous amount of libraries, nearly as many as Java. Not to mention WAYYY more open source projects on sourceforge.net that Java could ever hope for. The world supported the language, and so did I.

But. There was a problem. After building these amazing systems, that did some really cool things. I found myself repeating the same lines of code over and over again. I was creating objects that had the get and set methods within objects and had the CRUD principle embraced. I began unifying my approach. Creating a save method that did both a update and create depending on the state of the object, centralizing the objects storing and access mechanisms for my all the data within the database. Evolving to standardize date, text, string, url, and all the other MySQL data field types and personal standardized column types in a base class extended by all Models. Basically, I was simplifying tasks I was doing every time I created a new Model so I didn’t have to repeat myself over and over again.

This was a great time in my development career. Realizing that I was paving a path that I would allow me to be able to create objects that could access fields I created in the database without having to implicitly specify by introspecting what was going on, and create the guts of the Model class automatically. Realizing the productivity gains alone on this were enormous I kept on it. I got quite a long way along this path, before something happened that changed the direction of career entirely.

I found this framework called Ruby on Rails. At first I was extremely frustrated. As many would who were working so hard to create something so important for several years in the background while trying to pay the bills would, and see the tool had already evolved to a very usable state by someone else, and even had a budding community behind it. This was an interesting time, and I began to look into the framework a bit more. And more. And then I decided what was the point of developing the remaining pieces of same thing in PHP when it was already pretty much 100% of what I wanted in another language? Simple choice, learn the new language and framework and save what could be hundreds of hours development.

This was the beginning of my journey learning Ruby on Rails, as well as Ruby the language which the framework was built on.

While learning the framework, I seen some major differences between PHP and the language of Ruby. Things like “for” iterators were somewhat non-existant in a 1:1 comparison.

Something like this in PHP…

<?php
$array = array('my list', 'of', 'items');
for ($index = 0; $index < count($array); $index++) {
  echo "$index. $array[$index]";
}

// alternatively

$array = array('my list', 'of', 'items');
foreach ($array as $index => $item) { echo "$index. $item"; }
?>

Looked like this in Ruby…

<%
array = ['my list', 'of', 'items']
array.each_with_index { |item, index| p "#{index}. #{item}" }
%>

The clarity of the syntax, and the language in general was purely impressive.

I continued to ride along the Rails train, finding more and more benefits along the way, such as previously described as ActiveRecord’s ability to dynamically introspect all the fields of a table and have all the functionality needed to create, update, delete, and read any row of data automatically with one line of code.

In addition, ActiveRecord could be done with any database adapter. Whether it was PostgreSQL, MySQL, Oracle, etc. The factor of connectivity alone when in PHP required additional modules such as AdoDB or PEAR::DB. Both of which has some really crazy syntax that was quite complex to learn. You had to learn SQL, then you had to learn the implementation of SQL abstraction. With Rails, this was inherited.

Another great feature of Ruby on Rails I had discovered was the simple concept of organization. A concept known as MVC was perfect. For those that haven’t heard of the term it’s called Model-View-Controller. It was directly in line with what I had done in the past with PHP projects after adopting concepts from frameworks such as FuseBox and the multitude of others sharing the same principles.

The list of benefits for Rails got better and better, the more I learned of the framework, the happier I was realizing that I wouldn’t have to repeat myself nearly as much as when I was writing PHP apps.

So, while along this learning adventure in the world of Ruby on Rails, I started to find out more about the advanced concepts of Ruby, the underlying language of Rails. The most profound realization of mine was when I learned that there was no waterfall approach to a the Class hierarchy. With PHP and many other languages, you have a Class, and you extended a Class in a new Class to inherit and then subsequently add additional functionality. With Ruby, you have a Class defined in one file, and you can change that same Class entirely in another file by overriding methods, adding new ones. The language was showing it’s true colors as one of the most dynamic tools I had ever used.

Constantly finding myself comparing Ruby to PHP while learning the syntax of the language and underlying Objects, finding the equivalents of things like “count” ([1,2,3,4].length), or “str_replace” (”string”.gsub) in Ruby continued. I found myself in a world of Object Oriented bliss, rarely looking back at the dull, functional world of the PHP library.

It’s been close to 2 years now since I started playing with Rails back in February of 2005, and I have found little reason to go back, other than the odd open source project which is too impressive not to use and save the time it would take to rebuild it in Rails.

Actually, there is one other reason I frequently look back at PHP. The documentation. My learning curve in PHP was spring-boarded due to the elegance of the hard working PHP documentation team, and their choices made to organize the information in such a manner that was instrumental to many peoples adoption and education. So much so, that even right now I find myself remembering my appreciation setting up a local version of the PHP documentation at php.inimit.com helping support the threads of access and decreased latency of users dependent on the documentation with hosting a local mirror sponsored by my development business. It never got accepted as a Canadian mirror due to what seemed like messy political tape of the core PHP team, but that’s besides the point. I still appreciate the documentation, and will continue to host the mirror regardless.

What I find in ever increasing potency is that Ruby and Ruby on Rails needs documentation like PHP. Actually, every language ever created needs documentation like PHP. It is, at least it should be, the gold standard of documentation for anyone learning a language, and could likely be construed as the single most instrumental reason why PHP has had such a significant adoption rate within the world of development.

I became a supporter of the Ruby and Rails documentation project known as Rannotate, and on December 18th, 2005 registered the domain railsmanual.org to ensure that the community benefits from the only similar version of the gold standard of documentation that PHP has. RailsManual is a great resource, but needs some major work to raise it’s value to that of the same degree as PHP.net.

There has been quite of attention as of late on this subject. The people over at caboo.se managed to raise some ~$15,000 USD to help out on the documentation effort, but have had some trouble finding people to actually write the documentation itself.

I have given my $0.02 on the mailing list on how we can solve this, which would actually take the PHP.net documentation system to the next level. It’s really a simple process.

Here is a very basic layout of how I see it looking and functioning like.

rubydocumentor.jpg

It’s really quite simple, but to the point. No one person needs to create the documentation It’s a collaborative approach. The main area of concern for such a collaborative system is the prevention around the area of spam. Without registration, or confirmation of email validity, the site will eventually become ridden with Spam, as nearly every blog has been plagued by.

It may appear that I have digressed on my comparison of PHP vs. Ruby on Rails, but I haven’t really. The one area of Ruby and Ruby on Rails that is flawed, or at least needs major improvement, is the documentation. Everything else about Ruby language at it’s core and the framework of Rails, is amazing.

One thing I have simply glazed over at this point is the fact that Rails is a framework, and PHP is a language. And as the saying goes, you should really compare Apples with Apples, and not Apples (Programming Languages) with Oranges (Frameworks). Ruby on Rails is indeed a framework. One which extends upon the foundation programming language known as Ruby. This means that Rails provides additional functionality on top of Ruby. Including a many number of Objects enhancing capabilities within any application built on top of the Rails layer. These Rails enhancements are specifically catered to those building web applications.

Now to go back in my story, remembering when I mentioned how Java was the swiss army knife that could be used to help create everything a programmer wants, specializing in nothing. PHP in this case, is just that now except it caters to web applications. It is also a programming language that can create everything a programmer wants, but it was built first as a web development language. Where Java could do everything a programmer could want, PHP is falling victim to the same virus that creeps into anything that has been around long enough. Unintended growth in all directions. This isn’t entirely a flaw, but now enough leaves room for something better to come along that is focused on one area rather than all areas.

Ruby is the same as PHP, and even can be compared at a fundamental level to that of Java with one major difference I would like to point out. Ruby is as well focused on doing as much as a programmer wants and needs. But it does it with the elegance, simplicity, and dynamism that is lost with PHP, and next to non existent with Java.

So now that we are somewhat clear of comparisons, realizing that PHP and Ruby on Rails are fundamentally different. Seeing that we are actually comparing a language with a framework. Let’s compare a PHP framework such as PHP on Trax, a clone of Ruby on Rails written in PHP, compared to the original framework that sparked the clone wars - being Ruby on Rails.

For this, we look at an ActiveRecord example from each. Starting with a class definition in PHP on Trax written in PHP.

<?php
class Product extends ActiveRecord {
  public function validate_title() {
    if ($this->title == '')
      return array(false, "Title can't be empty");
    if ($this->find_first("title = '{$this->title}'") != false)
      return array(false, "Title must be unique");
    return array(true);
  }
  public function validate_description() {
    if ($this->description == '')
      return array(false, "Description can't be empty");
    return array(true);
  }
  public function salable_items() {
      return $this->find_all("date_available <= now()", "date_available desc");
  }
}
?>

And now in the same class in Ruby on Rails, inherently written in Ruby.

<%
class Product < ActiveRecord::Base
  validates_presence_of :title, :message => "Title can't be empty"
  validates_uniqueness_of :title, :message => "Title must be unique"
  validates_presence_of :description, :message => "Description can't be blank"
  def salable_items
    Product.find(:all, :conditions => 'date_available <= now()', :order => 'date_available desc')
  end
end
%>

This is a real comparison between the two frameworks, and you can clearly see just by the lines of code alone. Ruby on Rails is less. Ruby on Rails even helps to clean up the validations to mere single lines of code having inherited functionality built within ActiveRecord::Base. And when it comes to Ruby, ignoring entirely all what is actually happening as far as functionality is concerned within the framework’s Class, you see the language really shine. The precision of each character is far from being wasted. There is next to nothing there that doesn’t need to be, allowing for even those understanding the logical order of words an intuitive grasp of what is happening within the lines of code written.

Now, when we decide to stop ignoring what is actually going on, we may ask “What are each of these blocks of code really doing?”.

Each sample creates a Object called Product that you can access throughout your application providing the programmer with:
1) Access to all rows of data in the “products” table through a single interface to create, update, read, and delete.
2) Optional validations for any data that is set to be stored in the database passes certain conditions
3) Integrated error handling
4) As well as inheriting tons, and I mean _tons_ of additional functionality provided by ActiveRecord (PHP on Trax) and ActiveRecord::Base (Ruby on Rails) respectively.

So, now that we have compared only a single slice of each each of the Apples (Languages) as well as the Oranges (Frameworks). We can see the decision really comes down to how much we enjoy the taste of simplicity at this point. Developing in either framework boils down to nearly the same thing. Saving the programmer time when it comes to creating and maintaining and displaying the data within applications.

Ruby provides to Ruby on Rails the simplicity to save more time for programmers compared to the other frameworks. Provides the ability for programmers to write less lines of code than the comparable frameworks. Requires less time for even the most novice programmer to understand what’s going on. And is quite simply more elegant to work with.

Rails has and will continue to be imitated as it has already been in nearly every language. Whether it’s PHP (PHP on Trax), Java (Sails), Perl (Catalyst), Python (Turbo Gears, Django), and even .NET (Castle) - developers from every language recognize the benefits which Ruby on Rails, as proven by their implementations in their native languages.

Yet with all these framework imitations in their respective languages, it comes down to Ruby at the foundation that makes Rails at the heat of it all, so simple, so elegant, so much the reason why it has caught fire so fast and so far across the globe that nearly every developer that is at all interested in keeping their job, has at least heard of it.

The way I see it, the only framework that is going to replace Ruby on Rails, is another one built in Ruby. It’s not the framework that makes it so simple, elegant, and tasty as a whole. It’s the language the framework is built on that makes Rails what it is today.

I would love to hear your thoughts on this, please do comment below or send me a private email from my website.

Have you converted from PHP for the greener pastures of Rails?