Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tailwind Isn't for Me

spicyweb.dev

Post reply on HN
Print view View original

111–120 of 191 posts

Re: Tailwind Isn't for Me

#111

Post by PrimeMcFly »

TekMol wrote: post #19
nomilk wrote: post #12

Earlier quoted context omitted.

In your analogy, wouldn't tailwind be more of a multivitamin, in that it contains a bunch CSS classes (vitamins) conveniently packaged and ready to go? I haven't used tw yet, but I intend to because I was blown away by how much sense the authors' book Refactoring UI made.

Taking multivitamins is usually the wrong approach. So they are indeed a kind of snake oil. Which condition do you intend to treat by taking multivitamins? Have you looked at randomized controlled studies and found that they support your idea that taking MVs has a positive effect on that condition? Have you got your bloodwork done? Did the doctor then suggest that based on your situation MVs are the right approach? I…

> Taking multivitamins is usually the wrong approach. So they are indeed a kind of snake oil.

Not true at all. It ensures people get needed nutrients when they have shitty diets. It's not snakeoil at all.

Re: Tailwind Isn't for Me

#112

Post by lenkite »

timeon wrote: post #94
jack_riminton wrote: post #16

Earlier quoted context omitted.

Locality of Behaviour: "The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code" https://htmx.org/essays/locality-of-behaviour/ Some people want "cleaner" and that's fine, I much prefer things to be "right there" as much as possible. Must be how my brain works

Also known as spaghetti code.

This - the burden of affixing and naming the hundreds of pieces of composite styling consisting of 30+ tailwind classes is fully moved to the poor guy who needs to read, grok and maintain the code that the original author was too lazy to care about.

Re: Tailwind Isn't for Me

#113

Post by 9dev »

omer_balyali wrote: post #105
9dev wrote: post #86

Earlier quoted context omitted.

I don't know about you, but I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that finished HTML structure. Instead, it's usually an iterative process of adding HTML, styling that, then adding more content. That isn't even related to Tailwind, or any other CSS framework -- just that Tailwind allows you to stay in the HTML (or component) contex…

I don't understand the big problem with switching different files. Don't we write components and tests in separate files? When we develop a component we add it to other components/views. When you need to add new props to a component, you open up the component file, add your prop, open up your component test file write your tests, if there are any tests fails you go back to component file and fix it there, then if eve…

> I don't understand the big problem with switching different files.

Maybe it's really just fundamentally different workflows - I doubt we'll reach consensus here, and that's probably okay.

> What people misses out is CSS should be written in state-based architecture

I agree with you here. That breaks down as soon as you have states that depend on the layout - saying a button should be larger on smaller devices requires adding a style into a media query that lives separate from the button styles, unless you add hundreds of individual media query blocks. Tailwind alleviates that by making "md:" a state prefix just like "hover:".

> if you have a component, which Tailwind creators recommend you should, then you already need to find names for your components

True; I need to name my button component "Button", but I don't have to find a name for the wrapper container of the icon that goes to the right side of buttons that include an icon, which it needs to create a flex context.

Re: Tailwind Isn't for Me

#114

Post by PrimeMcFly »

globular-toast wrote: post #17

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…

> The only reason I think Tailwind is becoming popular now

I think it just matches the way some people think. Nothing more than that.

It's one of many approaches that works well for some people and not for others.

Re: Tailwind Isn't for Me

#115

Post by 9dev »

ricardobeat wrote: post #100
9dev wrote: 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…

“Need to switch back and forth” is a strangely negative way of putting it. Do you “switch back and forth” to a function definition, and is that an argument for procedural code and repetition? Then your second paragraph is a great point against the need for Tailwind and the long class attributes, as you’re going to encapsulate all of that in a component (and “switch back and forth” to see its styles) anyway.

You've pretty much answered this yourself - a function, just like a component, is a self-contained unit. If you're working within the scope of a function, you don't switch back and forth; but I'm pretty sure you wouldn't want to have to declare the names of any local variables in that function in some kind of global variable table in another file ("let's add a loop here.. switch to vars.file, add someFunction_firstLoop_i as 0... back to the loop, add the variables...").

Re: Tailwind Isn't for Me

#116

Post by ipsum2 »

yellow_lead wrote: post #3

As someone who used to make websites in the myspace days (and has about that much experience with web dev, plus a few static client sites from high school), I gave tailwind a try for my most recent project. I think it saves me a bit of time, and it's easier to get a decent aesthetic quickly. That said, I don't feel it's strictly necessary, and I don't like the HTML bloating either. It makes me want to create classes,…

Did you see that the person who wrote the article also created https://www.vanillabreeze.dev/ to remove dependencies from Tailwind?

Re: Tailwind Isn't for Me

#117

Post by theshrike79 »

timeon wrote: post #90
SebastianKra wrote: post #45

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…

also: - Do you care for bloat user needs to download?

If your web page is so efficiently managed that the amount of CSS Tailwind adds is "bloat", I envy you =)

Re: Tailwind Isn't for Me

#118

Post by dbbk »

9dev wrote: post #98
dbbk wrote: post #79

Earlier quoted context omitted.

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

This isn't about decision paralysis, but picking good names that other people will understand. But they won't, not all of them at least. No matter how great you're at naming things, you are going to do it differently than other people do. That doesn't matter on your personal home page, but it breaks down with a larger team. Inevitably, naming principles will drift apart, and after a few years, you'll have a mess. Don…

Why does the name matter? If it's a Wrapper or a Container or an InnerWrapper or whatever. It's just a 'label'.

Re: Tailwind Isn't for Me

#119

Post by jack_riminton »

timeon wrote: post #94
jack_riminton wrote: post #16

Earlier quoted context omitted.

Locality of Behaviour: "The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code" https://htmx.org/essays/locality-of-behaviour/ Some people want "cleaner" and that's fine, I much prefer things to be "right there" as much as possible. Must be how my brain works

Also known as spaghetti code.

Spaghetti would imply tangled surely? Tailwind is verbose but it’s the opposite of tangled

Re: Tailwind Isn't for Me

#120

Post by omer_balyali »

9dev wrote: post #113
omer_balyali wrote: post #105

Earlier quoted context omitted.

I don't understand the big problem with switching different files. Don't we write components and tests in separate files? When we develop a component we add it to other components/views. When you need to add new props to a component, you open up the component file, add your prop, open up your component test file write your tests, if there are any tests fails you go back to component file and fix it there, then if eve…

> I don't understand the big problem with switching different files. Maybe it's really just fundamentally different workflows - I doubt we'll reach consensus here, and that's probably okay. > What people misses out is CSS should be written in state-based architecture I agree with you here. That breaks down as soon as you have states that depend on the layout - saying a button should be larger on smaller devices requi…

How do you change a single CSS property (let's say "border-color") with Tailwind, when the conditions are: "color-scheme: dark", "high-contrast", "focus-visible", "not:disabled", "intent: destructive"? And how do you change 3 such CSS property (border-color, color, background-color) on the same conditions? As far as I can tell, you need to repeat the same condition for each property you need to change. And when you have all these combinations together, which is not uncommon for component libraries to have such different states and combinations, it's just become unreadable mess; just to be able to see which CSS properties the element has without switching files.

I guess to change these 3 property on the same condition, you need to write this TW classes (or create a "variant" in separate config file): class="dark:contrast-more:focus-visible:enabled:data[intent=destructive]:border-slate-700 dark:contrast-more:focus-visible:enabled:data[intent=destructive]:bg-slate-50 dark:contrast-more:focus-visible:enabled:data[intent=destructive]:text-gray-50"

Or am I missing something that Tailwind makes it as easy as writing these states and combinations in regular CSS (without apply, which TW creators don't recommend using)? If that example is the preferred way of writing TW, and it's only 1 condition combination, I would happily switch back-and-forth files and write regular CSS without that syntactic high-fructose corn syrup.

Post reply on HN