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

291–300 of 559 posts

Re: Why Tailwind CSS Won

#291

Post by onion2k »

Shrezzing wrote: post #118

I find Tailwind's claim that you can "build modern websites without ever leaving your HTML" to not be entirely correct. Instead of context switching from my `.html` to a `.scss` file, I just end up context switching to their documentation website to find the syntax they used. It's internally inconsistent, so you can't guess what the Tailwind class name is for styling, while you can do this for CSS on the majority of…

I just end up context switching to their documentation website to find the syntax they used.

I don't, but I've been using Tailwind for a little while. Once you grok the syntax structure it's not that different to writing CSS.

Re: Why Tailwind CSS Won

#292

Post by yurishimo »

emmacharp wrote: post #233

Food for thought: https://csswizardry.com/2018/11/css-and-network-performance/ Progressive rendering of CSS is a great boost in performance. Tailwind can't benefit from this technique I think and as such, imposes an added cost on our users. Correct me if I'm wrong!

I don't think is accurate. While it might not be built in currently, the same is also true of something like SASS or even plain CSS.

The article describes a strategy for loading CSS in the most performant way given a variety of interconnected factors (mainly JS).

You could generate the Tailwind file, and then split it when the media queries start (they're all grouped in order of screen size) with a small bash script into separate files as a part of your build process.

You could have multiple build steps that analyze your component architecture and generate separate CSS bundles for each component. This is already done w/ most JS frameworks.

If your argument is one of the final CSS file size, that is not an issue. Tailwind only generates classes that you write in your markup. Most Tailwind bundles I have seen, are dramatically smaller than their CSS counterparts, and it makes sense when you think about how CSS is written.

Say you have a two UI elements; an article preview image and a user avatar. Say you want them to mostly display the same, but with some tweaks to the avatar to add a fancy filter on hover. Okay easy enough. Maybe you start with some sort of base mixin and then overwrite add behavior for the avatar. Over time, you add more and more tweaks to the avatar until one day, you get a call from the head of Design Department that the articles are getting their own special CSS filter. Okay, so now you extend the article. Over time the two continue to drift until you're overwriting anything that they originally shared in the beginning. The articles have different margins than the avatars and now marketing wants to allow users to upload images to comments. Does that extend the original mixin from 3 years ago? Maybe you think, "why do I even have this base class; can I get rid of it?" After some quick testing you remove the original mixin and go home for the day. Over the weekend, you get a call saying that the avatars showing user contributions from a fundraising event are all messed up. It turns out, the base mixin added `display: block` to the images, but when you tested, you really only looked at the logged in user profile photo in the navbar. Whoops.

Now take that scenario and multiply it by 100 devs on 20 different teams. We've all seen it. This is why CSS is often never deleted in large companies. Devs instead to continue writing ever increasing specific selectors or using techniques like BEM/OOCSS to stop the bleeding. It takes an insane amount of discipline to wrangle CSS on a sufficiently large project. Tailwind helps manage some of that complexity, and at least provides good guard rails for teams of developers by empowering them to know that a "small refactor" won't break an entire layout.

https://frontstuff.io/in-defense-of-utility-first-css

https://github.com/sarahdayan/utility-first-compression-demo

Re: Why Tailwind CSS Won

#293

Post by jonwinstanley »

3cats-in-a-coat wrote: post #239
scrollaway wrote: post #225

Earlier quoted context omitted.

> That's good, it means in a few years Tailwind will be considered a dead tech. And that’s good because of what, beyond your own personal preference as to your Framework Of Choice?

It is good because Tailwind actively fights the engineering choices behind the web platform, it doesn't understand them, it doesn't build on top of them in synergy and alignment, but it counteracts and nullifies them with religious fervor and zeal. Tailwind projects read like the wall writings of a mad man, who is convinced they've discovered the secret of the Universe. And that secret is compiling absurdly large, GI…

I'm not sure I fully agree with your view on what tailwind is and why it is growing.

In my opinion, tailwind is gaining some popularity because some people find it faster and easier to use than writing traditional CSS files.

I realise it also has some downsides, and seeing all those class names in the html is particularly ugly, but if the people using it got their project out faster, then surely there is a place for it?

Re: Why Tailwind CSS Won

#294

Post by emmacharp »

ethanbond wrote: post #282
emmacharp wrote: post #246

Earlier quoted context omitted.

If the Tailind defaults are used in a design language file, wouldn't it be simpler? If it's only a problem of "aesthetics", 20 minutes is enough to use Tailwind's defaults in pure CSS. No need for calling a designer here either. Side benefits include that there is then no need to update any dependencies or library, no need to run a JIT server, no need for a new syntax, no need to wait for implementation of new CSS fe…

Just checking that I understand your suggestion: it’s that you copy/paste Tailwind into a file called “designsystem.css” and then say that you are not using Tailwind? Or are you saying take their design system and use your own syntax for it (so it’s less complete than TW, less well-documented, and less transferable to/from the vast resources of the internet centered around TW)?

I'm talking about the design aesthetics included in Tailwind as default. Keep the values and the names if you want. Like this, for example:

"blue-500" becomes --blue-500. That's it.

This is a far cry from using Tailwind as a whole while keeping the good-looking aesthetics.

Re: Why Tailwind CSS Won

#295

Post by scrollaway »

3cats-in-a-coat wrote: post #239
scrollaway wrote: post #225

Earlier quoted context omitted.

> That's good, it means in a few years Tailwind will be considered a dead tech. And that’s good because of what, beyond your own personal preference as to your Framework Of Choice?

It is good because Tailwind actively fights the engineering choices behind the web platform, it doesn't understand them, it doesn't build on top of them in synergy and alignment, but it counteracts and nullifies them with religious fervor and zeal. Tailwind projects read like the wall writings of a mad man, who is convinced they've discovered the secret of the Universe. And that secret is compiling absurdly large, GI…

> Tailwind projects read like the wall writings of a mad man

My dear pot, you should meet my friend Kettle.

Really, this is a lot of text that sums up your personal preferences as to why you don't like Tailwind. Nothing concretely objective here. And, by the way, I agree with some of it! But you're also ignoring Tailwind is used by massive, engineer-first companies (such as Stripe), and the engineers in question actually like working with Tailwind. This idea that people who use Tailwind hate it is obvious nonsense, and it's always a significant tell that someone hasn't really produced anything with it when they start claiming that about others.

Re: Why Tailwind CSS Won

#296

Post by [deleted] »

3cats-in-a-coat wrote: post #216
keyle wrote: post #140

Gray beard's 5c: Tailwind is a farce and a catastrophe. It's as modern as the style parameter is, and it's as reusable as a moving a dirt pile from one corner to the next. You're not learning anything valuable by learning Tailwind. Learn CSS, that will stick with you for the next 20 years. It amuses me when a library is implemented 'with tailwind', which means it's totally useless to the people _not using tailwind_,…

You're not downvoted, which means... the tailwind... is turning. I apologize.

[deleted]

Re: Why Tailwind CSS Won

#297

Post by Glide »

hailpixel wrote: post #139

I love tailwind, and I've been writing CSS professionally since CSS2.1. I have often debated with many developer friends why it has performed so well, and this article really missed some big reasons: 1. It's works extremely well with the current component-focused UI frameworks (react, svelte, etc). Subsequently, the verboseness that is often a complaint isn't an issue at all, but a feature. 2. Does everything out of…

I agree with all of your points. I am kind of shocked that I had to scroll so far down to see point #3 on this thread at all.

CSS doesn't give the best toolset in order to do styling and organize styling. The locality of HTML structure and styling makes things far easier to work with.

I would also throw in that front end coding feels far more fickle and arbitrary. Tailwind allows me to define a set of rules and then apply them directly. It ends up being more maintainable when used in conjunction with component abstractions.

Re: Why Tailwind CSS Won

#298

Post by Zealotux »

3cats-in-a-coat wrote: post #214

I work every day with web projects, and the notion "Tailwind won" in any capacity sounds like a thunder from a clear sky. If we see more articles to that effect and this is not an outlier, it means the Tailwind cult is in its "red dwarf" stage, where the community becomes smaller, but denser and more convinced than ever that the entire world is a copy of their small bubble. That's good, it means in a few years Tailwi…

If you listen to Twitter: nobody uses PHP anymore, everyone's high on Tailwind, React is dying and Svelte is soon-to-be king.

Re: Why Tailwind CSS Won

#299

Post by dalmo3 »

xigoi wrote: post #134
conradfr wrote: post #114

Earlier quoted context omitted.

If you know the convention it's quite easy. I don't know Tailwind but with Bootstrap it would be m = margin, y = y axis, b = bottom, sm/lg = screen size, 4/5/6 = size

4/5/6 what? Bananas? And what exactly is “screen size”? Does it refer to physical size, or number of pixels? Does it count width, height, or both?

You don't need 5 question marks to tell us you don't know what breakpoints are.

Re: Why Tailwind CSS Won

#300

Post by bobmaxup »

keyle wrote: post #140

Gray beard's 5c: Tailwind is a farce and a catastrophe. It's as modern as the style parameter is, and it's as reusable as a moving a dirt pile from one corner to the next. You're not learning anything valuable by learning Tailwind. Learn CSS, that will stick with you for the next 20 years. It amuses me when a library is implemented 'with tailwind', which means it's totally useless to the people _not using tailwind_,…

I think this always gets summarized as:

Tailwind is a pretty good framework for people who want to practice atomic CSS easily, and it is a bad framework for anyone trying to avoid that pattern.

The pros and cons of atomic CSS can then be argued about elsewhere.

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Post reply on HN