Progressive rendering of CSS is a great boost in performance. Tailwind can't benefit from this technique I think and as such, imposes an added cost on our users.
I don't think is accurate. While it might not be built in currently, the same is also true of something like SASS or even plain CSS.
The article describes a strategy for loading CSS in the most performant way given a variety of interconnected factors (mainly JS).
You could generate the Tailwind file, and then split it when the media queries start (they're all grouped in order of screen size) with a small bash script into separate files as a part of your build process.
You could have multiple build steps that analyze your component architecture and generate separate CSS bundles for each component. This is already done w/ most JS frameworks.
If your argument is one of the final CSS file size, that is not an issue. Tailwind only generates classes that you write in your markup. Most Tailwind bundles I have seen, are dramatically smaller than their CSS counterparts, and it makes sense when you think about how CSS is written.
Say you have a two UI elements; an article preview image and a user avatar. Say you want them to mostly display the same, but with some tweaks to the avatar to add a fancy filter on hover. Okay easy enough. Maybe you start with some sort of base mixin and then overwrite add behavior for the avatar. Over time, you add more and more tweaks to the avatar until one day, you get a call from the head of Design Department that the articles are getting their own special CSS filter. Okay, so now you extend the article. Over time the two continue to drift until you're overwriting anything that they originally shared in the beginning. The articles have different margins than the avatars and now marketing wants to allow users to upload images to comments. Does that extend the original mixin from 3 years ago? Maybe you think, "why do I even have this base class; can I get rid of it?" After some quick testing you remove the original mixin and go home for the day. Over the weekend, you get a call saying that the avatars showing user contributions from a fundraising event are all messed up. It turns out, the base mixin added `display: block` to the images, but when you tested, you really only looked at the logged in user profile photo in the navbar. Whoops.
Now take that scenario and multiply it by 100 devs on 20 different teams. We've all seen it. This is why CSS is often never deleted in large companies. Devs instead to continue writing ever increasing specific selectors or using techniques like BEM/OOCSS to stop the bleeding. It takes an insane amount of discipline to wrangle CSS on a sufficiently large project. Tailwind helps manage some of that complexity, and at least provides good guard rails for teams of developers by empowering them to know that a "small refactor" won't break an entire layout.
I'm not sure you understood correctly what I meant. Or maybe is it me. Hehe.
To reiterate: you can link and load CSS for a component just when this component is used instead of loading everything at first. So the first load of the page is faster. Same thing with media queries in link tags. Isn't that something Tailwind can't do? Tailwind will load every style, every time, right?
As for your example, I get your pain. I' ve experienced it too. But it isn't a reason for completely pushing aside CSS in favor of a framework and all that it entails. It is a reason to have good linting.
For example, no component should ever influence the "outside world". So no margins on components. Rhythm (gaps or margins) is better taken care of by the parent (a grid, a list, etc.). This is a simple linting rule in Stylelint that will prevent this development behavior.
As for the rest of your problem, I'd say the "mixin" approach is of disservice here. That and, the way you implement the filters.
Are filters to be arbitrarily applied on the whims of the designer? Creating filter classes to be applied in a singular way then may be a good approach.
Are there rules governing the usage of the filters? Then a systemic approach could be a winner, especially if you can talk with the designer.
There are simple ways of managing these issues/problems with native technology and a little linting.
PS: Sometimes the problem IS the design. If the design is irrational, the real, efficient solution is not to implement these irrational patterns but to talk with the designer and find a rational solution. I know this isn't always easy but that is the problem resolution we should strive for as it is the most efficient one.
I think we largely agree, so I'll go back to focusing on the tool.
> Isn't that something Tailwind can't do? Tailwind will load every style, every time, right?
Tailwind's only function is:
- Scan codebase
- Generate classes
- Save them in a file with the a .css extension.
Anything else that you want is outside the scope of the tool. It makes no assumptions about what your files are named, where they are, or how it's loaded in the browser. At the end of the day, it's up to the developer to write `<link rel="stylesheet" href="/path/to/my/generated/file.css">`
This is no different or made easier/harder by using Tailwind.
https://csswizardry.com/2018/11/css-and-network-performance/
Progressive rendering of CSS is a great boost in performance. Tailwind can't benefit from this technique I think and as such, imposes an added cost on our users.
Correct me if I'm wrong!