This article continues my mini-series on functional library design. Previously, I discussed why your library should provide multiple levels of abstraction. Today, we look at composability and avoiding callbacks. These two often go together - frameworks are based on callbacks and are not composable, while good libraries avoid callbacks and compose well.
Here’s my take.
What the author is saying is true in terms of the ‘downsides’ of frameworks - they force coupling, dictate the way in which you write your code, and make it difficult to move to any different framework.
But that doesn’t mean frameworks are inherently bad.
I recently used the Kivy graphics framework to build a GUI app in python. Yes, this means I have to structure my app the way Kivy wants it to be, but it also means I get a huge amount of heavy lifting done for free. Kivy takes care of rendering graphics, bubbling user input through the component hierarchy, all the underlying tricky stuff, and means I can focus my time where I want to; adding functionality.
Frameworks control the way you code, but in return they let you get going very quickly.
The prescriptive nature of frameworks can also be a huge boost in a commercial setting, because it makes it easy for developers to work together with a common understanding on what they are doing. If someone has built a mobile app in React Native and they move to another team that is also building apps in React Native, they know what they expect to see when they clone the repo. It’s not a fresh learning curve every time.
The negatives the author calls out are totally valid, but IMO there are upsides to consider too.