July 4, 2006
Web Frameworks, Underlying Technologies, and You
While the context of that discussion is what, if any, toolkits the Django framework should tie into, the philosophy runs deeper. I think Ian hits it on the head: frameworks should simplify your life most of the time, but give you the flexibility you need in special cases.
Of course you have to expect that any engineer or web developer you hire understands what’s going on under the hood. Using an ORM toolkit doesn’t mean you can get by with not understanding SQL or how to optimize queries or how indexes are used. Using an abstract REST API doesn’t mean you can get by with not understanding HTTP.
In the base case, using a higher-level programming language doesn’t mean you can be effective without understanding what’s going on underneath, what the CPU sees, how your VM utilizes memory, and so on. But you rarely see people anymore arguing that programmers need to always be burdened with these details. (You used to see that argument, but it’s rare.)
A framework is an abstraction, which frees up the developer’s mind to concentrate on delivering (if not perfecting) the overall functionality of the application on time. Frameworks represent the commodification of certain development skills, which is good, because it means more can get done. But to be effective, you have to know the limits of your framework, and be able to circumvent the framework when necessary.
Back to James’ original reluctance, though:
All of that is true (except the “worse idea” is really the first). But that’s the responsibility you take on when you develop a framework. In