4 ms·

From the tailwind homepage: > "Best practices" don't actually work. I’ve written a few thousand words [0] on why traditional “semantic class names” are the rea

From the tailwind homepage: > "Best practices" don't actually work. I’ve written a few thousand words [0] on why traditional “semantic class names” are the reason CSS is hard to maintain, but the truth is you’re never going to believe me until you actually try it. If you can suppress the urge to retch long enough to give it a chance, I really think you'll wonder how you ever worked with CSS any other way. [0] https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-... FWIW, that linked post was the thing that convinced me to try it, and I haven't looked back.

torginus 6y ago
still, this does not explain, why I should use class="w-24" instead of style="width:24px;" Other than "inline style bad", when the first one is built into the browser, and a second one requires including an external dependency, that I imagine contains classes w-1 to w-1000 or whatever. Now I strain my IDE-s autocomplete with 1000s of classes, will need a css minifier/bundler (that will at least make my build slower). I'm not a frontend dev, but I do dabble in writing the occasional website, and other than bootstrap (which contains complete styles for stuff like buttons), I never felt the need to use a CSS framework. I get it that in pre-grid days, it was a minor feat of wizardry to implement complex layouts, but nowadays, frameworks seem largely unnecessary to me. Another added benefit of using pure CSS, is you just have to learn it once (with tons of great resources), while with these CSS frameworks, I'll need to learn what everything's called for every framework. Not sold.
- dfabulich 6y ago
  There's a section of Wathan's article, "Isn't this just inline styles?" That directly addresses this question. Perhaps you missed it? > With inline styles, there are no constraints on what values you choose. [With utility classes] you can't just pick any value want; you have to choose from a curated list.
  - couchand 6y ago
    If the list is so long that the whole thing isn't even included by default and you need to custom configure which entries appear on the list, it's not that much better than arbitrary values.
- yurishimo 6y ago
  CSS classes can work with media queries while inline styles cannot. A ton of the classes that are generated are screen size variants. The IDE strain is overblown. There is an official Tailwind plugin for most IDEs and it performs well, even with the massive CSS files you use for development (but are purged/tree-shaken for production). Computers are really good at parsing text, and even at their worst, the CSS files are never more than a MB or two. Even if you enable ever single flag for every token, the dev file size is around 10MB I think. Big to load over the internet, but locally, and being parsed, not a huge problem at all.
- leviathan 6y ago
  except that w-24 is not 24px. It's 24 units of whatever your design grid says, so now you can use a design language to describe your layouts instead of absolute dimensions
  - Vinnl 6y ago
    And for more information on why "24" there isn't just an arbitrary magic number like it was in the original inline style: https://styled-system.com/guides/why-powers-of-two/ https://styled-system.com/guides/why-powers-of-two/
- davidwparker 6y ago
  Here's why, media queries: class="w-24 sm:w-36 md:w-48" Now I have a nicely designed interface for multiple sizes and it just works.
- jdminhbg 6y ago
  Other people have noted that your `style` example isn't responsive, but on top of that, there's nothing stopping you (or a collaborator) from writing `style="width:26px;"` somewhere else in the app. Having a restricted set of options helps enforce consistency across a project and gives you a much nicer look by default. This is especially useful for devs doing frontend work without a strong design background.
- mcrittenden 6y ago
  This post may clear things up a bit (disclaimer, I wrote it): "Utility classes vs. inline styles": https://critter.blog/2018/05/04/utility-classes-vs-inline-styles/ https://critter.blog/2018/05/04/utility-classes-vs-inline-st...
ajcp 6y ago
> "Best practices" don't actually work. Don't try and master the hard stuff: you'll just fail! Take my magic pill! Applied to everything from weight-loss to front-end development.
- climber_mac 6y ago
  Most innovative ideas at first seem like bad ideas. Flipping conventional wisdom on its head takes a while. This talk by Dan Abramov helped me understand better how 'best practices' are often taken so literally that their value is lost: https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase https://www.deconstructconf.com/2019/dan-abramov-the-wet-cod...
  - ajcp 6y ago
    I agree with you, Dan, and Adam Wathan for that matter. The point of my comment had more to do with front-loading of a pitch with copy specifically tailored for confirmation bias. Running to achieve weight loss can be hard. So much so that it's intended value can't be realized, or even be detrimental to the end goal. But I think we'd agree that anyone who simply says says "Running won't help you lose weight because it doesn't work, try this instead" is not seeking to help you, just sell you.
    - sbergot 6y ago
      Come one. This "pitch" is heavily contextualized. Interpreting it as "all best practices are bad" is not very charitable.
    - imbnwa 6y ago
      This was also React's initial pitch as well: getting DOM updates right is hard, use vDom instead! The truth is that the majority of frontend development is devs racing to shovle the latest stack of tickets that management cooked up with little collaboration or rhyme and reason into the Done column of JIRA (web dev is particularly imperiled by shitty lay management), any DX affordance they can get their hands on is valuable to this goal Concurrently, designers are pumping out comps as fast as possible to match pace with no real system cohering the whole thing, you need a design system to provide an "abstract interface", so to speak, for your CSS to really transcend into real separation. This is just what I've observed working at my comp
chias 6y ago
As another example of "am I crazy? No, it's the entire rest of the internet that's crazy" check out htmx [0]. It's another acknowledgement that best practices (for js / ajax) are not best in all circumstances, and has been a fantastic fit for most of my web projects. In practice, "the right way" is shorthand for "the right way for your project", and conventional wisdom / best practices are vital to know and understand so that you can recognize when they are a bad fit for what you need to do. [0] https://htmx.org/ https://htmx.org/
- egeozcan 6y ago
  I was going to mention how similar this is to intercooler then I saw: > htmx is the successor to intercooler.js
pc86 6y ago
Semantic CSS would be great if you could reliably unit-test style changes to semantic names within the IDE.
crusso 6y ago
Nice article. It manages to explain the uneasy feeling I've always had when people authoritatively talk about "decoupling HTML and CSS". The coupling is somewhere, and where it is causes tradeoffs that need to be considered.

torginus 6y ago

still, this does not explain, why I should use class="w-24" instead of style="width:24px;" Other than "inline style bad", when the first one is built into the browser, and a second one requires including an external dependency, that I imagine contains classes w-1 to w-1000 or whatever. Now I strain my IDE-s autocomplete with 1000s of classes, will need a css minifier/bundler (that will at least make my build slower). I'm not a frontend dev, but I do dabble in writing the occasional website, and other than bootstrap (which contains complete styles for stuff like buttons), I never felt the need to use a CSS framework. I get it that in pre-grid days, it was a minor feat of wizardry to implement complex layouts, but nowadays, frameworks seem largely unnecessary to me. Another added benefit of using pure CSS, is you just have to learn it once (with tons of great resources), while with these CSS frameworks, I'll need to learn what everything's called for every framework. Not sold.

dfabulich 6y ago
There's a section of Wathan's article, "Isn't this just inline styles?" That directly addresses this question. Perhaps you missed it? > With inline styles, there are no constraints on what values you choose. [With utility classes] you can't just pick any value want; you have to choose from a curated list.
- couchand 6y ago
  If the list is so long that the whole thing isn't even included by default and you need to custom configure which entries appear on the list, it's not that much better than arbitrary values.
yurishimo 6y ago
CSS classes can work with media queries while inline styles cannot. A ton of the classes that are generated are screen size variants. The IDE strain is overblown. There is an official Tailwind plugin for most IDEs and it performs well, even with the massive CSS files you use for development (but are purged/tree-shaken for production). Computers are really good at parsing text, and even at their worst, the CSS files are never more than a MB or two. Even if you enable ever single flag for every token, the dev file size is around 10MB I think. Big to load over the internet, but locally, and being parsed, not a huge problem at all.
leviathan 6y ago
except that w-24 is not 24px. It's 24 units of whatever your design grid says, so now you can use a design language to describe your layouts instead of absolute dimensions
- Vinnl 6y ago
  And for more information on why "24" there isn't just an arbitrary magic number like it was in the original inline style: https://styled-system.com/guides/why-powers-of-two/ https://styled-system.com/guides/why-powers-of-two/
davidwparker 6y ago
Here's why, media queries: class="w-24 sm:w-36 md:w-48" Now I have a nicely designed interface for multiple sizes and it just works.
jdminhbg 6y ago
Other people have noted that your `style` example isn't responsive, but on top of that, there's nothing stopping you (or a collaborator) from writing `style="width:26px;"` somewhere else in the app. Having a restricted set of options helps enforce consistency across a project and gives you a much nicer look by default. This is especially useful for devs doing frontend work without a strong design background.
mcrittenden 6y ago
This post may clear things up a bit (disclaimer, I wrote it): "Utility classes vs. inline styles": https://critter.blog/2018/05/04/utility-classes-vs-inline-styles/ https://critter.blog/2018/05/04/utility-classes-vs-inline-st...

ajcp 6y ago

> "Best practices" don't actually work. Don't try and master the hard stuff: you'll just fail! Take my magic pill! Applied to everything from weight-loss to front-end development.

climber_mac 6y ago
Most innovative ideas at first seem like bad ideas. Flipping conventional wisdom on its head takes a while. This talk by Dan Abramov helped me understand better how 'best practices' are often taken so literally that their value is lost: https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase https://www.deconstructconf.com/2019/dan-abramov-the-wet-cod...
- ajcp 6y ago
  I agree with you, Dan, and Adam Wathan for that matter. The point of my comment had more to do with front-loading of a pitch with copy specifically tailored for confirmation bias. Running to achieve weight loss can be hard. So much so that it's intended value can't be realized, or even be detrimental to the end goal. But I think we'd agree that anyone who simply says says "Running won't help you lose weight because it doesn't work, try this instead" is not seeking to help you, just sell you.
  - sbergot 6y ago
    Come one. This "pitch" is heavily contextualized. Interpreting it as "all best practices are bad" is not very charitable.
  - imbnwa 6y ago
    This was also React's initial pitch as well: getting DOM updates right is hard, use vDom instead! The truth is that the majority of frontend development is devs racing to shovle the latest stack of tickets that management cooked up with little collaboration or rhyme and reason into the Done column of JIRA (web dev is particularly imperiled by shitty lay management), any DX affordance they can get their hands on is valuable to this goal Concurrently, designers are pumping out comps as fast as possible to match pace with no real system cohering the whole thing, you need a design system to provide an "abstract interface", so to speak, for your CSS to really transcend into real separation. This is just what I've observed working at my comp

chias 6y ago

As another example of "am I crazy? No, it's the entire rest of the internet that's crazy" check out htmx [0]. It's another acknowledgement that best practices (for js / ajax) are not best in all circumstances, and has been a fantastic fit for most of my web projects. In practice, "the right way" is shorthand for "the right way for your project", and conventional wisdom / best practices are vital to know and understand so that you can recognize when they are a bad fit for what you need to do. [0] https://htmx.org/ https://htmx.org/

egeozcan 6y ago
I was going to mention how similar this is to intercooler then I saw: > htmx is the successor to intercooler.js

pc86 6y ago

Semantic CSS would be great if you could reliably unit-test style changes to semantic names within the IDE.

crusso 6y ago

Nice article. It manages to explain the uneasy feeling I've always had when people authoritatively talk about "decoupling HTML and CSS". The coupling is somewhere, and where it is causes tradeoffs that need to be considered.