Getting Started with Ruby on Rails
Issue № 257

Getting Started with Ruby on Rails

You’ve probably heard about Ruby on Rails by now. Your developer friends are raving about it, talking about how they wrote an application in less than half the time it would have taken using some other technology, how they really enjoyed themselves instead of stressing out, and then spent their extra time on the beach. Rails sure does sound like a pretty compelling technology. But what is it, and how does it fit into the big picture of web development?

Article Continues Below

If you’re a designer, user interface architect, writer, or a software developer not yet acquainted with Rails, you might be wondering what this technology is all about. Can it really cut through the headaches so often associated with web application development? Can it turn you, the mild-mannered non-developer, into a web application programmer overnight? Is Rails really the be-all and end-all development platform? What the heck are Subversion and Git? Do I need to learn all of this just to do design for Rails?

In this article, I’ll help prepare you for your first foray into Rails by explaining what it is, how it works, and where it fits into the spectrum of web development and design. I’ll address the issues above and more, with answers geared toward non-Rails developers, designers, and other creative professionals.

This article isn’t a Rails programming tutorial. We won’t be writing code here, but I will introduce you to some of the important concepts critical to understanding how the Rails framework functions. I’ll also explain what you’ll need to know to work with Rails developers and integrate your XHTML and CSS into Rails projects.

I’ll focus on the topics and issues that I’ve learned are most important for creative people instead of boring you with gruesome technical details. Yes, you’ll have to learn what terms like “MVC” mean, for example, but only in the context of getting stuff done.

What is Rails, and why use it?#section1

David Heinemeier Hansson, a partner at 37signals, created Ruby on Rails. As he built Basecamp, their flagship application, David extracted the application’s underpinnings and created code that he could use and re-use for software he wanted to build down the road.

The framework he created proved to be extensible, expandable, and multi-purpose. He decided to share it as open source software. A small group of developers, now known as the Rails Core Team, formed and improved and expanded the framework. After a good deal of effort, Ruby on Rails matured into a robust, solid software development platform. Today, Rails has a strong community and great documentation, and is used by thousands of developers to power hundreds of websites, such as Twitter, Blinksale, and the very site you’re reading now. There’s an even bigger list of sites over at Working with Rails.

Rails is designed to make building web applications simpler and easier. Rails provides developers with a large, easily expandable set of building blocks they can use (and re-use) to create web applications. Developers can use, integrate, and customize these components of code in any manner they choose to, to create the unique functionality they need for their application. Building software this way really helps reduce the time it takes for developers to create and later maintain their applications. It also helps to standardize the way applications get built, making it easier for many developers to collaborate and write more uniform code.

Web designers have time-tested CSS tricks to use as a starting point, web standards to adhere to, and Photoshop workflows they can rely on. Like these tools, Rails provides standards, conventions, tools, and a foundation upon which developers can construct applications by writing customized code using pre-built Rails libraries.

Rails vs. PHP#section2

One of the questions people often ask about Rails is how it differs from PHP. PHP is a general-purpose scripting language that can be embedded right into HTML pages, making it easy for developers to create dynamically generated web pages quickly and easily. Many web designers and most web developers have used PHP in some capacity. Because of its proliferation (it’s usually installed by default on most webhosts), PHP is often the go-to language for handling simple tasks like keeping your website’s navigation current, randomizing images on a website, and even creating a simple content management system. PHP is also useful for creating full-blown open source and commercial web applications such as WordPress, and HelpSpot, both PHP applications.

Technically speaking, we shouldn’t compare PHP, a programming language, to Rails, a web application framework. Instead, we should compare PHP to the Ruby programming language upon which Rails was built. Ruby was created in 1995 by Yukihiro “Matz” Matsumoto, and has slowly built a following, exploding in popularity and getting more mainstream attention in 2006, in no small part because of the popularity of Rails. At the time of this writing, Ruby ranks as the 9th most popular programming language in the world.

To quote the Ruby website, “Ruby is a dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write.” This elegance and focus on simplicity makes Ruby a very approachable language for people new to programming, and offers a refreshing change of pace for seasoned developers.

Let’s run through a quick example, just to get a “feel” for what we’re talking about. Let’s say we want to count from 1 to 10. In PHP, the code might look like this:

for ($i = 1; $i <= 10; $i++) {
  echo $i;
}

If you’re familiar with C, Java, or other C-like control structures, this is straightforward for you. But if you’re new to this, that might seem pretty intimidating.  Here’s the same code in Ruby:

10.times do |i|
  puts i
end

Ruby also has its own tricks and shortcuts that would make even a serious Perl hacker happy. The following line does the very same thing as the examples above:

puts *(1..10)

This kind of flexibility and simplicity makes Ruby an approachable language for software developers and web designers of all levels.

While PHP is a web-friendly programming language, Rails is a web application framework written in Ruby (and with access to all of Ruby’s functionality to boot). And because of the way Rails works, each application you build lives in the form of a project, with specific files and folders. Unlike many PHP apps which often “just work” when uploaded to a webserver, Rails apps rely on their framework and a customized hosting infrastructure (often called a “stack”). As a result, Rails applications can be a bit more challenging to deploy. Fortunately, a number of web hosting companies specialize in deploying, hosting, and managing Rails applications.

So how would you know when to use Rails and when to use PHP? There isn’t anything that one could do in Rails that they couldn’t do in PHP (or vice versa), so in the end it boils down to a matter of choice. For me personally, I have a simple rule: if I’m adding simple functionality (such as rotating header images) to an otherwise straightforward website, I’ll often use PHP. If I’m building a web application, especially one with a database, I’ll use Rails. Again, both could do either, but I find the Rails framework is wonderful for the kind of web application development I like to do.

It should be noted that there are frameworks with goals similar to those of Ruby on Rails that are written in PHP, such as CakePHP and CodeIgniter.

Mythbusting Rails#section3

Before we delve a bit deeper into what Rails actually is, what it does, and how you’ll probably use it, I want to dispel a few myths that non-developers often have about the framework. This list actually comes from real questions that real, live people have asked me about Rails over the last few years.

Myth #1: Rails is a content management system#section4

I’ve mentioned that Rails makes it super easy to build web applications quickly, that it has a ton of built-in functionality and pre-built components. But what Rails actually gives you, the framework we’re talking about, is code.  Rails isn’t a plug-and-play piece of software that you custom-tailor for specific applications, while just integrating some design along the way. You can think of Rails as being an elaborate menu of code that developers can select from, modify, and extend to create a completely customized application.

Myth #2: Rails lets you build applications a billion times faster#section5

In a way, the excellent “Rails makes it easy” marketing campaign has actually hurt some independent Rails development shops. Customers expect Rails applications to be rolled out in days regardless of their feature set. In reality, Rails applications aren’t written for you automatically. Rails saves developers time by letting them focus on specific application functionality instead of things like database interconnectivity. It handles the heavy lifting required to build user interaction. Developers can use this pre-built code, and spend more time making applications that are more reliable and easier to use. Rails projects can still get quite complicated. Rails developers must still write real (and often complex) code, interactions, and tests. Rails makes development more fun and it eliminates much of the tedium involved in building web applications, but it doesn’t build them for you.

Myth #3: You don’t need to be a programmer to build Rails applications#section6

I hear that a lot, and of course it’s false. In reality, Rails developers do much more than assemble components. Sure, they use Rails conventions and build atop a comprehensive platform, but they still write brand new, unique code.

It is true, however, that you might not need to be as experienced a developer to create a Rails application as you might need to be to build, for example, a PHP, Java, or Objective-C application. This is due both to the simplicity of the Rails framework as well as the elegance and readability of the Ruby programming language, upon which Rails sits. You still need to learn to write code.

Getting started#section7

Getting Rails up and running on your computer falls outside of the scope of this article. Fortunately, the latest version of Mac OS X 10.5 (Leopard) comes with Rails pre-installed (or you can build your own). I’ve written a tutorial for installing Rails on older versions of Mac OS X. There’s a One-Click Installer for Windows. You can also download the source code or find additional resources on the Ruby on Rails website to help you get things going.

Rather than expect you to go through the paces of getting Rails installed for the first time, for now, I’ve created a default Rails project that you can download and look at on any computer, regardless of whether you have Rails installed or not. Grab the file and unzip it somewhere you can find it.

Note: The folders and files you’ll find in the archive are identical to those that Rails would have created for you if you’d have run rails demo on the command line, followed by script/generate scaffold article body:string. Again, these are commands you may never have to run, but Rails developers use them to help create the code they use in their projects.

MVC#section8

Speaking of creating code, there are a few software development concepts you should know about, even as a designer, before you dive into Rails. Understanding these concepts will help you understand the Rails layout, and make it easier for you to work within the framework itself.

Rails implements a software engineering technique called model-view-controller, commonly abbreviated as MVC. This technique (or pattern) separates business
logic (things like database interaction) from the user interface, which we call the presentation logic. This separation actually makes the life of the designer much easier, because unlike other web frameworks, the amount of Rails code a designer actually has to see and shuffle around is significantly reduced.

In Rails, each of these different pieces of the application are kept in different folders. The business logic (the models and the controllers) are stored separately from the views. What’s important to understand here is that MVC means the XHTML and CSS you create is kept as separate as possible from the deeper levels of code. Pure developers see less design, while designers wade through less code.

How to edit Rails files#section9

Rails stores its files as plain text, so you can choose any text editor to edit files in a Rails project. I prefer a Mac OS X application called TextMate, which is ideally suited for working with Rails. BBEdit, another Mac OS X application, also works well, as do most text editors on Windows. Linux, too, has its share of capable text editors. Some editors do a better job of displaying Rails code using syntax editing and color-coded highlighting, making the code pretty to look at. Other editors don’t recognize Ruby on Rails code at all. Below is an example of code being edited in TextMate:

Ruby on Rails Syntax
Example of Ruby on Rails Syntax

Pretty, eh?

Textmate (and BBEdit) have the added advantage of being able to open and display entire project folders in their drawer, allowing you to quickly locate and edit a file.

Everything in the right place#section10

Rails projects are made up of lots and lots of folders and files, most of which Rails generates during the initial creation of the application. If you’re used to dealing with smaller projects, this may at first seem like a somewhat daunting amount of content.

Using folders in this fashion makes it easier to separate the models, controllers, and views. And just about all of the files that non-developers will need to be concerned with will live in the same place in every Rails project, far from the deeper code that belongs to the business logic layer. Let’s take a look at the files and folders Rails created.

Example of default Ruby on Rails folder structure.

These files and folders will be pretty much the same no matter which Rails application you’re working with. Even very large, feature-rich, complicated Rails applications will have this identical layout. And even better, your files and presentation logic will always go in the very same place.

It’s actually safe for you to ignore most of what you see here for now. The folders that are important for you to pay attention to are the app/views, app/layouts, public/images, and public/stylesheets folders, highlighted below.

Folder image
Example of folder structure.

Embedding Rails code in HTML#section11

Typically, when you work with Rails developers, you’ll comp a design and they’ll insert the Rails code into it. But on occasion, it’ll work the other way around, the Rails developers will already have a basic set of files and you’ll need to “design around” their code.

If you’re familiar with the way that templates work in blogging software such as Movable Type or WordPress, you’re already somewhat familiar with the way that layouts and views work within Rails. Rails allows developers to separate an application’s functionality into groups of related view pages. If we’re developing different ways to create, edit, and display an article for a web magazine, Rails will want us to put those views into a folder named articles in the app/views folder.

The template files that contain the HTML that users will actually see don’t end in .html like regular HTML files. Instead, they have special file extensions: .html.erb. The addition of the .erb tells Rails that these files contain embedded Ruby code, and will use Ruby’s template technology. This technology allows Rails developers to embed Ruby on Rails code right into any template file very easily. Take a look at the apps/views/articles/edit.html.erb file:

Example of Ruby code embedded into an HTML template.

You may notice a few tags that you wouldn’t normally see in an HTML file. These special tags tell Rails where to look for embedded code. When Rails sees them, it executes the code inside of those tags and outputs the result right into the user’s web browser as it renders the page.

The <%= and <% tags indicate the beginning of the Rails or Ruby code, while the %> tag indicates the closure of both tags. As a non-programmer, it’s safe for you to put your HTML around and inside of these tags, but be careful to keep what’s inside of the tags intact. You can, however, move this block of code wherever you might like within your HTML, or edit the HTML inside and around this block as needed. For example, you could change the snippet above to look like the example below without affecting any of the Rails code:

Ruby is versatile: it can be moved in and out of existing HTML with little effort.

While you may have completely changed how the page displays, the functionality remains intact.

In Rails, there is a primary template, a file usually found in app/views/layouts/application.html.erb. This file contains the “wrapper” of XHTML that surrounds the content the application displays to users. If you open that file now, you’ll see exactly what I’m talking about.

In many blogging systems, designers are used to “cutting up” their designs, separating things like the header, footer, and sidebar into different files. While Rails supports this, the usual pattern is to put those elements right into the application.html.erb file and use Rails to stream the content into place.

If you wanted to customize the design of a Rails website, this is the place you’d start. And you’re free to customize as much as you like, just keep your eye on the special line that looks like this:

<%= yield %>

That’s the special bit of Rails code that says “put the content for this page here.” The location of this single line determines where the main content for each page appears.

Rails developers have techniques to vary the content that appears in different areas of the main template, such as a page’s title, different stylesheets to include, or variable sidebar content.

If you recall the discussion on Model/View/Controller above, you’ll remember that our primary focus will be on working with views. Each general area of functionality within a Rails application will have its own folder within the views folder. For example, if we were working on the designs for a web magazine like the one you’re reading now, there would be special views dedicated to displaying articles, and those views would always live in the app/views/articles folder.

While it’s true that not every Rails application will have articles, Rails specifies that each area of the website, articles, comments, issues, invoices, etc., will each get its own folder within the views folder. It’s part of the Rails pattern.

The public folder#section12

Unlike the rest of the files in a Rails application, everything within the public folder is visible to the outside world. Within the public folder are two folders you’ll want to pay special attention to: images and stylesheets. While there’s no hard rule that says your images and stylesheets must live in these locations, putting them there is a boon to Rails developers, who can then easily call them from within their code as needed.

Source control#section13

Anybody who creates files that change over time will, at some point, probably need help to keep track of how the files change, and will naturally want to keep a backup of those changes. This is even more important when you’re sharing project and code files with other people who will also make changes to them.

Fortunately there’s special software, usually referred to as source control or revision management software, to help us manage this process. The system used most commonly with Rails projects is called Subversion (also known as SVN). Subversion is a free, open-source solution available for most platforms. It remembers every change ever made to the files and directories in your projects. This allows you to recover older versions of your data, or examine the history of how your data changed.

Source control systems replace the “change a file and FTP it to the server” method of updating files, creating instead a consistent way to make your changes available to everybody on your team simultaneously, and keep everything up to date and integrated in one step.

Git, an alternative source control system, has gained in popularity recently, so much so that the Rails Core Team is actually using it to manage the code for Rails itself.

Although the process and commands you’ll use to manage the changes you make vary somewhat between different source control systems, the concept is similar regardless of the technology being used. And although it may seem somewhat cryptic once you actually start using it, the benefits of using a source control system to manage a Rails project easily outweigh the learning curve.

Instructions for managing projects using Subversion and Git fall outside the scope of this article and often vary based on the system used as well as by the team using it. But it’s important to know that you will probably be expected to use this kind of system, and that it will likely involve either typing commands at the command line or using a new source control management application to do the kinds of things you used to do without any additional complications.

Next steps#section14

If you’re interested in learning more about Ruby on Rails, there are lots of places to start. An excellent way to learn Rails is to watch some of the excellent Rails screencasts.

There’s lots of great Rails documentation available as well, with some good starting points on the Ruby on Rails documentation page.

You can learn everything you ever wanted to know about Subversion and source control management by reading the (free) online version of Version Control with Subversion.

There are also many, many wonderful blogs, podcasts, articles, tutorials, and screencasts with a focus on learning Rails available online. Just check out this list on Google if you want a good place to start.

Conclusion#section15

I hope that this gentle introduction to Rails answers a few questions and perhaps dispels a few of the myths surrounding Rails. And while Rails is a great platform, it still needs more people like you, designers, interface architects, and writers, to help guide and direct its future. It’s a young enough platform that people with your experience can really help determine what it evolves into both now and in years to come.

28 Reader Comments

  1. Im a designer/developer and have been working with ruby on rails for the past 2.5 years, its a wonderful platform to work off. I love the way the framework is organized, it keeps the code clean. Im getting better at writing actual ruby code, but I still have a long way to go. When I compared the rails framework to php frameworks such as zend, cakephp, and symfony, it seemed as though they were all just trying to copy rails. Which is in itself flattering! Go Rails!

  2. Hey Dan, thanks, especially for the PHP comparison. I admit I know very little about programming so it’s nice to know PHP isn’t “the debil” as lots of Ruby users might think. 😉

    Also, thanks for clarifying the fact that Rails is a _code_ framework and not a super pixie dust maker. Spending too much time talking to RoR guys and I start to believe -it- +I+ can do magical things. It’s like me telling a client “CSS is super easy, anyone can do it!” Even CSS is still code.

    You’ve made me appreciate developers so much more today, as though it were possible. 😉 The trouble with making things _look_ easy is accidentally implying that anyone could do your job and that is just not so.

  3. after looking thru the previews of google app engine it looks like theyre going to be doing the MVC thing. i couldnt help but think that it was a rails killer after watching it. anyone else?

  4. Hey Dan,

    Great article. What are you using to make those nice red arrows on your screenshots? I have seen it elsewhere and its a really nice technique.

    Cheers,
    Alastair

  5. bq. You compared Rails to PHP? Shouldn’t that be a Ruby and PHP comparison?

    Eugene, he explained that here:

    bq. “Technically speaking, we shouldn’t compare PHP, a programming language, to Rails, a web application framework. Instead, we should compare PHP to the Ruby programming language upon which Rails was built.”

  6. This article is very good overview of the Rails framework, and was very useful to me.
    I am web develpoer and a not very experienced Java programmer, and I’m just beginning with Rails. The only one thing that, for me, you should say stronger, is that learning the Object Oriented programming principles is essential to make a decent use of Rails, and it can be very difficult for smart people too, and anyway it takes a lot of time.
    So I think that if you are a designer that can write some php or javascript but knows nothing about OO programming, or you plain to become a software developer (and invest about one year to learn it) or much better you forget Ruby and Rails.

  7. bq. after looking thru the previews of google app engine it looks like theyre going to be doing the MVC thing. i couldnt help but think that it was a rails killer after watching it. anyone else?

    Not really, the google app engine certainly has a huge advantage on Rails in the scalability department, but in other areas it won’t be able to match Rails’ flexibility. At least not in the short term.

    If the google app engine does emerge as a market leader in web application development it will not be at the expense of Rails, but rather it will mark a paradigm shift and the decline of open source and self-hosted web applications. That would be a dangerous development for the open nature of the web in general.

    However as far as Rails is concerned, it’s not particularly vulnerable for the time being. Despite the brilliant marketing by David Heinemeier Hansson resulting in a widespread assumption that Rails is little more than a flavor-of-the-month fad, Rails’ continued success has been a result of well-conceived architecture embodying established best practices. There’s nothing really new about Rails… it’s just pulling the best ideas from the last 10 years of web development and rolling them up in an agile package that tends to give you more bang for your buck than anything that came before. Of course it can’t hold a candle to PHP for one-off dynamic additions to static pages, or to J2EE for interfacing with sprawling enterprise backends, but there’s a sizable sweet spot.

    Eventually best practices will evolve—due in no small part to the influence of modern frameworks such as Rails, Django and Seaside—and Rails will be superceded by something newer and less ossified. However even Google is not capable of something that will blow Rails out of the water yet.

  8. Hello,

    This is one of the best introduction article i have read. It really promotes rails and makes it clear.

    A List Apart is very famous for CSS also. I would like to see few articles on mixing Great CSS styles with rails.

    Tabs, Sliding Doors, CSS Comments. Liquid and 3 column templates are few of articles which can be shown with rails.

    Rails can become more powerful with good CSS.

    Thanks

    SoftMind

  9. We’ve been using Zend Framework for the company that I work for. Though it’s still a bit immature, it’s incredibly robust, easy to understand, and certainly flexible. ZF has everything I’ve ever needed. My only complaint with RoR is the learning curve. I just process/think that way. Our company almost went the ROR direction (as well as Adobe’s Flex) but decided on ZF. Kudos to anyone who uses ROR, but Zend Framework speaks my language.

  10. bq. Technically speaking, we shouldn’t compare PHP, a programming language, to Rails, a web application framework. Instead, we should compare PHP to the Ruby programming language upon which Rails was built.

    Actually, since the article is about Rails, not Ruby, you should have compared CakePHP or Zend Framework to Rails. I know a comparison wasn’t the point of the article, but as a PHP programmer, I would have found that more useful than “Ooh, you can write the same for loop 2 different ways!”

  11. only gets mentioned once! So to set the record straight Perl also has excellent, modern MVC frameworks the best of which is Catalyst.

    http://catalyst.perl.org/

    And of course, writing your app with perl not only means you can (re)use anything from CPAN (a *massive* free software repository compared to Rubys gems) you also have a large, friendly, responsive community to get you through your learning curve.

    Perl’s not dead it’s just very very stable and is well worth considering for any size website. It’s certainly worthy of a mention on ALA – where would you all be without CGI.pm ?

  12. A List Apart came through at the right time for me. I was just thinking this week about how I’d like to learn more about RoR, and bam! Two complimentary articles. I’m completely inspired to go learn this language and framework.

  13. Drupal is a CMS written in PHP. It has many great modules, that do almost anything you want. Yet, almost always, you want that one thing which doesn’t exist yet.
    So, you write a module, using some already supplied functions, from other Drupal modules, and voila – you have a whole new functionality.
    Can PHP on Drupal be considered as RoR – a language to write code, based on an already written code, in the same language?

  14. Just wanted to add a comment on use of the editor for code development with Ruby and/or Rails. JEdit [www.jedit.org] is also a great free alternative to Textmate, when used with the free Ruby plugin and the ProjectViewer plugin. The Ruby plugin gives you all the keyword hightlighting plus ruby and rails docs and a class structure browser which is great for navigating code. The ProjectViewer plugin gives you the folder view like Textmate and probably much more flexibility. Each of these plugins gives you a dockable/collapsible window as well.

  15. For those of you who want a great way to get started in rails, Aptana IDE has a great development environment plugin for Rails developers. They also have some great screencasts to get you started. Aptana can be found at aptana.com and the screencasts are found at aptana.tv. They have a great free version and a pro version you can upgrade to as well. Aptana really helps you visualize the structure and debug your rails apps from within one common application.

  16. If anybody wants to have a go at Ruby on Rails without having to set it up, try “Heroku”:http://heroku.com. They host the application on Amazon’s ec2 hosting service. You can set up an application with the click of a button and edit files in your browser – it’s brilliant! It’s just like google’s app engine, so I can’t see that killing off rails anytime soon. More likely that more and more sites will use elastic hosting that takes the pain out of deployment.

    DAZ

  17. Rails is powerful, but it is a coding framework. Not exactly the most natural solution for web designers. There are interesting stirrings in the Ajax community around creating visual, even WYSIWYG tools for building web apps. Examples include WaveMaker, Aptana, Bunkai. WaveMaker is open source, runs on Mac, Windows and Linux, available at http://www.wavemaker.com/downloads

  18. Your article is a good primer on the environment of Ruby on Rails, but I think you should point us in the direction of some more support resources. Many tutorials, and even the screencasts on rubyonrails.org, contain code that breaks or doesn’t work as of Rails 2.0. I would suggest pointing us towards a list of changes to watch out for, because it may stand in the way of many people, including myself.

  19. I enjoy working with RoR, but I think there needs to be more emphasis on choosing to use it only when it’s right for the job. Dan did mention that he uses PHP on certain things, but I think it should be taken a little further than that.

    Why? Because there is so much RoR buzz going around that I have clients demanding Rails sites, regardless of the feature set or scope. I’ve also seen some scalability issues with Rails that not many people are willing to address.

    Now, I’m not trying to discourage anyone from using Rails. Just remember – you’re a craftsman. Choose the right tool for the job! If it happens to be Rails, then enjoy.

  20. I just entered the programming world and was looking at the different methods and your article is a great help on the front.

    Will definitely give ruby on rails a shot.

  21. Honestly, if it wasn’t for stumbling onto rails 3 or so years ago I’ve no idea what I’d be doing now. It’s not just that the coding style was a welcome relief from the Microsoft last I’d lived in for 10+ years, but that the community around it was much more interesting. The entire “ruby lifestyle” has significantly reduced my stress levels and made coding fun again.

  22. Stumbled across this article recently. I know I am late commenting! However, I just feel the distinction needs to be made between PHP4 and PHP5 when discussing PHP or even comparing it to other languages like Python, Ruby, Perl, etc. Given PHP’s complete overhaul of their object model with v5, PHP4 and PHP5 are basically two different languages meriting distinction. This also seems to be the case with every major version release of PHP.

    I feel the real comparison would have been RoR vs Django. Although I admit I am far more partial to Django and Python than RoR and Ruby. 🙂

    When it comes to PHP frameworks, out of the box, the standard is the Zend framework. Most of the other PHP frameworks are built on the PHP4 language and are flawed from the start as such. IMO, using v4, you are basically building a legacy application as you code! It’s unfortunate that PHP did not have a real, solid object model in v4.

    However, when it comes down to it, building an MVC framework can be done in any language (the design pattern has been around for decades now) and really is quite simple. A good exercise for any intermediate programmer is to build out your own MVC framework in your language of choice. At the very least, it will give you a solid understanding of what is actually going on underneath the hood of all these other frameworks even if you do not fully complete it.

    Nice article though, solid writing, very concise.

  23. Been using Ruby and ROR for nearly four years and it has gone from strength to strength.

    While there are a lot of ordinary articles which give an overview of Rails, this is a exceptionally article, and given that a lot has changed in last few years with Heroku, Rails 3, it might be a good idea to update this one.

    As for Stephen point about PHP4 vs PHP5, while it is true to some extent, in practical terms a lot of developers still use PHP as they always used to in PHP4. While technically it has a object model, the adoption percentage is still low.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA