A framework is kinda like going to a travel agent and saying: "I want to visit Italy. Can you plan that for me?" This travel agent is known for its Italian vacations, but it gives the same basic itinerary to everyone with a few optional variations. When you are there, if you decide you want to do something different from your itinerary, you have to pay (lose a deposit) for the missed events. Going against the itinerary costs extra money, sometimes significantly.
A library is more like planning your own vacation, perhaps with the help of some online tools. It requires a little more research on your part to discover the events and organize a schedule. But without a pre-arranged appointment, you can decide to skip events or swap them out for others. This flexibility costs more of your time, but not nearly as much as going against the travel agent's itinerary. You can also craft exactly the experience you are looking for. A wine tour? A picnic in the countryside? A walking tour of Rome? It is your choice, and you can change your mind when you get there.
Well, this ended up being an LI5 analogy.
I think both frameworks and library approaches are valid ways to go depending on your goals. I have used lots of frameworks over the years. Nowadays I am only interested in the library approach because maintainability and quality are high priorities. Being locked in to a framework means I eventually have to write hacky, hard-to-maintain code to work around a missing/mismatched framework feature. Because every framework is just someone's opinion on how to solve a set of problems... but a given strategy doesn't work well in every scenario. Also, swapping out a library for a better one is a serious endeavor but it is usually achievable. Swapping a framework is completely intractable, and it usually means a complete rewrite of the app. Still, frameworks can be good for getting your app out quickly. Sometimes this is a higher concern than longevity.
A framework is kinda like going to a travel agent and saying: "I want to visit Italy. Can you plan that for me?" This travel agent is known for its Italian vacations, but it gives the same basic itinerary to everyone with a few optional variations. When you are there, if you decide you want to do something different from your itinerary, you have to pay (lose a deposit) for the missed events. Going against the itinerary costs extra money, sometimes significantly.
A library is more like planning your own vacation, perhaps with the help of some online tools. It requires a little more research on your part to discover the events and organize a schedule. But without a pre-arranged appointment, you can decide to skip events or swap them out for others. This flexibility costs more of your time, but not nearly as much as going against the travel agent's itinerary. You can also craft exactly the experience you are looking for. A wine tour? A picnic in the countryside? A walking tour of Rome? It is your choice, and you can change your mind when you get there.
Well, this ended up being an LI5 analogy.
I think both frameworks and library approaches are valid ways to go depending on your goals. I have used lots of frameworks over the years. Nowadays I am only interested in the library approach because maintainability and quality are high priorities. Being locked in to a framework means I eventually have to write hacky, hard-to-maintain code to work around a missing/mismatched framework feature. Because every framework is just someone's opinion on how to solve a set of problems... but a given strategy doesn't work well in every scenario. Also, swapping out a library for a better one is a serious endeavor but it is usually achievable. Swapping a framework is completely intractable, and it usually means a complete rewrite of the app. Still, frameworks can be good for getting your app out quickly. Sometimes this is a higher concern than longevity.
Gotcha! Good examples used 😉