4 ms·

I haven't actually used tailwind yet. But writing CSS -- usually with SCSS, sometimes bootstrap, sometimes just totally DIY -- I have _never_ managed to keep m

I haven't actually used tailwind yet. But writing CSS -- usually with SCSS, sometimes bootstrap, sometimes just totally DIY -- I have _never_ managed to keep my CSS well organized. It always eventually becomes an unholy spaghetti mess, including overrides of overrides. So my interest in tailwind or "utility" approach generally (I have started using bootstrap utility classes more), is not to avoid having to know CSS, but to avoid having to write CSS that I don't know how to keep from turning into an unmaintainable unperformant mess. (It makes me feel ashamed. I feel like I'm pretty good at writing maintainable code normally. But when it comes to CSS, I have never managed to learn how.) I do see how you have to know more in some ways, and have two levels of abstraction to debug or reverse engineer when looking at existing code -- tailwind and the underlying CSS, which, yes, pokes through the abstraction. It does seem like describing tailwind as a "language" basically right. That "cost" may well be worth it though.

pcthrowaway 4y ago
Tailwind really shines for this, but the caveat seems to be that it's much more useful when using a component-based frontend framework (React, Svelte, Vue, Angular, etc.) I was recommending it to a friend who does wordpress development, but it occurred to me that it might not be useful (or not as useful anyway) in that environment. For React, all the alternatives I've used have really sucked.
- yurishimo 4y ago
  I used Tailwind v1 to build a WP theme years ago. It was still useful to enforce the design system and color tokens. With the Block Editor, I imagine that's even more true now. The hardest part is customizing all of the different modules/plugins to either use TW classes (via injection somewhere) or write a custom CSS file with `@apply` rules. The WP theme templating system has partial file includes, so creating "components" is certainly possible.
- mcluck 4y ago
  I prefer to use good old fashioned CSS modules for React etc. Tailwind is basically just a way of keeping your styles co-located with your components. For me, having `Component.tsx` and `Component.module.css` is good enough. People talk about jumping between multiple files when you're tweaking things but I just split my screen. TS on the left, CSS on the right, and go to town. In my experience, Tailwind makes React code really messy because now I have some potentially massive string on `className` instead of `className={styles.component}` or whatever
yurishimo 4y ago
I think Adam Wathan's (the creator of TW) article [0] sums up the issues you are likely having. Modern CSS has an inherent dependency on the structure of your markup. This is a newer byproduct of modern design. Back in the day, you'd add something like `a { color: orange; }` for your entire site and be done with it. As sites got more complicated and design became a feature rather than an afterthought for websites, our needs changed. Adam's argument relies on your CSS being tied to your markup in some way. If they are related, then the code should be co-located as well. Splitting things into separate files/names creates the scenario we've all found ourselves in where you are afraid to delete "old" CSS because you don't know if someone else has started depending on that behavior. By colocating the CSS with the HTML, you are now 100% sure that deleting that bit of "CSS" will not impact anything else. This is arguably a good thing! It's long been a principle that code should be easy to delete. Tailwind enables you to "delete" CSS with confidence, in addition to its other main feature as a Token/Design/Style guide enforcer. 0: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-...
- HelloNurse 4y ago
  This kind of "colocation" doesn't scale too well: a family of as little as two pages should share a stylesheet for their common classes, ids and common structures, not consistently repeat identical CSS in multiple files. The common technique of defining components encapsulating related markup and CSS makes repetitions in the output pages harmless because they are write-only, but it only moves the problem one abstraction step up (families of components with related CSS).
  - mixmastamyk 4y ago
    Keep globals in globals, locals in locals.
  - deleted 4y ago
    [deleted]
  - imbnwa 4y ago
    Isn't it still nonetheless better to arrive at that category of common classes as an outcome of 'component-first' co-location? These two needs don't seem mutually exclusive.
idlehand 4y ago
Something I like about some newer web frameworks like Next.js is that stylesheets are component-scope by default. This means that any stylesheet I use is inevitably going to affect, at most, one React component. And so I can call every actual container simply .container without worrying about conflicts or namespacing.
xkcd1963 4y ago
It's not possible really. As example we still cant use query selectors based on parents width. What do we do? Do we put all mobile styling in one big query selector with components inside or do we create many query selectors per component?

pcthrowaway 4y ago

Tailwind really shines for this, but the caveat seems to be that it's much more useful when using a component-based frontend framework (React, Svelte, Vue, Angular, etc.) I was recommending it to a friend who does wordpress development, but it occurred to me that it might not be useful (or not as useful anyway) in that environment. For React, all the alternatives I've used have really sucked.

yurishimo 4y ago
I used Tailwind v1 to build a WP theme years ago. It was still useful to enforce the design system and color tokens. With the Block Editor, I imagine that's even more true now. The hardest part is customizing all of the different modules/plugins to either use TW classes (via injection somewhere) or write a custom CSS file with `@apply` rules. The WP theme templating system has partial file includes, so creating "components" is certainly possible.
mcluck 4y ago
I prefer to use good old fashioned CSS modules for React etc. Tailwind is basically just a way of keeping your styles co-located with your components. For me, having `Component.tsx` and `Component.module.css` is good enough. People talk about jumping between multiple files when you're tweaking things but I just split my screen. TS on the left, CSS on the right, and go to town. In my experience, Tailwind makes React code really messy because now I have some potentially massive string on `className` instead of `className={styles.component}` or whatever

yurishimo 4y ago

I think Adam Wathan's (the creator of TW) article [0] sums up the issues you are likely having. Modern CSS has an inherent dependency on the structure of your markup. This is a newer byproduct of modern design. Back in the day, you'd add something like `a { color: orange; }` for your entire site and be done with it. As sites got more complicated and design became a feature rather than an afterthought for websites, our needs changed. Adam's argument relies on your CSS being tied to your markup in some way. If they are related, then the code should be co-located as well. Splitting things into separate files/names creates the scenario we've all found ourselves in where you are afraid to delete "old" CSS because you don't know if someone else has started depending on that behavior. By colocating the CSS with the HTML, you are now 100% sure that deleting that bit of "CSS" will not impact anything else. This is arguably a good thing! It's long been a principle that code should be easy to delete. Tailwind enables you to "delete" CSS with confidence, in addition to its other main feature as a Token/Design/Style guide enforcer. 0: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-...

HelloNurse 4y ago
This kind of "colocation" doesn't scale too well: a family of as little as two pages should share a stylesheet for their common classes, ids and common structures, not consistently repeat identical CSS in multiple files. The common technique of defining components encapsulating related markup and CSS makes repetitions in the output pages harmless because they are write-only, but it only moves the problem one abstraction step up (families of components with related CSS).
- mixmastamyk 4y ago
  Keep globals in globals, locals in locals.
- deleted 4y ago
  [deleted]
- imbnwa 4y ago
  Isn't it still nonetheless better to arrive at that category of common classes as an outcome of 'component-first' co-location? These two needs don't seem mutually exclusive.

idlehand 4y ago

Something I like about some newer web frameworks like Next.js is that stylesheets are component-scope by default. This means that any stylesheet I use is inevitably going to affect, at most, one React component. And so I can call every actual container simply .container without worrying about conflicts or namespacing.

xkcd1963 4y ago

It's not possible really. As example we still cant use query selectors based on parents width. What do we do? Do we put all mobile styling in one big query selector with components inside or do we create many query selectors per component?