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

151–160 of 367 posts

Re: Tailwind UI

#151

Post by Tomte »

leeoniya wrote: post #148
Tomte wrote: post #13

Earlier quoted context omitted.

Is there a production-ready CSS purger that's not written in JavaScript? Last time I looked I couldn't find any. I'm not particularly against JavaScript, but I'm not willing to install and use npm and several hundred dependencies. All documentation for purgecss always includes postcss and a gazillion other packages I have never heard of. Maybe something in Go, as a single executable?

https://github.com/leeoniya/dropcss still in js, but very fast, ~10KB (min), 0 dependencies, and does not require npm [1]: however, it expects properly formed html and css; the parsers are quite unforgiving. (i'm the author) [1] https://github.com/leeoniya/dropcss/tree/master/dist

Thanks! Properly formed input is not a problem in my case.

Re: Tailwind UI

#152

Post by sandGorgon »

dinkleberg wrote: post #69
sandGorgon wrote: post #53

so the problem is that this is priced too high. Its not about free, but the real pricing market now is themeforest. For example - http://landrick.react.themesbrand.com/ is 17$. https://g-axon.com/wieldy-ant-design-react-redux-admin-templ... is 24$ (which uses ant design)

Tailwind UI is not a theme, it's a component library. The target audience is different. I bought this the moment I got the email about it this morning because this is going to help my productivity in building web applications. When you use Tailwind, you aren't using a pre-made theme as you would with a bootstrap theme you buy, you are designing it from scratch. With this UI kit you'll get some nice building blocks to…

Not to be an ass, but so is Ant design or Semantic UI.

I honestly think this is priced too high.

Re: Tailwind UI

#153

Post by iudqnolq »

ec109685 wrote: post #150
iudqnolq wrote: post #132

Earlier quoted context omitted.

Or each of your headings is a React/Vue/Web/Polymer/etc component and that's a single edit. Also, sed.

And then the components get bloated to handle logic differences between views of the component, so you went from bloated CSS to bloated components and the need for everything to be a component in order to share a single look and feel. Once the components get too bloated, you start forking them, and you are back to each page looking subtly different.

Sure, no magic bullet.

Re: Tailwind UI

#154

Post by tasogare »

alharith wrote: post #137
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…

> 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. No because I believe that for every enterprising person wanting to circumvent paying for software, there are that many people who want to support the entre…

I wouldn’t bet on that. Most people want things for free and would stole digitized assets if they can go away. In a way what you wrote is true, but I’ll reverse it: for anyone willing to pay, there are many...

Re: Tailwind UI

#155

Post by Ligrev »

wwweston wrote: post #149
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.

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.

That assumes you have the means, the knowledge, and the time, to go through a build step.

What you find to be clean code might go the opposite way for someone (i.e. why would I use scss if utils are all I need?).

You might work with large scale apps where BEM may make more sense. You might work on a site builder where utils might be better. You might be creating splash pages for marketing purposes where going for element selectors may be enough.

Re: Tailwind UI

#156

Post by ec109685 »

city41 wrote: post #124
have_faith wrote: post #65

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.

Your components often get bloated since you have to account for subtle business logic differences between views.

Re: Tailwind UI

#157

Post by blattimwind »

reaperducer wrote: post #126
city41 wrote: post #121

Earlier quoted context omitted.

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.

uikit as well (the CSS framework, not the Apple thing)

Re: Tailwind UI

#158

Post by mcbetz »

wwweston wrote: post #149
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.

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; }

Re: Tailwind UI

#159

Post by rymate1234 »

arcatek wrote: post #130
mike1o1 wrote: post #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 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 700 is a shade of gray not a font weight

Re: Tailwind UI

#160

Post by blattimwind »

mike1o1 wrote: post #134
arcatek wrote: post #130

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…

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

Post reply on HN