Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
"Changing a framework usually requires a full rewrite"
This hits the spot.
I have tried to explain this in the past by highlighting restrictions placed by frameworks which business logic need to follow, failing which your code won't work as expected. And that governs most of your app.
Example for front end frameworks, you need to know the event lifecycle (methods or hooks) to place certain code at the right places for certain tasks.
Whereas with libraries, it's opposite, the lifecycle of each part of the app/site is in your control (not the library's) and you call the library like a function call, from wherever you decide to call it from.
However this didn't strike home for many. Your explanation is more concise and better.
Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
A library augments code. Ie it adds capabilities.
A frameworks provides the foundation of all your code.
If a library breaks, parts of your codebase may break but the overall codebase will likely still function.
If a framework breaks, nothing will work.
Changing a libraries is low-impact. Changing a framework usually requires a full rewrite.
"Changing a framework usually requires a full rewrite"
This hits the spot.
I have tried to explain this in the past by highlighting restrictions placed by frameworks which business logic need to follow, failing which your code won't work as expected. And that governs most of your app.
Example for front end frameworks, you need to know the event lifecycle (methods or hooks) to place certain code at the right places for certain tasks.
Whereas with libraries, it's opposite, the lifecycle of each part of the app/site is in your control (not the library's) and you call the library like a function call, from wherever you decide to call it from.
However this didn't strike home for many. Your explanation is more concise and better.
"iT's JuSt A lIbRaRy"
Seems to be a common marketing tactic employed by framework Dev Rels to increase adoption.
Unfortunately, that's where a lot the confusion stems from.
Adopting a framework comes with real costs and constraints that should be considered.