You Can't Not Have a Framework

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

Definitions

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.

Positions

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 will write code to glue the modules and libraries together.
• You will write abstractions when you identify boilerplate to make yourself and your team more productive.
• You will write abstractions to consider things the consumers of your code probably don't know about (i.e. accessibility, browser quirks, etc.)

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:

• Dedicate time to design public APIs with several developers: don't just commit what works for your current feature. A bad abstraction is really expensive; you need more brains than your own to prevent them.
• Document public API--in fact, don't commit any without usage docs. If your team can't figure out how to use your stuff, they have to come to you; you've become a bottleneck. Additionally, using git blame to figure out who to talk to when you're stuck in some home-grown framework code is a terrible plight.
• Maintain the framework. If you don't, it'll evolve into a liability.
• Realize the cost. A community puts exponentionally more effort into an abstraction than you can, how much time will you spend on the framework v. other responsibilities?
• Be capable. Framework-level code is difficult, most of us aren't good at it. Do you have the experience and design skills needed?
• Be able to answer yes to this question: if the framework you end up with were on github, would you still pick it?

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?