Live data from Hacker News

Tailwind UI

tailwindui.com

311–320 of 367 posts

Re: Tailwind UI

#311

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 de…

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.

Re: Tailwind UI

#312

Earlier quoted context omitted.

> In my experience trying to do semantic CSS just adds a lot of extra cognitive overhead. Do people really struggle with this? Heading Tagline It far more straight forward just to call something what it is and you can actually read the CSS afterwards.

Sure in a 4 line example it's fine. On a real site with 5 different kinds of hero elements, with some styles in common but a lot of small variations and each with its own responsive behavior it's not so easy anymore. Coming up with good names for things is one of the hardest jobs in programming and this style forces you to name everything . I've been building sites the way you suggest for 20 years. I also had a negat…

> Coming up with good names for things is one of the hardest jobs in programming and this style forces you to name everything.

People say that. If you build stuff in components like you are supposed to you almost always have a server side component or component logic that you will have to name. So you are going to have to start naming things properly somewhere.

You are simply kicking the can down the road.

> I've been building sites the way you suggest for 20 years. I also had a negative knee jerk reaction to tailwind.

It isn't a negative kneejerk reaction. I've worked with sites where they have done similar things to tailwind and it is a nightmare to understand what is going on with the page.

> But I had enough of an open mind to try it and now I have no interesting in going back.

The markup is almost unreadable, it completely defeats the point of what CSS is supposed to do and it creates considerable mental overhead for someone who isn't familiar with it.

But I suppose I shouldn't really expect anything else from other web developers that over the last 20 odd years somehow manage to not understand the tech they are given.

Re: Tailwind UI

#313
post #269

Earlier quoted context omitted.

My question is why you cant just name the card and then use selectors to style the title or any other internal styling? This removes the need to name at all. It can just be .card > h2 or whatever and there you would do your font-weight and color.

Because I don't want that cognitive overhead of even thinking about what the selector should be. Then what if I have another sub-sub text? Do I make that an h3? An h4? I don't want to have to think about that. I just make it "text-xs" and move on. I don't even need to move over to my css file at all - I stay within my template and stay within my flow. It seems crazy and counter-intuitive at first, but I find that it…

Something to consider: semantic HTML helps with accessibility.

Re: Tailwind UI

#314

Earlier quoted context omitted.

Your components often get bloated since you have to account for subtle business logic differences between views.

Isn't that what the container/component split is for? Presentation logic in a container, markup and styling in a component. If you need to reuse the same visual component in logically different contexts you create a new container that mangles the props as appropriate.

Yeah, you can. I've just seen this result in really complicated components. Other styles of CSS naturally separate presentation from html markup generation, so the cost of forking and specialized components is much lower.

Re: Tailwind UI

#315
post #269

Earlier quoted context omitted.

My question is why you cant just name the card and then use selectors to style the title or any other internal styling? This removes the need to name at all. It can just be .card > h2 or whatever and there you would do your font-weight and color.

Because I don't want that cognitive overhead of even thinking about what the selector should be. Then what if I have another sub-sub text? Do I make that an h3? An h4? I don't want to have to think about that. I just make it "text-xs" and move on. I don't even need to move over to my css file at all - I stay within my template and stay within my flow. It seems crazy and counter-intuitive at first, but I find that it…

I understand but then why not .card > *:nth-child(1) and then so on down the child list? You could get away with those two selectors to match anything with at least an initial name. No decisions except for the first name.

Some editors like Brackets allows you to edit other files online and handles css specially so you can edit it just by hovering over class names, etc.

Re: Tailwind UI

#316

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 de…

> 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?

Re: Tailwind UI

#317

Earlier quoted context omitted.

Because I don't want that cognitive overhead of even thinking about what the selector should be. Then what if I have another sub-sub text? Do I make that an h3? An h4? I don't want to have to think about that. I just make it "text-xs" and move on. I don't even need to move over to my css file at all - I stay within my template and stay within my flow. It seems crazy and counter-intuitive at first, but I find that it…

Something to consider: semantic HTML helps with accessibility.

Yes, but class names doesn't affect the semantics of their tags.

Re: Tailwind UI

#318
post #108

The problem with this IMO is that some enterprising person will just use regular tailwind (or another utility-css framework like tachyons) and re-implement all of these components and give it out for free, circumventing the license and killing the value of this. Normally with themes it would be time prohibitive to do so, but the nature of utility-css is that it's relatively straightforward to implement each component…

It might happen, but I don’t think it would kill the value. There are tons of free and pretty great UI kits, CSS themes, etc already. Adam Wathan has done a really good job building up a community around Tailwind, and that brand and goodwill is part of the value here, I think.

> There are tons of free and pretty great UI kits, CSS themes, etc already.

There are tons that look visually appealing, but very few I've found that take a component-based approach (where they document each component individually - or think about how they interplay with each other). I've found the CSS is usually muddled, they often have legacy build pipelines that has to be rewritten to fit with Webpack, and a distinct lack of flexibility.

If Adam solves that side, Tailwind UI will be worth the money.

If it causes other theme providers to up their game, even better.

Re: Tailwind UI

#319

I really like Tailwind's approach in some cases, it does make prototyping extremely fast. What I'm really missing (and I don't understand it doesn't exist) is a way to compose classes into a single class, to refactor collections of small utility classes into a meaningful class with semantic sense. Why can't I do something like: .my-class { use .text-sm use .text-gray use .bold } Kind of like calling several functions…

Other commenters have addressed ways to implement this.

But ideally, instead of extracting that specific collection of classes out to a class, extract out the HTML fragment into it's own template (or into it's own React Component or insert framework component abstraction here).

The cleaner separation now is:

1. classes represent some atomic unit that enforces (for that unit) some design system specification

2. html fragments represent a specific implementation composed of those atomic units

Re: Tailwind UI

#320

Earlier quoted context omitted.

Sure in a 4 line example it's fine. On a real site with 5 different kinds of hero elements, with some styles in common but a lot of small variations and each with its own responsive behavior it's not so easy anymore. Coming up with good names for things is one of the hardest jobs in programming and this style forces you to name everything . I've been building sites the way you suggest for 20 years. I also had a negat…

> Coming up with good names for things is one of the hardest jobs in programming and this style forces you to name everything. People say that. If you build stuff in components like you are supposed to you almost always have a server side component or component logic that you will have to name . So you are going to have to start naming things properly somewhere. You are simply kicking the can down the road. > I've be…

That markup is almost unreadable for you.

And despite your crude last jibe at web developers attracted to Tailwind's model, most competent web developers will be able to quite easily pickup this very sane CSS utility framework :)

Post reply on HN