To me, the problem is distance. Once a project reaches a certain size, the distance between a thing like a component and where its styles live grows to be too far for mental context.
If you’re working on a page that gets variables from this file, component styles from a scoped style block, typefaces from one file, layout from another…it all becomes a bit much.
Pair that with tooling that doesn’t _seem_ to easily lend itself to discovery - with any function or method or variable in my Vue files, I can tell the LSP to Go to Definition and I’m there. But CSS classes? Maybe. Depends - is there a preprocessor? Is there an abstraction layer that makes it hard to follow? What if someone did an “oops” and overwrote a global style in a scoped block?
On smaller projects or regimented teams, keeping styles in a well-organized structure of CSS/SASS can definitely work. But once you have even a modest handful of imports, or you’re bikeshedding the discussion around how to name classes and variables, it gets unwieldy.
Anecdote time: when I came into my current workplace, our project was already a mess of sorts - Craft CMS, Vue, SASS, just for the frontend. Backend is a separate service that drives a lot of the main content (CMS side is secondary for marketing stuff). The style situation was a mix of SASS in folders for “general stuff”, “project specific stuff”, and “administrative portal stuff”. Oh and then scoped styles per component. There was no clear design language that was shared among teams - the Craft team largely did the original SASS work and painstakingly implemented the design team’s vision for everything from breakpoints to grids to colors to forms. But we weren’t really keyed in on that, and by the time I got there we were rolling up some…50? individual SASS imports plus scoped styles - yikes!
Last year we began the process of separating the various sites from each other - CMS keeps being CMS, customer frontend and admin areas are both separate projects. I made a push to adopt Tailwind and there were the expected “I don’t get it” people and i gave them the crash course on the naming conventions and using the docs. Add the Tailwind LSP and it’s really a no-brainer: we have one single CSS file, per project, that configures things like color tokens and base style overrides for eg breakpoints. Everything else is pure Tailwind.
I’m in a button, my button styles are all right there - no context switching, no hunting down disparate selectors, no worrying if someone slipped an !important into the code somewhere down the line and broke something for everyone else.
I was hugely skeptical of Tailwind some three years ago, gave it a shot, and wouldn’t go back at this point. Sure the syntax is verbose, and I embrace that over the hidden nature of your styles being defined in one (or several) places and your makeup being elsewhere.
If you’re working on a page that gets variables from this file, component styles from a scoped style block, typefaces from one file, layout from another…it all becomes a bit much.
Pair that with tooling that doesn’t _seem_ to easily lend itself to discovery - with any function or method or variable in my Vue files, I can tell the LSP to Go to Definition and I’m there. But CSS classes? Maybe. Depends - is there a preprocessor? Is there an abstraction layer that makes it hard to follow? What if someone did an “oops” and overwrote a global style in a scoped block?
On smaller projects or regimented teams, keeping styles in a well-organized structure of CSS/SASS can definitely work. But once you have even a modest handful of imports, or you’re bikeshedding the discussion around how to name classes and variables, it gets unwieldy.
Anecdote time: when I came into my current workplace, our project was already a mess of sorts - Craft CMS, Vue, SASS, just for the frontend. Backend is a separate service that drives a lot of the main content (CMS side is secondary for marketing stuff). The style situation was a mix of SASS in folders for “general stuff”, “project specific stuff”, and “administrative portal stuff”. Oh and then scoped styles per component. There was no clear design language that was shared among teams - the Craft team largely did the original SASS work and painstakingly implemented the design team’s vision for everything from breakpoints to grids to colors to forms. But we weren’t really keyed in on that, and by the time I got there we were rolling up some…50? individual SASS imports plus scoped styles - yikes!
Last year we began the process of separating the various sites from each other - CMS keeps being CMS, customer frontend and admin areas are both separate projects. I made a push to adopt Tailwind and there were the expected “I don’t get it” people and i gave them the crash course on the naming conventions and using the docs. Add the Tailwind LSP and it’s really a no-brainer: we have one single CSS file, per project, that configures things like color tokens and base style overrides for eg breakpoints. Everything else is pure Tailwind.
I’m in a button, my button styles are all right there - no context switching, no hunting down disparate selectors, no worrying if someone slipped an !important into the code somewhere down the line and broke something for everyone else.
I was hugely skeptical of Tailwind some three years ago, gave it a shot, and wouldn’t go back at this point. Sure the syntax is verbose, and I embrace that over the hidden nature of your styles being defined in one (or several) places and your makeup being elsewhere.