Linux Apache MySQL PHP Tips

1. 2 Responses to “What can Ruby on Rails do that php can't?”

2. Nothing.

   Both Ruby/Rails and PHP can accomplish the same things.
   Having used both for quite a while, here is my opinion:

   Ruby and the Rails Framework lead to cleaner code. Also, Rails pushes Test Driven Development, which is something you must do on reasonably sized projects.

   Also, it is a lot more fun to program in
   Ruby/Rails has a pleasant syntax.

   I personally will not code in PHP again. I refuse.

   By rubyredtrain on Dec 15, 2010

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

   In part 1 we explained how PHP is just a language, yet we never really talked about Ruby, the language in which Rails is written. Ruby is a fun and interesting language in its own right; however, it has gotten a lot more spotlight these days, specifically because of Rails. So, if you are using Rails you’ll be writing Ruby code, and now it’s time to compare some aspects of Ruby to PHP. For me, the biggest difference between Ruby and PHP is that Ruby is an object-oriented language throughout, while PHP’s object model feels more like an afterthought. In Ruby everything is an object, while in PHP most everything is a native variable type.

   I’ve been using object-oriented design exclusively for a few years now, and while I continue to model my PHP web applications with objects, they can be very awkward at times. When this happens I’m usually forced to jump back to procedural programming to do things like iterate over a collection of objects. Iterators, by the way, are very cool in Ruby. For example, in Ruby I can do something like:

   employees.each {|employee| employee.give_raise}
   That .each statement lets me iterate over the collection and then use the reference between the pipes as a way to perform actions onto the object. In this case, giving each employee a raise.

   In PHP few things are objects by default, including collections. Instead, there is a native array type and a bunch of functions that you can pass an array to that do something of interest. For small scripts this doesn’t bother me, but for my bigger projects it’s a real pain. Early on I even considered writing my own array object. I quickly let the idea die when I came to realize I’d have to pass out native array types to the various tools (like Smarty and a number of other PEAR Objects) anyway, as that’s what they knew how to work with.

   So those are some of the biggest reasons why I’m starting to prefer Ruby over PHP, but this comparison still has one more part: deployment. What good is an app if you can’t put it onto a production server? In the final installment of this comparison we’ll look at the differences in deploying a Rails app vs a PHP app. See you then.

   In part 1 of our series we explained how PHP is just a language, not a framework; in part 2 we talked about Ruby’s object-oriented foundations and its cool iterators. Today we are going to finish our series with some thoughts on deployment. More specifically, we will discuss why deploying a Rails app is a little harder than PHP. If there is one thing that has me down on Rails it’s deployment. When I say deployment I don’t actually mean the act of uploading a new release. That’s actually very easy to do with a tool called Switchtower. No, I’m talking about using a shared-hosting provider. Dedicated hosts are easy to get going with Rails, but when you are using a shared box there is a little more to take under consideration. Let me explain.

   The first reason why shared-hosting environments are tough is simply because Rails is still so new. PHP was the same way when it first started getting popular. These days however, I’d be shocked if any shared-hosting environment didn’t offer some level of PHP support. The second reason is because running a Rails application properly requires more resources and power given to the users on that shared box. Because of this most system admins of shared-hosting setups are rightfully cautious.

   I can’t say I know exactly why Rails needs so much more “oomph.” The big thing to keep in mind is how most CGI environments work. The web server will normally build up the environment for the CGI, execute the code, return the HTML that was built to the client and then destroy the environment. It does this every time a request comes in. Now, it could be that Ruby is a little slower than PHP, but I suspect the main bottle neck is something else. If I recall, Rails inspects the database to help build the models it will use. Doing so every time could easily add a lot of overhead and thus cause a slow down. Anyway, without getting too specific(for I know not what I speak, err type), Rails is really slow when run under CGI. To speed things up we need FastCGI!

   In a production environment, most Rails applications are being run under a thing called FastCGI. The main benefit of running Rails under FastCGI is speed. FastCGI will load and hold your app in memory so that it doesn’t have to build the entire environment per request. The negatives of FastCGI include extra CPU and RAM usage. On a box that might be shared between a hundred or so accounts it’s not hard to imagine how this might cause some problems.

   Thus Rails on shared-boxes sounds bleak, but there are companies out there advertising such services. Now, most hosts on that page mention monthly fees so low it’s scary to think about how bad the service might be. For those not interested in playing web host roulette, let’s talk a little about the most popular of the shared-hosting + Rails setups, TextDrive.

   I have no personal experience with TextDrive, but my biggest concern with them is reliability. They sell themselves as a company with bleeding edge technologies, and from what I read on their forums and third party blog posts, they tend to bleed regularly. I suspect lots of people are/were signing up for their $12/month plan, using it as a development server and constantly breaking things. I also suspect that the company continues to have growing pains. Perhaps, as they get more comfortable, and Rails more stable, things will get better. Another thing that might help is the fact that TextDrive is introducing Business Hosting Plans which promise “an average of only 20 customers per high-end storage-attached server.” The less crowded servers will more than likely have much better reliability —- we’ll see.

   I’d would just be thrilled if Pair started to support Rails. I’ve been using Pair for a few years now and love their service. I also loved the chocolates they sent me for Christmas.

   When it comes to the Clickable Bliss site, I’m currently using Pair for DNS+Email and pushing all web traffic to Zelda, my little Mac mini server. It’s working quite well so far, but with only myself and a dozen or so friends hitting the server on a regular basis there really isn’t all that much to do. In time I may move to TextDrive or a similar service. I have a feeling over the next 18 months we’ll see a huge increase in the number and quality of hosting providers offering Rails-application hosting.

   That’s the skinny on deployment for small (shared-hosting sized) Rails applications. It’s a little tough right now, but I have a feeling it will get better soon. For those interested in launching bigger apps on dedicated hardware, don’t blink when it comes to Rails. It is as easy (or easier) than what you have previously used.

   By Josh B on Dec 15, 2010

Sorry, comments for this entry are closed at this time.