Hot Docs

Using a Frontend Framework

Managing a lot of style rules is difficult and using a third-party library can help — sometimes

A good frontend framework can save a lot of work. They typically provide a large number of well-designed components that are ready to use. You can create an accordion, a carousel or a card component just by adding a few class names.

To show the power of these frameworks and give you an idea of how to use them on Hot Page, we have a template that uses a framework called Bootstrap. The page includes many of the most powerful features of the library and you are free to copy any part of it for your projects.

The Drawbacks

The problem with these frameworks is that often when you try to do something outside of the established guidelines, you end up fighting it.

For example, when we created the menu on the left side of our Bootstrap template, we used the so-called offcanvas component. This works great because on smaller screen sizes it automatically becomes a drawer that slides in from the left side.

However, it appears this was not designed to house links to different sections of the same page and we ran into a problem when we wanted the drawer to close after the user clicked one of the links. Bootstrap let’s you add a data-bs-dismiss=offcanvas attribute on any element to close the drawer, but adding that attribute prevented the links from working at all. Our solution involved a bit of JavaScript that would have been very difficult for a beginner to write by themselves.

Often, when you use a framework like Bootstrap, you get a “class soup” on your elements. The pull quote on the page has six class names: .float-md-end.col-md-6.m-md-2.ms-md-5.bg-primary-subtle.p-2. Even if you know that the class p-2 adds padding, it won’t be as readable as just looking at the CSS itself. The framework is an added layer of abstraction and that always comes with both advantages and disadvantages.

Hot Page is designed to help you write your own style rules easily directly with CSS. That runs contrary to the purpose of many of these frameworks, which are often used to avoid writing CSS entirely.

Also, CSS is just better these days as the technology has advanced. Browsers have fewer quirks because standards are better and more features have been added. For example, a responsive grid system based on classes is not so necessary anymore, because it is now easily achieved with raw CSS with the grid layout module.

Frameworks are powerful but they are also large and take time to learn. A monster like Bootstrap has dozens of components and hundreds of class names. That’s a lot of material to cover and time that you could spend just learning CSS, a skill that’s lower level and more likely to be useful for future projects.

Utility Classes

Bootstrap has a lot of classes that only add one CSS declaration to your element. For instance, it has a class called opacity-25 which adds the CSS declaration opacity: .25. You could ask yourself what’s the point? Instead of class="opacity-25" why not just use style="opacity: .25"?

Well it turns out, inline styles have a few limitations. Notably, they don’t support media queries and state-based pseudo classes like :hover. Bootstrap’s utility classes often do, so for instance, there’s a class w-50 which is equivalent to the CSS for width: 50%, but you can also use w-md-50 which means the rule will only apply on a medium (tablet) or larger screen size.

Another benefit to these utility classes is they can help to enforce a design system. For example, the framework comes with classes for padding that are p-1 through p-5. Limiting the padding to five values will give your design a certain symmetry that would otherwise require a lot of careful attention to detail.

If you’d like to have this benefit without using Bootstrap in your own code, you can use CSS variables (also called custom properties). Create a variable like --spacer: 10px and then use it like padding: var(--spacer) or padding: calc(var(--spacer) * 2).

These utility classes also have drawbacks, of course. For one, they require familiarity with the framework. So someone who sees a class named ps-md-2 on your page will probably think you’ve lost your mind, unless they are already familiar with Bootstrap’s naming conventions.

Utility classes must be added to elements one by one, where as the power of CSS selectors means you can style many elements all at once. For example, in the image carousel on our Bootstrap template, we could have styled the images with a bunch of utility classes but this would have required copy and pasting the classes onto each image. When the styles changed, we would have to change each image individually. With a few lines of CSS we were able to apply the styles we needed to all of them in one place.

Utility classes in Bootstrap are never going to be as complete or powerful as using CSS directly, of course. For example, you can change a link’s opacity on hover to 50% with link-opacity-50-hover, but if you want to change a background-color on hover you’re out of luck. The framework doesn’t support it, so you’d have to make your own utility classes or customize the framework with a build step.

Another popular CSS framework called Tailwind, takes this practice to an extreme. The library has so many utility classes that it can’t even be used without a compilation step to remove all the extra classes. If they were all included, the CSS would be enormous and pages would load slowly. This may sound like a bad idea, but the framework is very popular for large projects because it’s thought to make code bases above a certain size much more manageable.

Now that you know some of the pluses and minuses of using a framework, let’s run through some of the big ones:

Probably the best way to learn more about these projects is to try them out by building a few pages and see if you find them helpful for your workflow.

Web Components

Most of the biggest and most established frontend frameworks have an all-or-nothing approach. They’re meant to change the entire look of your page and give it a consistent feel. If you tried to add two different frameworks, bad things will usually result: the styles will conflict and you’ll have a big mess on your hands.

Browsers now have a new feature that could change all of this: custom elements. We covered this a bit in our page on elements but it’s worth mentioning again here again because it will likely be an increasing part of these frontend frameworks, making it easier to pick and choose components in the process.

Shoelace is a library of custom elements that is already quite complete and provides many of the same components as the frameworks listed above.