TailwindCSS v2.0

So many people reach for a solution without really understanding their own problem.

I'm talking specifically about maintainable code. And maintainable CSS code at that.

For scaling CSS imagine a continuum with complete isolation one end (BEM, ECSS et al) and complete abstraction at the other (started with 'Atomic CSS', which then spawned countless others including Tailwind).

My experience is that either end of that continuum leads to an approach that can scale well and be maintainable. Mixing of approaches is where people come unstuck because they don't understand why that is problematic.

Understanding that fundamental (more here: https://css-tricks.com/scaling-css-two-sides-of-a-spectrum/) goes a long way to dealing with the problem.

My preference is isolation (which I detailed at https://ecss.io and in the book 'Enduring CSS' about 5 years back — not mentioned to pimp myself, I don't give a hoot if you buy/read)). I like code that is easy to reason about and delete (I like deleting code far more than writing it!) and that suits my mental model.

I also believe our job as a front-end developer is to accommodate designs, not turn around and say, "sorry, we don't have a class for 8px margin, it will have to be 5px or 10px". I'm not suggesting this or that framework can't accommodate this need, just highlighting why I feel the way I do and choose the solution I do.

Think about how __you__ want to build and maintain code. Don't just jump on something because everyone else does. Analyse your problem. Where are your actual pain points. Find the solution to your own issues. Otherwise you'll just swap one set of problems for another.

A framework may very well meet your needs. And by all means listen to others extolling its virtues but that will not save you from a lack of due diligence!

[ends attempting to dispense fatherly advice]

The experiment failed though, we've been trying for over a decade. You can't let one group write the HTML and one group write the CSS (with the pipedream being the designers writing the CSS). The only way to make complex designs is to modify both as you develop. They're too intertwined and CSS alone isn't powerful enough to do everything you want.

Keep your actual data like blog post content, blog post meta data, images etc. separated but it's 1) not practically possible and 2) there's no significant benefits to keeping your CSS and HTML separate besides sticking to dogmatism "best practices" that haven't panned out.

Right, and I don't see the HTML and the CSS as separate concerns when the HTML describes a GUI, not a document. There being two languages in play is a historical detail that as developers we have to tackle in the best way. I don't believe that it's some sort of holy spirit we have to respect.

For my money, separation of concerns is things like where do I put my mutable state, which part of the application talks to the network, etc.

> but what if I'd like to have multiple styles

I have to say that's not a thing I've ever needed to worry about. I'm worried about things turning into a big pile of goop. The old approach too often devolved into making a separate class for each tag. Starting with repetition and noticing patterns that then get factored out is a better approach for me.

I will say, though, that in Tailwind it absolutely would be workable to give e.g. colours a semantic name - like primary and secondary - and then map those to whatever you want, including CSS custom properties. So you absolutely can implement both build-time and runtime theming at that level if you want, where you just need to change configuration options or a set of properties.

> What do I have to gain from Tailwind if I am using already SASS as the preprocessor and a good library of "utility classes" that can be @imported/@use'd/@apply'd to the document without touching the HTML?

Again, I'm not afraid of touching the HTML, that's not a goal for me. In my work, any change of any consequence is going to involve both HTML, CSS, and JS anyway. I am much more afraid of accumulating cruft in poorly-maintained CSS files.

Tailwind's utility classes are pretty fantastic - for instance, you can define a colour palette and they also become usable in gradients - so they're a good place to start. I also like that it's basically real CSS because that forces developers to learn, which will lead to better layouts. And yes, it will in some cases lead to the same set of classes as a semantic approach, because sometimes that classes are what makes sense. But the thing is, how do you arrive at that set of classes, and what do you do with the edges and boundaries and all the glue you need. Tailwind provides an extremely usable starting point and a good thought pattern for building the type of apps I do.

Also, it's not a matter of strictly separating the groups of people doing one task or another. It's a matter of being able to extend in one dimension while keeping the other untouched.

> They're too intertwined and CSS alone isn't powerful enough to do everything you want.

I'd argue that is precisely backwards. The reason that we don't see any more different designs and more bold experiments is because we are not defining the interaction points between different layers in the development stack.

If most developers keep this mentality that all they need to do is to get a system that solves their immediate problems and solves their own unique solution, then all they are going to do is this mushing together of their structure and their presentation layers, and all we are going to get is a pile architectures are going to converge to different local maxima. If instead we don't take the easy way out and make things with flexibility and extensibility in mind, then the likelihood of it becoming the basis of something ground-breaking grows enormously.