Innovating beyond libraries and frameworks ↦
Nils Norman Haukås:
I have been a big fan of the write libraries, not frameworks argument for a while now. Lately, I’ve come to ponder that there might be a fruitful expansion to this argument, that we should start to value principles over patterns, patterns over libraries, and libraries over frameworks.
I don’t disagree!
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).
In other words, libraries & frameworks are an end product. Principles & patterns are means to an end. It’s easier to ship a product than to ship the means to it.
The latter is the realm of documentation, education, and conversation.
Sign in or Join to comment or subscribe
Nils Norman Haukås
It’s interesting on one hand how libraries and frameworks can package up big ideas and offer it to end-users. For example npm installing Redux gives you flux-architecture, and npm installing Immer.js gives you strong concepts of immutability. It’s easy to just do npm install and not give a second thought to the ideas that might lie embedded in the code.
On the other hand adopting an idea (principles and patterns) directly instead of pulling them in as dependencies requires more work, but in turn it might add more flexibility and longevity to a codebase because ideas doesn’t need security updates or funding. :)
Snorre Magnus Davøen
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.
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.
Nils Norman Haukås
Thanks for your comment!
+1 to the notion that it can feel like frameworks box you in and take you along for a ride. I remember using Next.js pre-static-site-generation where it had a getInitialProps API for data fetching which fit my use cases a lot. Granted, it was tricky to use because if you weren’t careful you could suddenly bundle a lot of server-side dependencies into the client-side bundle. Later Next.js launched new data-fetching APIs to support static-site generation and incremental static regeneration. This coincided very well with the Jamstack industry trend. For our use-cases getInitialProps worked great because we wanted fresh data and didn’t need caching. SSG was an answer to a problem we didn’t have, but since Next.js went all in on that hey we got to come along for the ride. Looks like SSG is where we’re at now folks. No disrespect to the Next.js team here for their hard efforts, just noting how frameworks affect our codebases.
Flux architecture is a catchy name, like extreme programming. Had it been called global-state-machine architecture it might have given people a bit more pause to consider what they’re getting into.
Yes, maybe so. In practice, I see that me and my colleagues need to put extra effort into staying on top with updates and position the code to fit with where the framework / library is headed or else it can be quite hard to keep up. If we don’t keep up with updates the upgrade costs will deter clients from saying yes to spend time on it and eventually we’ll be stuck working on some older version and sifting through deprecated documentation in order to still be able to push out changes.
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”).
Nils Norman Haukås
Ah, the classic case of the prototype that went to production. That’s a hard one to solve. Do people ever delete prototypes, like actually treat them as throwaway code? Yeah, I’ve been burnt by prototypes that went to production and by that you’ve cut so many corners to get the thing out the door that pushing new features becomes downright dreadful.
I’m glad you mention the realities of everyday project work. When we need to show results fast we need to go to our go-to tools which we have experience in. But exactly what libraries and frameworks we use and how we choose to use them is not always given careful thought. Within a project there’s usually not much time for any R&D we just need to stick to what we know.
However, between projects I think it’s possible for developers to find time to discuss what tools to use and how to use them well. Like, nobody got fired for picking Gatsby, Next.js, 11ty or Nuxt. However, if your project is to last 5+ years without too much update churn then maybe it would be better to pick a “boring” framework like Express that’s supported by the OpenJS foundation?