from one codemonk to another

I am struggling mightily with this one. I love ruby and rails, but more and more I am resenting the constraints of the controller architecture, the router, and activerecord, and I miss writing and tweaking raw SQL. This is not to say that I don’t love rails for quick and dirty stuff, and it has done wonders for writing MVC web applications, but I miss being able to break that pattern where it applies and being able to understand the result. I view rails just like I view Cocoa Bindings. I love the magic that they do, but there is a performance cost, and it is suboptimal for me to have little to no visibility into how they do what they do.

My friends who are really into rails tell me of course, you can use it without those modules, namely ActiveRecord, but if my problem is with ActiveController, and its routing magic, along with the conventions then what is the point. I was looking at MERB, but it is difficult to say what the result will be in rails 3. But almost no matter how I consider the outcome of that Merb will inevitably become more Rails like. I mean, rails is the 800 lbs gorilla in the web dev space, who would argue with Rails and win?

Well, there are plenty of examples of ugly PHP sites, and there are some examples of almost elegant code in PHP. Better yet, there is no magic, I can avoid heavy frameworks if I choose and still have my choice of easy deployment options with mod_php. The rails community keeps saying that hardware is cheap, and it is if you have money to begin with. If I need to deploy on a $30 / month host, it is very hard to deploy a rails app with a homegrown framework on rack. I am sure they exist, but PHP hosting has gotten so cheap as to almost be an afterthought.

Some of the PHP code that I have written recently is quite clean and readable. Its using classes and MVC to a degree, but I have objects that implement a hydration base class that allow them to persist their contents by overriding some simple parameterized SQL via PDO in the subclass. That is really all of the database abstraction that I need. If I want to persist objects, I’ll just save them to disk. Ruby’s marshal works just fine for that, so does PHP’s serialize / unserialize. If I want to use a relational database, I’ll write SQL and let it play to its strengths instead of pretending that it doesn’t exist.

The functional and library support that PHP has is unparalleled in the web dev community. I would have to agree with Rasmus Lerdorf that I like my SQL to look like SQL, my JavaScript to look like JavaScript, and my implementation language to look like my implementation language.

This is not an anti-framework rant, despite the way it sounds. I love Rails, Cake PHP, Groovy, Struts, etc… I think they are a great way to get a project going quickly or as a way to learn good web development processes, but I also think there is a time where you need performance and control, and this is it for me. I think most web developers should start by learning one of these frameworks. Once they can understand the tradeoffs you make when using them, it is probably time to leave. I don’t differentiate, I think that JavaScript frameworks are the same thing. They are awesome until you are performance bound, or you are trying to express a design that the frameworks either didn’t consider, don’t support, or don’t match the framework creator’s view of the world. That is fine, I don’t want for DHH to accept that there are times when convention over configuration is too cumbersome and the performance tradeoff isn’t worth the simplicity, or that some things are better expressed in a functional way instead of an OO way. For those projects, I just won’t use his framework.

There are totally justifiable situations in which Rails is the absolute best choice. I work in Rails every day at work and love it for that particular problem domain. I just have started realizing that I have been seeing the world as Rails shaped nails. There is no one language, framework, design pattern, or library that is the end-all-be-all method for solving problems. It takes good practices and pragmatic choices to choose the best tool or tools for the job. I was getting away from that, now I am coming back.

Bold Predictions About Rails

For a couple of years now I have been very disparaging of Rails, and in general the whole convention driven development movement. I have always figured that maybe I could do things a little better myself perhaps. Recently, however I have found myself using rails, and in a larger sense, adding Ruby to my toolbox, and have been a much happier programmer.

What suprises me is how many excuses I found myself making about why I shouldn’t use Rails. What I eventually realized is that I didn’t care if I could write that CRUD code a little better, or if I could shave a tenth of a second of execution time from whatever function I had written in *name the language* the important thing was that I could get my project done and get outside, or work on several projects simultaneously, instead of only two. I found myself spending time and thought cycles on code that was directly related to solving my problem, instead of code to get me to where I could start solving my problem.

Now I am always suprised when I hear my same old excuses coming out of other good developers’ mouths. I want to say, “you just don’t understand.”

The reality of the situation is that the ground has shifted under our feet. Because of rails, business stakeholders are demanding quicker turnaround on features and products, and non-rails shops are struggling to keep up.

Performance is always the first crotchety old excuse, the answer is memcache. Then reliability, f5 big ip is the answer.