Over the last few weeks, I’ve been asked by both friends and clients, “So what is that thing called Rails I keep hearing about (and/or keep hearing you talk about)? How is it different from PHP?” Typically I give them a three-part answer that’ll I’ll now iterate for the blog. While this is far from a complete comparison, hopefully it will be useful to some people out there.
The first thing to keep in mind when trying to form a comparison between PHP and Rails, is that PHP is just a language. It’s a scripting language that has a lot of useful functions that make adding dynamic content to web pages easier than its predecessors. What PHP is not (and what Rails, in fact, is) is a framework. In software terms, frameworks are generally tools and pre-built objects that help you create a solution faster by not reinventing the wheel.
More specifically, Rails is a full-stack framework. Full-stack basically means that when you decide to use Rails it will provide practically all of the tools necessary all by itself. While you are welcome to use other tools for sections of Rails’ functionality, most current Rails developers are not (and for obvious reasons described below.
So PHP is just a language. When you choose to use PHP to build a significant web application what you’ll want to do is look for tools and pre-built objects that are written in PHP. Some are packaged together in frameworks. Other times you’ll assemble them ala cart (a database abstraction layer here, a template system there). Sometimes building systems this way makes a lot of sense, but other times the overhead of divided tools makes for more work than it might be worth.
In Rails, they follow a mantra of “Convention Over Configuration.” With this in mind, Rails will follow industry conventions to make your job easier whenever possible. One example where you can see this in action is with page templates.
In Rails, if you have, for example, a
Now, when I am doing something similar in my own PHP apps, I have to manually instantiate the template object, manually pass references to any variables I know the view will be interested in and then manually tell it what template file to use. While all that manual code is pretty simple and easy to write, on even medium-sized apps it starts to take a toll on the leaness of the codebase.
This is one of the many reasons I like Rails. It will follow obvious conventions when possible but allow you to override the convention with a specific command; in this case to use a template file other than
Conclusion for part 1: PHP is just a language. Rails is a full-stack framework. PHP has lots of useful tools; they just don’t gel as well and usually require more configuration.
The first thing to keep in mind when trying to form a comparison between PHP and Rails, is that PHP is just a language. It’s a scripting language that has a lot of useful functions that make adding dynamic content to web pages easier than its predecessors. What PHP is not (and what Rails, in fact, is) is a framework. In software terms, frameworks are generally tools and pre-built objects that help you create a solution faster by not reinventing the wheel.
More specifically, Rails is a full-stack framework. Full-stack basically means that when you decide to use Rails it will provide practically all of the tools necessary all by itself. While you are welcome to use other tools for sections of Rails’ functionality, most current Rails developers are not (and for obvious reasons described below.
So PHP is just a language. When you choose to use PHP to build a significant web application what you’ll want to do is look for tools and pre-built objects that are written in PHP. Some are packaged together in frameworks. Other times you’ll assemble them ala cart (a database abstraction layer here, a template system there). Sometimes building systems this way makes a lot of sense, but other times the overhead of divided tools makes for more work than it might be worth.
In Rails, they follow a mantra of “Convention Over Configuration.” With this in mind, Rails will follow industry conventions to make your job easier whenever possible. One example where you can see this in action is with page templates.
In Rails, if you have, for example, a
BlogController and it has a method called list, Rails will automatically use the list.rhtml file inside of a folder called blog in your views folder. Not only that, but Rails will automatically pass on any instance variables you were using in the controller so that the view has access to them.Now, when I am doing something similar in my own PHP apps, I have to manually instantiate the template object, manually pass references to any variables I know the view will be interested in and then manually tell it what template file to use. While all that manual code is pretty simple and easy to write, on even medium-sized apps it starts to take a toll on the leaness of the codebase.
This is one of the many reasons I like Rails. It will follow obvious conventions when possible but allow you to override the convention with a specific command; in this case to use a template file other than
list.rhtml if needed.Conclusion for part 1: PHP is just a language. Rails is a full-stack framework. PHP has lots of useful tools; they just don’t gel as well and usually require more configuration.
Part 2 will be posted soon. In it, we’ll look into the Ruby language and how it differs from PHP. Continue Reading in Part2
Stumble
Reddit
del.icio.us
Technorati
