Hacker News .hnnew | past | comments | ask | show | jobs | submitlogin

I don't get why you wouldn't use LESS mixins or SASS class extensions (or whatever the modern equivalent of that is) instead of inlining each utility class directly into each div.

Having a name for each element in your markup is really powerful and useful, and it seems like the Tailwind approach exists specifically to avoid having to name things.



I think the thought process is that if you are using Tailwind it's probably with a component based system like React. So you don't need a button "name" because you have a button component. You re-use components instead of classes.

This makes it so you don't have to remember all the names specific to the project (or learn an existing projects css names).

I've never used Tailwind myself so I am not advocating it per say, just explaining how I understand it.


After 20+ years of HTML, CSS I started to use Tailwind for a new project. Using web components (disabling the shadow dom unfortunately).

You guessed it right. There is no need for named selectors anymore.

And you get the advantages of standardisation. People can share snippets of code you can reuse as is.

And when you have a problem, you are probably not the first to have it, and can quickly find a solution on youtube, stack overflow, etc.


Embracing components over classes is what helped me understand and appreciate functional CSS (Tachyons, Tailwind, etc). Lots of headaches removed when the DOM structure finally 1:1 reflects the style inheritance structure, without having to maintain the latter separately.


the code-reuse is such a boon


Exactly. When using something like React, the abstraction of using classes to create reusable components is redundant with the framework's, and thus no longer carries its weight. Especially considering how, in practice, that abstraction isn't that effective in the first place: it's rare that a layout change involves just a CSS change. (I'm somewhat rehashing from a blog post of mine [1] here - if anyone wants this more extensively argued they can read that.)

[1] https://vincenttunru.com/why-tailwind/#the-right-abstraction


Also you avoid writing CSS and designing like before CSS existed. Its more messy but a bit easier to learn then CSS. CSS is simply too advanced and powerful it takes years to master. Ohh and you can copy/paste components into your spaghetti code.


>Also you avoid writing CSS and designing like before CSS existed.

I know this is controversial because of the web dev canon of "lol CSS sucks", but many people really love CSS, and find it incredibly powerful and enjoyable to use. If you put in the time to truly learn it, these tools seem silly and redundant.


So you're using Tailwind fine, but find CSS too advanced? But you gotta master CSS to know what Tailwind is doing.

Otherwise, you're just improvising.


Naming things sucks though.

In my experience you tend to end up in a weird thought experiment trying to work out what the third child of the body of a card should be called when actually you just want it to be bold with some padding.

As other people have said, naming things also becomes totally redundant when you’re using something like React or Vue where the abstraction is a component which is itself already named.


Author here, I have a few custom classes that look like more traditional CSS. Tailwind gives an example[0] of how to do this in their docs. I have about 15 of these extracted classes. I use them for common styling patterns, such as transforming "flex items-center justify-center" to "flex-center," or to unify styling on components I haven't abstracted into a styled version, such as "listbox-option" or "flyout."

[0] https://tailwindcss.com/docs/extracting-components#extractin...


I've been considering an approach like this, but I don't want to risk going back down the path of "having to name things".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: