Comment by ksubedi | Hacker News Reader

Comment by ksubedi | Hacker News Reader

Parent Full thread

Seems like you are basing your opinions on some misconceptions. Let me try to clear that for you.

"CSS modules still seem to solve every problem Tailwind solves, and better."

- Not necessarily true. Unlike css modules, tailwind removes the whole "think about a name for your class" mindset, reducing friction from the development process. It also unifies some base level design decisions like spacing and colors, which developers would have to rely on "best practices" otherwise, which don't necessarily get strictly enforced.

"I'm not sure how Tailwind works, but any CSS that's built at runtime and JS and inserted into the DOM dynamically should be avoided, and is an example of favoring developer experience over end user experience."

- You are right, looks like you are not sure how Tailwind works. Tailwind does not build anything at runtime, it all happens at build time. Tailwind will compile only the things you need (using the new JIT mode) into a css stylesheet which is sent to the frontend. Not much different from how sass or scss works.

"CSS modules let you use the full power and control of vanilla CSS, without having to worry about styles bleeding across components."

- Tailwind does not stop you from using vanilla css, but in most cases you do not need to. As per their website, you can think of it as an API to use parts of CSS, instead of CSS replacement. I think you are confusing Tailwind as a replacement for something like CSS Modules, but those two are completely unrelated. You can still use CSS Modules while using Tailwind. Think of it as an api to your design sytem just like you could think of an ORM as an API to your database.

Aside from all of this. Try to use tailwind for 1 side project. You’ll see the difference of productivity when you remember most of the tailwind classes as opposed to having to open another css file, create a class, then reimport them.

I just can’t go back without tailwind.

I used Emotion for a few years (CSS-in-JS). I was so in love with it that I never thought I'd change to something else. But Tailwind converted me. I can't go back either, it's too powerful.

You can use both and gain the benefits of Tailwind-in-JS to dynamically apply utilities and arrays/objects of utilities composed together, all using a nifty wrapper library called "twin.macro".

It sits on top of Styled Components or Emotion (your choice), and uses your project's Tailwind config faithfully, minus a few of the plugin features.

It eliminates the need for JIT or PurgeCSS because it compiles Tailwind's utils with a drop-in Babel macro, eliminating the need for PostCSS.

As a lover of vanilla Tailwind in Vue and Svelte projects, Twin Macro has made using it in React 10x better and I haven't looked back! :)

+1, tried Tailwind and liked it, but when I found I was able to use CSS-in-JS with it with twin.macro i was amazed. Now is used on all my side projects.

Just checked it out, looks nice. What I'd really like is a more concise way to apply tw classes in jsx. Something like this:

  <Button
    h5
    w6
    bgBlue500
    textWhite
    hidden={props.hide}
  />

I'm curious how that would work with typescript since it's adding extra props like `css` and `tw` to components which don't exist in the types

It's Typescript-friendly, and if you use the Twin Intellisense extension for VSCode, it will autocomplete from all of the generated utilities in Tailwind, even the ones created from your own configuration of colors, spacing, etc.

Twin Macro has a few snippets of type definitions you can add to your project based on whether you're using Styled Components or Emotion, specifically to support these two props (tw and css).

They link to their Examples repo from the official readme with several projects using many different combos, with a handful of TypeScript ones.

JIT mode basically means it recompiles your styles before you can press reload on your browser.

Before they didn't have all colors enabled by default, because generating classes like `bg-blue-500`, `text-blue-500`, `border-blue-500`, etc. for all colors would increase the resulting CSS way too much. They did the same thing with variants.

With the JIT none of that is necessary anymore. Plus you can use arbitrary values because it's being compiled now.

And even that is less magic than it sounds. Unless it’s changed in v3, there’s just a regex matching stuff that could be a class name and building a rule for it.

    /[^<>"'`\s]*[^<>"'`\s:]/g

The other thing is, building css the traditional way, after refactoring and renaming things a bit, I usually end up with something that looks very similar to tailwind syntax anyway. So might as well have a flavour of that we can all refer to and agree on than each person having their own set of utilities and naming conventions. That way I don't have to explain or write elaborate comments - I can just point the person to the tailwind docs. So it solves that kind of problem for me.

> You can still use CSS Modules while using Tailwind

Recommended even. I use Tailwind with CSS Modules as a fallback when there's simply no way to achieve the result using Tailwind (rare) or it's prohibitively complicated/messy.

Also for CSS hacks if you need to support an older browser.

Reply on news.ycombinator.com