Live data from Hacker News

Show HN: Tailwind Template Directory

tailkits.com

41–50 of 81 posts

Re: Show HN: Tailwind Template Directory

#41

Earlier quoted context omitted.

I strongly disagree on the maintainability. Mistakes are easy to make and have been made when comparing a list of 20 class names across a dozen elements. Its only "maintainable" if you ignore the class list when reading. I review my local evangelists' tailwind code and from their mistakes its clear they're not reading the class list. It reminds me of how some people claim they're great at multitasking and can text &…

I’ve experienced the exact same thing. Most TW evangelists I know are admittedly not that great at CSS. Those who are generally prefer a library like MUI instead, which offers the same maintainability benefits, a far more consistent UI, but with a higher learning curve.

As an end user (not developer) I'd take just about any design system over MUI. It's so clunky/heavy, has an abundance of useless white space, and just feels really outdated.

Re: Show HN: Tailwind Template Directory

#42

Earlier quoted context omitted.

So that’s a mid blue button that gets slightly darker on hover, with bold white text, it’s got a little more horizontal padding than vertical padding and has slight corner rounding and a slight drop shadow. And I can see all of that in context where the button is declared rather than having to go look at another file and see what everything is. Oh and I know that none of those TW classes conflict or over write any pr…

Good luck changing the style site-wide.

A few points on that. First, in 25 years of front end dev at scale I can't think of a time when a site I've worked on has ever actually made a site wide change to the styling without it being a big deal. It's always a lot more work than just changing some CSS because you have to consider things like whether you actually want to change every button, what background color the buttons are sat on, what text color it has, whether the color you choose should be applied everywhere or just in dark|light mode, and so on. Site wide changes are a big deal and the actual code is a relative small part of that.

Secondly, with the componentization of web apps this is largely quite simple from a code perspective. All the other complexities remain but changing a Tailwind styled button isn't much hard than changing a CSS class.

Lastly, designers are moving to design tokens applied in Tailwind config or CSS vars. This decouples the colors from the classes and turns them into config that's exported from an app like Figma, with tools to automate that export as a git PR if you're feeling technical.

These things were hard to do. People in front end tech have thought about that and built tools to make it a lot easier.

Re: Show HN: Tailwind Template Directory

#43
post #42

Earlier quoted context omitted.

Good luck changing the style site-wide.

A few points on that. First, in 25 years of front end dev at scale I can't think of a time when a site I've worked on has ever actually made a site wide change to the styling without it being a big deal. It's always a lot more work than just changing some CSS because you have to consider things like whether you actually want to change every button, what background color the buttons are sat on, what text color it has,…

There are solutions of course. But they quickly break down when you're iterating quickly, copying in code from libraries like flowbite, etc and want to go back and restyle later.

A better approach that doesn't seem to exist would be some after-the-fact automated cleanup that could at least restructure the class list on attributes to e.g. sort class names alphabetically, replace where you copied text-blue-* instead of text-primary-* to fix issues like that, or other tools to aid refactoring.

Re: Show HN: Tailwind Template Directory

#44
post #12

Earlier quoted context omitted.

Interesting response. I'm in this war against build steps. Is there a way to 80/20 Tailwind without the build steps? I mean, get 80% of the benefits with 20% of the work.

Yes, CSS variables. Defining a preset of variables on :root for sizes and color ranges goes a long way. The design philosophies behind Tailwind are sound, but like so many I dislike the technical implementation. I feel like there is a lot of halo effect happening with Tailwind where judgement of technical merits is influenced by judgement on visual merits.

Interesting. Seems quite well supported.

https://caniuse.com/css-variables

Re: Show HN: Tailwind Template Directory

#45
post #42

Earlier quoted context omitted.

A few points on that. First, in 25 years of front end dev at scale I can't think of a time when a site I've worked on has ever actually made a site wide change to the styling without it being a big deal. It's always a lot more work than just changing some CSS because you have to consider things like whether you actually want to change every button, what background color the buttons are sat on, what text color it has,…

There are solutions of course. But they quickly break down when you're iterating quickly, copying in code from libraries like flowbite, etc and want to go back and restyle later. A better approach that doesn't seem to exist would be some after-the-fact automated cleanup that could at least restructure the class list on attributes to e.g. sort class names alphabetically, replace where you copied text-blue-* instead of…

There are rules for stylelint that will reorder and dedupe Tailwind classes.

Re: Show HN: Tailwind Template Directory

#46
post #10

A lot of Tailwind's value comes not from the utility classes, but from the design system they enforce on the user, which is the most valued feature Tailwind offers, in my opinion.

I’ve always had the idea of producing a CSS design system with just a bunch of preset CSS variables to use like ‘margin-left: var(—-p2);’, as it’s close to how I end up using Tailwind lately; ‘@apply ml-2;’

Re: Show HN: Tailwind Template Directory

#47
post #40

Earlier quoted context omitted.

If you can’t follow a DOM tree through some custom components to debug uhhhh… maybe practice more.

The point was, obviously, that the styling string doesn't go away if you hide it inside an element.

Then I’m failing to see why it’s “bad” other than the verbosity/visual noise, which does in fact go away if you hide it (this is the point of abstraction in general, of course)

Re: Show HN: Tailwind Template Directory

#48

I really was hoping that tailwind was a fad which died but like everything JavaScript it's here to stay sadly I recently found myself staring at a button element with more classes than I have ever seen like Click me! . It’s like the eccentric artist who insists on using every color in the palette. After been forced to use it for almost 2 years I still don't see the point. Your HTML files? Bloated. Your sanity? Questi…

The point is that it’s ridiculously fast to build and extremely easy to maintain. It’s also not hard to read after, idk, a week of working in it? The only people I’ve seen struggle beyond that are people who dug in their heels and dogmatically decided to struggle with it. FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a element.

You lost me at ‘maintain’. It’s definitely not easier than just updating a single .button class, and I’m not going to create reusable components out of everything in my project, the approach doesn’t work for everything.

Re: Show HN: Tailwind Template Directory

#49
post #48

Earlier quoted context omitted.

The point is that it’s ridiculously fast to build and extremely easy to maintain. It’s also not hard to read after, idk, a week of working in it? The only people I’ve seen struggle beyond that are people who dug in their heels and dogmatically decided to struggle with it. FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a element.

You lost me at ‘maintain’. It’s definitely not easier than just updating a single .button class, and I’m not going to create reusable components out of everything in my project, the approach doesn’t work for everything.

Yes, it is easier to maintain

(assuming no css-in-js) Your styles are bound to the component, not some global in your app.

States and their representations are controlled in the component themselves

With normal css files and class names, you must jump between files. With tailwind, I see what's going on with a component right in my jawascript

Re: Show HN: Tailwind Template Directory

#50
post #48

Earlier quoted context omitted.

The point is that it’s ridiculously fast to build and extremely easy to maintain. It’s also not hard to read after, idk, a week of working in it? The only people I’ve seen struggle beyond that are people who dug in their heels and dogmatically decided to struggle with it. FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a element.

You lost me at ‘maintain’. It’s definitely not easier than just updating a single .button class, and I’m not going to create reusable components out of everything in my project, the approach doesn’t work for everything.

The things it doesn't work for are the things that .button doesn't work for either.
Post reply on HN