[m8s]

Jeez, you’d think you were on Reddit with all these comments.

Like it or not, Tailwind (and things that help people use Tailwind) serves a very valid niche. Unwrapping years of legacy CSS, intertwined with CSS injection in jQuery, is no simple feat. Adding Tailwind to that project and only writing Tailwind has helped immensely.

The downside is that there are times when you have a really long list of classes on a given tag, which can be difficult to read and parse. I’m not sure if this tool is right for me or my team, but that’s one use case I could see for using it.

Are we really complaining about emojis in READMEs nowadays? Good grief.

[sbergot]

I am saddened by all the negativity around those new css approach.

I like most HN threads but anything frontend is laughed at by people with little frontend experience. They repeat some truth they learned 20 years ago.

Honestly HN is not a good place to discuss frontend stuff. You will only see "get off my lawn" kind of comments.

[crubier]

I posted a negative comment here (look it up), and I can explain why I still believe my comment is constructive, and why I don't think I fit in "people with little frontend experience". It's not an appeal to authority, but more a rebuttal of you affirmation that HN is full of "non frontend people"

1. I have a passion for front end, I have a PhD in Human Computer Interaction.

3. I am the cofounder and CTO of a company whose main product is based on CSS-in-JS (Emotion, Chakra UI)

2. I really like Tailwind and used it on several production projects.

4. So I know very well both of these approaches. I know their advantages and drawbacks.

5. In my comment I state the sad truth about this particular project: It combines the worst of both approaches in terms of performance, without any added value as compared to these approaches. Slow build AND slow runtime, without any added modularity.

This approach is objectively bad and this is why people react like this.

And to be constructive: If you want to use tailwind, use tailwind and you will have performant runtime but less customizability. If you want to use CSS-in-JS, use it and you will have customizability, but slower runtime. Engineering is trade-offs, but twin is still the worst of both worlds.

[sbergot]

Your comment is completely valid. I am just reacting to the usual flow of hate toward any frontend library that do not follow the initial ways of the early days of html/js/css.

[crubier]

I agree on that actually, I’m generally annoyed by these HN comments like « this JS lib is shit because it’s more than 12kb, and why do you need JS anyway »

[brundozer]

You can combine together theses classes in another class name for reusability. I've been doing CSS for 15 years and I love tailwind. It's just a bunch of handful predefined classes but they encourage you to write everything in small, single-purposed classes that you combine together.

You can absolutely do that with CSS (and some people probably did for years), but having theses classes already available kind of shows you the way.