He lists some attributes that might be true of certain libraries, like “feature complete,” “interchangeable,” and “single dependency,” but these aren’t true of most libraries.
He lists some attributes that might be true of certain libraries, like “feature complete,” “interchangeable,” and “single dependency,” but these aren’t true of most libraries.
I wouldn't exactly say that frameworks teach non-transferable knowledge. Concepts like data bindings and reactivity tend to be constant across all major frameworks. The syntax might be a little...
I wouldn't exactly say that frameworks teach non-transferable knowledge. Concepts like data bindings and reactivity tend to be constant across all major frameworks. The syntax might be a little different, but it's concepts that are hard to learn, not keywords.
As for their use, I think it really just depends on what you're building. If you want your logic to live on the server-side, then you can probably get away with building something entirely using libraries. I'm sure you'd at least want a good charting/graphing library, and maybe something for building dashboards.
If you want the advantages of an SPA (instant updates, no page reloads) and prefer your logic to run locally, then I think a framework can still make sense. They require more upfront complexity, but tend to smooth out the technical debt over a longer period. This is especially true when working in a team, where component-based design lets you break features into smaller logical chunks.
Really, frameworks are just another tool. I find them useful for many tasks, but not all. It's up to any developer to choose the tools they wish to work with when starting a project.
He lists some attributes that might be true of certain libraries, like “feature complete,” “interchangeable,” and “single dependency,” but these aren’t true of most libraries.
I wouldn't exactly say that frameworks teach non-transferable knowledge. Concepts like data bindings and reactivity tend to be constant across all major frameworks. The syntax might be a little different, but it's concepts that are hard to learn, not keywords.
As for their use, I think it really just depends on what you're building. If you want your logic to live on the server-side, then you can probably get away with building something entirely using libraries. I'm sure you'd at least want a good charting/graphing library, and maybe something for building dashboards.
If you want the advantages of an SPA (instant updates, no page reloads) and prefer your logic to run locally, then I think a framework can still make sense. They require more upfront complexity, but tend to smooth out the technical debt over a longer period. This is especially true when working in a team, where component-based design lets you break features into smaller logical chunks.
Really, frameworks are just another tool. I find them useful for many tasks, but not all. It's up to any developer to choose the tools they wish to work with when starting a project.