Atomic CSS with Mathues Albuquerque
===

Paul: [00:00:00] Hi there and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket provides AI first session replay and analytics which surface UX and technical issues impacting user experiences. Start understanding where your users are struggling and try it for free at logrocket. com today.

My name is Paul and joined with us is Mathias Albuquerque, . Here to talk about atomic CSS. Atomic CSS has always been ~kind of ~one of those interesting things. It's like, Hey, ~do I,~ do I use Tailwind? Do I use Atomic? And I'm so excited to dig into not only this comparison, but what Atomic CSS is and what it can bring to organizations.

Big and small that's currently being used out there in the wild. So welcome to the podcast, Mateus. Excited to have you.

Matheus: Hey, it's great to be joining again, like one of my favorite podcasts.

Paul: Let's go. We love hearing that. ~Uh, ~so let's hop right into talking about Atomic CSS. ~I mean, ~what is it? I did hint a little bit. We're going to do some [00:01:00] comparison with Tailwind and use that as ~sort of ~like a lens to look at it. But what's the elevator pitch if you were to tell somebody who has never heard of Atomic CSS?

Matheus: Cool. So it's basically this CSS architecture model that focuses on creating those small single purpose utility classes where that you're going to use them to apply styles. So you're. ~Uh, ~like probably most of the classes representing a single CSS property and value like text center or margin top for,~ uh,~ padding bottom to this kind of thing.

And yeah, it's getting a lot of attention recently, ~I guess, ~because of things like tailwind that are getting more and more popular, but the whole idea itself isn't that great. Quite new. Like we have this atomic CSS naming since 2013, for example. And even before that with CSS preprocessors, we were doing something similar, for example, but that's maybe a little bit more than just an elevator pitch, but that's what it's all

Paul: No, it's [00:02:00] great. ~So, ~so are you an atomic CSS user Through and through? Are you a CSS Afic auto? ~You know, ~I'm very curious what compelled you ~to, ~to talk about Atomic CSS 'cause we're not just talking about it here on this podcast. ~Uh, ~you also had a talk that,~ uh,~ is up on YouTube. ~The, the name of the video is, uh, lapsing on my memory right now, but yeah.~

What got you into it? Uh, do you love CSS.

Matheus: Yeah, so ~that's, uh,~ that's the thing. ~Um, I'm,~ my front end developer persona leans more towards performance and architecture and a little bit of accessibility. But throughout the years,~ uh,~ I've played and pushed production code with,~ Um,~ Atomic CSS, but also with CSS preprocessors, all sorts of them,~ uh,~ and et cetera.

And the reason why, so the title of the session,~ it's,~ it's 2020 and then year like 2023, 2024. And I can finally talk about Atomic CSS. And actually what prompted me ~into this, uh,~ into having this session is that I figured that in the recent couple of years, and [00:03:00] that's probably a lot because of tailwinds,~ uh,~ growing popularity,~ uh,~ just so much discussion going on.

And not only this, but ~it's, it's,~ it really turned into a bigger side thing is like, which team you identify, either you love it or you hate it. I was ~kind of ~tired of this whole debate on how a lot of people were conducting the debate on the topic. So, it's not even that I particularly love it or hate it, it's more like I wanted to just bring a different debate on the matter.

Paul: talk about it. You can finally talk about it.

Matheus: Silence.

Paul: on things that are incorrect, because that is usually some of the most defining contrasting,~ uh,~ lines and contours to understand what we're discussing.

So [00:04:00] primarily, why would comparing this to an inline style be misguided? And why might people initially think about that? ~You are,~

Matheus: ~Yeah. So I've, I ~I'm also~ into the,~ on the side of,~ uh,~ bringing the Berg arguments and like one of the first section of the talk is actually, let's get a couple of things out of our ways. And,~ uh,~ the reason why I mentioned this line in line styles is because. That's like top three arguments people make online,~ like,~ Hey, if you're doing atomic CSS with something like tailwind or similar, you might as well just do inline styles as you would do with regular inline styles.

~But that's the thing is that, ~and I feel like a lot of developers, they just feel that atomic blurs this line between embedding some information ~into the, ~into the HTML. But I think that First, why it's a bad argument is that they're just not the same to begin with. Inline styles have a performance,~ uh,~ implication that they cause reflows when you're changing this.

And also with inline styles, ~you're not, ~you don't have a guarantee or most of the times you don't, that you're, Picking something from [00:05:00] a predefined set of things. And that's something you have when you're doing Atomic CSS. So you have a very, very clear API. This API could be Taewin, but it could just be Tashans or whatever is the Atomic CSS that you have.

And you're picking from something. So you have a finite SDK of things that you can build from. And I think it takes a little bit of a mind shift to, ~you know, ~Start thinking about, yeah, this tile composition is performed in HTML, but it's not like you're using a line or style or width or height attributes.

It's like your HTML is just assembling pieces from a style sheet that is written in CSS. So your HTML is just a consumer. ~So, yeah.~

Paul: said, focused on performance a lot. So maybe for folks who aren't focused ~on, ~on performance. What is a reflow? Why is that bad? And I think that's interesting because it definitely helps paint the picture of This is not necessarily inline. It doesn't do this thing.

Matheus: ~So, ~repaints, [00:06:00] reflows, and,~ uh,~ a lot of these other rethinks that we know from the browser basically about re triggering,~ uh,~ what the life cycle that goes in when we're, we have our browser engine. So that's not about JavaScript itself. It's ~about, ~about the browser engine. And when you're changing inline styles, you, these need to be recalculated.

So that's the performance gotcha there. ~They're like~ inline styles are not the only things that could be triggering repaints, reflows, and general recalculations. There are CSS things and other JavaScript things you can do, but that's ~like ~one key differential between using a finite set of class names and between just changing,~ uh,~ what's the style attribute.

And by the way,~ with, ~I'm talking about the style attribute,~ uh,~ when~ people,~ for example, you have a, an element and then you set style equals, and then you start writing things like,~ uh,~ with a tie, this kind of thing.~ Not in, ~not in the React fashion ~of, ~of using this tile prop, [00:07:00] for example.

Paul: So when people are taking, we can call them like shortcuts or aliases and putting them into right into your HTML code,~ um,~ writing their styles, some folks will say, and this is the classic tailwind argument that you find on every single YouTube video I've created. Where's the separation of concerns? How do you view that?

Is this a problem? Is it something that's helpful? Not helpful? Does it speed up development?

Matheus: Yeah, so that's funny because,~ uh,~ I think that people nowadays, they just have a ~very, ~very dogmatic and even impractical vision of what's actually separation of concerns. ~And, ~And by the way, that's not only a problem that happens with Atomic CSS. ~Uh, ~when JSX was out there in React like a decade ago, people would hate React because JSX would break separation of constants.

And if,~ uh,~ I think it's too severe in their documentation. They even have a section of the documentation with ~like, ~Separation of concerns doesn't mean separation of file [00:08:00] types and this kind of thing and breaking some of,~ uh,~ visions that people tend to have ~on, ~on separation of concerns. So I particularly, I see,~ uh,~ where the argument could come be coming from, but I don't think that it's,~ uh,~ a bad thing for atomic CSS or etc.

It's more again about the mind shift. So ~you, you, ~you have to think of your HTML and your markup in general as the consumer of your CSS. ~And, ~and ~that's, ~that's about it. So it's not like you're just revisiting ~which concern, ~how these concerns are and how they're separated, but you're not in my opinion, breaking it.

Silence.

Paul: in the general development cycle ~or, ~or code paradigms. ~Um, ~so if we could start with encapsulation, like what is encapsulation and how does this style of writing, for [00:09:00] example, you know, be and then putting parentheses and putting a hex color in there for the background,~ how,~ how does that improve encapsulation or does it?

Improve encapsulation. What is encapsulation?

Matheus: Yeah, so I think that when you have the sort of approach, you have style contained in those classes and only applying to those elements using those classes. Most of the times,~ uh,~ and of course it could happen, but you don't really have to worry about accidentally breaking something when modifying one specific rule in one specific class, which is like something we're quite used to having to worry about in other CSS methodologies.

And I think that,~ uh,~ another,~ uh,~ great,~ uh,~ issue of CSS that throughout the years with always trying ~to, ~to,~ uh,~ Addressed with many different,~ uh,~ ways of organizing CSS and not doing CSS ~is, ~is how to handle specificity and et cetera. And I think that with atomic slash utility first,~ uh,~ approach, we have each element having its own glass,~ uh,~ for [00:10:00] its own needs.

And I think to summarize, I think you end up with better encapsulation and ~you, you have. ~You minimize your specificity related issues that often come when you see yourself writing complex CSS selectors, for example, and things like this.

Paul: Kind of decreases the damage zone or like the edge cases of random CSS fliner. Okay, got it. Got it.~ Um, what it, I mean, ~this kind of bleeds into consistency.~ Uh, ~do you think atomic CSS improves consistency and how have you seen consistency? been improved by using this pattern.

Matheus: ~So~ I think that actually consistency is one of the main selling points, or it could be at least one of the main selling points ~for, ~for atomic CSS. But at the same time, I don't think that it comes,~ um, it, it, ~it just happens if you're adopting it. And of course that having this.~ Uh, ~predefined set of things that you can just,~ uh,~ reuse across your different components.

If [00:11:00] you're doing React, for example, will help, but I think that there are other practices that will make you see ~the, the, the outcome, the,~ the consistency outcome. And I say this because I've been approached by people who were, and that those was literally after one of my sessions and CSS, ~and they were struggling to build a, uh,~ They were in the experimental phase building an internal implementation for our design system, and they were discussing different approaches to it.

So there we could go with atomic CSS, we could go with semantic CSS, and etc. And a lot of people on the team were ~kind of ~Not really into Atomic CSS because they couldn't see how just by using it, it would map automatically to consistency. But then~ I,~ when we started actually some hands on and checking the code and their proof of concepts and everything, I realized that for example, ~their approach wasn't really.~

~So~ if ~you know, for example,~ chat CNUI that is like super popular up there and et cetera. Over there, you got a ~really, ~really good example ~of bringing, ~[00:12:00] of building consistent UI components,~ uh,~ a consistent design system with tons of UI components on top of Tailwind, ~and,~ but that's not only because you're using Tailwind, but you're using a lot of utilities,~ uh,~ to work with Tailwind, you're using things like CVA, and so ~just, ~just a huge layer of tooling around it that helps,~ uh,~ And I think that if you combine this really well, then you end up with the consistency you're looking for.

Okay.

Paul: Is consistency something that comes before you even write the CSS or is consistency something that also bleeds into the actual implementation paradigms? And if so, what are some of those paradigms that help push the envelope with consistency?

Matheus: ~Um, that's, ~that's a good question to be honest. ~Um, ~I don't know. I think it, it perhaps really depends on the stage of your project or product or code base,~ uh,~ that you're in. ~I mean, if I feel like, uh, it's, it's.~ Consistencies, a lot of times it's just like general technical debt. ~It eventually,~ even if you make great [00:13:00] technical decisions along the way, eventually you might end up with consistency issues, for example, because of the ecosystem or other challenges.

~Uh, ~at a huge company, for example, where. We had a great,~ uh,~ and very well established design system, but the issue is ~throughout, uh, uh, ~throughout the journey, because we weren't enterprise. So throughout the journey, we had a lot of acquisitions and then,~ uh,~ we ended up with different design systems that at the end, they were trying to implement the same thing, but even though they seemed, they had, they were all based on the same figment file, for example, because there were different code bases using different technologies.

It was just so hard to keep them consistent. So I think that there are a lot of environment or ecosystem factors that are not even about the technical decisions you make that could impact consistency or any other similar technical debt.

Paul: Got it. Yeah. ~I mean, ~it depends. ~It's the,~ it's a very common [00:14:00] answer. ~Um, ~so ~on, on,~ if you go to the atomic CSS website,~ which is it a CSS dot. Devacss. io Yeah~

Matheus: ~been a while, but I think, I think, yeah, it was the first implementation of it. ~

Paul: ~Yeah, well, there's a ~there's a quote even by one of the creators of Tailwind on there saying, ~you know, ~Atomic CSS ~We finally got~ as the Tailwind group we finally got to kind of like what these guys were doing for 10 years and They were ahead of the curve and you know, they're two separate areas of concern.

You could think of for two different personas you might target and what you're trying to accomplish. And so with that being said, ~you know, they're~ each has their own uses, each has their own similarities and differences. And they're both great frameworks. But there are some things that perhaps People would criticize Tailwind for missing in terms of specificity, a very particular CSS behavior that you might not be able to do easily with Tailwind.

Do you think Atomic CSS fills that gap? And do you think that's a fair argument to make about one of the differences between Tailwind and Atomic?

Matheus: ~So it's been, uh,~ to be honest, it's been quite a while since I last used,~ uh,~ the Atomic CSS library. So ~I don't know, uh,~ I don't know how they're up to tail [00:15:00] end ~or, ~or other libraries like or other utility first,~ uh,~ cloud solutions. But I think that Tailwind, for example, I've seen a lot of criticism,~ um,~ throughout different years on Tailwind, how they were lacking feature A or B from CSS, for example.

So, Hey, CSS now has this min or max function, or Hey, CSS has this new thing. ~So. ~I feel like,~ uh,~ this sort of thing will always happen to do it. And I'm curious if atomic CSS also likes those, but I think it's just the nature of the things that~ if they're being, ~if something gets implemented to CSS, there will be a curve.

~Uh, ~to take that until it gets implemented into the solution you're using. ~Um, ~I think that it's just that so many people, and this probably even applies to other CSS preprocessors. So back in 2011, 12, 13, when CSS preprocessors were still super popular, we had less [00:16:00] SASS and et cetera. Every new CSS feature also took a while to get to these precesses, and I think that what happens at Tailwind is just the same.

It's just that everyone is looking at tailwind, so every new feature,~ it, it, that it,~ that Tailwind doesn't have ity with CSS,~ it,~ it, it's just gonna be another bullet point against it.~ I mean, you,~ I've seen people, for example, it's even on GitHub, right? ~Uh, ~specific plugins to, to address those. So I think Clamp for example, is a function that even though Tailwind still doesn't plugin that there's a plugin on GitHub that you can use, for example.

~So, ~yeah, it's just super hard to catch up with an ever evolving API.

Paul: ~Do you feel like, uh, Atomic CSS and Tailwind differ at all in their ability to Be further on that curve, whether that be in the actual library itself, the plugin ecosystem, the developer ecosystem.~

Matheus: ~Um, I don't know, because again, it's been, it's been a while since I last used Atomic CSS. It's of the, the original library. So, yeah. ~

Paul: ~Uh, ~

Matheus: ~what if people are moving, from traditional CSS into something like Atomic What do you think is o top challenges thatnumber one or second ilke~ What if people are moving from traditional CSS into something like Atomic. What do you think is o top challenges thatnumber one, or second ilke.

Paul: that developer persona would [00:17:00] encounter when they're trying to begin using it. And I would love to focus on somebody who is very accustomed to CSS, maybe not like a junior developer, somebody who's been in the field for a little bit, they've been using CSS,~ what ~what would be part of that learning curve?

Matheus: ~Yeah, so ~I myself, for example, and I've heard this from a lot of other people. ~Um, ~especially ~when,~ back in when the ecosystem wasn't really great. So now ~you, it's,~ you can even have out of completion on things and et cetera. But I remember,~ um,~ my first time, and not only with Taewon, but back when Tashawn's or other solutions, I found myself having to refer a lot to.

to documentation to do something I knew how to do before. So I, okay. I know how to do this with CSS, but I don't know exactly what convention they're using here to name this specific properties,~ uh,~ at this attribute versus valid thing. So I find myself having ~to, ~to refer a lot ~to, ~to [00:18:00] documentation. ~Um, ~I think that depending on.

The whole ecosystem around you, you may also have different challenges. I've noticed ~like, uh, ~people who are used to writing web components or who for not using,~ um,~ react or other view libraries,~ they, they.~ They have a general,~ uh,~ different impression of the front end ecosystem. And then they will find it tricky to use Atomic CSS ~with, uh,~ or to win with,~ um,~ Shadow Dawn or with something.

So depending on where you're coming from, the same persona of a CSS writer,~ uh,~ could have different challenges and. Then also your code base. So if you're starting a code base from scratch, then,~ uh,~ you don't have a lot of challenges, but if you're maintaining a huge code base, enterprise scale, et cetera, and you want to gradually migrate it, then you have a whole other set of [00:19:00] challenges,~ but yeah.~

Paul: ~Right? If you are in that enterprise situation, and you're trying to migrate over, And we can focus on, you know, this like class name, uh, sorry Matthias, what would you call this paradigm of Tailwind and Atomic of, you know, using class or class name equals and putting a string in there? Is it, um, Utility, utility based,~

Matheus: ~Yeah.~

Paul: ~right, okay,~

Matheus: ~first.~

Paul: ~utility first, ~so if you are moving to a utility first ~sort of ~paradigm, how do you take a bunch of existing CSS and redefine that strata of, hey, here's a boundary of,~ of, ~of the container ~and, ~and here's like where we put the background colors and here's how everything cascades, because that might seem a little daunting if you have a ton of CSS already in the bucket.

Matheus: ~Yeah, yeah, that there are, uh,~ interesting enough, there are some tools that work based on static analysis, and ~they. Uh, ~there are different tools, ~but I think that, um, I don't even, I don't remember the name, but I even have a screenshot of it in the session, but~ there is one that, for example, it scans,~ uh,~ traditional semantic CSS and it tries~ to build, uh,~ to convert it to tailwind based classes.

Of course, that does depend a lot ~on, ~on, side effects from those of your current CSS code base. So you have, if you have a lot of selectors overriding each other, and if you have a lot of important things, if you're playing a lot with magic numbers, for example, that work in very specific situations, I think it makes it,~ uh,~ way [00:20:00] harder for any static analysis tools to do its job.

But overall, I think that this could help a lot. And then restraining the scope of what you're doing, just ~like, ~for example, I've seen huge,~ uh,~ applications go from Angular or Backbone to React because they were broken into smaller,~ uh,~ applications, and then they started doing,~ uh,~ micro frontends, for example.

So if you can. Reduce and narrow down the scope of the migration you're trying to do and. Maybe start with the parts that are, that, that tend to be less side effectful, for example. ~Uh, ~I think that this could help.

Paul: What if you're starting a project fresh and ~you know, ~you have a couple of components, five, 10 components, you have one or two pages. What are some of the do's and don'ts of using utility first styling? So you don't put yourself into this hole of oh my gosh Everything's bleeding onto one or another and you go to change something and then it's ~I mean ~that is that's a hellish place to be In if [00:21:00] you don't plan it out, right?

So I would love to hear some of the do's and don'ts.

Matheus: Yeah. So I would say invest a lot in tooling. So for example, a lot ~of, ~of things that people complain about utility first, no matter tailwind, atomic, et cetera, they can be addressed with tooling. ~So, ~For example, you can use linters and formatters to improve readability, which is a fairly proper,~ uh,~ thing that people complain about.

And I agree. ~I mean, ~if you're debugging some code and you see that long multiple line strings. ~Uh, it's, ~it's hard to reason about that. ~So, ~but there are tools that another thing is I've seen people complaining a lot, people coming from things like material UI or even CSS and JS and complaining that they missed some TypeScript support.

So there are nowadays plugins that can bring in, that can make your atomic CSS more type safe. So use this kind of thing. ~Uh, ~also. [00:22:00] There's a number of people who complain about the tag soup that you end up with if you're just doing atomic CSS. And I myself, I don't think that atomic CSS maps to having a tag soup and a bloated HTML.

But the thing is, If ~you're, you,~ you do end up a lot of times just,~ uh,~ creating divs and wrapper containers and things. And it, because it's a lot of the mentality, Hey, I need somewhere to insert this class because I have this class available for me. So ~let, ~let me just create another div. ~So, ~and.

Paul: Classic

Matheus: yeah, I myself did that in the past.

~So, ~but the thing is this could be,~ uh,~ bad for your accessibility, for example. So keep in mind to have automation tools or accessibility. So I guess that the biggest,~ uh,~ do is revisit all of the issues that people have raised about atomic slash utility for CSS and see how they can be mitigated by tooling [00:23:00] and,~ um,~ I think that perhaps one dot and, or one category of dot is,~ um,~ in Taewin, you have things like,~ uh,~ you have,~ uh,~ the apply directive that basically allows you ~to, ~to write your

Paul: Whatever

Matheus: yeah, do whatever, and even Taewin, he advises against it.

Of course, there are for existing huge code bases that are in the process of migration, it is acceptable. And perhaps even the sweet spot that you find some hybrid, but if you're starting a code base from scratch, then try to stick with just utility CSS with just the class names ~and, ~and try to avoid this hybrid approach unless you really have to as your project scales.

[00:24:00] Okay.

Paul: kind of like are in its own bubble. But when you have it in your JSX or in your HTML, ~you know, ~you don't want to do something more specific in a parent component and then have to like pave over it using a bunch of BS ~later ~later on.

So how can you begin to grapple with that? Should you think about the HTML structure first? Should you think about the CSS structure first? Or is there another ~like ~guiding principle? to not end up in that hole.

Matheus: ~Yeah, ~I tend to recommend that you always think your markup first, even though I know that it's not a very practical thing to do always. But if you think markup first and go from there, I think you just get semantic HTML from day zero, which is great because I myself on a daily basis address a lot of,~ uh,~ accessibility issues that are not caused at all by any [00:25:00] CSS strategy, but they are caused because of mass markup or bad area, people say that no area is better than bad area.

~And, ~and I definitely understand that. So I think that if you think markup first,~ uh,~ if you can, then,~ uh,~ And then style things from there. It just tends to be easier,~ uh,~ rather than having to revisit a lot of things that exactly are so dependent in their hierarchy and the prefectures are just so complex.

Paul: And are there any significant performance impacts that you might want to preemptively consider or think about when using,~ uh,~ utility for styling? Because in your mind, you're like, okay,~ it's,~ it's in the markup, it's there, it's static, like it doesn't really matter. ~Uh, ~or are there things that you should take into account in order to not do I'm going to reference the reflows.

Uh, as sort of like an example here is to not end up with those things. Not trick yourself.

Matheus: ~Yeah, so I've, ~I've [00:26:00] seen,~ uh,~ one problem that usually comes along atomic CSS, but it's not caused by it, but it's exactly when you have ~this, uh,~ those, Huge tags,~ uh,~ and huge,~ uh,~ nested disk that you keep nesting then ~so that your, ~so that your markup will fit your,~ uh,~ utility classes. So this is not a problem if you have a small app, but if you have ~like ~a really, really huge app, and if your customers, like if your user base.

~Uh, ~if they're using like,~ uh,~ low end devices and this kind of thing,~ uh,~ there's even,~ um,~ a case study on this, it's called the inequality gap. So it basically compares like the cost of your done versus,~ uh,~ certain device types that, ~so I think that.~ But again, that's not an atomic CSS problem. But the point is, ~if you're, ~if you're not minding ~your, uh,~ the amount of HTML that you keep adding so that it's going to fit your utility classes, then, and you have like [00:27:00] lists of, with thousands of items and that are not virtualized.

And that's it. So this kind of thing, if ~you, ~you might end up with a huge don and then. This is a performance problem. Also, there are a few other problems that were more common in the past. And then you would have to use things like purgers to eliminate code that is not being used in this kind of thing.

But this was an issue years ago. If you're using modern tailwind or other technologies like Uno CSS, all of this, most of them, they will just ship what you're using in the new, don't need a purger or anything like this. But yeah, performance ~is, ~is always a culture thing. So keep an eye on ~auditing, ~auditing tools,~ uh,~ check your Chrome developer,~ uh,~ tool stab for unused CSS and this kind of thing that they have reflected as the unused bytes.

And you can see if class names are not being used and et cetera. ~So, yeah.~

Paul: ~Uh, well, ~Mateus, we are running up on time here,~ um,~ even though ~I, ~I would love [00:28:00] to learn more about using utility for styling,~ uh, create like in,~ in a responsible manner because me myself, Oh my gosh, I end up with some awful spaghetti code because ~I'm not, I'm, you know, ~I'm not a CSS expert by any means. So we could keep talking ~for, ~for quite a while, but I'm going to put you on the spot now and ask.

Maybe kind of like a hot take, a hot question. Do you think that utility first styling, such as with Atomic CSS, should be the de facto way to build an app in 2024?

Matheus: Wow, that's a tough one.

Paul: I know, sorry.

Matheus: Now,~ um,~ now ~I, ~I tend ~to, ~to run from these defective,~ uh,~ solutions and actually, for example, a lot of people, ~they were. Um, ~on Twitter, they were saying that, for example, you should have TWAIN built ~in, ~in Chrome so that,~ uh,~ it would just work and that TWAIN should be made part of our spec and this kind of thing.

~Uh, I don't think, uh,~ I don't think that's the case. I myself,~ uh,~ whenever I'm starting a site project or some small thing, I've been using it. [00:29:00] So for the last two to three years, it's been my go to solution. ~But I don't, uh, yeah, um,~ philosophically speaking, I'm against,~ uh, this, ~this kind of, yeah, it should be the way of doing things.

And actually, I think that a lot of people saying that it should be the right way is ~kind of ~what causes this phenomenon of having, okay, if you don't like it and some people are saying it's the only right way, then you tend to hate that thing and et cetera. ~So. ~Yeah, I think that people pushing it so hard one way is exactly what causes people on the other end to, okay, you love it, but I hate it and I'm never going to use it.

And so,~ so, ~yeah, exactly. Exactly. ~So, ~but I, myself, it's been my solution for new code bases for in the last two to three years, for sure.

Paul: Yeah, I think it's really funny you can listen to some youtubers talk about and they're like~ Who cares ~who cares just ~build ~build cool stuff, you know ~build ~build a website, ~you know, whatever ~whatever works for you Well, thank you. Thank you for your opinion there. Sorry for putting you on the spot

Matheus: Now that [00:30:00] works.

Paul: what you're working on,~ uh,~ side projects or any other,~ uh,~ blog posts you might have about CSS, Atomic CSS, performance and styling, where can folks learn more?

Matheus: ~Yeah, so I'm, I'm, uh,~ you can find me anywhere online as white accommodator. So why the accommodator, why the ladder? So that's on my website, I'm on Twitter, on GitHub, everywhere, white accommodator. So all my sessions go there. I admit I don't blog a lot, I have ~a lot, ~a lot of drafts that never went published, but that's the good thing about sessions.

You cannot postpone them. So I have sessions on the topic and yeah.

Paul: Awesome. ~Well, ~it was a pleasure having you and we'll look forward to having you on in the future to dig more into styling and learning about performance. It was great to have you.

Matheus: Thank you.