Live data from Hacker News

Tailwind Isn't for Me

spicyweb.dev

161–170 of 191 posts

Re: Tailwind Isn't for Me

#161
post #130
post #126

Earlier quoted context omitted.

The custom element specification (section 4.13) deals mostly with the registration and usage details, but the general extensibility section earlier on covers the basic use case: https://html.spec.whatwg.org/multipage/infrastructure.html#e... "User agents must treat elements and attributes that they do not understand as semantically neutral; leaving them in the DOM (for DOM processors), and styling them according to C…

Yes. It means they are not "custom elements". They are basically divs.

Yes, they are basically divs, but with a semantic name. Which is exactly what we wanted to achieve.

Re: Tailwind Isn't for Me

#162

Earlier quoted context omitted.

You don't have to define it, though. Browsers are supposed to just put unknown elements in the DOM and style them like any other element, using CSS.

Is this behavior specified by the standard? Any links to the relevant section?

You don't need a standard if it works in most browsers. And that's worked fine for me on nearly a dozen enterprise web apps since ~1995

Re: Tailwind Isn't for Me

#163
post #130
post #126

Earlier quoted context omitted.

The custom element specification (section 4.13) deals mostly with the registration and usage details, but the general extensibility section earlier on covers the basic use case: https://html.spec.whatwg.org/multipage/infrastructure.html#e... "User agents must treat elements and attributes that they do not understand as semantically neutral; leaving them in the DOM (for DOM processors), and styling them according to C…

Yes. It means they are not "custom elements". They are basically divs.

More like span, since the default is inline

Re: Tailwind Isn't for Me

#164
post #65
post #25

Earlier quoted context omitted.

Why not Styled Components? I've been using them for years now and I'm extremely productive. Tailwind on the other hand looks like a hellish nightmare, horizontal reading, proprietary syntax, no selector targeting of other components.

Tailwind on the other hand looks like a hellish nightmare, horizontal reading, proprietary syntax, no selector targeting of other components. Is "horizontal reading" worse than reading two files? What if the other file is actually 30 files compiled with SASS? What if they're 30 files, compiled with SASS, and written by a bunch of devs who don't know CSS well, didn't use BEM or anything to name things well, and didn't…

> Is "horizontal reading" worse than reading two files?

Yes, very. I'm amazed that this is even in question.

Re: Tailwind Isn't for Me

#165
post #10

I love tailwind. I strongly feel that most modern CSS solutions are massively overthought. In engineering we have bigger problems to solve than a key/value list that makes a div blue. Tailwind removes the thinking around CSS, naming, preprocessors etc etc, it just lets me write good CSS and focus on components and other engineering problems. I seem to be one of the few people who can read CSS properties horizontally…

My biggest issue with Tailwind is point #5 on the article: Tailwind encourages div/span-tag soup. Together with the class name soup my HTML becomes unreadable.

A big issue that these articles never mention is that using browser dev tools to debug CSS becomes a huge pain with tailwind. It also makes it harder for community to create custom themes/user scripts for your website/app since targeting specific elements becomes incredibly hard when no class names exist.

Re: Tailwind Isn't for Me

#166
post #54

Earlier quoted context omitted.

My biggest issue with Tailwind is point #5 on the article: Tailwind encourages div/span-tag soup. Together with the class name soup my HTML becomes unreadable.

How does Tailwind encourage div/span tag soup compared to anything else? You literally cannot do anything on the web without a div/tag soup

It doesn't the author is just bad at semantic HTML. That first example should be an `` and the 5th example doesn't actually show div/span soup.

Re: Tailwind Isn't for Me

#167
post #140

Earlier quoted context omitted.

> I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that Indeed, not in the past 7-8 years. But we used to do it, and the outcome was great - semantic, accessible and machine-readable HTML was the norm. It’s unfortunate that we lost this in the transition to components.

> But we used to do it, and the outcome was great - semantic, accessible and machine-readable HTML was the norm You know, there are still people alive who lived through this Golden Age of 10 years ago? 20 years ago? And they call bullshit on your statement.

I started in 2004. Spent the years of 2007-2012 writing semantic, standards-compliant html (microformats, the works), css and js. Even my first years at booking.com still had that as a concern. Unless this was all a fever dream…

Re: Tailwind Isn't for Me

#168
post #46

Earlier quoted context omitted.

Tailwind is opinionated, meaning it encourages a structure that helps devs avoid common potholes. You may not like its choices but saying it creates a mess has been the opposite of my experience. One of the main pitfalls I have noticed no longer running into is that the structure tailwind encourages prevents issues with CSS selector specificity. As a result I’ve definitely noticed fewer instances of ‘!important’ in c…

You could instead learn what patterns should be avoided and why . This means you can make meaningful judgements on whether it's ok to use those tools on occasion (like goto in C). Tailwind is a mess by default. People didn't invent separation of style and content for no reason. They did it because what they were doing before was as mess. This is that same mess.

"You could instead learn what patterns should be avoided and why."

In an ideal world yes. But in the real world nobody knows everything, we have deadlines, and no company actually sets aside time to onboard you on CSS.

But also, it takes a while to establish a pattern. Using tailwind wasn't my decision and it took a while of working with it before I noticed that I was rejecting fewer PR's for `!important`. It took a little longer to establish the cause was tailwind and the reasoning behind why.

But also, how are people supposed to learn with all this noise? Most of the critique of tailwind in this thread is incredibly surface level.

Re: Tailwind Isn't for Me

#169
post #8

People want painkillers, not vitamins. That's why there is this endless flow of snake oil frameworks like Tailwind and all the others. People see some fancy demos and think "wow, so cool so easy" and "This is the newest framework, so it must be the best" and go for it. Then over time, they get caught in a web of problems that the complexity of the framework produces. Then a few people go for the vitamins route (plain…

The vitamins vs painkillers analogy is about productivity-boosters vs problem-solvers. Using plain html/css/js is neither of those. You could say Tailwind fits both of them.

Re: Tailwind Isn't for Me

#170
post #140

Earlier quoted context omitted.

> But we used to do it, and the outcome was great - semantic, accessible and machine-readable HTML was the norm You know, there are still people alive who lived through this Golden Age of 10 years ago? 20 years ago? And they call bullshit on your statement.

I started in 2004. Spent the years of 2007-2012 writing semantic, standards-compliant html (microformats, the works), css and js. Even my first years at booking.com still had that as a concern. Unless this was all a fever dream…

You were a statistical anomaly then. Very very very few people wrote or understood what semantic HTML is. And very few do now.

To pretend that there was some time when, unlike now, people wrote semantic HTML en masse is silly.

Post reply on HN