You Can't Not Have a Framework

By Ryan Florence

Lots of hubbub about frameworks versus libraries in browser development. Its an unavailing conversation because the choice doesn't really exist.


Module - A unit that performs a single task or a few related tasks.

Library - A set of modules with shared purpose.

Framework - The glue between modules and libraries to expose a unified API with abstractions that keep code you don't want (or know) to write out of your application.

A note about the definition of framework: Some people define framework v. library as "I call library code, frameworks call my code." I can't identify frameworks with this definition when I call React.renderComponent() and then React calls render on my component. If this is your definition of framework, please s/framework/architecture/g.


Frameworks: Abstract the stuff you need to do all the time and focus instead on what makes your app unique.

Libraries: Frameworks will have a couple bad opinions, or twenty, and you write a ton of code to get around them; just give me flexibility because my app is unique.

You Can't Not Have a Framework, Though

When you decide to not pick a public framework, you will end up with a framework anyway: your own.

You'd better go update your twitter profile because you are now the author of a framework.

It's Fine, Just Be Serious About It

If you don't pick a public framework, you should commit to building one on purpose, not by accident:

It's About Design

When you cross over from algorithms to architecture, you are now in the subjective side of programming. Unlike algorithms, there is no objectively optimal design for a framework API. Some people are not going to like your design in the same way you didn't like the design of the public frameworks.

Finally, do you prefer driving in auto parts or automobiles?