One of the things that have been percolating in my brain for awhile relates to the question of why I prefer to work with the Camping microframework instead of Ruby on Rails. Answering the question seems to be harder than I expected, because I thought I was disenfranchised with Rails, but it turns out, Camping fits my head better.
I have no doubt that the sexiest work being done for web-based consumers is in web applications in-the-large – and certainly this is getting most of the attention. What’s more, the sweet spot for Ruby on Rails lies in building such web applications. If you have some experience with RoR or Camping, I bet you already thought of a half-dozen examples of RoR-built web applications. You know what I’m talking about.
But the thing is, most websites out there aren’t web apps. They’re mostly static pages with one or two small dynamic things, like a contact-us form, or a search engine. Is Ruby on Rails really the right technology for that?
I contend that it isn’t. If you’re using Rails to build a contact-us form, or any app of similar ambition, then you are, in effect, using a power drill where only a jeweller’s screwdriver is needed.
I suppose it sounds like I’m trolling on Rails, but I’m not. When I first discovered it (back in the 0.8 days) I fell in love with it – hard. I loved the MVC design. I loved how I could refer to fetched datasets in Ruby notation. But that’s probably nothing new to you. You might have fallen for Rails just as hard, and loved it for these reasons and more.
And when you’re using a tool that seems to make the process of building applications so much faster, and so much more fun, it’s so easy to want to keep using it for every single project. And maybe you’re doing that right now, and having a blast. Or, maybe you’re the type who already had the experience to know that any given tool isn’t always the right tool for the job.
Or maybe you’re like me, and found yourself trying to figure out how to use this power drill to build something where only a jeweller’s screwdriver was really required. That’s kind of a sobering experience, isn’t it?
Well, speaking for myself, it was sobering for awhile, until I discovered the Camping microframework. Now this, I thought, this is the tool that I’ve been looking for.
One thing that’s obvious to anyone who’s worked with Camping is that it’s small – not only is the framework itself less than 4K, but applications written against the framework are typically stored in one file, and generally not more than 2-400 lines in length. This is an amazing advantage because by design, you’re encouraged to write apps simple enough to fit into your head.
Even more remarkable is the fact that I could still have my MVC goodness, and, if I needed to work with a database, I can also tap ActiveRecord. And that means, in that 2-400 line script, half the code (in my experience) becomes the view, and the other half is split between Model code and Controller code.
I write simple apps. It’s my sweet spot for software projects. Most of the work I do is on sites with mostly static pages, and pockets of dynamic content. I know it’s not glamourous work, but it’s the kind of work that I see is predominant – most sites are static, with a few pockets of dynamic content. And so, like most developers (whether they know it or not), I need simple tools to match my level of ambition. The Camping microframework delivers that in spades.
Copyright © 2009
Robert Hahn.
All Rights Reserved unless otherwise indicated.