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

Tailwind UI

tailwindui.com

Post reply on HN
Print view View original

181–190 of 367 posts

Re: Tailwind UI

#181

Post by gyrgtyn »

rjknight wrote: post #41
pcurve wrote: 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.

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…

It's good across projects/teams/job too. You know what everything does. You don't have to learn every btn--rounded--primary thing for every app you work on.

Re: Tailwind UI

#182

Post by terenceng2010 »

mcbetz wrote: post #158
wwweston wrote: post #149

Earlier quoted context omitted.

OK, this: ` Isn't this why we have CSS preprocessors? So we can do: .description-of-what-this-is { .lg_flex() .lg_items-center() .lg_justify_between(); } Assuming there's enough complexity beneath the mixins to justify their use -- some of these might just be CSS properties.

You can do this with Tailwind as well: https://tailwindcss.com/docs/extracting-components // in JS, then build .btn-blue { @apply bg-blue-500 text-white font-bold py-2 px-4 rounded; }

This feature makes it a very progressive library for various stages of development. Inline earlier, then gradually extracting the style for reuse in later stage. Besides, their documentation is really good for one to learn those newer css concept.

Re: Tailwind UI

#183

Post by WilliamEdward »

larrywright wrote: post #11
chrshawkes wrote: post #9

Earlier quoted context omitted.

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

If you truly know assembler, C/Python/Ruby/Go is a waste of time. See how dumb that sounds?

I get the sentiment but Python is to assembly as Tailwind is to assembly. It's too far removed.

The leap between vanilla css and tailwind is not large at all.

Re: Tailwind UI

#184

Post by jwr »

newfeatureok wrote: post #71

The problem with this IMO is that some enterprising person will just use regular tailwind (or another utility-css framework like tachyons) and re-implement all of these components and give it out for free, circumventing the license and killing the value of this. Normally with themes it would be time prohibitive to do so, but the nature of utility-css is that it's relatively straightforward to implement each component…

I use Semantic-UI, which had a problem of finding sustainable funding. There is a community fork (Fomantic-UI), which does not align with my (business) needs: stability, bug fixes, long-term sustainability, rather than adding features left and right and becoming Yet Another All-Encompassing JavaScript-heavy Framework.

Tailwind-UI looks very interesting and I would have no problem paying for it, rather than getting a "free" version, if only for the long-term sustainability. Community projects often go through endless rewrites, and suffer from feature creep and lack of direction.

In a business setting (I run a self-funded SaaS business) I am much more interested in a framework that fixes bugs and is stable.

The only thing that worries me is that the pricing is one-time rather than subscription. How can the authors expect long-term sustainability with a one-time payment? Maintaining a CSS library is a continuous effort, not a one-time thing.

Re: Tailwind UI

#185

Post by gyrgtyn »

deweller wrote: post #6
rado wrote: 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.

For comparison, what is bootstrap v4's weight?

https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstra... is about 20K, gzipped

plus javascripts

Re: Tailwind UI

#186

Post by nfRfqX5n »

csande17 wrote: post #122
reaperducer wrote: post #115

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.

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

it would still be a one line fix if you are building with components

Re: Tailwind UI

#187

Post by [deleted] »

mike1o1 wrote: post #166
blattimwind wrote: post #160

Earlier quoted context omitted.

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

[deleted]

Re: Tailwind UI

#188

Post by s17n »

csande17 wrote: post #122
reaperducer wrote: post #115

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.

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

I think that the idea of using well designed CSS rules and classes basically just turned out to not be very useful in the real world (one discussion of the issues: https://speakerdeck.com/vjeux/react-css-in-js)

Re: Tailwind UI

#189

Post by tjholowaychuk »

newfeatureok wrote: post #71

The problem with this IMO is that some enterprising person will just use regular tailwind (or another utility-css framework like tachyons) and re-implement all of these components and give it out for free, circumventing the license and killing the value of this. Normally with themes it would be time prohibitive to do so, but the nature of utility-css is that it's relatively straightforward to implement each component…

There's inherent value in supporting something with money though, it's likely to actually stick around and improve, rather than some hacky OSS project that will die in a few months.
Post reply on HN