Web development has come a very long way since the turn of the century. With so many things changing on every level, it always amazes me that new programmers don't move on to professions that don't require as much caffeine and aspirin. Albeit, what drives a programmer is this insatiable passion to always know more. All rhetoric aside though, the fact that the world of web development is a very fast-paced, ever-evolving beast makes for some very identifiable separations between groups of programmers.
Having been a programmer for 20+ years now, I have been exposed to languages like Microsoft's™ Visual Basic & C#, Perl, PHP, and most recently Ruby. I currently work for an agency that acquired other development companies as well as their code bases. My strongest language has been and will likely remain PHP & Perl, but my work at this agency has forced me to learn Rails in crash course format and I must say, I find Rails to be more frustrating than trying to walk through an insurance sales convention with a sandwich board that boldy has "Potential (Sucker) Customer" printed on both sides.
Now, some of you might be immediately shouting at your screens and saying, "Yo, dumbass! Aren't you forgetting HTML & Javascript as languages?". Well, first let's just clear up the fact that those are not 'languages'. HTML, as the acronym states ever so clearly, is a markup language and it's sole purpose is for formatting content, not executing instructions. Javascript could loosely qualify more arguably as a programming language since it actually does perform stateful execution of instructions. But I think now would be a good time to inject that I am referring to true back-end, server-side languages used wholly for the development of full-blown application and business logic.
So, the real meat & potatoes of this post though was to address the rather significant differences between PHP CodeIgniter and the aggravating pitfalls of Ruby on Rails. Getting a narrative push-off started, I would like to first make the statement that new programmers should not confuse a programming language with a framework. These are two very uniquely different beasts and if schools are doing their jobs properly, they will drill that point into students heads relentlessly. They might put on a test, PHP is to CodeIgniter, what Ruby is to ________.
Both CodeIgniter and Rails are MVC frameworks. MVC or Model-View-Controller methodologies utilize the concepts of separation of business logic from presentation and that is well outside of the scope of this topic. But suffice it to say though that separation of business and presentational logic can be acheived without the use of MVC frameworks. It's just more like trying to convert a lawnmower engine into a car engine. It can be done, but not without exhausting every profanity out there and likely in multiple languages also. Nonetheless though, there are countless informational resources to be found on MVC development structures.
So, let's begin to compare antidotes & poisons...*coughs* I meant, apples & oranges.
First, we have Ruby On Rails:
Personally, I am not a very big fan of Rails on many levels. The framework assumes that the developer doesn't care about the lower-level details of the back-end and all they care about is rapid development. Although this can be good for certain designs, it clearly is not a framework for seasoned programmers that wish to maintain much more control over the application's internal processes and functional flow. Rails hides much of this from the developer and assumes that that's of no interest to the him/her. I'm sorry, but if convention over configuration is the new "in thing" then count me "out". That's for lazy developers. People afraid to learn about the systems and processes that are at the heart of their beloved Rails applications.
Here's a few of my hottest reasons for why I view Rails as a poor choice of frameworks;
- It forces the developer into very rigid coding structures with little room for flexibility.
- It boldly takes full control over database schema. (I'm sorry, but this is a BIG turn off!) Give me liberty or give me death!
- The framework hides so much low-level processes from the developer that it actually kills the K.I.S.S. mindset entirely.
- Setting up a development environment for a Rails app might as well be like pulling teeth. I have never seen anything this ridiculous since PHPCake came out.
- A production Rails application is such a resource hog that no matter how much memory you open up on your server, Rails quickly absorbs it very greedily. In fact, one of our client's sites has to be restarted every couple of weeks just because of this fact alone.
- Rails compiles and runs it's entire code base into memory. A first thought might be that this is a great thing, but it quickly leaves little room for the server to reserve memory for heavy queries.
- Right when you thought you learned Rails, they shit out another version of it and totally ruin any chance that anything you learned from earlier versions has any validity or worth anymore.
- Documentation for this ridiculous framework is about as scattered as the corruption of our government. You're only real resource is a few good souls on places like Stackoverflow. That's pretty messed up if you ask me.
I'm sure that you can tell that I am pretty anti-Rails, but I would like to go as far as to say that I have equal feelings about PHPCake for the exact same reasons.
Enter PHP's CodeIgniter (hear the ranks of angels singing?)
I'll get back to Rails shortly, just because it leaves far too much room for spite. Now here is an extremely well thought out MVC framework. It leaves a wonderful flavor on the palette and only requires a minimal of effort to get up and running. CodeIgniter has seen its bad days as any other up & coming framework has, but here are a few reasons why it has earned this *coughs* humble blogger's seal of approval;
- It's extremely well documented.
- Mildly painless when upgrading it on an existing application.
- Extremely extensible.
- Allows the developer to create a database that actually can perform referential integrity on its own rather than assuming that the database architects that created MySQL or what have you, couldn't possibly know how to make that happen.
- Code execution can very easily be traced since the vast majority of the execution of the code makes very few assumptions about what you intend it to do.
CodeIgniter is pristine as an example of the best of both worlds. On the one hand, you can interact with the database entirely through ORM mechanisms if so desired. Namely, an ActiveRecord implementation. On the other, you can completely desert the ORM aspect and not even have to change one thing about the framework.
Back to Rails bashing now. (my favorite past time when not being extraordinarily productive with CodeIgniter)
Oh Rails...you treasure trove of endless pains in the ass! Okay, back to the fun. So, in direct contrast to CodeIgniter, Rails will ALLOW you to write your own queries, but god forbid you should actually have a table name that doesn't match the stinking model name. BOOM! In your face! Really?! I say, get over your self-righteous ass-umptions, Rails!
The original creator of Rails works for 37 Signals and that fact right there is why he invented Rails. He works for an agency and agencies typically are all about meat-puppet, high-volume development. I currently work for an agency, but I will say this, this agency is the exact inverse. The owner actually insists that everyone only work 37.5 hours a week as they refuse to have people slaving over their work. Now THAT is what I consider to be a mentality that fosters dedication from it's employees.
So, because the inventor likely works for a place that requires inhuman development volumes, the creator of Rails figured, and probably rightfully so, that the only way he could save his sanity and likely his job/ass was to create a framework whereby he didn't have to pay any attention to the lower-level workings of applications. This is fine until it comes time to debug. OH YEAH! I totally forgot about this little tidbit of shit with Rails...debugging!
GOOOOOD FREAKING LUCK WITH THAT!!!
You heard me. Yeah, Rails actually expects you to do all your debugging through the freaking development or production log file. Seriously!? Grow some error reporting balls! Oh...and when you do get an application error (and that is more likely than not), do you think you get intuitive debug info that actually leads you to the problem with any fair amount of relevant information? NOT! The only thing any worse than Rails error reporting is Microshit's .NET errors. *slightly vomits in my mouth*
Okay, so in closing, I would like to say, on the record, that I have a Love/Hate relationship with Rails. Stated simply, "I love to hate rails!".
I can't wait to see the shitstorm this blog post stirs up with all the diehard Rails developers that seem to think that this framework qualifies them, even remotely, as "developers". Bring on the lions!
