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

501–510 of 559 posts

Re: Why Tailwind CSS Won

#501

Post by ajanuary »

harshitaneja wrote: post #337
ajanuary wrote: post #179

Earlier quoted context omitted.

One of the selling points that Tailwind pushes that I haven't seen other people mention here is that inline styles are _too_ flexible. You can do `style="color: red"`, but you can also do `style="color: #FE0005"` or `style="color: #FE1111"`. While tailwind lets you write your styles in the same _location_ as the style attribute, it allows you to restrict what _values_ you can use. You can set up a colour palette so t…

Can't this be solved by creating small css classes for your colour palette like font-color-primary, background-color-warn, etc? The benefit being that anyone who needs to include these only needs to think about the context and have consistency everywhere.

Yup. This isn’t the killer feature of tailwind that’s impossible to get any other way. It’s one component of a bigger solution. But why it’s relevant here is it’s an example of how that bigger solution is different to just using style attributes.

Re: Why Tailwind CSS Won

#502

Post by blitz_skull »

yoav wrote: post #304
blitz_skull wrote: post #267

Earlier quoted context omitted.

Cool hot-take but it’s not true. You’re literally learning CSS when you learn tailwind. And no one (good) picks up a tool solely because it’s shiny, they pick it up because they find it has utility, which evidently LOTS of people do. And if you don’t think it’s reusable then you at least need to bring an argument for why that’s so because the docs, personal anecdote, and the opinion of LOTS of people is completely op…

Senior Staff grey beard: Counterpoint: The C in CSS stands for Cascading. So you’re not learning CSS. You’re learning Tailwind specific classnames that expand to non-cascading style rules.

You're not the first person to mention that, to which I counter: Cascading is a mistake in today's component-first web. It works at a very small scale, and _sure_ some things should be cascaded—which Tailwind absolutely lets you do. But 80% of your styles are going to end up scoped to their component—so you might as well use a tool that leverages that concept to its fullest extent.

All my "hard opinions" aside, I have anecdote that no amount of facts can change—I build things faster, more maintainably, that look BETTER than anything I did before Tailwind. Until those pillars stop being true—Tailwind will have my heart.

Re: Why Tailwind CSS Won

#503

Post by deergomoo »

epolanski wrote: post #182
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_,…

+1. Let's say things how they are: Tailwind is a small catastrophe from an implementation, performance and maintenance point of views. It got few things quite well in being a more modern bootstrap, had a stellar marketing and it's color palettes are really well done and leagues above the default material ones. ...that being said... Tailwind's biggest pro is that it allows people that _don't_ know css that much to sty…

> Tailwind's biggest pro is that it allows people that _don't_ know css that much to style stuff more consistently and easily

I have never understood this claim. You need a good understanding of CSS to use Tailwind effectively because it is CSS.

It’s not an alternative technology, it’s essentially just an alternative syntax—one that naturally leads away from footguns that many teams end up battling, like fragile CSS that everyone is scared to change.

You could just as easily define the utility classes yourself every time you need one, it’d just be a lot more work.

Re: Why Tailwind CSS Won

#504

Post by emmacharp »

marcosdumay wrote: post #433
emmacharp wrote: post #236

Earlier quoted context omitted.

Well, that is not using Stylelint I'd say. Within half a day of configuring, you can prevent almost all of the problems denounced in this thread. Ultimately, it really is "a couple hours of thinking/configuring a linter vs. multiple layers of abstraction, complexity and dependencies added to the codebase." Maybe I'm missing something (and be my guest if I do!) but there is an objectively better choice here.

Well, that means stylelint has a problem. They should be talking about how to solve it, because nobody wants to not enable debuging information on a develoepr build. If the devs do not acknowledge this as a problem, this means stylelint is a bad piece of software. I really dislike sass the way it's normally used. It was once a necessary hack, but it's mostly not useful anymore. Something that just concatenates your C…

I'm not sure what you mean about "Stylelint having a problem".

There's a default config, with only base rules, without the more opinionated ones. Then you configure/extend it as you would with almost any other tool. Isn't it the way most tools of this kind work?

Or am I missing something?

Re: Why Tailwind CSS Won

#505

Post by emmacharp »

troupo wrote: post #381
emmacharp wrote: post #294

Earlier quoted context omitted.

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.

> "blue-500" becomes --blue-500. That's it. Of course it's not "it". Now in every class that needs it, you also need to add { ... other styles... background-color: var(--blue-500); } And then you need to apply that class

How is that different than writing "bg-color-blue-500" in every component that needs it?

As for the class, it's the name of the component, the same name you give to the component file. Does it really add that much work?

Correct me if I'm wrong but as I see it, that's literally a couple of seconds of "work".

Re: Why Tailwind CSS Won

#506

Post by emmacharp »

troupo wrote: post #378
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…

> 20 minutes is enough to use Tailwind's defaults in pure CSS not 20 minutes, more. Plus all the boilerplate around @media rules > no need to wait for implementation of new CSS features What CSS features are you waiting for with Tailwind? > better performance possibilities It's very hard to beat Tailwind's performance since it's a fixed set of css classes (and a very small set in production, since it only includes cl…

Boilerplate? What do you mean?

Any IDE can autocomplete 90% of any media query. And, on a sidenote, I was only talking about using Tailwind's default aesthetics in pure CSS, here. That's what the 20 minutes refers to. And I think it was a conservative estimate.

As for features, it took months before grid was included in Tailwind. New powerful and useful selectors aren't there. It took years for Tailwind to support "group hovers". And I can give even more examples if you're still not convinced. Or you can have a look at the changelog.

As for performance, can Tailwind split its compiled CSS so that only rules used in the displayed components are loaded? And that's not even considering the weight difference between the "tailwinded" HTML and the one needed to support pure CSS. These things matter if performance is a goal (as it should be).

If I'm missing something, go ahead and tell me, I'll be reading with great interest!

Re: Why Tailwind CSS Won

#507

Post by emmacharp »

ofcourseyoudo wrote: post #452
emmacharp wrote: post #271

Earlier quoted context omitted.

This is easy and should not be a problem. It also is the kind of help/solution that should be implemented first, before any librairies or frameworks are added.

Have you worked on a FE team with 5 or more people? There's a lot that is easy and shouldn't be a problem when you get to define the scope and technologies and shared conventions used.

Yes, I have. And I don't see how it can impact the feasibility and easiness of activating source maps.

I may be wrong, though. Don't hesitate to correct me if that's the case.

Re: Why Tailwind CSS Won

#508

Post by emmacharp »

for1nner wrote: post #445
emmacharp wrote: post #271

Earlier quoted context omitted.

This is easy and should not be a problem. It also is the kind of help/solution that should be implemented first, before any librairies or frameworks are added.

"should" is often the enemy of "speed" even when it's the _correct_ way to build a system. I think most of us here have experienced that at businesses of varying sizes.

As I said below, I don't understand how the number of team members can impede our capacity to activate source maps. Again, I may be wrong so go ahead and tell me if that's the case.

Re: Why Tailwind CSS Won

#509

Post by emmacharp »

haswell wrote: post #470
emmacharp wrote: post #269

Earlier quoted context omitted.

But you really don't have to do that. Naming components only (as you already are) really is sufficient. And yes, specificity and flexibility can easily be managed/included with CSS, particularly now, with all the new widely supported features/selectors. These solutions to an old "problem" are lighter, simpler and easier to maintain in the long run. If you're curious, I'll be pleased to give you more concrete examples…

Most of my HTML/CSS skills were formed when these things did not have good built-in solutions. As someone who just wants to hack together a responsive blog that looks nice, the things that are now “simpler and easier in the long run” have not been easy or obvious to come by when looking for resources, and while I’d love a deep knowledge of CSS, the investment in time doesn’t make sense given my use case. This is why…

I understand this perfectly and is maybe the argument I have the most sympathy for.

And, because you are absolutely right, I'm working right now on something like what you propose.

The only way to convince people that CSS is a better (as in lighter, simpler, more efficient, etc.) solution than a framework like this, is to show and prove that it is. Arguments can only go so far...

So, as the saying goes, I'll be putting my money where my mouth is. Hehe.

Re: Why Tailwind CSS Won

#510

Post by kthejoker2 »

wildrhythms wrote: post #124
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.

N=1 but this is not true for me specifically. I'm a data guy, built my last professional web site in 2015 but build stuff for fun to this day.

I grok flexboxes and responsive design through Tailwind more than I ever did in those years.

I could certainly learn more pure CSS but there's no need at this point. I am happy and productive in my ignorance.

Post reply on HN