Introduction:

In this blog, we will be talking about design systems, diving into the different types of CSS frameworks/libraries, then looking into issues that come with choosing a framework that is not right for your type of project. Then we will be going over different business use cases where these different frameworks/libraries match their requirements.

Let's paint a scenario: when starting a project, you start by choosing a JS framework. Let’s say, for example, that you went with a popular framework like React. Depending on whether you want an isomorphic app, you will look at Next.js. Next, we choose a UI framework, and that’s when our next set of problems appears.

WHICH ONE?

It’s hard to go with even the popular ones because it might not be what you are looking for. There are different types of libraries handling different types of use cases, and there are so many similar ones that each handle stuff slightly differently.

These frameworks come and go, so it’s essential to understand the fundamentals of CSS. These libraries and frameworks help you build faster; they don’t change how CSS works.

But, continuing with our scenario, let's say we choose a popular library like Bootstrap, or Material. Then, later on, as you’re working through the project, you notice issues like:

- Overriding default classes more than required 

- End up with ugly-looking code that’s hard to read

- Bloated CSS that reduces performance (flash of unstyled content issues, reduced CLS, FCP score)

- Swift changing designs, but you’re stuck with rigid frameworks, so migrating is hard and requires a lot more effort

- Require swift development but end up building from scratch

- Ending up with a div soup with no semantic meaning

To solve these problems and understand how these frameworks work, we have segregated them into the following category types. 

‍

We will dig into each category and look at how they work, their pros/cons and their business use case.

Categorizing the available frameworks:

Vanilla Libraries 

These libraries allow you to write vanilla CSS with some added benefits like vendor prefixing, component-level scoping, etc.  You can use this as a building block to create your own styling methodology. Essentially, it’s mainly CSS in JS-type libraries that come in this type of category. CSS modules would also come under these as well since you are writing CSS in a module file.

Also, inline styles in React seem to resemble a css-in-js type method, but they are different. For inline styles, you would lose out on media queries, keyframe animations, and selectors like pseudo-class, pseudo-element, and attribute selectors. But css-in-js type libraries have these abilities.  

It also differs in how the out the CSS; inline styling would result in inline CSS in the HTML for that element, whereas css-in-js outputs as internal styles with class names.

Nowadays, these css-in-js types are popular for their optimized critical render path strategy for performance.

Example:

Emotion

Styled Components

List of example frameworks: 

   - Styled components

   - Emotion

   - Vanilla-extract

   - Stitches

   - CSS modules
(CSS modules is not an official spec or an implementation in the browser, but rather, it’s a process in a build step (with the help of Webpack or Browserify) that changes class names and selectors to be scoped.)

Pros:

• Fully customizable—you can build on top of it
• Doesn’t bloat CSS, only loads needed CSS
• Performance
• Little to no style collision

Cons:

• Requires effort and time to make components from scratch
• Danger of writing smelly code
• Have to handle accessibility on your own

Where would you use these?

• A website with an unconventional design that must be built from scratch.
• Where performance and high webvital scores are required—the performance, in this case, refers to an optimized critical render path strategy that affects FCP and CLS.
• Generally, it would be user-facing applications like B2C.

Unstyled / Functional Libraries

Before coming to the library, we would like to cover a bit on accessibility.

Apart from a website’s visual stuff, there is also a functional aspect, accessibility.

And many times, when we say accessibility in the context of web development, people automatically think of screen readers. But it doesn't just mean website accessibility to people with a disability; it also means enabling as many people as possible to use your websites, even people with or without disabilities or people who are limited. 

Different age groups

Font size settings on phones and browser settings should be reflected on the app

Situational limitation

Dark mode and light mode

Different devices

Mobile, desktop, tablet

Different screen sizes

Ultra wide 21:9, normal monitor screen size 16:9 

Interaction method

Websites can be accessible with keyboard only, mouse, touch, etc.

But these libraries mostly handle accessibility for the disabled, then interaction methods and focus management. The rest is left to developers, which includes settings that are more visual in nature, like screen sizes, light/dark mode etc.

In general, ARIA attributes and roles are used to provide information about the interaction of a complex widget. The libraries here sprinkle this information onto their components before giving them to be styled.

So, in short, these are low-level UI libraries that handle the functional part of the UI elements, like accessibility, keyboard navigation, or how they work. They come with little-to-no styling, which is meant to be overridden.

Radix UI

React Aria

List of the frameworks:

• Radix UI
• Reach UI
• React Aria, React Stately (by Adobe)
• Headless-UI

Pros:

• Gives perfect accessibility and functionality
• Gives the flexibility to create composable elements
• Unopinionated styling, free to override

Cons:

• Can’t be used for a rapid development project or prototyping
• Have to understand the docs thoroughly to continue development at a normal pace

Where would you use these?

• Websites like news or articles won’t require this.
• Applications where accessibility is more important than styling and design (Government websites, banking, or even internal company apps).
• Applications where importance is given to both accessibility and design, so customizability to these components is preferred (Teamflow, CodeSandbox, Vercel).
• Can be paired with Vanilla libraries to provide performance with accessibility.
• Can be paired with utility-style libraries to provide relatively faster development with accessibility.

Utility Styled Library / Framework

These types of libraries allow you to style your elements through their interfaces, either through class names or component props using composable individual CSS properties as per your requirements. The strongest point you have with such libraries is the flexibility of writing custom CSS properties. With these libraries, you would often require a “wrapper” class or components to be able to reuse them. 

These libraries dump these utility classes into your HTML, impacting your performance. Though there is still an option to improve the performance by purging the unused CSS from your project in a build step, even with that, the performance won’t be as good as css-in-js. The purging would look at the class names throughout the whole project and remove them if there is no reference. So, when loading a page, it would still load CSS that is not being used on the current page but another one.

Tailwind

Chakra UI

List of the frameworks

• Tailwind
• Chakra UI (although it has some prebuilt components, its concept is driven from Tailwind)
• Tachyons
• xStyled

Pros:

• Rapid development and prototyping
• Gives flexibility to styling
• Enforces a little consistency; you don’t have to use magic numbers while creating the layout (spacing values, responsive variables like xs, sm, etc.)
• Less context switching—you’ll write CSS in your HTML elements

Cons:

• Endup with ugly-looking/hard-to-read code
• Lack of importance to components, you would have to handle accessibility yourself
• Creates a global stylesheet that would have unused classes

Where would you use these?

• Easier composition of simpler components to build large applications.
• Modular applications where rapid customization is required, like font sizes, color pallets, themes, etc.
• FinTech or healthcare applications where you need features like theme-based toggling in light/dark mode to be already present.
• Application where responsive design is supported out of the box, along with ease of accessibility and custom breakpoints for responsiveness.

Pre-styled / All-In-One Framework 

These are popular frameworks that come with pre-styled, ready-to-use components out of the box with little customization.

These are heavy libraries that have fixed styling that can be overridden. However, generally speaking, overriding the classes would just load in extra CSS, which just clogs up the performance. These kinds of libraries are generally more useful for rapid prototyping and not in places with heavy customization and priority on performance.

These are quite beginner friendly as well, but if you are a beginner, it is best to understand the basics and fundamentals of CSS rather than fully relying on frameworks like these as your crutches. Although, these frameworks have their pros with speed of development.

Material UI

BootStrap

List of the framework:

• Bootstrap
• Semantic UI
• Material UI
• Bulma
• Mantine 

Pros: 

• Faster development, saves time since everything comes out of the box.
• Helps avoid cross-browser bugs
• Helps follow best practices (accessibility)

Cons:

• Low customization
• Have to become familiar with the framework and its nuisance
• Bloated CSS, since its loading in everything from the framework on top of overridden styles
• 
  

Where would you use these?

• Focus is not on nitty-gritty design but on development speed and functionality.
• Enterprise apps where the UI structure of the application isn’t dynamic and doesn’t get altered a lot.
• B2B apps mostly where the focus is on getting the functionality out fast—UX is mostly driven by ease of use of the functionality with a consistent UI design.
• Applications where you want to focus more on cross-browser compatibility.

Conclusion:

This is not a hard and fast rule; there are still a bunch of parameters that aren’t covered in this blog, like developer preference, or legacy code that already uses a pre-existing framework. So, pick one that seems right for you, considering the parameters in and outside this blog and your judgment.

To summarize a little on the pros and cons of the above categories, here is a TLDR diagram:

Pictorial Representation of the Summary