The Framework Learning Cycle

Much of the discussion around frameworks -- particularly in the Javascript community -- is mired in misunderstanding over a key question: who are frameworks really for?


Beginning web developers tend to lean heavily on frameworks. This is a good thing — it lets them stand on the shoulders of giants and start shipping useful programs. And it gets them involved in communities and companies where they can steadily grow into more experienced developers.

But newbies are powerless to debug through leaking abstractions. When things break — and in software something always breaks — they must cross their fingers and hope Stack Overflow already has the answer.


Eventually the beginner gains enough experience to not be a beginner anymore. The pain of not understanding the next layers down in the stack is still fresh in her mind, so she vows to compose her own architecture, containing exactly what she needs and nothing she doesn't.

This is the stage where people wax rhapsodic about the virtue of microlibs. Down with the tyranny of frameworks! Just pick and choose exactly the pieces you want. It feels so much simpler and lighter.

(This is also exactly the stage of the learning process in which a Linux aficionado switches from Ubuntu to Gentoo or LFS. Customize and optimize all the things.)


Now she understands all the pieces. But as she matures further as a programmer and architect, she starts to see all the myriad ways that her bespoke architecture is not as good as the more standardized alternatives.

It can't be, because all the people spending their time on bespoke solutions are solving the same problems over and over again separately. Meanwhile, the people working on shared solutions keep building off each other. Over the long-run it gives a massive quality advantage to shared solutions built by healthy communities.

Her journey is complete when she circles back around and can pick up somebody else's framework with strong shared community conventions and still understand all the pieces. She's not intimidated by the prospect of debugging down through layers of abstraction. Because she's good enough to write a framework, she doesn't have to. She can just contribute to one, and benefit from everybody else who's also contributing.

There and back again

Computing is built on a tower of abstractions. This is vital if you want to make something like Angry Birds without first learning how to grow pure silicon crystals.

Frameworks exist at the boundary between Abstractions That We Take For Granted and Solutions to Individual Problems. Frameworks are where we're actively hashing out what the next layer of general purpose abstractions should look like.

So who are frameworks for? Everyone! To discover really good abstractions, we need input from the broadest possible range of people and projects.