5 ms·

I think you miss the point. Having 25 developers trying to manage a CSS stylesheet together while naming classes does not scale. Having 25 developers not worr

I think you miss the point. Having 25 developers trying to manage a CSS stylesheet together while naming classes does not scale. Having 25 developers not worry so much about stepping on other people’s toes with Tailwind scales better. Or in a nutshell: What is one of the hardest problems in CS? Naming things. What is Tailwind’s biggest feature? Build a frontend with minimal need to name things.

alt227 2y ago
Why on earth would you ever have 25 front end developers editing the same classes in the same stylesheet?
- gjsman-1000 2y ago
  12 year old project, 2 developers per year, turnover every year. That’s all it takes.
  - alt227 2y ago
    > Having 25 developers trying to manage a CSS stylesheet together Your comment suggests you mean 25 developers simultaneously 2 developers per year can easily maintain a coherent stylesheet.
jakelazaroff 2y ago
CSS modules solved the classname collision problem years prior, though.
- recursive 2y ago
  When people say "CSS modules", I never know which one they mean. There's a feature on the spec track for CSS "imports". There's also a family of webpack plugins with various behavior. CSS modules, collectively solved it a number of times with various trade-offs. You can even end up with multiple kinds of CSS modules in the same code base.
exceptione 2y ago
25 developers working in the same module? Without a common style? Afaik we came from plain CSS -> BEM, because scoping styles was hard, so people found a discipline in naming things to isolate styling. Scoping did not exist in CSS. Then we got a movement from BEM -> Tailwind, because doing the scoping by hand was a bit difficult(?) Then we get Tailwind -> Tailwind + DaisyUI because Tailwind results in messy concretion. -------- The question I have: are the modularity/scoping primitives in modern css good enough now, rendering Tailwind e.a obsolete? Are we still using Tailwind because people do not understand the original problem? Maybe someone can enlighten me.
- tengbretson 2y ago
  Going from plain CSS to BEM more or less meant abandoning the "cascade" part of CSS. We've basically spent the last 15 years styling our markup directly, bouncing back and forth between different strategies for doing so in the most capable, and aesthetically palatable way possible.
azangru 2y ago
> does not scale CSS already has @layer; and @scope is coming (waiting for firefox). There are naming conventions like bem. There are also tools to guarantee unique class names (css modules, 'single-file components' in various js frameworks). There are design systems to standardize and reduce the amount of CSS. There are web components, with their styles encapsulated in the shadow DOM.
sfsefwafawfa 2y ago
Hard agree, written Tailwind since the very inception. I love it for exactly this, the purging, JIT, arbitrary values, plus you can just write plain CSS any time you want. I have used Tailwind on big FAANG sites and boutique shops. Worked great for both, scales, and is very customizable.
isodev 2y ago
> Having 25 developers trying to manage a CSS stylesheet together As opposed to 25 developers trying to manage a React component together? I don't think that's feasible either.
- dsego 2y ago
  Hence why companies adopt UI toolkits, otherwise it gets messy. Without discipline it's hard to develop a set of core components and often times devs will duplicate work and fail to extract common parts due to the nature of working on features across the stack and failing to recognize common patterns.
  - isodev 2y ago
    My point was, you use the language features to separate concerns into manageable pieces (which CSS can do just as well as TypeScript). Tawilwind was created at a time when we were still feeling the IE days, triton was still a thing and people generally had to look up resets or how to setup tooling to help them with vendor prefixes (that was before Interop was a thing), etc. All this while, designers would ship individual design tokens for implementation (e.g. a button, a combo box). Things like “styled components” would feel like a relief because “oh I can style a button without breaking the entire website”. Since then, all these points of friction have been improved or removed all together. We wouldn't lose anything if we revisit the platform and see how we can get all the benefits of tailwind without actually adopting it by default. By the way, the same argument can be made about React and revisiting what one can do with modern DOM features. I guess something all frameworks born in the past to solve real problems have in common - we tend to forget to deprecate them once the underlying need for them was gone.

alt227 2y ago

Why on earth would you ever have 25 front end developers editing the same classes in the same stylesheet?

gjsman-1000 2y ago
12 year old project, 2 developers per year, turnover every year. That’s all it takes.
- alt227 2y ago
  > Having 25 developers trying to manage a CSS stylesheet together Your comment suggests you mean 25 developers simultaneously 2 developers per year can easily maintain a coherent stylesheet.

jakelazaroff 2y ago

CSS modules solved the classname collision problem years prior, though.

recursive 2y ago
When people say "CSS modules", I never know which one they mean. There's a feature on the spec track for CSS "imports". There's also a family of webpack plugins with various behavior. CSS modules, collectively solved it a number of times with various trade-offs. You can even end up with multiple kinds of CSS modules in the same code base.

exceptione 2y ago

25 developers working in the same module? Without a common style? Afaik we came from plain CSS -> BEM, because scoping styles was hard, so people found a discipline in naming things to isolate styling. Scoping did not exist in CSS. Then we got a movement from BEM -> Tailwind, because doing the scoping by hand was a bit difficult(?) Then we get Tailwind -> Tailwind + DaisyUI because Tailwind results in messy concretion. -------- The question I have: are the modularity/scoping primitives in modern css good enough now, rendering Tailwind e.a obsolete? Are we still using Tailwind because people do not understand the original problem? Maybe someone can enlighten me.

tengbretson 2y ago
Going from plain CSS to BEM more or less meant abandoning the "cascade" part of CSS. We've basically spent the last 15 years styling our markup directly, bouncing back and forth between different strategies for doing so in the most capable, and aesthetically palatable way possible.

azangru 2y ago

> does not scale CSS already has @layer; and @scope is coming (waiting for firefox). There are naming conventions like bem. There are also tools to guarantee unique class names (css modules, 'single-file components' in various js frameworks). There are design systems to standardize and reduce the amount of CSS. There are web components, with their styles encapsulated in the shadow DOM.

sfsefwafawfa 2y ago

Hard agree, written Tailwind since the very inception. I love it for exactly this, the purging, JIT, arbitrary values, plus you can just write plain CSS any time you want. I have used Tailwind on big FAANG sites and boutique shops. Worked great for both, scales, and is very customizable.

isodev 2y ago

> Having 25 developers trying to manage a CSS stylesheet together As opposed to 25 developers trying to manage a React component together? I don't think that's feasible either.

dsego 2y ago
Hence why companies adopt UI toolkits, otherwise it gets messy. Without discipline it's hard to develop a set of core components and often times devs will duplicate work and fail to extract common parts due to the nature of working on features across the stack and failing to recognize common patterns.
- isodev 2y ago
  My point was, you use the language features to separate concerns into manageable pieces (which CSS can do just as well as TypeScript). Tawilwind was created at a time when we were still feeling the IE days, triton was still a thing and people generally had to look up resets or how to setup tooling to help them with vendor prefixes (that was before Interop was a thing), etc. All this while, designers would ship individual design tokens for implementation (e.g. a button, a combo box). Things like “styled components” would feel like a relief because “oh I can style a button without breaking the entire website”. Since then, all these points of friction have been improved or removed all together. We wouldn't lose anything if we revisit the platform and see how we can get all the benefits of tailwind without actually adopting it by default. By the way, the same argument can be made about React and revisiting what one can do with modern DOM features. I guess something all frameworks born in the past to solve real problems have in common - we tend to forget to deprecate them once the underlying need for them was gone.