Hacker News new | ask | show | jobs
by luketheobscure 2305 days ago
Tailwind is fantastic. Everyone goes through the initial shock of complaining about the "ugly markup", the violation of separation of concerns, etc. But I've worked in enough large codebases to tell you that the ones that use Tailwind have a more consistent UI, with much less handwritten CSS. Bootstrap sites inevitably devolve into a soup of custom CSS and Bootstrap framework. You end up with lots of verbose class declarations like "btn btn-link btn-primary btn-xs danger", but you still need lots of little `margin-left: 3px` rules to push and pull things into place. Most other CSS libraries suffer the same fate.

On the other side of things, sites without a framework generally opt for a convention like "BEM" (block-element-modifier). BEM seems to be the worst of both worlds, both abandoning the "cascading" part of "Cascading Style Sheets" and still requiring verbose class names!

I've been working on a Tailwind project for the last six months with a team of around 8 people. We did a bunch of initial work getting the Tailwind config just right and some base styling in place, but since then we've barely written a line of CSS. Yes, the templates are verbose, but they are also incredibly readable and easy to reason about what classes are doing what. On-ramping new people has been easy as well, since they don't have to learn some custom system, instead they can just read the docs on the Tailwind site.

6 comments

I agree with you about Tailwind, but had to call you out on this:

> BEM seems to be the worst of both worlds, both abandoning the "cascading" part of "Cascading Style Sheets" and still requiring verbose class names!

BEM doesn't abandon the cascade (or really care about it). What BEM is actually pushing back on is rule specificity. For example:

  #navbar a { color: blue }
  /* Can't do this, it doesn't change my navbar-submenu colors */
  .navbar-submenu { color: inherit }
  /* Have to do this as a workaround */
  #navbar .navbar-submenu { color: inherit }
And now I'm in an arms race with myself over rule specificity.
I think BEM is often misunderstood, it's not immediately obvious to beginners why it's helpful. Specificity is one problem it helps solve as you mentioned but the biggest thing for me is it forces you to think about what an element is and who it belongs to.

If someone writes '.nav a' they're saying "select all links inside of nav", but what they really wanted to say was "select all nav menu links, and nothing else", a class like '.nav__link' will never select other links that happen to be in the nav (CTA buttons, logo links, etc) and will survive markup restructuring, something like ".nav > ul > li > a' will not survive minor markup changes as it doesn't express what someone wanted to select in the first place. I think this way of thinking brings a lot of benefits that most CSS frameworks don't give.

> Everyone goes through the initial shock of complaining about the "ugly markup", the violation of separation of concerns, etc.

Hmm, that's not really my main concern. My main initial feeling is that it feels like just as much work as writing plain CSS?

For comparison, I've been using Bulma for a lot of my projects so far, and given that many websites/web apps really don't have any special unique layout, it's covered my use cases very well so far, to the extent that I really don't recognise the anecdote of needing lots of little `margin-left: 3px` rules. (Though a magic number like that would be a red flag anyway...)

The primary benefit that Bulma gives me there is that it's just much less work! I really don't need to throw together some shadows, rounded corners, borders, etc. to make something look like a card, but I can just use Bulma's `card` class, and set some global settings w.r.t. colours and dimensions.

Is there a reason I might be interested in Tailwind still?

>Is there a reason I might be interested in Tailwind still?

Bulma or Bootstrap are ok if you stick to the defaults, but it get's tricky if you work with different fonts, icons and graphics in general, where you often have to make small adjustments to align things.

Everything sits in their own little bounding box and might look off next to another element. Tailwind and other utility based systems with generous enough sizing scales make it easier to make those small adjustments.

Sure you could re-center icons from your icon libraries manually within a design tool and adapt their bounding boxes to fonts this way, but it's a time consuming task.

Personally I think css utils are better suited for layout related stuff, acting more like layout primitives (hbox, vbox) etc since those tend to be pretty ad-hoc.

As far as concrete UI components go, I'm not sure this technique is any better, especially since you often need pretty ad-hoc styling with pseudos etc.

I think if CSS had built-in mixin support you could have the best of both worlds pretty easily, still crossing my fingers we get that some day, would be nice to drop all these build systems.

Did the Tailwind projects use the @apply directive, or just plain Tailwind classes all the way? Asking because I wonder how Tailwind deals with project wide style changes. With traditional CSS you just update the class in one location, with functional CSS you have to hunt down every location where the class was used.
You create components and reuse them.
Agreed, after switching to tailwind, writing CSS became very rare for me.
Hey, is any of you Tailwind UI websites public? Would love to see it!
It just came out. Nobody is using it in prod yet.