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

Why Tailwind CSS Won

matt-rickard.com

Post reply on HN
Print view View original

121–130 of 559 posts

Re: Why Tailwind CSS Won

#121

Post by stefanfisk »

9dev wrote: post #97
stefanfisk wrote: post #92

Earlier quoted context omitted.

Where have you seen such an encouragement? Even Adam states that @apply was a mistake https://twitter.com/adamwathan/status/1559250403547652097?la... .

It’s a completely viable solution for certain situations, say, having a .button class. The things mentioned in that twitter thread have nothing to do with that.

I was commenting on "As soon as you have recurring product prices, you’re encouraged to use @apply to group those classes. ". It's certainly technically possible to create a CSS class. But AFAIK the recommendation is loudly and clearly to use components https://tailwindcss.com/docs/reusing-styles#extracting-compo..., and for good reason.

Re: Why Tailwind CSS Won

#122

Post by bryanrasmussen »

xigoi wrote: post #79
seedboot wrote: post #73

Earlier quoted context omitted.

Hopefully your link will be a component, so you only need replace one line anyway. Then again if your styles are abstracted to a component, your CSS framework is irrelevant!

Why would you use a component for something that's already a built-in HTML element?

I don't know, but a consulting company saddled us with a monstrosity that does exactly this.

Maybe it's some sort of lock-in feature.

Re: Why Tailwind CSS Won

#123

Post by peferron »

xigoi wrote: post #53
codersfocus wrote: post #31

The hardest part about programming is naming things. If you use tailwind you don’t have to name things. That’s why it won.

Do you also use De Bruijn indices when programming so you don't have to name variables?

When I program I make all my variables global and name them with BEM to get the same great experience as in vanilla CSS.

Re: Why Tailwind CSS Won

#124

Post by wildrhythms »

rpastuszak wrote: post #18

I think Tailwind is more accessible to many[*] less experienced or CSS-oriented developers. Big generalisation , I know, please don't yell at me, but many of us can get 99% of Tailwind's value with UI libraries supporting: 1) style encapsulation, 2) colocated presentation/content/behaviour and 3) a more minimalist mindset/habits when building UIs (e.g. relying on simpler styling hierarchies, native DOM elements, sema…

>I think Tailwind is more accessible to many[*] less experienced or CSS-oriented developers.

Umm... How? You have to know CSS and be quite proficient to understand how to map it to Tailwind. I don't understand this claim at all.

Re: Why Tailwind CSS Won

#125

Post by alex_suzuki »

I always felt slightly dirty after writing a bit of inline CSS (`style=”color: red“`) instead of a proper class, yet at the same time it accomplishes the goal and it was fast. So this is basically Tailwind, right?

Re: Why Tailwind CSS Won

#127

Post by yurishimo »

barnabee wrote: post #83
yurishimo wrote: post #42

Earlier quoted context omitted.

> the Tailwind code is still pretty crazy. The rendered output is crazy, yes. But this argument applies to every JS framework ever created. Authoring the code is best encapsulated by components. If you look at the source files available for their paid templates, they are all componentized.

Most JS frameworks are as bad too! Maybe the issue is that the giant pile of JS mess has created such a disaster that adding Tailwind doesn’t feel like making anything much worse. I can buy that. For what HTML is for (documents, web pages, etc.) CSS makes sense and Tailwind seems crazy. If you’re trying to code an application, for now perhaps React + Tailwind and a mountain of NPM dependencies does actually make sens…

I think your last point has legs, for sure. It makes sense that some other language will compile to wasm and make some app development more straightforward, but I don’t think the end result will be that different.

The web platform is not going to move away from current paradigm without an overwhelming shift in priorities or needs. Wasm still generates html and outputs it on the screen.

My biggest reason to use tailwind is maintainability. Having everything right in front of me with only the tiniest of abstractions, makes it really simple to refactor and maintain. I can confidently delete “CSS” and know it has no side effects. I can cut and paste a block of html and it will render EXACTLY the same. I don’t have to worry that Steve used a generic sibling selector in a CSS file 3 years ago that is screwing with my layout/design.

Is the HTML more bloated than if I had written “normal” css? Yes, but I think it’s worth the trade-off. It’s important that we can agree that their are trade-offs and then it’s up to each project to decide if those are worth it for their use case.

I’ll also mention the actual CSS file is crazy small as well since the tool only generates classes that are actually used in your project. No more ever-growing css that other people are afraid to delete for fear of breaking some legacy page!

Re: Why Tailwind CSS Won

#128

Post by dgb23 »

fjfuvucucuc wrote: post #108
rpastuszak wrote: post #18

I think Tailwind is more accessible to many[*] less experienced or CSS-oriented developers. Big generalisation , I know, please don't yell at me, but many of us can get 99% of Tailwind's value with UI libraries supporting: 1) style encapsulation, 2) colocated presentation/content/behaviour and 3) a more minimalist mindset/habits when building UIs (e.g. relying on simpler styling hierarchies, native DOM elements, sema…

What's up with the colocation argument? Colocation of markup and business logic makes a lot of sense. Colocation of presentation? Why do you even need that? Presentation is abstracted into CSS by design. Having presentation decoupled allows you to abstract around visual elements on a page at their instead of having to sufficiently wrap everything in divs classes just to the right level to make the CSs classes work.

The decoupling of CSS and HTML is a lie.

HTML describes layout, not just content.

Your overall structure is going to be vastly different whether you use flex or grid. And if you don’t want to write overly clever CSS you’re wrapping your dt/dd pairs in divs or you put dummy elements into your sections to control where the anchor links scroll to etc. And don’t get me started on non-hierarchical layout relationships.

HTML is not flexible enough and CSS is not expressive enough for this theoretical separation to hold in practice. You would need a translation layer between pure content and layout for this to be true (like XSLT).

Re: Why Tailwind CSS Won

#129

Post by sebstefan »

000ooo000 wrote: post #63

Silly premise and vapid article. Tailwind 'won' in the same way Bootstrap 'won', i.e. it was popular for a time. $10 says Tailwind will be the Bootstrap of 2027.

Well also bootstrap "died" in the most honorable way possible, it got antiquated by the CSS standard implementing flex and grids (the original specification was based on XUL though and not bootstrap - https://medium.com/@BennyOgidan/history-of-css-grid-and-css-...)

Kind of the same with jquery (although it took quite a lot of new stuff...)

I feel like Tailwind won't get that

Re: Why Tailwind CSS Won

#130

Post by wildrhythms »

izoow wrote: post #117
bennyp101 wrote: post #14

For getting designs up and running quickly, it really is great. Being able to think "Hmmm, I want a rounded button, with a border and a blue background" and just typing class="rounded border border-blue-600 bg-blue-500" and it's done. With lots of UI being components now, it doesn't really matter that it is verbose - I actually find that helpful. And even if you want to have a class that you use all over the place, j…

> Being able to think "Hmmm, I want a rounded button, with a border and a blue background" and just typing class="rounded border border-blue-600 bg-blue-500" and it's done. I'm not a frontend developer and don't really know much about these frameworks, but how is this different from just using style="actual css"? This just feels like inline styles reinvented for whatever reason.

Yes it's like inline styling, but the difference is that with Tailwind your build has just 1 CSS class with { display: flex; } used across your HTML, rather than inline styling or decoupled stylesheets with hundreds of instances of {display: flex}. If you use a framework like React, Angular, Svelte, it makes sense because your styles are usually coupled to your components anyway.
Post reply on HN