Yes, I Use a Framework. So What?

There is an argument in web development that refuses to die. Someone mentions Bootstrap in a meeting, and another person makes the face normally reserved for a Friday afternoon production deployment.

A framework?

For CSS?

How embarrassing.

According to this school of thought, serious developers write everything from scratch. They reset every element by hand, rediscover every browser inconsistency, build another grid system, and personally fight each version of Internet Explorer in honorable combat. Anything less would be cheating. I used to take this argument more seriously than it deserved. In fact, allowing it to influence me became one of the professional decisions I regret most.

The framework I did not build

Years ago, during a dinner with web developers in Barcelona, I asked two respected front-end programmers whether they wanted to help me create an HTML and CSS framework. The idea was simple. We would build a reusable foundation containing the things every project needed, something broader than the CSS resets available at the time, but still small enough to understand and customize.

They looked at each other. No words were necessary. Their faces had already completed a full code review. One of them eventually answered that it was not worth doing. Depending on a framework, he said, was for mediocre developers. He did not need help building a website.

The argument continued in that direction. Good developers supposedly built everything themselves. Reusing a foundation was a sign that you lacked skill, discipline, or some mysterious quality possessed only by people who enjoyed solving the same browser bug every six weeks. I went home and reconsidered the idea. That was the mistake.

Instead of asking whether the framework would solve a real problem, I allowed somebody else’s pride to turn the tool into a moral question. Other people did not make that mistake. They built frameworks, preprocessors, libraries, and reusable components. Many of those projects became part of the normal way we build for the web.

I eventually redeemed myself by creating a framework for iPhone-oriented web development. Between the downloads from my site and the old Google Code repository, it reached around 100,000 downloads. The project is obsolete now, as most web code eventually becomes. Entropy is very productive in our industry.

Still, people used it. Other projects borrowed ideas from it, and some of those ideas later appeared in newer frameworks. That experience taught me something I should have understood at the dinner table: The framework was never the problem. Pride was.

Repeating work is not craftsmanship

A framework is simply a collection of decisions and reusable solutions. It may provide a grid, typography rules, form styles, buttons, navigation components, responsive behavior, utility classes, JavaScript interactions, or a basic project structure.

None of this prevents you from understanding HTML or CSS. It prevents you from having to rebuild the same foundation for every project. There is a difference between craftsmanship and repetition. Craftsmanship means understanding the material, making deliberate decisions, and producing something appropriate for the problem. Repetition means writing another clearfix because apparently this is the project where your version will finally achieve spiritual perfection. Nobody gives you a medal for handcrafting every line of CSS.

The customer does not care that you spent three days recreating a responsive grid already maintained and documented elsewhere. They care that the product works, loads quickly, behaves consistently, and can be maintained by someone other than the original author. Time matters. Every hour spent solving a problem that already has a good solution is an hour not spent on the part of the product that is genuinely different. Sometimes building your own solution is correct. Sometimes it is necessary. It should be a technical decision, not a ritual of professional purity.

Programmers already understand this

Programmers have been using libraries and frameworks forever.

Nobody expects a Ruby developer to rebuild routing, database access, templates, sessions, security protections, and command-line tooling before beginning the actual application. They could. That would certainly demonstrate commitment. It would also be a spectacular waste of time.

Frameworks such as Rails became useful because they packaged common decisions into a shared structure. Developers could begin with a known foundation, follow documented conventions, and concentrate on the behavior specific to their product. The framework does not remove the need to understand the language or the application. It removes the need to pretend every project is the first project in history. Front-end development should not be treated differently. HTML and CSS may look approachable, but browsers contain years of inconsistent defaults, historical decisions, compatibility behavior, accessibility concerns, and device-specific problems.

Starting from an established base can be a perfectly sensible engineering decision. The strange part is that some developers happily install fifty JavaScript packages to format a date, then become offended by the suggestion of using an existing CSS foundation. Apparently dependency management becomes dishonorable only when borders are involved.

Your two-line reset is not enough

One of my favorite arguments against CSS foundations goes like this:

* {
  margin: 0;
  padding: 0;
}

“There. I solved browser inconsistencies.”

No, you did not. You removed margins and padding from every element. That is certainly an action. It is not the same thing as normalization. Browser differences have never been limited to spacing. They include typography, form controls, media elements, line heights, heading behavior, tables, focus styles, and dozens of small inconsistencies accumulated over years of browser development.

A project such as normalize.css was designed to preserve useful defaults while correcting common browser inconsistencies and documented bugs. It was not merely a more fashionable way to write margin: 0. This distinction matters. A reset removes defaults. A normalizer tries to make defaults more consistent. A framework may go further and establish an entire visual and structural foundation. These tools solve different problems.

Throwing a universal selector at the page and declaring victory is like removing every fuse from a building because one of them keeps blowing. The symptom may disappear, although the evening will become less productive. Frameworks do not solve every browser problem either. No responsible tool can promise that. They do, however, collect solutions to common problems in one place and allow those solutions to be reviewed, tested, documented, and improved over time. That is usually better than collecting random fixes from search results and placing each one wherever it seems least likely to explode.

More eyes help, but popularity is not proof

One of the advantages of a widely used framework is that many people have examined its code. Bugs are reported. Edge cases are discovered. Accessibility problems are discussed. Documentation improves. Other developers can recognize the conventions without receiving a private tour of your brain. Bootstrap, for example, was already designed so developers could select and customize individual parts rather than blindly accepting the entire package. Its archived documentation allowed teams to choose which Less files, components, and plugins were included in a build. That modularity is important. Using a framework does not require using every component. You can adopt its grid and ignore its buttons. You can use its normalization and replace its visual styles. You can change variables, remove modules, extend components, and write the product-specific layer yourself.

A framework is a starting point, not a restraining order. Of course, popularity does not automatically make code good. A project can have thousands of stars and still be the wrong choice for your product. Large communities can preserve bad ideas just as efficiently as good ones. The advantage is not that many users make the framework infallible. The advantage is that you have more evidence.

You can inspect the code, issues, documentation, release history, browser support, and maintenance activity before choosing it. That is more information than you usually have about the mysterious internal framework written by a former employee named Carlos who left no documentation and cannot be contacted. The final commit message is fix stuff. Carlos knew what he was doing. Probably.

A framework is not architecture

Using Bootstrap, Foundation, or any other framework does not mean you have designed the product. It means you selected a foundation. This is where some teams get confused. They install a framework, copy a few examples, change the primary color, and announce that the design system is complete. It is not. A framework cannot decide the hierarchy of your product. It does not know which actions matter, what your customers are trying to accomplish, or whether your navigation makes sense. It provides components. You still need to design.

This is why so many sites built with the same framework appear identical. The problem is not necessarily the framework. The problem is that nobody continued past the default settings. Defaults are meant to help you begin. They are not a substitute for product decisions. A competent team should be able to bend a framework toward the product’s needs. The resulting interface should not look like a demonstration page with the company logo attached.

When developers say that all Bootstrap sites look the same, they are often describing projects where Bootstrap was used as the finished design rather than as construction material. That is like blaming bricks because several buildings are boring.

Frameworks create a shared language

One benefit of frameworks is rarely discussed enough: they make collaboration easier. A documented framework gives the team a shared vocabulary. Developers know how the grid behaves. Designers know which breakpoints and components exist. New employees can read documentation instead of reverse-engineering years of individual preferences. Code reviews become easier because the implementation follows known conventions. This matters more as a team grows. A custom solution may feel beautifully simple to the person who created it. To everybody else, it is an archaeological site.

There are undocumented naming rules, exceptions inherited from old projects, and utility classes whose purpose can only be revealed by running git blame and finding the developer who introduced them seven years ago. That developer is now raising goats in another country.

A common framework does not guarantee maintainability, but it gives the team a public reference point. When someone needs to change the system, they can consult documentation, examples, tests, and community discussions. That is a significant operational advantage. The best code is not merely the code you can write. It is the code another person can understand without arranging a séance.

When you should not use one

Frameworks are useful, but they are not compulsory. There are good reasons to avoid one. A very small page may not need the weight or structure of a complete framework. A highly specialized interface may spend more time fighting the framework than benefiting from it. A product with strict performance constraints may be better served by a smaller custom foundation. A team may already have a mature design system that solves the same problems more appropriately.

The framework may be abandoned, badly documented, difficult to customize, or built around assumptions that do not match the project. In those cases, do not use it. The correct lesson is not “always use a framework.” The correct lesson is “do not reject a framework because using tools makes you feel less heroic.” Evaluate it like any other dependency.

What problems does it solve?

How much code will you actually use?

Can you remove the parts you do not need?

Is it accessible?

Is it maintained?

Does the team understand it?

What happens when you need to upgrade?

Can you leave it later without rebuilding the entire product?

These are engineering questions. “Will other developers think I am mediocre?” is not.

Learn the platform first

There is one situation where frameworks can become genuinely harmful: when they replace learning. A beginner can use predefined classes to assemble a convincing interface without understanding the HTML structure, cascade, box model, specificity, responsive behavior, or accessibility behind it.

Everything appears to work until it does not. Then the developer has no model for understanding why. The solution is not to ban frameworks. It is to learn what they are doing. Inspect the generated HTML. Read the CSS. Change variables. Remove components. Break things deliberately.

Use the browser’s developer tools and follow the rules through the cascade. A framework should accelerate knowledge, not conceal its absence. You need enough understanding to know when the tool is helping and when it is creating a problem. You should be capable of overriding it without building an increasingly desperate wall of !important.

If every customization requires another !important, the framework is no longer the only thing that needs investigation. Learning the underlying technology also protects you when the framework disappears. Frameworks become obsolete. APIs change. Projects lose maintainers. The fashionable solution of one decade becomes the legacy migration of the next. HTML and CSS remain underneath. The framework is temporary. Your understanding is the part you keep.

Convenience beats nostalgia

Developers are strangely nostalgic about unnecessary difficulty. We remember how much work something required and begin to treat that work as proof that the result had value. It is the same reason people occasionally romanticize deploying through FTP or testing websites in six virtual machines by hand. The fact that we suffered does not mean the suffering was essential. Tools improve. Browsers improve.

Workflows improve. The job is not to preserve every inconvenience that once demonstrated expertise. The job is to build good products. A framework can save time, reduce repeated mistakes, improve consistency, and make collaboration easier. It can also add unnecessary code, constrain the design, hide important details, and create dependency on decisions you do not control.

Both statements are true. Professional judgment means knowing which one applies to the project in front of you. Use the framework when it gives the team leverage. Skip it when the cost is greater than the benefit. Customize it when the defaults do not fit. Replace it when it becomes an obstacle. But do not write everything from scratch merely to prove that you can. We already believe you. Now please finish the website.