Initially a new framework looks empowering. The examples and ideas behind them are inspiring. You think, of course, this is how things should be done. You try it out and marvel at how quick it is to get up and running. You witness the power you now wield to create software for the masses with minimal effort. You're hooked.
You start to talk to others about how amazing this new framework is. How it solves all the problems you've ever encountered and how everyone should immediately stop working with their antiquated junk and adopt it. Naysayers are easily dismissed because they just haven't yet come to understand the elegance. You become an evangelist for this new way of thinking.
At this moment of triumph a new reality starts to nag at you though. You've been working with this framework for some time now and are starting to see the rough edges. You find yourself wishing to change small aspects, to better serve your needs, but struggle to do so. You even reach out to the maintainers and ask for, or propose changes, but receive only hesitancy and apprehension. Valid concerns are raised about breaking compatibility or not being inline with the core vision. You contemplate forking, but don't really want to sink the time into maintaining this code base and battling upstream changes.
Finally you accept these limitations and move on. You continue to use the framework since you've invested so much time learning it, but it feels like an eventual dead-end. You start looking elsewhere for answers and, eventually, find some. Inevitably a new framework appears and starts to look appealing. Thus, the cycle starts anew.
- good They make life easier for the developer so you don't have to think about the framework.
- bad You don't think
- The frameworks we use to build our apps should be a dynamic evolving construct
- We should be able to customize them to meet our needs
- As new ideas emerge, we should be able to incorporate them with minimal frustration