3 ms·

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

MichaelMug 3y ago
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.
- tipiirai 3y ago
  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.
  - jonwinstanley 3y ago
    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.
  - unculture 3y ago
    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.
- teen 3y ago
  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.
tylerchilds 3y ago
heyo- i made https://www.cutestrap.com/ 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.
WA 3y ago
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.
asimpletune 3y ago
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?
DannyBee 3y ago
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.
- tipiirai 3y ago
  Thank you for the advice! You are right. I'll do that in my next article about Tailwind.

MichaelMug 3y ago

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.

tipiirai 3y ago
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.
- jonwinstanley 3y ago
  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.
- unculture 3y ago
  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.
teen 3y ago
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.

tylerchilds 3y ago

heyo- i made https://www.cutestrap.com/ 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.

WA 3y ago

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.

asimpletune 3y ago

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?

DannyBee 3y ago

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.

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