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

Working with Tailwind CSS every day for 2 years

themosaad.com

Post reply on HN
Print view View original

161–170 of 215 posts

Re: Working with Tailwind CSS every day for 2 years

#161

Post by greenhatman »

1123581321 wrote: post #78
lloydatkinson wrote: post #23

Oh two tailwind hate threads today instead of the usual one at a time? Everyone as usual saying "long class lists" even though the literal home page tells you not to do this and to make components or partial views or whatever your tool of choice calls it. At least be inventive and follow the instructions before you start blaming something.

It's a lot of work to create components just to reduce CSS duplication (i.e. to create more components than you would make if you used traditional CSS classes.) Not always a good solution. I do like Tailwind, for the record. It would be nice if its allies and enemies would both admit it makes tradeoffs.

It's only slightly more work than creating re-usable CSS.

Re: Working with Tailwind CSS every day for 2 years

#162

Post by dimmke »

nirvdrum wrote: post #147
dimmke wrote: post #134

Earlier quoted context omitted.

This is so frustrating to read over and over. Tailwind uses PostCSS. You can literally wrap a bunch of utilities inside a semantic class name. Or, if you're using containers/writing components you can literally do something like this: https://pastebin.com/qkdzGWNT But that a { could just as easily be "tag" Personally, I've always found BEM to be tedious and the sort of "roll your own" class names just doesn't scale.…

> This is so frustrating to read over and over. Tailwind uses PostCSS. You can literally wrap a bunch of utilities inside a semantic class name. If it's being asked repeatedly, it should probably be addressed somewhere. I see no mention of it in the tutorial or any of the amazing starter videos I've seen. I also have never used PostCSS directly before, so that's not an obvious solution. I appreciate the example you s…

Fair enough. I've realized I am currently using Tailwind in a way that is not the default and maybe a lot of people don't know about it. I think I will write a blog post about it.

Also, I think I am wrong. It's possible to use Tailwind without implementing a build step like PostCSS, which would necessitate using it much like the documentation describes.

>We've had well-functioning applications that predate Tailwind or CSS in JSS, so I'm not sure what doesn't scale.

CSS has fallen victim to the same "cult of semantics" that HTML has, and it's disingenuous bullshit just like it is in HTML (mostly).

Yes, if you have someone who really cares and writes great CSS they will have everything broken out into custom variables and well designed and named classes. You still have the problem of how you scale that, right? After all, if you have a .card that is formatted one way on one page but laid out differently on another, you have to think up a different class name or refactor.

Enter BEM. Block, element, modifier. A consistent naming system for your large application. That is both subjective, requires a lot of extra mental bandwidth in a time when you're lucky if half the "front-end developers" you're working with know more than the basics of CSS to begin with.

I have seen some truly tortuous HTML that uses BEM classnames. It was awful.

So when I say it doesn't scale, it's that most large codebases end up with !important everywhere and z-index:9999999 etc...

So throw it out completely. Utility classes make sense when you accept that you are probably styling a component and that markup will be inserted everywhere the component is. You never have to think about what your class name should be, and if it makes sense, or if it conflicts with other scopes.

Yes, an HTML element with 15 classes is not ideal.

The example I posted would hopefully be the logical end (and is if you're using Svelte with PostCSS configured) - where we're no longer writing html documents full of elements and then a stylesheet styling them. Each discrete UI element has one document, markup, state and styling are tightly coupled, and it can be reused many times.

It gets rid of nesting being very important, it gets rid of having to write verbose media queries for responsive. It makes changing things really fast.

The part about Tailwind providing sensible defaults in terms of sizing, spacing etc... is just icing on the cake. The problem that Bootstrap had is that it tried to do too much. It came about in an era when doing layout in CSS was really hard. So it rolls its own stuff like modals, dropdown menus, grid etc... it also takes it upon itself to style actual HTML elements, which to me is a very poor choice. Including bootstrap will get you default styles for headings etc... but I believe in Tailwind it's all done through utility classes.

Tailwind doesn't do that. The focus is on removing semantics from styling. Look at the API surface: https://tailwindcss.com/docs/

There's a "Components" link, but that's to a paid resource showing common UI patterns built with Tailwind.

Re: Working with Tailwind CSS every day for 2 years

#163

Post by robswc »

lloydatkinson wrote: post #23

Oh two tailwind hate threads today instead of the usual one at a time? Everyone as usual saying "long class lists" even though the literal home page tells you not to do this and to make components or partial views or whatever your tool of choice calls it. At least be inventive and follow the instructions before you start blaming something.

I never read the docs (ok, I do, eventually) but I actually never saw that "tidbit" but it just seemed intuitive that having a million classes wasn't good... but that's why I almost always make what I need to make and then start breaking it down into components. Or, if I have a good plan, start with components. I've never had to use an absurd amount of classes.

What is the alternative?

Re: Working with Tailwind CSS every day for 2 years

#164

Post by dimmke »

nirvdrum wrote: post #147
dimmke wrote: post #134

Earlier quoted context omitted.

This is so frustrating to read over and over. Tailwind uses PostCSS. You can literally wrap a bunch of utilities inside a semantic class name. Or, if you're using containers/writing components you can literally do something like this: https://pastebin.com/qkdzGWNT But that a { could just as easily be "tag" Personally, I've always found BEM to be tedious and the sort of "roll your own" class names just doesn't scale.…

> This is so frustrating to read over and over. Tailwind uses PostCSS. You can literally wrap a bunch of utilities inside a semantic class name. If it's being asked repeatedly, it should probably be addressed somewhere. I see no mention of it in the tutorial or any of the amazing starter videos I've seen. I also have never used PostCSS directly before, so that's not an obvious solution. I appreciate the example you s…

Also, I did look at the docs and there is an entire page dedicated to this subject that you can read and it does mention @apply.

https://tailwindcss.com/docs/reusing-styles#extracting-class...

Re: Working with Tailwind CSS every day for 2 years

#165

Post by karaterobot »

mind-blight wrote: post #102
karaterobot wrote: post #58

Earlier quoted context omitted.

Pretty much every CSS framework I've ever seen (and certainly every CSS-in-JS solution I've ever seen) has as its underlying premise "we know you hate CSS, and want to avoid thinking about it as much as possible". For people like me (and perhaps you) who actually like CSS, our reaction is "why would I ever want to use something that abstracts away the power and flexibility of a thing I enjoy using?" The problem is th…

I actually think a lot of CSS-in-js frameworks became popular for the same reason that React became popular: css, html, and to some extent JavaScript can't really be decoupled. Things like CSS Zen garden made it seem like they were, but that was only a separation of control. If the HTML structure changes, then the CSS likely needs to change. That's a tight coupling. CSS-in-js embraces the coupling and makes it explic…

I wrote that because the benefit most people who liked styled-components told me they appreciated was that they didn't have to think about inheritance. Everything is encapsulated in the component. This, to me, is equivalent to saying "I think the cascading part of CSS is either a mistake, or too complicated to maintain in practice, so I am going to eliminate it."

Re: Working with Tailwind CSS every day for 2 years

#166

Post by conradfr »

wagslane wrote: post #118

I really like Tailwind, I see a lot of hate in this thread so I'll try to offer a counter-perspective. First of all, it's important to understand what Tailwind is good for, and what it's not good for. Tailwind is NOT a design framework. It doesn't dictate the "theme" of your app. I like to think of tailwind as a tool for writing "clean" css that encourages good UI/UX practices. We need to stop comparing it to Bootstr…

> We need to stop comparing it to Bootstrap.

Bootstrap has actually a lot of utility classes (since v4 IIRC).

Re: Working with Tailwind CSS every day for 2 years

#167

Post by satvikpendem »

dmitriid wrote: post #146
satvikpendem wrote: post #115

Earlier quoted context omitted.

By having a style guide with variants, StitchesJS pioneered this but there are others like Vanilla-Extract. With TypeScript, you can then enforce that only a certain variant can be used with a certain component at compile time, basically making sure that your design style guide gets mapped 1:1 to your code. https://stitches.dev/

Hm. I see the same CSS-in-JS with a sprinkle of string interpolation for some variables :) I may run into the same issues as the other CSS-in-JS solutions (I only encountered stitch once, and not for a long period of time)

Unlike other CSS-in-JS though, the way it's made, via object properties, enforces compliance to the design system. In things like styled-components, it doesn't.

Doubly so when using TypeScript, as with Vanilla-Extract: https://vanilla-extract.style

Re: Working with Tailwind CSS every day for 2 years

#168

Post by nirvdrum »

dimmke wrote: post #164
nirvdrum wrote: post #147

Earlier quoted context omitted.

> This is so frustrating to read over and over. Tailwind uses PostCSS. You can literally wrap a bunch of utilities inside a semantic class name. If it's being asked repeatedly, it should probably be addressed somewhere. I see no mention of it in the tutorial or any of the amazing starter videos I've seen. I also have never used PostCSS directly before, so that's not an obvious solution. I appreciate the example you s…

Also, I did look at the docs and there is an entire page dedicated to this subject that you can read and it does mention @apply. https://tailwindcss.com/docs/reusing-styles#extracting-class...

Thanks. I did overlook that. Although, the docs are a bit foreboding.

"Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse."

Then it lists a bunch of reasons that seem to just be the author's preferences on things like naming and workflow productivity. I guess I don't think naming things is that hard. I generally need a name of some sort anyway so I can interact with the thing from JS. I haven't seen anyone argue not to use React or Web Components because naming a component is hard. I wonder if it's just a granularity thing. I tend to give a class name to a logical entity and then use ancestry selectors for nested tags, with SCSS mixins to avoid duplication.

Re: Working with Tailwind CSS every day for 2 years

#169

Post by nirvdrum »

greenhatman wrote: post #153
nirvdrum wrote: post #90

Earlier quoted context omitted.

I've been doing front-end development in some capacity almost as long as you, but it's not my forte. I've looked at Tailwind and I can see its value as a way to quickly prototype, but it also looks to violate the deeply instilled belief I have about semantically named classes. I know front-end development has changed its set of best practices several times now. We went from unobtrusive JS and semantic class names to…

Semantically named classes is a lot of effort to come up with, and don't really help much. One of the big selling points is that you can quickly style things without having to name every HTML element.

Thanks. I've commented on this elsewhere, but I think there's probably a mismatch in my thinking on the granularity of naming. I don't literally name every single element I'm styling. I agree that would lead to some very contrived names. I've understood semantic naming to apply to what, for lack of a better term, I'd call a component and then use ancestry rules to style within that "component". If you need to customize it, you can use the cascading part of CSS or use a pre-processor like SCSS to mix in and override things. I've found that leads to easily identifiable rules.

Of course, the trade-off is if you completely change the structure of that "component" you'll need to update any ancestry rules. But on the naming front, I'd need to come up with an identifier or logical class name to find the element in JS anyway, absent something like React that sort of controls the world.

Re: Working with Tailwind CSS every day for 2 years

#170

Post by dimmke »

nirvdrum wrote: post #168
dimmke wrote: post #164

Earlier quoted context omitted.

Also, I did look at the docs and there is an entire page dedicated to this subject that you can read and it does mention @apply. https://tailwindcss.com/docs/reusing-styles#extracting-class...

Thanks. I did overlook that. Although, the docs are a bit foreboding. "Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse." Then it lists a bunch of reasons that seem to just be the author's preferences on things like naming and workflow productivity. I guess I don't…

I agree that some of it is preference, but the main point he is making is that the number of utility classes doesn't matter if you're using a framework and styling a component. Yeah, it's ugly markup but so what?

With that said, I think it's reasonable to roll some things up into general classes. They remain very easy to change.

>I haven't seen anyone argue not to use React or Web Components because naming a component is hard.

I think the whole point is that that UI element, or "interface", or "component" is the thing that should have a name. That entity doesn't need to have a unique CSS classname.

Post reply on HN