Framework: This is (usually) someone else’s code that calls your code.

Library: This is (usually) someone else’s code that you call from your code.

I think these two sentences nicely summarise the difference between frameworks and libraries and why I prefer the library approach. I find frameworks somewhat claustrophobic. They are often too constricting and enforces an architectural or code style that might not fit all of one’s use cases. Adapting a framework to your own needs often entails doing the equivalent of black magic, typing out some esoteric incantations that forces the framework to do things a bit differently.

Libraries on the other hand affords you the freedom to build your own framework of sorts. You can pick and choose those libraries which gets the job done. You need something to validate that data/objects match some schema? There is a library for that. You want to generate some API docs? There is a library for that. Then it is just a matter for finding libraries that go well together and write som glue code. A big advantage gained is then the ability to switch out libraries once new and improved libraries arrive on the scene. With frameworks you would need to wait until the framework authors decide to switch.

I guess in a way picking libraries come with their own limitations. And libraries can in and of themselves be prescriptive in terms of which patterns and principles are to be used. In the case of React there is a clear sense of the library optimising for immutable data patterns and declarative views. But the library still allows you to do imperative things, albeit not as easily as the idiomatic approach. I guess what is powerful about such libraries is that they allow you to get the work done.

Jerod Santo:

The challenge with principles & patterns is they are more difficult to formalize (and communicate) than libraries & frameworks because they’re by nature less specific and more meta (lowercase “m” ftw).

When I first read about the Flux pattern I was convinced this was the “Right Thing TM” for web based applications, at least the kinds I had been working on. But actually implementing these principles in terms of one or more usable libraries would be none-trivial and consume resources that could be used to work on the apps themselves. I’m not sure the cost-benefit analysis of writing your own libraries and frameworks are all that great for smaller companies. In effect people would end up re-inventing the wheel a lot. Which is not necessarily a bad thing, but could be seen as wasting resources. In a way I think “stackless” might be the right thing for very small projects/companies that just need some simple logic. Big companies will invent their own stacks. For anyone else I think the benefits of shared knowledge and bug fixing outweighs the costs of pulling in the libraries and/or frameworks.

I agree with the tone of the article, but in everyday life of project work there is often the pressure to have something to show off with very limited time – often supposed to be only a prototype. And so you lean on to a framework to get a result as fast as you can. Later, the prototype becomes the working solution as it is good enough and so you’re bound to it – no matter how bad the decision is (so back to “sunk costs”).