As developers we toss around quite a few acronyms. Most of them are positive like, TLA, REST, and TATFT. And of course there are few of them which are not so good, like NIH. Today, I propose a new acronym for the not-so-good list: ISTR or I’m Smarter Than Rails.
We developers like to think of our self as an intrinsically smart bunch. Well of course we are! We create web sites and applications out of funny spelled words and esoteric symbols. We can be smart within the confines of frameworks, or we can be smarter than our frameworks. But be careful, being smarter than our frameworks will only doom as all.
We all love frameworks because they remove lots of the heavy lifting we have done in their absence. Rails is pretty good implementation of a web framework. More and more sites are popping up using Rails because it is easy to use and extend.
At some point, we have all bumped into a limitation of Rails. Either it didn’t exactly fit the mold of what we were trying to do, or it was too slow, or it just did something completely different than we would have done it originally. We have a few options at this point.
A) We can embrace the constraint, and potentially come up with another solution which doesn’t defy the conventions.
B) We can extend the framework with the conventions, and contribute our change back to the Rails core.
C) We can defy conventions and patch Rails to our will.
At some time or another all of these conventions are the right course of action. But I’m here today to evoke the feelings of bad juju when go with route C. When you patch Rails to your whim and break conventions, you start a chain of potential problems.
The first problem is that you might not be able to upgrade Rails to the newest versions that may contain important security patches or other functionality. Being able to upgrade Rails is pretty important. The farther you drift away from the base, the more likely it is that you won’t be able to drift back when you are ready.
Another problem is unforeseen complexity. If you are changing the Rails framework, you are in no doubt introducing new complex idioms. These idioms may seem perfectly fine to the implementer, but will be Greek to the person who will inherit this code in the future. The new maintainer won’t have the benefit of the community when it comes to diagnosing and amending the code base.
So, to all of you who think ISTR, why don’t you prove it by implementing easy to understand solutions and contributing the community for further scrutiny and maintenance through submitted patches to the core or through plugins?
Don't forget the D) option, use sinatra, ramaze or merb.
Of course this applies to other frameworks as well. Smart-Aleck…
I think we both have some experience with ISTR given our time together at RHG so without going into too much detail, you hit the nail on the head with this one. It was a valuable lesson though in that I will never again venture so far off the 'rails' as we did all too often there.
I agree in principle, but without a Rails API in practice this can difficult.
For example, we use the “multi_db” plugin (like masochism) to transparently load balance between a master and slave(s). AFAIK, there is no way to have a plugin to do this without reaching into the guts of Rails and change the behavior of the db connection. This is fragile, and doesn't always make upgrading easy but what's a better alternative?
Even as a plugin author it can be tricky to know what is fair game to reference. Obviously, methods that are private or protected are likely to change, but about public methods? Are those all API?
You're certainly right that there are very unnecessary ventures into “C” territory, but even when trying to stay on the golden path, it isn't always very well marked.
Sinatra is not a framework. It's just a library. Who needs frameworks?
See http://github.com/alexch/vegas for my lame lightning talk attempt at proving you can have an app with all the power of Rails without any Rails in it.
Absolutely. By far the majority of our time spent coding Erector was figuring out how to plug a new View type into the godawful mess of spaghetti that is ActionController. And then doing it again and again whenever there was a new release of Rails.
I would be to differ. Sinatra is a web framework. Calling it “just a library” is playing semantics.
I don't think I'm playing semantics. Call it what you like, but Sinatra's scope is vastly smaller than Rails'. Sinatra just does routing. Rails does routing plus views plus ORM plus a whole lot else. Personally, I find that extra stuff oppressive rather than liberating, for several reasons:
(a) personal aesthetics about design (e.g. why aren't views objects?)
(b) too much invisible magic (i like convention, but what's so bad about configuration as long as it's concise?)
(c) Rails' absence of clean or consistent APIs (see my reply to graysky, and also all the many different and undocumented semantics for view helper methods)
An analogy — admittedly imperfect — is Sinatra is to Rails as Servlets are to J2EE.
With Rack and Sinatra and enough good gems, and just a little bit of glue code, anyone can write their own little framework. So… what's the point of Rails again?