Live data from Hacker News

Why Tailwind CSS Won

matt-rickard.com

81–90 of 559 posts

Re: Why Tailwind CSS Won

#81
post #49
post #24

Earlier quoted context omitted.

I can sum up what I like about Tailwind in the following code: ``` (in CSS) a.link { border: red; } a.link:hover { border: blue; } ``` ``` (in Tailwind) ``` It's much easier in Tailwind for me to see locally what's going on with that styling. If I lived in this code all the time, or I was good at structuring CSS, then maybe the first would be more appealing. But I'm a shit at CSS, it always turns into an unmaintainab…

Now imagine that you want to change the border color to yellow. Would you rather change a single line of CSS, or every single link on all your pages?

Tailwind done correctly would have you use another system like react/templates so that you still only have to modify one place.

In practice however I see a lot of copy paste in tailwind html so it doesn't work quite as well in reality.

Re: Why Tailwind CSS Won

#82
post #34
post #11

I don't get Tailwind. In my book, CSS is here to facilitate the style of multiple webpages by modifying a set of rules, and classes are here to mutualise said rules. With Tailwind, it looks like you design by writing HTML, which is the opposite of what CSS aims at. So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule. Every time I've had to work with Tailwind, it felt…

> So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule. Changing the CSS to apply site-wide changes sounds great in theory but after working in front-end since IE6, this almost never happens in practice. You're never certain how the styles cascade and indirectly affect things so you're afraid of changing the core CSS. Styles isolated to components is a much more scala…

I do use tailwind and I find it terribly convenient for some things, but this argument still seems to mostly stem from too many people doing css who are not great at designing css and are doing things they really should not.

How will I ever keep track of where I used px-6 and where md:px-4 in my templates and why, without semantic classes? Of course I can then build more solutions around that. Or I can accept that good css design is hard, just like any good software design is hard.

Re: Why Tailwind CSS Won

#83

Earlier quoted context omitted.

I don't feel this point is strong because when you look at some of the most popular Tailwind components or templates in the ecosystem, such as the one made by the Tailwind people, the Tailwind code is still pretty crazy.

> the Tailwind code is still pretty crazy. The rendered output is crazy, yes. But this argument applies to every JS framework ever created. Authoring the code is best encapsulated by components. If you look at the source files available for their paid templates, they are all componentized.

Most JS frameworks are as bad too!

Maybe the issue is that the giant pile of JS mess has created such a disaster that adding Tailwind doesn’t feel like making anything much worse.

I can buy that.

For what HTML is for (documents, web pages, etc.) CSS makes sense and Tailwind seems crazy.

If you’re trying to code an application, for now perhaps React + Tailwind and a mountain of NPM dependencies does actually make sense.

Really I think going back to application coding via something like WASM surely has to replace all that though.

Re: Why Tailwind CSS Won

#84
I don't think the last word has been spoken yet.

It's true that, as the OP claims, many developers are not writing HTML/CSS, they are writing JSX (or similar) so maintaining a separate CSS file is a context switch. Point taken, and well made. Also, the original HTML/CSS split made more sense when one was writing documents, not applications, and the author and designer/typesetter were separate people.

However, svelte (my current favourite framework) gives you the option of putting a CSS block in a component source file, which is compiled to be local to the component. For example if you put "h1 { color: red }" in a component, then effectively what you get is some kind of "h1.warning" rule. It just works in the background how you expect it to, doesn't interfere with anything else, and you don't have the context-switching overhead of separate files.

I know that svelte has a lower market share than some, and of course you can use tailwind together with svelte, but the claim that "writing CSS = switching files" is only true within the scope of e.g. React, not in general.

Re: Why Tailwind CSS Won

#85
post #11

I don't get Tailwind. In my book, CSS is here to facilitate the style of multiple webpages by modifying a set of rules, and classes are here to mutualise said rules. With Tailwind, it looks like you design by writing HTML, which is the opposite of what CSS aims at. So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule. Every time I've had to work with Tailwind, it felt…

I like to use tailwind with Svelte since I rarely reuse css but rather the component as a whole. It’s rare for two components to share a class/style

Re: Why Tailwind CSS Won

#86
post #48

In the start-up space, Tailwind is to product UI as Bootstrap was (or still is) to marketing-focused landing pages. It almost serves as a litmus test as to whether you work in a start-up like environment or an enterprise environment. If you are in a design or product function in a enterprise company in non-tech industry, you steer clear from Tailwind. But, I appreciate its usefulness for developer's who just don't wa…

Could you explain why you’d steer clear from it in enterprise environments?

Re: Why Tailwind CSS Won

#87
post #47
post #34

Earlier quoted context omitted.

> So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule. Changing the CSS to apply site-wide changes sounds great in theory but after working in front-end since IE6, this almost never happens in practice. You're never certain how the styles cascade and indirectly affect things so you're afraid of changing the core CSS. Styles isolated to components is a much more scala…

> this almost never happens in practice …so let's solve that by making it completely never happen?

Let's solve that by switching to a different abstraction that proves to be more useful. In this case, isolation-by-component instead of isolation-by-class.

I'm not the person you're replying to, but I'm in a similar position, and while I'm not in love with Tailwind*, it's successful because it's oriented around components rather than classes. In every project I've worked on, it has been far easier to manage the complexity of components over classes, because components link style and structure together, which usually end up very tightly coupled anyway. This limits the scope of the CSS you're writing a lot, making it a lot simpler to understand what any individual declaration is going to do - you know exactly where it's being used, you know exactly the HTML structure it's operating on, you can see exactly what it will do as a result.

* I use it a lot at work because it's very easy to get something written, but I find the pseudo-CSS DSL irritating if I need to write more complex queries. Something like CSS modules requires a bit more boilerplate to use, but you end up writing real CSS queries, which I find more natural. But this is personal preference.

Re: Why Tailwind CSS Won

#88
post #24
post #11

I don't get Tailwind. In my book, CSS is here to facilitate the style of multiple webpages by modifying a set of rules, and classes are here to mutualise said rules. With Tailwind, it looks like you design by writing HTML, which is the opposite of what CSS aims at. So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule. Every time I've had to work with Tailwind, it felt…

I can sum up what I like about Tailwind in the following code: ``` (in CSS) a.link { border: red; } a.link:hover { border: blue; } ``` ``` (in Tailwind) ``` It's much easier in Tailwind for me to see locally what's going on with that styling. If I lived in this code all the time, or I was good at structuring CSS, then maybe the first would be more appealing. But I'm a shit at CSS, it always turns into an unmaintainab…

It's too bad that SASS has fallen out of favor. With SASS, that would have been:

```

  a.link
    border: red

    &:hover
      border: blue
```

Re: Why Tailwind CSS Won

#89
I like using Tailwind. There's good reference online to help style pages. I usually find what I need, copy it, and it works most of the time. Since I don't know much about UI, Tailwind helps me get the job done.

Re: Why Tailwind CSS Won

#90
post #24
post #11

I don't get Tailwind. In my book, CSS is here to facilitate the style of multiple webpages by modifying a set of rules, and classes are here to mutualise said rules. With Tailwind, it looks like you design by writing HTML, which is the opposite of what CSS aims at. So if you wish to change your design, you'll have to update multiple templates instead of one CSS rule. Every time I've had to work with Tailwind, it felt…

I can sum up what I like about Tailwind in the following code: ``` (in CSS) a.link { border: red; } a.link:hover { border: blue; } ``` ``` (in Tailwind) ``` It's much easier in Tailwind for me to see locally what's going on with that styling. If I lived in this code all the time, or I was good at structuring CSS, then maybe the first would be more appealing. But I'm a shit at CSS, it always turns into an unmaintainab…

The tailwind version is actually horrible, don't do this: you are supposed to style all the links in the same way, as with the css example, not style each link in it's own way; or you will get a link red, another one blue, another one yellow, and your ux will be crappy and your code unmaintainable
Post reply on HN