Why do I distrust CSS Frameworks (and why should you, sometimes)?

CSS, the essential language of web development, brings interfaces to life by defining their visual style. The primary objective is customization, but in the quest for consistent, aesthetically pleasing renderings, developers often turn to CSS frameworks. These tools, designed to simplify the styling process, offer a quick and practical solution. However, the use of these frameworks is not without its compromises. It's essential to take a step back and consider some of the drawbacks that can sometimes be overlooked.

Unreadable code and long HTML tags

One of the main drawbacks of CSS frameworks lies in the creation of long, unwieldy HTML tags. What starts out as an effortless quest for speed and style often turns into an accumulation of alphanumeric classes added to tags, all with the aim of quickly achieving a desired style. In the rush to apply a style without writing a line of CSS, you can quickly end up with a dense HTML structure, adding class names one after the other. This contrasts with the clearer approach of creating a separate CSS file, where you can logically organize all the styling with a simple selector or class name.

Undesirable effects

Integrating a framework can introduce undesirable functionalities. Predefined styling effects, which seem harmless at first glance, can quickly change the appearance of your site, giving it a recognizable style, for example with Bootstrap's default outlines applied to buttons and form fields.

Limited customization

The use of CSS frameworks can greatly simplify the creation of a user interface. However, when it comes to standing out with a customized design, things can get a little tricky. Customization, while desirable, can be a challenge, especially for junior front-end developers where some actions may be required (as in the case of Bootstrap).

Class names to memorize

Learning framework-specific class names can be tedious (although class names are often closely related to CSS properties). Rather than coding intuitively, you often find yourself consulting the documentation to remember whether it's "font-bold" or "fw-bold"...

Framework dependency

When a new major version of the framework is released, to take advantage of its benefits in your future applications, you need to familiarize yourself with the new syntax, leaving behind the one you had previously mastered. This constant reliance on learning and relearning can make your code sensitive to frequent framework evolutions. Opting for a more permanent solution, such as the direct use of CSS, whose syntax evolves less frequently, can offer an alternative that avoids this ongoing dependency.

Back to Simplicity

For seasoned CSS developers, working without the constraints of frameworks can be faster and more efficient. No need to constantly search for the right classes, and the separation of concerns is preserved.

Now, of course, I can't ignore the benefits of CSS frameworks. They can greatly speed up development, ensure consistency and make it easier to manage updates. But here's the rub: the comfort of immediacy shouldn't make us lose sight of the value of customization and deep understanding of our own code.

For a self-starter CSS developer, it can be easier, quicker and more efficient to work without the constraints of frameworks. By avoiding the need to learn a new set of specific class names, the developer can already quickly create a CSS file and apply styles using familiar selectors. The constant search for the right class in the documentation sometimes becomes a hindrance.

Separation of concerns, a fundamental principle of application development, is also compromised when all styling logic is mixed with HTML in the same file. This goes against code clarity and can make debugging and maintenance more laborious.

So, while I acknowledge certain merits of CSS frameworks, it is crucial to recognize that their usage requires a trade-off. Perhaps it's time to reconsider the balance between convenience and creativity in the frontend development process.