Live data from Hacker News

Tailwind UI

tailwindui.com

121–130 of 367 posts

Re: Tailwind UI

#121
post #36

On the surface, the markup is pretty damn awful. But if you reach certain level of proficiency, this will definitely speed up development. Back End Developer Personally I would prefer Bootstrap over this approach.

It's as if one person was arguing for hard-line separation of style and content, and another person was arguing that in-line is the way to go, and then Tailwind came along and said, "Why not both?" So now it's the worst of both worlds: an abstraction layer and dirty code.

Tailwind isn’t the first to take the utility class approach. Atomic CSS was an early implementation of the idea: http://acss.io

Re: Tailwind UI

#122
post #36

On the surface, the markup is pretty damn awful. But if you reach certain level of proficiency, this will definitely speed up development. Back End Developer Personally I would prefer Bootstrap over this approach.

It's as if one person was arguing for hard-line separation of style and content, and another person was arguing that in-line is the way to go, and then Tailwind came along and said, "Why not both?" So now it's the worst of both worlds: an abstraction layer and dirty code.

I think it's a little more subtle than you're saying.

When you use inline styles for everything, you're making the initial development a little faster by making future maintenance and changes a lot harder. (Like, if you decide headings should be italic instead of bold, that's a one-liner fix if you're using CSS properly, but if you're using inline styles you have to individually fix every heading on every page.) So most people have internalized "don't use inline styles for everything" as a general rule.

But if you don't actually care about that sort of future maintenance (or you're charging hourly for it), then using inline styles for everything looks really attractive to you! But you can't literally use inline styles for everything because even non-experts know that using inline styles for everything is bad for future maintenance. So instead you pull in Tailwind so you can say you're using a CSS framework.

Re: Tailwind UI

#123

Earlier quoted context omitted.

Disagree. Dumb is doing the same thing over and over again and creating new tooling to do the same thing over and over but with added dependencies and frameworks. The fundamentals of web development have barely changed but the flavor of the month way of doing the same thing is constant.

HTML and css are way too low level to be productive in, in my opinion. Especially when dealing with wide ranges of screen sizes, browsers, and platforms. The only way I’m interested in touching the stuff is if there are tools to alleviate the pain. Caveat: not a UI developer, I’ve mostly done backend work And DevOps for quite some time.

HTML and CSS are too low level? Does such a tool like dreamweaver with response rendering exist?

It's an interesting concept.

Re: Tailwind UI

#124

Earlier quoted context omitted.

I find that the verbosity is annoying at first, but it makes it incredibly easy to come back to some old HTML and work out exactly what it's doing, and why. Even with Bootstrap, you need to maintain a mental model of what the classes are doing and how they compose, and each custom class adds more complexity to that mental model. Yes, Tailwind has lots of classes, but each class does one thing , so reasoning about the…

> 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.

Re: Tailwind UI

#125
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 think of class names while designing a new page.

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.

Later on, if I end up repeating that combination in a number of places, I have more context of what that class name really should be, and I can extract the utility classes to a specific class name.

Really powerful stuff that has helped to increase my velocity quite a bit.

Re: Tailwind UI

#126
post #121

Earlier quoted context omitted.

It's as if one person was arguing for hard-line separation of style and content, and another person was arguing that in-line is the way to go, and then Tailwind came along and said, "Why not both?" So now it's the worst of both worlds: an abstraction layer and dirty code.

Tailwind isn’t the first to take the utility class approach. Atomic CSS was an early implementation of the idea: http://acss.io

It doesn't have to be first to be bad. They can both be bad.

Re: Tailwind UI

#127
First, I want this. TailwindCSS has great developer experience for me. I would pay for this even if I wouldn't use it, but I definitely will.

I like how they didn't limit too much what can you do with components in license, which is really good.

I generally am OK with this and want to see if I want to get just appUI or both sets. I think Adam should've joined them together and maybe given us some deal on pricing as early adopters. But, he is great guy, and this is excellent way to support him and project.

Re: Tailwind UI

#128
post #4

Earlier quoted context omitted.

Looks good and polished, but that landing page requires 165 KB of CSS, gzipped. That's, to put it lightly, ridiculous.

Yes, but that's just because I think for simplicity they created one large CSS file that is used for all their components and example pages. That's not very realistic. You're not supposed to do it like this for your own project. Instead if you use Tailwind CSS and PurgeCSS I'm pretty sure you would end up with ~10 or 15 kB of CSS gzipped, maybe less.

> You're not supposed to do it like this for your own project.

If even the creator of Tailwind doesn't use Tailwind properly, does anyone?

Re: Tailwind UI

#129

Earlier quoted context omitted.

All of these new frameworks look great, but there just isn't a good way to switch from, e.g., Bootstrap to a new one. I've never come across a framework that had any kind of conversion tool or even a guide on how to efficiently switch.

Jason McCreary from Laravel Shift made a tool called Tailwind Converter which will convert Bootstrap code to TailwindCSS. It's pretty wild. https://laravelshift.com/convert-bootstrap-to-tailwind-css

It converts the css but keeps the markup.

Re: Tailwind UI

#130

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 the property order, whereas in your case I would guess you still have the cognitive overhead requiring you to know that "gray" comes before "700" (unless it's expected to be preprocessed away? what if I use text-700-gray?).

Post reply on HN