Live data from Hacker News

Tailwind CSS marketing and misinformation engine

nuejs.org

51–60 of 125 posts

Re: Tailwind CSS marketing and misinformation engine

#51
I believe there are two problems Tailwind tries to solve: styling and layout.

For laying out items it might be useful but for styling it is not (why would you create a separate component for each HTML element, like a button!?).

And I even don't get the styling example in the article.

Why would you use a 'primary' class on a button while the button type makes it primary?

If you style your submit button with `button[type=submit]` you are sure all submit buttons in your app look the same. There is no need to use classes. (I also never understood why it is common to add a 'table' class to a table.)

I think the main reason why most CSS files become such a mess is that style and layout are not separated.

Re: Tailwind CSS marketing and misinformation engine

#52
The key point in this article is not Tailwind.

It is the endless susceptibility by software developers to marketing campaigns.

There are real costs to the use of any tool and these are completely glossed over by someone looking to sell you goods or services.

Here are some very real costs: technical attrition, maintenance, and training.

Technical attrition: Perhaps some people would use the terms amortization or depreciation, but I consider software to be in a separate class than intangible or tangible assets, the point being, there is a rather short shelf life for almost any technical product. CSS isn't going anywhere but tools like Bootstrap will come and go.

Maintenance: The old version of a CSS wrapper will stop receiving support and require upgrading to the new version which will take significant time and effort.

Training: There are orders of magnitude more individuals that know CSS than know Tailwind and they will be less productive for a given period of time.

Re: Tailwind CSS marketing and misinformation engine

#53
post #44

Earlier quoted context omitted.

I have for many years! And this block needs media queries and stuff for active and other states. That line you quote is .primary>[data-slot=icon] { margin-left: -0.5rem; margin-right: -0.5rem: }

And you still need 60+ lines to create a button like that?

Come on - your turn. Come back with your version of that Catalyst button that does everything that’s being done by those Tailwind styles.

Re: Tailwind CSS marketing and misinformation engine

#54
post #13

Like many I was initially skeptical of Tailwind because I thought it made the code look “ugly”. But then I started using and almost immediately noticed the productivity boost. Two things that I noticed while using it was 1) I never knew how much I disliked naming things before I didn’t need to do that anymore and 2) how big of a mental burden it was to keep the mapping between the id/classes and the CSS, not mentioni…

Naming things is notoriously hard, but it's a skill you need to master to make reusable things. You name things that repeat. Think of function names in JavaScript, class names in object-oriented languages, or component names in Figma.

You can still name things in Tailwind + React (create a new component or variant), what changes is that if I need to add a 10px margin on the right I don't have to create a new component (like when using styled components), I simply override `className` and move on.

Re: Tailwind CSS marketing and misinformation engine

#55

Tailwind is write only, you’re not supposed to read it or maintain in. Want to change some property? Delete the entire class=“” attribute and start anew. Take that primary button example from the article - no one is claiming that it’s readable, especially when there are hundreds of primary buttons throughout the app, each with a slight variation. This works great for marketing or landing pages, or other use cases whe…

This is just demonstrably not true.

Re: Tailwind CSS marketing and misinformation engine

#56

Earlier quoted context omitted.

Naming things is notoriously hard, but it's a skill you need to master to make reusable things. You name things that repeat. Think of function names in JavaScript, class names in object-oriented languages, or component names in Figma.

Ideally we shouldn’t have to name things that are never reused. Often class names are only ever used once. There isn’t much benefit in naming the class.

Yeah, this is exactly my point. I still need to name my reusable components, but I don’t need to name every single html element I want to style.

Re: Tailwind CSS marketing and misinformation engine

#57
post #2

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

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 g…

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.

Re: Tailwind CSS marketing and misinformation engine

#58
The popularity of tailwind isn't because of their marketing. Many colleagues using tailwind don't even care or have heard about the claims in your article. It's popular because it solves a real world problem for small to medium sites. It challenges "best practices" by showing that those in fact are just very opinionated and don't solve real world problems for many sites. I've witnessed over 2 decades of css evolution and tailwind is by far the most elegant solution for developers just needing some style for their app that works.

Re: Tailwind CSS marketing and misinformation engine

#59

I agree with the overall sentiment of the article, but find it a bit harsh. I honestly find the real debate to be inline styles vs stylesheets. Tailwind is just fancy inline styles. Personally, every single time I've used stylesheets in a large production-grade project it's an absolute mess. Every project I start now I use inline styles. I'm pretty indifferent on Tailwind though, it's sometimes nice to get opinionate…

It's not just inline styles. Idk why so many people comment on these threads with no experience using the framework.

Re: Tailwind CSS marketing and misinformation engine

#60
post #5

Meh, tailwind is the most maintainable and easy to understand way of doing style I've experienced (from solo to massive teams). Been doing this for around 13 years, so plenty of time to try a lot of flavors of styling. I'm so glad I no longer have to wonder what primary means, let alone the other weird names people come up with for classes. And if you don't want to see the classes, just write it out into a reusable c…

> I no longer have to wonder what primary means The point is exactly that you don't need to worry about styling in the HTML. You just structure the HTML. If you want to know what primary means that you open the css file and search .primary and see all the css properties right there. It was never rocket science. The HTML was designed to be the structure of the site. So you can designate items as buttons, primary butto…

I think the crux of the issue is, the separation of HTML from css came from an era when we were styling documents, nowadays we're increasingly styling webapps.

For me personally, I've rarely had a design to implement that didn't require a bunch of scaffolding html to conform to the design, css alone was never enough. But that means for all but the most trivial of changes you will need to touch the html and the css.

So the question becomes, is it worth maintaining that separation?

My experience has been that most sites get built, get signed off on, run for some number of years before the site get redesigned and rebuilt, we're rarely making changes to a site that are just simple like the colour of something, all that was decided during development, most of it was signed off on during the design phase even.

So I think that's the angle Tailwind fans take, if the point of separating css from html is to allow for easy changes to the design, but those changes are either never required or can't be achieved via css alone, what's the point? Better to go inline because the development process is quicker and easier.

Post reply on HN