Hacker News Reader

Comment by tipiirai | Hacker News Reader

Author here: This is probably the most important content piece I've ever written. Curious to hear your thoughts. Thank you!

View on HN

I don’t like Tailwind. But you probably have it the wrong way. You claim malicious intent such as vendor lock-in. Your article sounds as if all this was planned as a cash grab from the beginning. The more likely development path of Tailwind was:

1. Create a utility CSS system, use it, feels nice, publish an article around it why it might make sense and why it feels nice (which is probably a hindsight explanation)

2. People start using it, way more than ever expected.

3. Iterate on the product

That’s it. I’m pretty sure nothing about this was planned, the vendor-lockin wasn’t planned and just happened.

While your arguments about inconsistencies about semantic components in Catalyst vs semantic class names are right, it is highly likely your assumptions are missing a critical piece, because there are clearly many happy users.

I share your sentiment and position on Tailwind. My first introduction to programming was in 2003 as a 10 year old with HTML CSS and PHP. I think we will see Tailwind, like other frontend tech, fade into the sea of choices.

If I had to summarize this I'd say don't fall victim to hype cycle and marketing. Make technical choices based on the problems.

I've worked on teams where CSS was a mysterious language with many gotchas. So I can see how Tailwind can help with this.

I can also see how Tailwind can help teams that just want to move forward by copy/pasting ready-made components without ever looking "under the hood".

However, I wrote this article for the love of CSS, web standards, and the web in general. I think Tailwind's dishonest marketing tactics aren't doing good for the development community. Especially for young developers who are suddenly told that things like separation of concerns and good naming practises are a bad thing.

In your article you highlighted that semantic markup can be much cleaner using a class like “primary”.

But in that instance, all of those css rules will still exist, but they’re stored in a separate css file and given a class name.

Having the reusability at the css class level means that someone else might break your component by updating the css.

With Tailwind, the reusability is at the component level. All the styles are self contained. No one can break your component accidentally.

You really need to cut out these accusations of dishonesty - it’s a bad look.

He’s not saying “separation of concerns and good naming practices” are bad things, he’s saying that separation of concerns between HTML and CSS is mostly a false separation (it’s the same concern - making the UI look right) and that good naming practices are hard - best just do that in one place, the component that address the concern with both style and structure.

I've been doing CSS for 20 years, Tailwind indeed lives up to the hype. Just the fact that amount of CSS code you need to send down the wire stops scaling linearly with each new component is a big benefit in its own right.

heyo- i made https://www.cutestrap.com/ and even though i haven't been using it much anymore, i share it to say I've thought a lot about CSS and I agree with your sentiments.

I think a lot of the complexity in CSS is accepted because of complexity in other parts of the stack. I've dug pretty deep into real-world use cases of many approaches to front end and ultimately, tailwind solves the #1 issue people encounter daily.

Fear Of Breaking Something Else Entirely

by never leaving the html tag for a secondary resource, confidence today is gained at the cost of future compound complexity.

as someone that specializes in design systems, tailwind breaks my heart because it it fairly reductive in expression. Truly white-labeling a product is not as simple as changing variables, it is more like a zen garden of css.

Advice from a professional arguer:

You seem to deliberately not present tailwinds strongest arguments. For example, you claim their is no next step to abstraction, but literally in the paragraphs before the ones you quoted they say to build reusable html+css components instead of trying to make css only abstractions. Which very clearly responds to your argument and complaint.

There are other places in your writing like this.

It's fine to think and claim they are wrong. But it would be a lot more persuasive if you take them at their best and knock them down, instead of being selective.

Overall take their absolute best case scenarios and reasons and show why you are still right.

Thank you for the advice! You are right. I'll do that in my next article about Tailwind.

I had a question for the author. Have you used Tailwind to build a project before? Or what has been your personal experience so far with the framework?

Reply on news.ycombinator.com