They repeat the same tailwind classes 20,000 times and if the application gets bigger they repeat it 40,000 times and if they have to change the way it looks it is the mother of all cut and paste jobs.
There is an unholy convergence of the tools being almost but not quite adequate, the platform being driven by companies that have overly favorable unit economics (Google could care less if it cost $2M to make a simple web site) and a designer mindset that is all too comfortable with trading a bulldozer for a spoon.
Tailwind would be a lot more appealing to me if it was coupled with some system where I could say "class X inherits from tailwind classes A, B and C" and thus have a layer of abstraction over just writing properties.
CSS appeals to a programmers mindset. Cascading seems like a good idea. Having classes that are reusable seems like a good idea. Complex selectors seem like a good idea. These are all forms of abstraction, almost like functional composition but not quite.
But after decades of fighting with it, I have to admit that it just doesn't work. The myth that you could change an entire site design just by changing the CSS is a complete myth. I've been party to more than a few whole site redesigns and I can assure anyone unfamiliar that it involved a heck of a lot more than updating CSS (and more than HTML in almost every case as well).
In fact, almost all advancements in CSS (including Sass and Less) seemed to tend toward isolating the effect of changes. Pretty soon most projects had a compenent.html/component.scss pair for every fragment and naming conventions like BEM [1] became the norm. Reusability for things like fonts and colors were handled with CSS variables.
Tailwind is proof to me that isolation is more important for visual design than abstraction/inheritance/cascading. Inline styles would be the same advantage but they are way too verbose.
You should tell that to this site which has been doing exactly that for 20 years: https://csszengarden.com/
I've seen hundreds and hundreds of clever tech demos. I even believed in some of them for a time. Now I realize they were carefully constructed gimmicks.
css zen garden is made explicitly to do one thing and it manages to do that one thing. It's hard for me to even say that it does it very well, clicking through the featured designs. Unfortunately, the dream of redesigning a website that wasn't purpose-made for this particular trick remains but a dream.
Easy to do when you don't actually have to update the content or functionality. And even with those advantages, most versions of it look bad.
There was nothing more annoying than including a component on a page and some aspect of the component was visually broken. Like a margin inflated somewhere or a wrong color. And then time would be wasted trying to figure out what was cascading/inheriting. Worse case it was some CSS included at runtime by some JS script that was forced onto the team by marketing. But on large teams there was just a constant collision between page authors, component authors and other stakeholders.
HTML Web Components tried to solve the problem by making the shadow dom isolated but in our experimentation the support was just too inconsistent across browsers. It was also a major pain to debug at the time (maybe this has gotten better?)
I was completely against Tailwind, absolutely hated looking at it and I even used my position as a senior engineer at a company to block its adoption. I felt it flew in the face of the entire premise of CSS and the high-ideal of separating form and content. I now believe I was wrong.
How is that different from:
D {
@apply A B C;
}
https://tailwindcss.com/docs/adding-custom-styles#using-modi...
Please link to something that supports this claim, because it's not the first time I've seen it made on HN, but only found it on HN
I actually think CSS is the wrong tool for modern webdev. Or rather, it should be the output of a compile process instead of something that designers and developers wrestle with.
In general, we're building these complex SPAs, and still working directly in standards that were intended for a static document model. Part of the reason is we somehow believe we need infinite customizability, so for that we're writing in Assembly.
But, the truth is that user interfaces are largely consistent and should be. Still, even if we did want maximal customizability, we should use tooling that generates the CSS, etc.
And that tooling should be visual. I mean think about the fact that we're trying to hand code visual designs with text. Or that it was so accepted that we're only recently trying to generate the code from design tools like Figma, which is still imperfect.
So many thousands of developer hours lost to this effort. Bass-ackwards to be sure.
I'd point out the grid layout and flexbox as being features ideal for application work and https://www.w3.org/TR/2011/WD-html5-20110405/forms.html#form... is practically a love letter for applications.
I feel the same. Give the component a class and then in the SCSS assign the setting there. But inlining each individual CSS setting? I don't get it. Sure maybe great for a quick prototype / MVP. But as a permanent tool? I don't see it.
This mindset is the problem. You don't want or need this abstraction in the CSS, what you want is to encapsulate these styles properties in a reusable "HTML component", and then use that component wherever needed. It then carries those style properties into every instantiation. What use are semantic style classes in this context? Atomic CSS makes perfect sense in this context and makes composable development a breeze by comparison.
I should have also mentioned that your "semantic CSS" is necessarily anti-composable by contrast. Any reusable HTML components with semantic classes now require you to manually lift their CSS definitions into your CSS top-level context, which is a step that isn't required with atomic CSS / tailwind.