10 ms·

just got parachuted into a tailwind project. have to say I don't fully get it. the major stumbling block has been how tailwind is mostly just css translated in

just got parachuted into a tailwind project. have to say I don't fully get it. the major stumbling block has been how tailwind is mostly just css translated into its own hard-to-memorize lingo. For example, say I want to do something basic like "display:flex; justify-content: start". In tailwind you would type "flex justify-start" instead. Which doesn't really follow any rules as far as how to get from A to B, so it's just a matter of having to look the magic word up in their docs each time until you memorize. And there are a lot of keywords (many modifiable according to n-dimensional properties) to memorize. I know there are handy slugs like "w-1/3" that encapsulate a best practice - but I'm a person who'd rather master the underlying mechanics of that best practice and be able to deploy, tweak and debug it myself.

dcre 5y ago
The difference is you type that lingo inline into the HTML instead of in separate files and you don't have to come up with any class names.
- animal_spirits 5y ago
  Coming up with variable/class names is one of the most annoying aspects of programming, so any way we can eliminate that task I think is always going to be a productivity boom
  - seph-reed 5y ago
    So strange. Using good variable names is even better than docs in my experience. And having HTML where every div is named helps a ton. It blows my mind how different people's preferences can be on these things.
    - cwaffles 5y ago
      Memorizing and looking up names has significant impact on my productivity, especially on codebases that I do not touch frequently. I often losing my train of thought or momentum because of too much abstraction
    - d3ckard 5y ago
      Most people suck at naming things. Also, most companies don’t have a strong culture for choosing names carefully. Honestly, I agree with you on the good variable names, but in average team setting I prefer no names than bad ones.
  - jeremyjh 5y ago
    Yes, communicating intent to other programmers and our future selves is hard, so let's not do it.
    - iovrthoughtthis 5y ago
      well, sometimes. yes. the semantics of most html elements is useless to know for more devs (and classes don't help users) in fact a class like .red conveys more useful information to a developer than .standout-link because when we go to change the colour of the button it's the colour we care about, not the "purpose" of the button
- tlamponi 5y ago
  Sounds a bit like a glorified <el style="display:flex;justify-content: start;">... ?
  - moritzwarhier 5y ago
    The differences are: * media queries * @apply * low specificity (tailwind doesn't do !important) EDIT: It "does" important, but only when instructed so, in 1.x it was a global switch, apparently since 2.x its available as a per-class modifier. Thanks dcre * the theming abstraction * brevity
    - dcre 5y ago
      Tailwind does have important, it was added with JIT. https://tailwindcss.com/docs/just-in-time-mode#built-in-important-modifier https://tailwindcss.com/docs/just-in-time-mode#built-in-impo...
      - aidos 5y ago
        Oh, nice, I think that’s a new 3.0 thing, not a JIT thing.
        dcre 5y ago
        Looks like TW 2.2 from June. It wasn't in the initial JIT release in 2.1. https://github.com/tailwindlabs/tailwindcss/releases/tag/v2.2.0 https://github.com/tailwindlabs/tailwindcss/releases/tag/v2....
        aidos 5y ago
        I’m…not sure how I missed that, because I did look for it. Thanks for the heads up!
    - deleted 5y ago
      [deleted]
    - 5y ago
- marstall 5y ago
  that gets long - especially if they are rendered inline, hard to scan through. I'm often in a cycle where I am tweaking a complex class with 10-20 properties including flex, transforms, animations, etc. - and having them each be on their own line (and the class being in a separate file along with its parents, siblings and children, frankly) is key for readability to me. I guess in the end I have come to have enormous respect for CSS as a powerful, mature language and I'm not looking to be buffered from it.
  - dcre 5y ago
    I don't think of it as an alternative to CSS. I think of it as a way of writing CSS. It can get long. I certainly have parts of my app where I break out into plain CSS because it's easier to understand.
    - docmars 5y ago
      I put most of my Tailwind utilities on their own line in my HTML, and for elements that need more than 3 or 5, I do the same but in classes or styled components where I'm listing them off instead. Keeps everything clean and readable!
- agumonkey 5y ago
  For toying / prototyping it's way nicer than I'd ever expect. Seriously fun. I now inject tailwing anywhere possible.
- bamboozled 5y ago
  This, I've used it only for about a week, there's no way I could go back now.
  - matijs 5y ago
    You’re not wrong. Once it’s in there, it’s not easy to remove/replace again.
- matijs 5y ago
  Those files (and components) still need sensible names (that would make very nice class names).
ponyous 5y ago
Yeah that's my issue as well and so much divitis and unnecessary nesting...
- aidos 5y ago
  Can you explain what you mean by this? You’re still applying css to html elements, it’s nothing different, right?
jesusthatsgreat 5y ago
The beauty of it comes when you're working in a team of say 5 other front end devs of varying skill levels. There tends to be a large amount of duplication & overlap, people have different ways of doing things and achieving certain looks. If everyone agrees to use tailwind, you stop people from writing custom code which is ultimately a good thing because custom code requires custom comments and custom documentation etc which let's face it - nobody does or wants to do and even if they do, it's not maintained to the sort of standard tailwind docs are.
- aidos 5y ago
  Not to mention, if your css isn’t scoped (and let’s face it, this is one thing traditional css sucks at) you just never quite know what rule some developer has put in somewhere at what else it effects.
seanwilson 5y ago
> the major stumbling block has been how tailwind is mostly just css translated into its own hard-to-memorize lingo. Autocompletion in your IDE makes this easy (the class names are similar to the CSS attributes, even in your examples, so you can usually guess them) and you use the same classes over and over again so you learn them quick. I barely spent 10 minutes in the Tailwind documentation the first few days because of the VSCode extension.
- marstall 5y ago
  ah yes - that would be a big help. alas I am not a vscode user. I use webstorm and haven't been able to figure out how to get tailwind autocomplete to work with it.
  - jpbow 5y ago
    There's a plugin that you have to install to get it going https://www.jetbrains.com/help/webstorm/tailwind-css.html https://www.jetbrains.com/help/webstorm/tailwind-css.html
    - marstall 5y ago
      oh I forgot to mention. ember. it's an ember project. something about handlebars not being supported yet.
  - superfad 5y ago
    Other than autocomplete, I would also suggest using this cheat sheet to help you: https://nerdcave.com/tailwind-cheat-sheet https://nerdcave.com/tailwind-cheat-sheet
BoorishBears 5y ago
I don't do frontend except when I have to and "flex justify-start" is way easier for me to learn and explore with than "display:flex; justify-content: start" And the keywords all seem to make sense to me? It's "n-dimensional properties" but the dimensions are pretty consistent...
skipants 5y ago
In my experience it's because any web app with complicated styling rules tends towards this anyways, except all the CSS names are custom, undocumented, and duplicated. The main tradeoff is that the CSS names are not domain specific, but honestly that's worked fine for me.
psygn 5y ago
I hear you. I don't understand the reasoning behind frameworks propensity to abbreviate things, especially at "atomic"/utility levels. I think it partially stems from wanting to prevent ignorant knee-jerk reactions like "hurr durr why not just write inline styles". I wish framework devs would just hyphenate (or even colon-ize) the CSS property names fully like "display-flex justify-content-start". I think Bootstrap does their own pattern like "d-flex", but all that does is require one to visit the docs to view some less common properties. Autocompletion pretty much makes typing these a breeze, and having less opinionated patterns for property names will make it less painful transitioning between frameworks.
- aidos 5y ago
  I think that’s a little uncharitable. One thing to consider is that being a bit more terse in tailwind is good because you effectively end up with media queries, dark mode, hover states etc all placed together.
BadCookie 5y ago
Consider using this handy Tailwind cheat sheet: https://nerdcave.com/tailwind-cheat-sheet https://nerdcave.com/tailwind-cheat-sheet I have it open in a browser tab almost constantly.
- docmars 5y ago
  This is wonderful, thanks for sharing!
docmars 5y ago
Try using an IDE extension for autocompleting Tailwind's utilities based on your tailwind.config.js. Twin Macro is a great wrapper library for Tailwind-in-JS with strong IDE support and it autocompletes all my utilities. I barely have to type anything to style everything in my project. I can even hover over utilities to peek at its raw CSS. https://marketplace.visualstudio.com/items?itemName=lightyen.tailwindcss-intellisense-twin https://marketplace.visualstudio.com/items?itemName=lightyen...
the__alchemist 5y ago
Spot on. Whenever you add a DSL like this, you need to carefully weigh costs and benefits. A hidden downside is that every new person who views your code base (And you in the future!) has to become proficient with the DSL. The base tech it wraps (HTML + CSS) is more fundamental; less overhead. Another way of saying this, is that Tailwind adds cognitive overhead.
- iovrthoughtthis 5y ago
  the classes you define become the new dsl though. so you keep the overhead of learning + the effort of writing and maintaing your own dsl
meerita 5y ago
> the major stumbling block has been how tailwind is mostly just css translated into its own hard-to-memorize lingo. This is the only problem of tailwind, it relies on its own lingo, as all the OOCSS/BEM projects. When you involve semantics, you will always bring these kind of problems. I covered this problem and I solved it with this approach http://minid.net/2019/04/07/the-css-utilitarian-methodology/ http://minid.net/2019/04/07/the-css-utilitarian-methodology/
papertokyo 5y ago
You have to learn the more verbose CSS properties in the first place, and the vast majority of tailwind's class names include the unique keywords of those anyway.

dcre 5y ago

The difference is you type that lingo inline into the HTML instead of in separate files and you don't have to come up with any class names.

animal_spirits 5y ago
Coming up with variable/class names is one of the most annoying aspects of programming, so any way we can eliminate that task I think is always going to be a productivity boom
- seph-reed 5y ago
  So strange. Using good variable names is even better than docs in my experience. And having HTML where every div is named helps a ton. It blows my mind how different people's preferences can be on these things.
  - cwaffles 5y ago
    Memorizing and looking up names has significant impact on my productivity, especially on codebases that I do not touch frequently. I often losing my train of thought or momentum because of too much abstraction
  - d3ckard 5y ago
    Most people suck at naming things. Also, most companies don’t have a strong culture for choosing names carefully. Honestly, I agree with you on the good variable names, but in average team setting I prefer no names than bad ones.
- jeremyjh 5y ago
  Yes, communicating intent to other programmers and our future selves is hard, so let's not do it.
  - iovrthoughtthis 5y ago
    well, sometimes. yes. the semantics of most html elements is useless to know for more devs (and classes don't help users) in fact a class like .red conveys more useful information to a developer than .standout-link because when we go to change the colour of the button it's the colour we care about, not the "purpose" of the button
tlamponi 5y ago
Sounds a bit like a glorified <el style="display:flex;justify-content: start;">... ?
- moritzwarhier 5y ago
  The differences are: * media queries * @apply * low specificity (tailwind doesn't do !important) EDIT: It "does" important, but only when instructed so, in 1.x it was a global switch, apparently since 2.x its available as a per-class modifier. Thanks dcre * the theming abstraction * brevity
  - dcre 5y ago
    Tailwind does have important, it was added with JIT. https://tailwindcss.com/docs/just-in-time-mode#built-in-important-modifier https://tailwindcss.com/docs/just-in-time-mode#built-in-impo...
    - aidos 5y ago
      Oh, nice, I think that’s a new 3.0 thing, not a JIT thing.
      - dcre 5y ago
        Looks like TW 2.2 from June. It wasn't in the initial JIT release in 2.1. https://github.com/tailwindlabs/tailwindcss/releases/tag/v2.2.0 https://github.com/tailwindlabs/tailwindcss/releases/tag/v2....
        aidos 5y ago
        I’m…not sure how I missed that, because I did look for it. Thanks for the heads up!
  - deleted 5y ago
    [deleted]
  - 5y ago
marstall 5y ago
that gets long - especially if they are rendered inline, hard to scan through. I'm often in a cycle where I am tweaking a complex class with 10-20 properties including flex, transforms, animations, etc. - and having them each be on their own line (and the class being in a separate file along with its parents, siblings and children, frankly) is key for readability to me. I guess in the end I have come to have enormous respect for CSS as a powerful, mature language and I'm not looking to be buffered from it.
- dcre 5y ago
  I don't think of it as an alternative to CSS. I think of it as a way of writing CSS. It can get long. I certainly have parts of my app where I break out into plain CSS because it's easier to understand.
  - docmars 5y ago
    I put most of my Tailwind utilities on their own line in my HTML, and for elements that need more than 3 or 5, I do the same but in classes or styled components where I'm listing them off instead. Keeps everything clean and readable!
agumonkey 5y ago
For toying / prototyping it's way nicer than I'd ever expect. Seriously fun. I now inject tailwing anywhere possible.
bamboozled 5y ago
This, I've used it only for about a week, there's no way I could go back now.
- matijs 5y ago
  You’re not wrong. Once it’s in there, it’s not easy to remove/replace again.
matijs 5y ago
Those files (and components) still need sensible names (that would make very nice class names).

ponyous 5y ago

Yeah that's my issue as well and so much divitis and unnecessary nesting...

aidos 5y ago
Can you explain what you mean by this? You’re still applying css to html elements, it’s nothing different, right?

jesusthatsgreat 5y ago

The beauty of it comes when you're working in a team of say 5 other front end devs of varying skill levels. There tends to be a large amount of duplication & overlap, people have different ways of doing things and achieving certain looks. If everyone agrees to use tailwind, you stop people from writing custom code which is ultimately a good thing because custom code requires custom comments and custom documentation etc which let's face it - nobody does or wants to do and even if they do, it's not maintained to the sort of standard tailwind docs are.

aidos 5y ago
Not to mention, if your css isn’t scoped (and let’s face it, this is one thing traditional css sucks at) you just never quite know what rule some developer has put in somewhere at what else it effects.

seanwilson 5y ago

> the major stumbling block has been how tailwind is mostly just css translated into its own hard-to-memorize lingo. Autocompletion in your IDE makes this easy (the class names are similar to the CSS attributes, even in your examples, so you can usually guess them) and you use the same classes over and over again so you learn them quick. I barely spent 10 minutes in the Tailwind documentation the first few days because of the VSCode extension.

marstall 5y ago
ah yes - that would be a big help. alas I am not a vscode user. I use webstorm and haven't been able to figure out how to get tailwind autocomplete to work with it.
- jpbow 5y ago
  There's a plugin that you have to install to get it going https://www.jetbrains.com/help/webstorm/tailwind-css.html https://www.jetbrains.com/help/webstorm/tailwind-css.html
  - marstall 5y ago
    oh I forgot to mention. ember. it's an ember project. something about handlebars not being supported yet.
- superfad 5y ago
  Other than autocomplete, I would also suggest using this cheat sheet to help you: https://nerdcave.com/tailwind-cheat-sheet https://nerdcave.com/tailwind-cheat-sheet

BoorishBears 5y ago

I don't do frontend except when I have to and "flex justify-start" is way easier for me to learn and explore with than "display:flex; justify-content: start" And the keywords all seem to make sense to me? It's "n-dimensional properties" but the dimensions are pretty consistent...

skipants 5y ago

In my experience it's because any web app with complicated styling rules tends towards this anyways, except all the CSS names are custom, undocumented, and duplicated. The main tradeoff is that the CSS names are not domain specific, but honestly that's worked fine for me.

psygn 5y ago

I hear you. I don't understand the reasoning behind frameworks propensity to abbreviate things, especially at "atomic"/utility levels. I think it partially stems from wanting to prevent ignorant knee-jerk reactions like "hurr durr why not just write inline styles". I wish framework devs would just hyphenate (or even colon-ize) the CSS property names fully like "display-flex justify-content-start". I think Bootstrap does their own pattern like "d-flex", but all that does is require one to visit the docs to view some less common properties. Autocompletion pretty much makes typing these a breeze, and having less opinionated patterns for property names will make it less painful transitioning between frameworks.

aidos 5y ago
I think that’s a little uncharitable. One thing to consider is that being a bit more terse in tailwind is good because you effectively end up with media queries, dark mode, hover states etc all placed together.

BadCookie 5y ago

Consider using this handy Tailwind cheat sheet: https://nerdcave.com/tailwind-cheat-sheet https://nerdcave.com/tailwind-cheat-sheet I have it open in a browser tab almost constantly.

docmars 5y ago
This is wonderful, thanks for sharing!

docmars 5y ago

Try using an IDE extension for autocompleting Tailwind's utilities based on your tailwind.config.js. Twin Macro is a great wrapper library for Tailwind-in-JS with strong IDE support and it autocompletes all my utilities. I barely have to type anything to style everything in my project. I can even hover over utilities to peek at its raw CSS. https://marketplace.visualstudio.com/items?itemName=lightyen.tailwindcss-intellisense-twin https://marketplace.visualstudio.com/items?itemName=lightyen...

the__alchemist 5y ago

Spot on. Whenever you add a DSL like this, you need to carefully weigh costs and benefits. A hidden downside is that every new person who views your code base (And you in the future!) has to become proficient with the DSL. The base tech it wraps (HTML + CSS) is more fundamental; less overhead. Another way of saying this, is that Tailwind adds cognitive overhead.

iovrthoughtthis 5y ago
the classes you define become the new dsl though. so you keep the overhead of learning + the effort of writing and maintaing your own dsl

meerita 5y ago

> the major stumbling block has been how tailwind is mostly just css translated into its own hard-to-memorize lingo. This is the only problem of tailwind, it relies on its own lingo, as all the OOCSS/BEM projects. When you involve semantics, you will always bring these kind of problems. I covered this problem and I solved it with this approach http://minid.net/2019/04/07/the-css-utilitarian-methodology/ http://minid.net/2019/04/07/the-css-utilitarian-methodology/

papertokyo 5y ago

You have to learn the more verbose CSS properties in the first place, and the vast majority of tailwind's class names include the unique keywords of those anyway.