Do we have a name for these types of libraries that use a bunch of classes to write less css? :)
My primary concern with these types of libraries are like you mention, the longer class definitions, and that they move the payload from the CSS onto the HTML.
Meaning even tho the library is smaller, the overall payload for a page may not be.
Personally i really like using the BEM + Atomic Design approach but with mixins for everything but atoms, that way each component is self contained, and when packaged i only get the used styles.
The douple definitions this generates, are then handled by strong gzip/brotli compression, meaning the overhead of the duplicate styles become insiginificant.
The increased productively is something i can agree to tho and is a big seller, not having to write styles seperately means a faster output. :)
My conclusion so far has been that BEM & Atomic design like patterns are good for established design systems, because consistency is easier, and you can do global design updates without running into issues where .pad-15 is defined as padding of 30px because we did not have time to update all the templates. :D
Outside of design systems, where consistensy is less important then making more parts fast, then i definitely see a good usecase for libraries like tailwind. :)
Shawn Wildermuth has been tinkering with computers and software since he got a Vic-20 back in the early ‘80s. He has been a Microsoft MVP, Pluralsight Author, and filmmaker.
The magic everyone misses in these languages is @apply. You start with the classes, then you can build the classes that are just a merging of those classes. Start with classes, deploy with @apply.
Looked it up briefly, it looks a lot like @mixins/include in sass but without the output duplication.
I hope something like this makes it into the CSS spec soon'ish. :)
Yes size gets moved to HTML, however, it is a fair tradeoff. Every HTML page that needs those styles, has them. The CSS then gets treated as a common import - with a finite size. The problem with other approaches is that there are often bad / changing categorisations of things when building. This results in duplication of CSS which is not easy to untangle.
What are you thoughts on CSS duplication being mostly removed with proper compression?
I'm also not sure what you mean by bad/changing categorizations, could you give an example?
The categorisation problem is the adage that naming things is hard. I have worked with designers and PM's who start with one design, and then cascade to many many variants without telling you in advance.
For example, say there is a component that only exists on the settings page - like a block of text above a group of buttons. You might start by calling the CSS container .settings-page as the block. Then you might call the text the .settings-page_text as block and element, then you might call the button group .settings-pagebutton-group, then you might call the individual buttons as .settings-page_button--primary to have block, element, and modifier.
Then your designer/PM likes the button group and wants to use it in a completely different page. You can no longer use the previous naming convention. This example is a bit contrived, but what I am pointing out, is that you can't always know in advance, how the naming should actually be for your usage. What you can know is that a button should be say primary and you apply the atomic style to style it primary.
And the same principal that means CSS duplication is compressed away also applies to HTML with a lot of duplicate classes. If you have a lot of components with bg-blue-400 in your markup the same thing will happen when it's served compressed.
Tailwind works when you have a component system on the template/server side. It abstracts away the components so you're not continuously using the same long list of classes throughout the app.
This is true with gzip compression, do you think brotli makes a different with it's dictionary?
Also, wouldn't the purge mean we have changing css files, that cannot be re-used if we generate the css files per page?
We could purge per project, but then we still have more classes then needed, and scanning an entire site would require a lot of deeper integrations to work vs doing it per page.
I don't know a lot about brotli, but I have to imagine every compression algorithm uses tokens to replace reused content, otherwise it wouldn't be effective at all.
The CSS purge is site or app wide, not per page. This is what you want, because the number of unique classes doesn't keep growing and growing as an app gets bigger. A single CSS file then covers the whole app, and is usually much smaller than traditional CSS that has to grow to style more components and patterns throughout an app.
I just checked a few sites using Tailwind in production (not mine), and the CSS build sizes were:
Their own definition for tailwind is "Utility-First: Building complex components from a constrained set of primitive utilities." - which kind of feels appropriate to me :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Do we have a name for these types of libraries that use a bunch of classes to write less css? :)
My primary concern with these types of libraries are like you mention, the longer class definitions, and that they move the payload from the CSS onto the HTML.
Meaning even tho the library is smaller, the overall payload for a page may not be.
Personally i really like using the BEM + Atomic Design approach but with mixins for everything but atoms, that way each component is self contained, and when packaged i only get the used styles.
The douple definitions this generates, are then handled by strong gzip/brotli compression, meaning the overhead of the duplicate styles become insiginificant.
The increased productively is something i can agree to tho and is a big seller, not having to write styles seperately means a faster output. :)
My conclusion so far has been that BEM & Atomic design like patterns are good for established design systems, because consistency is easier, and you can do global design updates without running into issues where .pad-15 is defined as padding of 30px because we did not have time to update all the templates. :D
Outside of design systems, where consistensy is less important then making more parts fast, then i definitely see a good usecase for libraries like tailwind. :)
Same bruv, I also use raw css but follow the CUBE methodology. Really love exceptions in that. Amen to what you said!
Nice, never heard of CUBE before, reading about it now, and i am really liking the different perspective, thanks!
The magic everyone misses in these languages is @apply. You start with the classes, then you can build the classes that are just a merging of those classes. Start with classes, deploy with @apply.
Looked it up briefly, it looks a lot like @mixins/include in sass but without the output duplication.
I hope something like this makes it into the CSS spec soon'ish. :)
Yes size gets moved to HTML, however, it is a fair tradeoff. Every HTML page that needs those styles, has them. The CSS then gets treated as a common import - with a finite size. The problem with other approaches is that there are often bad / changing categorisations of things when building. This results in duplication of CSS which is not easy to untangle.
What are you thoughts on CSS duplication being mostly removed with proper compression?
I'm also not sure what you mean by bad/changing categorizations, could you give an example?
Thanks! :)
The categorisation problem is the adage that naming things is hard. I have worked with designers and PM's who start with one design, and then cascade to many many variants without telling you in advance.
For example, say there is a component that only exists on the settings page - like a block of text above a group of buttons. You might start by calling the CSS container .settings-page as the block. Then you might call the text the .settings-page_text as block and element, then you might call the button group .settings-pagebutton-group, then you might call the individual buttons as .settings-page_button--primary to have block, element, and modifier.
Then your designer/PM likes the button group and wants to use it in a completely different page. You can no longer use the previous naming convention. This example is a bit contrived, but what I am pointing out, is that you can't always know in advance, how the naming should actually be for your usage. What you can know is that a button should be say primary and you apply the atomic style to style it primary.
Yeah, the term is utility classes.
And the same principal that means CSS duplication is compressed away also applies to HTML with a lot of duplicate classes. If you have a lot of components with bg-blue-400 in your markup the same thing will happen when it's served compressed.
Tailwind works when you have a component system on the template/server side. It abstracts away the components so you're not continuously using the same long list of classes throughout the app.
This is true with gzip compression, do you think brotli makes a different with it's dictionary?
Also, wouldn't the purge mean we have changing css files, that cannot be re-used if we generate the css files per page?
We could purge per project, but then we still have more classes then needed, and scanning an entire site would require a lot of deeper integrations to work vs doing it per page.
How bad would this be without the purge?
I don't know a lot about brotli, but I have to imagine every compression algorithm uses tokens to replace reused content, otherwise it wouldn't be effective at all.
The CSS purge is site or app wide, not per page. This is what you want, because the number of unique classes doesn't keep growing and growing as an app gets bigger. A single CSS file then covers the whole app, and is usually much smaller than traditional CSS that has to grow to style more components and patterns throughout an app.
I just checked a few sites using Tailwind in production (not mine), and the CSS build sizes were:
Nice, thank you for taking the time to get these numbers. :)
Their own definition for tailwind is "Utility-First: Building complex components from a constrained set of primitive utilities." - which kind of feels appropriate to me :)