Live data from Hacker News

Tailwind Isn't for Me

spicyweb.dev

71–80 of 191 posts

Re: Tailwind Isn't for Me

#71

Decent arguments. Ultimately, I think your preference comes down to: - Do you care about how your html output looks? - I personally don't, just like I don't care about what my Webpack bundle looks like. Web standards will always be slower to evolve, which is why we build tooling on top. - How do you think web components will be used? - I believe they will be used sparsely, only by libraries. But if you want to replac…

> Web standards will always be slower, which is why we build tooling on top. I don't follow. I don't see how frameworks or tools have anything to do with standards being slow.

* Slow to evolve

As in: it took years to get something thats even remotely comparable to framework components. Tooling can move fast and course correct, the standards have to get things right the first time.

Re: Tailwind Isn't for Me

#72
post #63

Man. It's 2024 and we're still talking about ugly-ass HTML. That's amazing.

HTML itself is beautiful. Show me a better way to express varied words and images with an eye for creative layout and design the way great books play with this content.

Every design system build on top of HTML is just an abstraction that adds layers of complexity whilst reducing the inherent flexibility of HTML. It's much like the years when every SPA framework rebuilt the concept of a back-button and page history, or standard HTML form inputs. All were shittier versions of what the browser provided (even if imperfectly at times).

Re: Tailwind Isn't for Me

#73
post #44

I can't understand why people bother about HTML with long class attributes so much. If you use "btn" instead of a long string of Tailwind classes, you just move the actual CSS properties into a stylesheet file, which you need to switch back and forth to just to change the looks of that button. And having said that, when using Tailwind with some kind of component-centred framework, those classes will be local to a com…

If you need to adopt the HTML to fit a certain style, you're doing it wrong. HTML should be a semantic markup, it shouldn't change much when you need to change the styling/CSS. So you don't really go "back-and-forth" to architecture CSS, you just write your CSS. But maybe it's a Tailwind thing that you need to add additional elements to HTML just to be able to style it correctly, I'm not sure. It's like saying you shouldn't have JSON files (and embed the data inside the business logic) as you need to change the JSON file when you need to change the logic of the app. In short, you adopt your CSS architecture to your semantic markup, not the other way around.

Re: Tailwind Isn't for Me

#74
As a non-web developer with a couple of relatively sophisticated side projects, I've never understood the appeal of Tailwind. It somehow manages to be hideous, verbose, and absolute gibberish all at the same time. If I wanted that, I'd write everything straight into the style tag. I can't understand why Tailwind would be any easier to maintain (and I'm sorry, but you will never convince me that I need a javascript precompiler for my damn stylesheets).

Re: Tailwind Isn't for Me

#75
post #44

I can't understand why people bother about HTML with long class attributes so much. If you use "btn" instead of a long string of Tailwind classes, you just move the actual CSS properties into a stylesheet file, which you need to switch back and forth to just to change the looks of that button. And having said that, when using Tailwind with some kind of component-centred framework, those classes will be local to a com…

[deleted]

Re: Tailwind Isn't for Me

#76
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?

I see this complaint a lot but I don't really get it. You can have a styled component in the same file or a separate file. In VSCode, you just command click on the component and you go straight to the style definition. Not an issue.

> What if the other file is actually 30 files compiled with SASS?

I only work in Styled Components-exclusive codebases so can't comment

> 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 organise them at all?

You got bigger problems

Re: Tailwind Isn't for Me

#77
post #46

Tailwind is an abomination. Of course it's easier to use. Pressing the bold button in MS Word is easier than setting up styles etc, but one makes it easy to create an impossible to maintain mess that could have been made by a primary schooler, and one makes it possible to create a consistent style that looks professional. The only reason I think Tailwind is becoming popular now is it's exposing a bunch of things like…

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.

Re: Tailwind Isn't for Me

#78
post #9

Yeah, it isn't Tailwind that doesn't support web components. It's Shadow DOM that is such a bad abstraction that it breaks the web in innumerable ways and need dozens of new standards to fix its shortcomings.[1] And yeah. That that is seemingly not an eyesore? It's not because Tailwind is bad and "pollutes HTML". It's because web components hide any and all ugliness from you so that you can pretend they are beautiful…

I'd like to like web components, but their reliance on JS to instantiate along with all the chaos of the shadow DOM keep them off the table for me. I think they are a great concept defeated by the implementation.

Re: Tailwind Isn't for Me

#79
post #70

Earlier quoted context omitted.

> removes the thinking around CSS, naming, preprocessors etc

It's a fairly limited set of rules that are mostly consistent, extensively documented, and easy to remember. But yeah, a little bit of effort is required when dealing with a styling language with over 300 properties. Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon. At first it's a button, then there's buttons that should look l…

> Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon

I can honestly say I've never spent more than 5 seconds thinking about what to name a styled component, do you really get decision paralysis with this?

Re: Tailwind Isn't for Me

#80
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 multi billion dollar vitamin industry disagrees. Kidding. Only half. I dislike this saying because it doesn't mean anything and just makes some VCs think they're saying something that sounds smart.

There are frameworks that genuinenly improve the development experience for certain uses cases. As with many things, it's important to still now the basics (in this case, CSS), but why not use Tailwind if the philosophy aligns with yours and makes you more productive?

Sure, switching frameworks ever few months to try the hottest shit out there is also not great, and many people overuse frameworks (e.g., React is an overkill for many (most?) applications I have seen). But that doesn't mean there isn't merit in frameworks.

Post reply on HN