It's 2023 and I Can Finally Talk About Atomic CSS

Libraries like Tailwind became quite popular and their utility-first—aka atomic classes—approach was an interesting paradigm shift in CSS. Many developers love it, and it's understandable why.

However, we tend to forget that the core of this technique isn't new. Way before Bootstrap, we all had our small CSS snippets copied from project to project with similar classes.

In this session, we'll discuss the evolution of scalable CSS, walk through the limitations and drawbacks of Atomic CSS, and also figure out where this concept can be beneficial.

This talk has been presented at React Summit 2023, check out the latest edition of this React Conference.

Watch video on a separate page

FAQ

The main challenges include the lack of built-in namespaces, CSS being stuck in the past due to backward compatibility, its unpredictable nature for humans due to style merging from different sources, and its static nature which struggles with dynamic web changes.

Atomic CSS differs from inline styles in that inline styles are more costly for browsers to process and cannot handle media queries or pseudo selectors. Atomic CSS, on the other hand, uses utility classes that act as a single source of truth and are less performance-intensive.

Common misconceptions include comparisons with inline styles, beliefs about HTML bloat, and concerns about breaking the separation of concerns. However, atomic CSS actually minimizes bloat with compression algorithms and maintains a clean separation by assembling stylesheets in HTML.

The speaker criticizes atomic CSS for potentially leading to bad claims about CSS modifications, the difficulty of converting atomic CSS back to more complex CSS structures, and the initial lack of support for certain CSS features and dynamic class generation in tools like Tailwind.

Atomic CSS can lead to excessive DOM sizes by focusing on classes over markup, sometimes resulting in nested structures that are not semantically meaningful. However, this is more a result of misuse rather than an inherent flaw of atomic CSS.

Tailwind CSS offers on-demand style generation, which ensures only the necessary CSS is generated and used. It supports modern tooling for type safety and stylesheet composition, enhancing developer productivity and ensuring efficient style management.

Tools recommended include Tailwind CSS ClassNames for type safety, the Tailwind merge utility for resolving class conflicts, and various plugins for improving accessibility and managing stylesheet complexity.

The 'Apply' utility can lead to the mixing of concerns and potentially undo the benefits of atomic CSS by allowing developers to incorporate custom styles that may conflict with the atomic utility classes.

Atomic CSS is well-suited for component-driven development environments like React, Vue, and Svelte, where it can streamline styling processes and enhance component modularity and reusability.

Choosing atomic CSS involves considering trade-offs such as ease of use versus potential for excessive DOM size, the learning curve associated with utility-first CSS frameworks, and the need for careful management of CSS classes to maintain clean and maintainable codebases.

Matheus Albuquerque
Matheus Albuquerque
30 min
06 Jun, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Today's Talk discusses the traditional problems of scaling CSS and the advantages of Atomic CSS, including better performance and handling media queries. Concerns about HTML bloat and the breaking of separation of concerns can be addressed. Tailwind CSS has limitations in class detection and can lead to excess markup. Challenges include component exploration and querying, as well as tweaking CSS. Type safety is now addressed with tools like Tailwind CSS ClassNames and TypeWind. Style sheet composition and Atomic CSS and JS are important for building UI kits. Considerations for Tailwind CSS include its suitability for component-driven development and potential limitations with Web Components.

1. Introduction to Atomic CSS and Scaling Issues

Short description:

Hello, everyone. Today, we're here to discuss the traditional problems of scaling CSS, the lack of namespaces, CSS being stuck in the past, its unpredictability, and its static nature.

Hello, everyone. It is great to be here in React Summit, joining all of you online. And today, we're here to finally talk about atomic CSS.

Before we move forward, this is me. You can find me everywhere as wide combinator. I'm a Senior Software Engineer at Medallia, a mentor at TechLabs, and a Google Developer Expert in Web Performance. And the link for this presentation deck you can find under this QR code and the links to many other presentations I also have.

So, today we're here to discuss, first, the traditional problems of having CSS at scale. Some of what I consider to be bad taste on the topic of atomic CSS, tailwind, et cetera. And then what I actually consider to be bad and ugly about atomic CSS as a methodology. But we're also here to discuss how you can address some of these problems, and then we'll have some closing thoughts about everything.

Starting with problems of scaling CSS, I guess that the cliche is the first one. So, the lack of namespaces. So it started as a feature in CSS to enable portability and the cascading part of CSS, but if you're doing other programming languages, you notice that if you lack built-in namespaces, you get to have problems at scale. And throughout the history of CSS, we've had different technologies trying to address that like CSS in JS and others that basically would use VLTools to intercept and generate scopes automatically.

Another key problem which I consider is CSS tends to be stuck in the past. That's mostly because you have to maintain backward compatibility as a top priority when you're building new features for the language, for the spec. And because of that, it's not always feasible to just go back in the past and undo bad decisions. And that happens because, yeah, you have to keep adoption rate in mind, you have to keep browser support, everything when making changes to the language.

Another thing is it's unpredictable to humans in a way. So the way CSS works is it merges styles coming from different sources, different origins. I'm talking like inline styles, internal and external stylesheets, a whole bunch of selectors you have, et cetera. And to properly figure out how this happens, you have to be aware of the specificity calculations, how inheritance work and many others. And that's quite complex for humans. So in the end, it's hard for us to predict how those styles are resolved.

And last but not least, CSS has a static nature. So, it's still primarily a set of static layout rules with limited support or dynamic and variable styling. And I know we have logical functions. I know nowadays we have CSS variables, so it's getting better and better. But what I kind of notice is that it still struggles to keep up with the demands of dynamic web pages, where you have theming and dynamic changes, that kind of thing, coming from data from JavaScript and et cetera.

2. Atomic CSS: Advantages and Addressing Concerns

Short description:

So, Atomic CSS is often compared to inline styles, but it offers advantages such as better performance, handling media queries and pseudo selectors, and a well-defined API. Concerns about HTML bloat and the breaking of separation of concerns can be addressed with modern compression algorithms and a shift in perspective. By using atomic CSS, you can assemble pieces from a style sheet in the HTML, providing an API and avoiding impractical scenarios. With modern tooling, atomic CSS can alleviate concerns and bring new benefits.

So, that's challenging. So, I'd say that those are the four main concepts we have.

And now, moving on to Atomic CSS, the core of this talk. So, I will try to do a good, bad and ugly approach here. But, if you're probably tired of listening to this multiple times, I wanna show you, I wanna do a different take here. And I'm gonna start by going through what I consider to be actually bad takes people have about Atomic CSS. And the first one is, they compare a lot with inline styles. But the thing is, first, inline styles are really costly for the browser, because it's just really costly to convert. The strings you have onto the style attribute and to native representation in the platform. And also, by adding those multiple styles, you are adding multiple reflows. Also, inline styles can't handle media queries, pseudo selectors, and other features you have. And one key point here is, mostly when you're doing inline styles, you're gonna have to follow preexisting definitions as you would have with utility classes, where you have a very well defined API, and those act as a single source of truth.

The other point we listen a lot of there is, it generates HTML bloat, and that's bad for performance. But, the thing is, we nowadays have a lot of compression algorithms, like GZIP, and we even have techniques made to handle duplicate strings like the deflated algorithm. And, I also drew another perspective in that. That is, the more a selector is repeated in the style sheet, actually the more work a browser has to do to resolve those styles. So, in that sense, semantics CSS and others could also be adding a bloat.

Then comes the concern of separation of consorts. And, a lot of people point that atomic CSS by definition break separation of consorts, but I think that we should kind of shift our view and see that the style composition is being performed in the HML, but you're not doing style align with the height, those attributes. Actually, what you have are just pieces from a style sheet that are assembled in the HML. So, the HML is kind of the consumer of the CSS you created. So, you have an API in that sense. And, also I think that this kind of represents this very extreme vision of what separation of consonants is all about. And, that's dangerous because that can lead to very impractical scenarios. And, this is even addressed, for example, in the Vue.js documentation where they point that a lot of people make a confusion between separation of consonants and separation of bio types, for example. And, in an analogous way, you have a bunch of other things like redesigning and faming becomes challenging or you end up with a lot of unused CSS or it's hard to use what's available, it's hard to know what's available there for you to use or even you have to learn a whole other language on top of CSS. And, the list is huge. Point is, I think that those are concerns kind of from, coming from the past. And, if we look at tail end and modern tooling we have in the scene of atomic CSS these days. We have the potential to alleviate most of those concerns and even get new benefits.