Programming languages and their numerous libraries provide all sorts of interesting functionality which aid in the development process - making it easier to bring ideas to life.
A major concept we teach in programming is the idea of encapsulation. Encapsulation, in practice, essentially means to shield the function/library/framework user from the details that compose the code they wish to invoke.
Just as pop up ads have posed the question "HAS SCIENCE GONE TOO FAR?!", let's take a moment to ask "Have we taken encapsulation too far?"
Have we taken encapsulation too far?
(Credit: StillLikeTrains)
I feel some developers may need a reminder of why encapsulation is so great. When done right, encapsulation makes code easier to use. But here's the rub: Although source that's well encapsulated tends to require less lines of code to perform a specific function, source that requires less lines to invoke does not necessarily imply the source is well encapsulated.
"Look how little code you need!"
In the Webdev world, we are absolutely addicted to tiny hello-world app demonstrations when evaluating frameworks. When I say "we", I don't just mean framework users. Even the framework developers have become "X-lines-of-code" junkies. Or perhaps they are simply enablers to our addiction. It's all about the code - its presentation, its length, its beauty.
Well what would you prefer, Joe?
I'm instantly sold on framework that can do the following:
- Convince me I have a problem that I didn't realize I even had
- Quickly explain not just how to use the framework, but how the internals make sense for solving the problem.
"Writing a lot of code" on its own is not a significant problem. I'm perfectly capable of writing helper functions / classes if I realize I'm repeating myself. I'm perfectly capable of writing helper functions / classes if I realize I'm repeating myself. (heh)
Point #2 is the main selling point I feel most modern frameworks lack. For any nontrivial project, you will most likely have to override the internals at some point. If you can explain how the internals provide the toolkit for solving most of my problems while providing examples that demonstrate how the internals work, I'm much more likely to trust that the framework can adjust to my client's ever-changing requests. Frameworks that can demonstrate this have incidentally demonstrated proper amounts of encapsulation.
Frameworks should be much easier to understand than projects. As a developer, I'm constantly attempting to determine how real world problems fit into the framework, not the other way around. Sure, you have to pick the right tool for the job. But when it comes to development, you know you've picked the right tool for the job when you're shoving a square peg into a round hole. The fact that the peg might fit with some dedication and some power tools is a cause for celebration.
My point is a framework that's easy to understand is much more valuable than a framework that requires fewer keystrokes. A framework that's hard to understand but requires fewer keystrokes doesn't actually require fewer keystrokes - it just offloads those keystrokes to Google instead of your source.
An example of good encapsulation
Even though I am not a front-end developer, I have to tip my hat to Backbone.js for providing a sufficient amount of encapsulation without going overboard. Backbone is so concerned with developers understanding its internals they even provide annotated source code.
In the Getting Started guide, Backbone immediately educates the developer on how their structures of Models, Views, and Collections work. The guide then provides examples of how the internals make sense for the type of development Backbone is intended for.
Backbone is more concerned with selling developers on philosophy of development as opposed to hello-world demos.
Summary
A framework's main selling point shouldn't revolve around saving developers keystrokes unless it truly revolutionizes how developers write code (like jQuery did). The fact that we as developers are looking at your framework means we're expecting the framework to either save us keystrokes or cover our asses.
A framework should focus on having a simple and obvious design. The framework should then demonstrate how its simple and obvious design helps developers reduce their projects to simple and obvious projects.