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

141–150 of 367 posts

Re: Tailwind UI

#141

Post by Nullabillity »

iudqnolq wrote: post #132
csande17 wrote: post #122

Earlier quoted context omitted.

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…

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

Sure. And in that case, just use inline styles (or CSS-in-JS, or whatever else you prefer).

Re: Tailwind UI

#142

Post by 32gbsd »

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.

that is some awful looking css you have there.

Re: Tailwind UI

#143

Post by iudqnolq »

deltron3030 wrote: post #138
iudqnolq wrote: post #93

Earlier quoted context omitted.

What if you want every link (from the perspective of the user, not based on the tag type) to have the exact same style? How would you do that without some sort of build step with an atomic unit for a link? Isn't a section just a case of a component?

You could define the anchor element in the preflight.css file (normlize.css/reset). Yeah, a section is a component, but in my book it also involves the visible page background where the element is located (you could override the page background with a section color), like a slice of the page.

Fair enough. I'd call that definition a component.

Re: Tailwind UI

#144

Post by robertoandred »

have_faith wrote: post #112
mattferderer wrote: post #97

Earlier quoted context omitted.

You're right. Don't use Tailwind if you don't know CSS well. The use case is for creating Template Components with something like React, Vue, Hugo, Razor or another component template framework. Tailwind offers a large list of customizable variables to use to help keep your CSS consistent. You're still pretty much writing CSS though, just with shortcuts. I consider it Emmet CSS + Variables. I also highly suggest usin…

I thought the anti-css crowd who use React etc generally preferred some form of Styled Components where the style is written in JS? It's a mixed up world of factions :) Whether building a regular website or a web-app I generally just use component names (like .card) the same way. I'm more of a fan of defined components with limited variations though than people being able to change anything with a lot of utility clas…

Styled Components still uses CSS, it just removes the ambiguity and additional abstractions around class names.

Re: Tailwind UI

#145

Post by iudqnolq »

Nullabillity wrote: post #141
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.

Sure. And in that case, just use inline styles (or CSS-in-JS, or whatever else you prefer).

Sure. I view tailwind as a moderate abstraction over inline styles.

Re: Tailwind UI

#146

Post by andrei_says_ »

holler wrote: post #73
generalk wrote: post #24

Earlier quoted context omitted.

I've been reading awful takes like this since I started writing software. "PHP is an awful language, superior developers write in Perl." "Rails is bloated and slow, making it unfit for any real work." "True developers don't rely on frameworks, writing all your own code is the only way to be performant." If you wanna handicap yourself, be my guest. I've written three or so projects in TailwindCSS, and it lets me creat…

that may be so, but I think it's a valid point to bring up the tradeoffs you're making, including using a non-standard dsl that other designers/developers/hires will likely be unfamiliar with. personally having written css since I was a teenager, my gut reaction is "eww", but if the team or stakeholders deem it to add value to a project and not affect productivity, sure why not?

I think it’s not for people who know CSS. It’s specifically for SPAs where site-wide changes are related to component changes and so having to change the html is not that different from changing the css.

I can not force myself to use something like this but I’ve been writing CSS for a long time.

I use BEM and predefined sets of colors and space values to ensure consistency and that’s efficient enough for me.

Re: Tailwind UI

#147

Post by 32gbsd »

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 people that use utility CSS like this will never maintain anything they create. They'll just throw everything away and start over with another framework.

Re: Tailwind UI

#148

Post by leeoniya »

Tomte wrote: post #13
psychometry wrote: post #10

Earlier quoted context omitted.

I'm sure that in an actual project, you can use tree shaking or a custom build to avoid including components you don't need.

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

Re: Tailwind UI

#149

Post by wwweston »

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.

Re: Tailwind UI

#150

Post by ec109685 »

iudqnolq wrote: post #132
csande17 wrote: post #122

Earlier quoted context omitted.

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…

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.

Post reply on HN