5 ms·

I don’t think you realize that there are a lot of old school developers such as myself (going +25 years) who’s simply looking for quick and dirty front end tool

by lvl102 4y ago

I don’t think you realize that there are a lot of old school developers such as myself (going +25 years) who’s simply looking for quick and dirty front end tools that simply work and get out of the way. Tailwind does exactly that.

postalrat 4y ago
How does it not get in your way? If you ignore it?
- dmitriid 4y ago
  It gives you a consistent design system with sensible defaults and easy-to-use (and rather memorable or easy to deduce) utility classes. Unlike the yet-another umpteenth bespoke `.card-header__buttons .card-header__button--secondary` that no one can remember and create an umpteenth+1 Tailwind works great when your site/app is a collection of components
  - atsjie 4y ago
    `.card-header__buttons` that example makes no sense unless you use global CSS/SASS, which very few projects do anymore. Component CSS/SCSS or CSS-in-JS are very common which resolve this scoping problem. So why bother with a DSL like Tailwind over Component CSS/SCSS for example?
    - dmitriid 4y ago
      How do you enforce consistency in CSS-in-JS? Paddings, margins, sizes, colors? Everywhere I've seen CSS-in-JS used, everywhere it's people busy writing bespoke styles in every file.
      - postalrat 4y ago
        That's the same problem I see with tailwind. I prefer a global set of styles and more specific selectors to override styles where needed. It may not work well on projects with many teams but for the projects I typically work on it's fine.
        dmitriid 4y ago
        > That's the same problem I see with tailwind. The thing with Tailwinf is that it already has a decent design syste encoded in its utility classes. It's very easy to slap a p-2 for a standardized padding than trying to remember what it was when you write the next component with `{ padding: 2 2 2 2 }` > I prefer a global set of styles and more specific selectors to override styles where needed. That's kinda what I mean. In all projects I've seen you have a global stylesheet with a bunch of classes that no one remembers, and hundreds of one-ofs in every component either reimplementing stuff from scratch or serving as an `!important` of sorts
      - atsjie 4y ago
        > How do you enforce consistency in CSS-in-JS? Paddings, margins, sizes, colors? JavaScript variables, css variables? Both can be used. It's pretty trivial tbh.
      - satvikpendem 4y ago
        By having a style guide with variants, StitchesJS pioneered this but there are others like Vanilla-Extract. With TypeScript, you can then enforce that only a certain variant can be used with a certain component at compile time, basically making sure that your design style guide gets mapped 1:1 to your code. https://stitches.dev/ https://stitches.dev/
        dmitriid 4y ago
        Hm. I see the same CSS-in-JS with a sprinkle of string interpolation for some variables :) I may run into the same issues as the other CSS-in-JS solutions (I only encountered stitch once, and not for a long period of time)
        satvikpendem 4y ago
        Unlike other CSS-in-JS though, the way it's made, via object properties, enforces compliance to the design system. In things like styled-components, it doesn't. Doubly so when using TypeScript, as with Vanilla-Extract: https://vanilla-extract.style https://vanilla-extract.style
        dmitriid 4y ago
        > the way it's made, via object properties, enforces compliance to the design system. The link literally has this: ``` export const className = style({ display: 'flex', flexDirection: 'column', selectors: { '&:nth-child(2n)': { background: 'aliceblue' } }, '@media': { 'screen and (min-width: 768px)': { flexDirection: 'row' } } }); ``` Which is indistinguishable from any other CSS-in-JS which has hundreds of these one-off things scattered everywhere. With a theme somewhere exposing another hundred or so variables of varing quality. And all these solutions basically converge on Tailwind (or other utility-first CSS approaches): ``` export const hero = style({ backgroundColor: vars.color.brandd, color: vars.color.white, padding: vars.space.large }); ``` is nothing more than `bg-brand color-white p-4` But TypeScript support is definitely nice.
        4y ago
    - deleted 4y ago
      [deleted]
icedchai 4y ago
I'm in the same boat, and Tailwind looks like something that would get in my way (or at least becoming annoying very quickly.) I don't want the equivalent of inline styles all over the place.
- greenhatman 4y ago
  This is probably the main thing that puts people in one camp or the other. Before Tailwind came along I very often found myself just wanting to put some inline styling in various places. It's so much easier to just add some CSS to an element than having to think of a class name, think of where the best place would be to put the class, etc.

by lvl102 4y ago

postalrat 4y ago

How does it not get in your way? If you ignore it?

dmitriid 4y ago
It gives you a consistent design system with sensible defaults and easy-to-use (and rather memorable or easy to deduce) utility classes. Unlike the yet-another umpteenth bespoke `.card-header__buttons .card-header__button--secondary` that no one can remember and create an umpteenth+1 Tailwind works great when your site/app is a collection of components
- atsjie 4y ago
  `.card-header__buttons` that example makes no sense unless you use global CSS/SASS, which very few projects do anymore. Component CSS/SCSS or CSS-in-JS are very common which resolve this scoping problem. So why bother with a DSL like Tailwind over Component CSS/SCSS for example?
  - dmitriid 4y ago
    How do you enforce consistency in CSS-in-JS? Paddings, margins, sizes, colors? Everywhere I've seen CSS-in-JS used, everywhere it's people busy writing bespoke styles in every file.
    - postalrat 4y ago
      That's the same problem I see with tailwind. I prefer a global set of styles and more specific selectors to override styles where needed. It may not work well on projects with many teams but for the projects I typically work on it's fine.
      - dmitriid 4y ago
        > That's the same problem I see with tailwind. The thing with Tailwinf is that it already has a decent design syste encoded in its utility classes. It's very easy to slap a p-2 for a standardized padding than trying to remember what it was when you write the next component with `{ padding: 2 2 2 2 }` > I prefer a global set of styles and more specific selectors to override styles where needed. That's kinda what I mean. In all projects I've seen you have a global stylesheet with a bunch of classes that no one remembers, and hundreds of one-ofs in every component either reimplementing stuff from scratch or serving as an `!important` of sorts
    - atsjie 4y ago
      > How do you enforce consistency in CSS-in-JS? Paddings, margins, sizes, colors? JavaScript variables, css variables? Both can be used. It's pretty trivial tbh.
    - satvikpendem 4y ago
      By having a style guide with variants, StitchesJS pioneered this but there are others like Vanilla-Extract. With TypeScript, you can then enforce that only a certain variant can be used with a certain component at compile time, basically making sure that your design style guide gets mapped 1:1 to your code. https://stitches.dev/ https://stitches.dev/
      - dmitriid 4y ago
        Hm. I see the same CSS-in-JS with a sprinkle of string interpolation for some variables :) I may run into the same issues as the other CSS-in-JS solutions (I only encountered stitch once, and not for a long period of time)
        satvikpendem 4y ago
        Unlike other CSS-in-JS though, the way it's made, via object properties, enforces compliance to the design system. In things like styled-components, it doesn't. Doubly so when using TypeScript, as with Vanilla-Extract: https://vanilla-extract.style https://vanilla-extract.style
        dmitriid 4y ago
        > the way it's made, via object properties, enforces compliance to the design system. The link literally has this: ``` export const className = style({ display: 'flex', flexDirection: 'column', selectors: { '&:nth-child(2n)': { background: 'aliceblue' } }, '@media': { 'screen and (min-width: 768px)': { flexDirection: 'row' } } }); ``` Which is indistinguishable from any other CSS-in-JS which has hundreds of these one-off things scattered everywhere. With a theme somewhere exposing another hundred or so variables of varing quality. And all these solutions basically converge on Tailwind (or other utility-first CSS approaches): ``` export const hero = style({ backgroundColor: vars.color.brandd, color: vars.color.white, padding: vars.space.large }); ``` is nothing more than `bg-brand color-white p-4` But TypeScript support is definitely nice.
        4y ago
  - deleted 4y ago
    [deleted]

icedchai 4y ago

I'm in the same boat, and Tailwind looks like something that would get in my way (or at least becoming annoying very quickly.) I don't want the equivalent of inline styles all over the place.

greenhatman 4y ago
This is probably the main thing that puts people in one camp or the other. Before Tailwind came along I very often found myself just wanting to put some inline styling in various places. It's so much easier to just add some CSS to an element than having to think of a class name, think of where the best place would be to put the class, etc.