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

Show HN: Tailwind Template Directory

tailkits.com

Post reply on HN
Print view View original

31–40 of 81 posts

Re: Show HN: Tailwind Template Directory

#31

Post by smatija »

nprateem wrote: post #21
smatija wrote: post #16

Earlier quoted context omitted.

Agreed, I find tailwind defaults sensible, but it tends to make templates quite unreadable. My compromise with it is just using @apply in css files: styles.css: .button { @apply px-2 py-1 rounded-sm shadow-md hover:shadow-lg font-bold cursor-pointer block; height: 32px; } .button.create { @apply bg-green-700 text-white; } template.html: ...

Ah the dream. Only now it takes my django project 45s to rebuild the tailwind any time I change those styles (and I only have about 30).

For me it's just a few seconds, but my css needs are rather compact. Luckily I don't have to change styles daily though.

Re: Show HN: Tailwind Template Directory

#32

Post by hennell »

oDot wrote: 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.

Yeah, the advantage of limiting colours and sizes to preset multiples made life a lot nicer for a while. Very easy to keep things looking consistent without needing to re-reference specific values. But they keep making it more and more easy to do things like p-[7px] which rather defeats the point and there seems to be talk about changing the scales to just using px/rem numbers which feels like a complete abandonment of the idea.

Customise the tailwind config for your design system, add additional CSS in a css file for specific needs. Generating arbitrary values on the fly just muddies the system back up again.

Re: Show HN: Tailwind Template Directory

#33

Post by nprateem »

hennell wrote: post #29
nprateem wrote: post #25

Earlier quoted context omitted.

Good luck changing the style site-wide.

Go into the button component change the style.

I'm sorry, I'm not creating a component per HTML tag with all the possible attributes just for my design system. What a complete waste of time.

Anyway the GP said he could see everything without extra files. Which is it?

Re: Show HN: Tailwind Template Directory

#34

Post by llamaimperative »

lawn wrote: post #15
llamaimperative wrote: post #3

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.

> FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a element. And pray you never have to tweak or debug that element. Hiding away bad code where you don't have to look at it doesn't stop it from being bad.

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

Re: Show HN: Tailwind Template Directory

#35

Post by mattbrewsbytes »

Crazyontap wrote: post #2

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…

Having just dipped my toes into tailwind and getting back up to speed on CSS, its shortcut syntax to base CSS. Putting all of that right on the element makes it easy for anyone to understand what is going on.

After seeing web tech come and go over the years, I have a distaste for most tech that transpiles or similar things. In my experience, transpiling increases the likelihood of painting yourself into a corner eventually. It complicates the tech stack by adding more dependencies and it appears a goal with a lot of frameworks is to avoid actually writing HTML and CSS. Sure the goal of using techniques so you don't have to repeat code is there too but how many abstractions are actually necessary to achieve that?

Re: Show HN: Tailwind Template Directory

#36

Post by llamaimperative »

orangepanda wrote: post #14
llamaimperative wrote: post #3

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.

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 &…

What kind of mistakes are easy to make? And why are you “comparing” class name lists?

Re: Show HN: Tailwind Template Directory

#37

Post by liampulles »

Crazyontap wrote: post #2

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…

Different strokes I guess.

I would say I have basic skills (and interest frankly) in web dev, and I find all the HTML and CSS to look pretty messy anyway. At least with Tailwind I can have the mess in one place and try and understand it there, rather than needing to track down and interpret which CSS class is causing what and how to modify it without breaking something else.

Re: Show HN: Tailwind Template Directory

#38

Post by simonw »

lobsterthief wrote: post #26
klabb3 wrote: post #11

Earlier quoted context omitted.

> And those cryptic class names? They’re as cryptic as ls, cat, pwd. They have well defined semantics, sensible default, and tooling that can warn if your properties are conflicting. In fact, with regular css you need to target elements by coming up with arbitrary class names, like .banner-main-content. Those are more cryptic imo, and completely arbitrary. (Naming things is problem #2, remember) Do I wish there was a…

Have you used MUI before? No need for utility classes, no need for writing custom selectors, everything ties back to the theme, and everything is consistent. I don’t believe that “80-95% of the time utility classes are better” when super popular alternatives like MUI exist. Tailwind introduces some solutions while introducing other problems. It has its place when used correctly, but I’ve never seen a single TW codeba…

Do you mean this MUI? https://github.com/muicss/mui

Last commit was four years ago and it has some weird bugs, eg this page tells me "Warning: Your browser does not support WebComponents" when Mobile Safari most definitely does. https://www.muicss.com/docs/v1/webcomponents/buttons

(Filed an issue: https://github.com/muicss/mui/issues/338 )

Re: Show HN: Tailwind Template Directory

#40

Post by lawn »

llamaimperative wrote: post #34
lawn wrote: post #15

Earlier quoted context omitted.

> FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a element. And pray you never have to tweak or debug that element. Hiding away bad code where you don't have to look at it doesn't stop it from being bad.

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.
Post reply on HN