Live data from Hacker News

Tailwind UI

tailwindui.com

161–170 of 367 posts

Re: Tailwind UI

#161
I've been using Tailwind for a year, I love it. I do think the example markup is often way more verbose then it needs to be.

My biggest request would be, making the naming conventions match more closely to CSS property names and Bootstrap 4 names. Once a developer learned the system, if they knew CSS property names they could automatically guess the Tailwind class without looking at the docs. Matching Boostrap 4 whenever its convention, would make it that much easier to convert BS4 sites to Tailwind (and easier to adopt for BS devs). My 2 cents.

Excited for UI. Keep it comin!

Re: Tailwind UI

#162
post #124

Earlier quoted context omitted.

> Tailwind has lots of classes, but each class does one thing I think this masks a lot of complexity that you have to manage when taking on this approach. And it's not because the approach is good or bad, more what it is or isn't suited for. The example on the homepage is very slickly presented, but the end result markup is extremely verbose. If I have a Card component, I would like to update them all at once when ne…

It’s common, even expected, to extract that card into a component of some kind (React, web components, mustache template, etc) so you still only have to update the css once.

Sure, until, you need a variation on that card for some elements, and add some other tailwind classes to the HTML to do it. Everything seems to work fine for a while.

Then you update the styles of the card again but the new styles clash with the ones in those tailwind classes and you end with broken styles in some elements.

Mixing components and utility classes is a recipe for future chaos.

Re: Tailwind UI

#164

Great job, this looks awesome! I wish something polished like this was around when I started my stuff. I'm not sure how I feel about Tailwind being almost 1mb of CSS :D, but it's probably worth all the time you save, especially for apps the size isn't such a big deal.

Tailwind is often paired with another build tool called PurgeCSS which eliminates any unused classes.

This was covered early in the tutorial I followed last summer. As someone who likes good web perf and remembers when sites were much slimmer on the frontend, I was very pleasantly surprised with the results I got.

Re: Tailwind UI

#165

Earlier quoted context omitted.

I'm tired of excuses for inferior tooling. If you truly know CSS, Tailwind is a waste of time.

I'm kind of with you on this. We're rebuilding a large internal admin tool with all in house css and components, it's tiny and fast. We didnt want to bring in bootstrap or some other huge framework. Those were fine when I was a jr developer - not anymore

The internet is in a perpetual state of beginner dev tutorials and junior developer tools. I am still waiting for the awesome stuff to come out but it all the same stuff.

Re: Tailwind UI

#166

Earlier quoted context omitted.

"text-sm" is just font-size and text-gray is a color code, so the order of the classes doesn't matter either. The biggest benefit of this over inline styles is that if I decide to change the color of "gray-700", since those colors come from a configuration, I only need to change it in my configuration. It takes some getting used to of the rules, but after a day or two I don't even need to think about what the class n…

> The biggest benefit of this over inline styles is that if I decide to change the color of "gray-700", since those colors come from a configuration, I only need to change it in my configuration. But gray-700 says it's a 70 % gray. Changing it to something else is akin to changing "color: #666" to "color: #444" through redefinition (JS?).

No, "gray-700" doesn't mean it's 70% gray. The term "700" is just referring to a color on a scale. I don't even need to name it "700", I can name it "dark" or whatever I want (which is what previous versions of Tailwind used).

i.e. "text-gray-dark", or "text-gray-700", would have a class with a single css property:

color: #4A5568;

By default Tailwind comes with a default color palette with hand picked colors. They were hand picked by a designer, not determined through an algorithm.

https://tailwindcss.com/docs/customizing-colors#default-colo...

Re: Tailwind UI

#167
post #162
post #124

Earlier quoted context omitted.

It’s common, even expected, to extract that card into a component of some kind (React, web components, mustache template, etc) so you still only have to update the css once.

Sure, until, you need a variation on that card for some elements, and add some other tailwind classes to the HTML to do it. Everything seems to work fine for a while. Then you update the styles of the card again but the new styles clash with the ones in those tailwind classes and you end with broken styles in some elements. Mixing components and utility classes is a recipe for future chaos.

How is that different from any other css? I'd argue any css solution would have this problem with components.

edit: thinking more, you can override classes. So yeah, maybe utility/atomic classes are not as effective here.

Re: Tailwind UI

#168

Tailwind has been great and I've been looking forward to this for months. I fought Tailwind as a concept pretty hard at first, but after hearing Adam and a few others raving about it I gave it a shot. It takes some getting used to at first but I can't imagine developing without it anymore. To me, the biggest benefit of Tailwind and utility classes in general is that it removes the cognitive overheard of having to thi…

Disclaimer: I haven't used Tailwind. Maybe I'm missing something. > For example, if I'm working on a card and I want some text below the main text to have a smaller, gray font size. What do I name that class? "card-sub-text", "card-sub-title"? No - don't even worry about it - "text-sm text-gray-700" and move on. What's the difference with "color: gray; font-weight: 700"? In this case I really don't have to care about…

I have been using tailwind on a new project and I only see 3 real benefits over using inline css styles:

1) Sizes are standardized in a predetermined set of discrete size classes. So you start to think about sizes, padding, margins, etc in terms of steps instead of values. You can change the steps in one place and they apply globally. It's a little easier to standardize a rough style guide compared to starting from scratch.

2) Colors are standardized in a similar way. You just need to configure your app's core colors and then you can just think in terms of steps instead of color values.

3) You have a smaller set of "best practice" means to achieve most outcomes compared to all that's available with css. You don't need to know the best way to do what you want, you can just browse the documentation to find what you want.

Outside of that, you still have to use @apply to collapse utility classes into more semantic classes if you want style changes to cascade (tailwind recommends using components or view partials to achieve this instead of via css classes, though this would work equally well with inline styles)

The styles are very verbose, just like with inline styles. They are only slightly shorter than inline styles since they are basically abbreviated forms of inline styles.

You can still do everything tailwind does for you by using your own style guide and building out css classes, but tailwind gives you a head start.

It feels like it makes you more productive in the beginning because you get a toolset with a lot of decisions already made for you, but I suspect it will make things a bit slower as the app gets more complicated.

Re: Tailwind UI

#169

Earlier quoted context omitted.

Disclaimer: I haven't used Tailwind. Maybe I'm missing something. > For example, if I'm working on a card and I want some text below the main text to have a smaller, gray font size. What do I name that class? "card-sub-text", "card-sub-title"? No - don't even worry about it - "text-sm text-gray-700" and move on. What's the difference with "color: gray; font-weight: 700"? In this case I really don't have to care about…

"text-sm" is just font-size and text-gray is a color code, so the order of the classes doesn't matter either. The biggest benefit of this over inline styles is that if I decide to change the color of "gray-700", since those colors come from a configuration, I only need to change it in my configuration. It takes some getting used to of the rules, but after a day or two I don't even need to think about what the class n…

(Also not a Tailwind user) I guess the common response to this is that well chosen semantic names usually help later down the line after these kinds of changes happen, especially with devs coming in and out.

I've actually come across C code that had "#define ONE_THOUSAND_TWENTY_FOUR 4096" because that was the audio buffer size and later had to be increased to 4096 but the macro name was never changed. AUDIO_BUFFER_SIZE would probably have been a better name in the first place.

Most code is not that bad though, haha. But that is still my first reaction. What if instead of slightly changing the gray color, you now want them to be blue and underlined? Or take HN for example, the username, vote buttons, and timestamp are all #828282, but have different class names. Is keeping this in sync ever a problem in Tailwind? This is only my first time looking at Tailwind, but it seems it's not really meant for "complex" apps where you'd run into these problems often?

Re: Tailwind UI

#170

Looks sexy but damn that's expensive. $250 for some pre-built styles I probably need to edit a lot anyway. I rather use a free option like https://semantic-ui.com/ than pay that much. Maybe if you are company but it doesn't really work if you are a solo dev or using it for a side project.

Try creating a similar set of components. Time yourself. Multiply with your hourly rate.

Not sure why you’re getting downvoted. I’m a developer but I don’t do much frontend stuff. I would absolutely look into something like this if I wanted to set up a website quickly and wanted it to look good without spending too much time on it
Post reply on HN