Chapter 9. Frameworks
By the time you start building a serious web application, you have already made dozens of decisions. How to structure your code. How to talk to a server. How to style a page. How to handle async operations that might fail. Each decision had trade-offs, and each one shapes what is easy and what is painful as the project grows.
Frameworks bundle these decisions for you. They come with opinions about routing, state, rendering, and a dozen other things you would otherwise have to figure out yourself. On a good day, those opinions match your problem, and you move fast. On a bad day, they fight you at every boundary.
Whether you need a framework at all is a question worth sitting with. The web platform today is far more capable than it was when most popular frameworks were designed. Modules, custom elements, the Fetch API, CSS variables: much of what frameworks once provided is now native. The question is not just which framework, but whether the trade-offs one introduces are worth it for what you are actually building.
Most framework decisions happen by social proof: the team already knows React, or a blog post made Vue look appealing, or the job posting listed Angular. These are real factors. But they are not the complete picture. Frameworks have long time horizons. The choice you make this quarter shapes what is easy and what is painful for years. The conference talks and glowing tutorials will fade. The codebase will not.
In this chapter, we will learn:
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access