The subject of which web development framework to use is quickly approaching what is known on the Internet as a holy war. Ever since RoR gained enough traction to spawn legions of copy-cats and innovations; each new framework has been recruiting developers to its cause. Developers on all sides have been drawing lines and some have been wasting bytes and bandwidth posting flames and useless arguments all over the Internet.
The basis for many of these flame-wars is the argument that, “x framework is better than y.” The problem with such an argument lies in the lack of context for a logical response. Despite what feature of technical detail a given framework has that another does not, it’s not likely that it matters given that there’s a lack of applicable context. What I mean is that a hammer and a wrench can both be used to hit a nail; but one certainly does it better than another. This is a common analogy used to solve the dispute — and yet these arguments are still cropping up almost two years later.
The problem I believe is that the instigators of such arguments are caught in the illusion that the hammer is better than the wrench since it hits nails the best. The reality is that for many web developers, nails aren’t the only problem to tackle. Some may have nuts and bolts, screws, and the more fortunate (or unfortunate) may have whole engines or bridges and what-have-you. One cannot tackle every problem with a hammer.
Ultimately, despite how flexible a framework may be, it’s core design is conceived to be a solution to a particular problem domain. It may be a very big domain or a very small one. If it’s well designed, a framework can be flexible enough to work on problems outside of it’s set domain. However, despite our attempts as programmers to develop tools that can be used in every scenario possible; in the end it’s a pipe-dream and the frameworks we do design work best for certain problems.
This isn’t a bad thing.
A good framework does something really well which is what makes it a good tool. A good programmer will have a host of tools in their chest; not just a hammer or screwdriver. A wrench, three different saws, maybe a blow-torch. This is what it means to be “framework agnostic.” Just as advantageous it is to be “OS-agnostic,” being framework agnostic means you can do more, faster, and more efficiently.
My advice is not to get too comfortable with a specific framework and use it to develop all of your applications. Dig into the internals of these frameworks and learn how they work. Understand the fundamental principles they use: reflection, request dispatching, etc. Then when a project comes up, you’ll know which tool to use and most importantly: why. It will mean you can spend less time on those forums bugging the developers to add “x feature to make my life easier.” It will mean you can be productive and enjoy the benefits each framework brings to each problem domain you face.
That is the true beauty of it all.