Live data from Hacker News

Konsta UI – Mobile UI Components Built with TailwindCSS

konstaui.com

191–200 of 243 posts

Re: Konsta UI – Mobile UI Components Built with TailwindCSS

#191

Earlier quoted context omitted.

I’ve recently started working on 2 legacy codebases, one with tailwind and one with scss. The #1 problem — that has cost me multiple hours! — is inheritance, because how developers write CSS and how business people think about design are very different. I constantly find myself causing side effects when making any change to the css, it’s a headache. I don’t think tailwind is perfect but coming into a well-established…

I work in React so all of our CSS is scoped, at the very least with CSS modules, so we never get to a point where we have global CSS, at all. If you're working on a project that uses global styles, then yes, it will be extremely painful. But in the days of components, Tailwind simply is worse to me from a maintainability perspective than just having scoped CSS. It is at best equal to CSS classes because inevitably th…

Why use @apply if your CSS is component scoped anyway.

Additionally, CSS Modules is not a replacement for TailwindCSS. TailwindCSS ships and strongly promotes the use of design tokens. It is harder to NOT use design tokens in TailwindCSS.

Because of this, there is no CSS Modules v. TailwindCSS. It is CSS Modules + X v. TailwindCSS. Where in the worst case "X" is just a stand-in for "everybody does whatever" which produces horrendous unmaintainable stylesheets whether they are global or not.

Re: Konsta UI – Mobile UI Components Built with TailwindCSS

#192
post #189

There's two distinct camps talking past each other: - Devs who make relatively small e-commerce-type websites, who loves tailwind, bootstrap, etc. Good defaults, fast throughput, maintenance is less important - Devs who make relatively big web apps, who hates them. Everything ends up customized one way or another, maintenance is most of the work, tailwind and bootstrap end up only getting in the way. The problem here…

Problem is tailwind is not hard to maintain. I would argue it's easier. Folks look at it and it looks like a nightmare (the documentation even says so) but you have to actually give it a fair shake. I can always jump back into a tailwind codebase and not only do I know what mr-4 does I know where it is when looking at the rendered component. You find yourself having to do "Right click > inspect" a whole lot less ofte…

> You find yourself having to do "Right click > inspect" a whole lot less often to figure out what's going on

Instead I find myself going to the Tailwind docs to find out how they renamed this random css property.

But it’s still better than plain CSS.

Re: Konsta UI – Mobile UI Components Built with TailwindCSS

#193

Earlier quoted context omitted.

[flagged]

I see the Tailwind fans come out on any criticism of their library. I posted my comment a few minutes ago and already got a few combative comments almost immediately afterwards.

I think it’s interesting that just because you don’t like Tailwind, suddenly vanilla-extract and Typescript are trash.

I wonder if there’s a correlation between people that like Tailwind and hate Typescript?

Re: Konsta UI – Mobile UI Components Built with TailwindCSS

#194
post #130

Earlier quoted context omitted.

I have a really hard time seeing someone use Tailwind as a shortcut because they don't know CSS. That comment does not say what you think it is. They are not saying they use it because they don't know CSS. The maintenance is what makes Tailwind awesome. I've written CSS professionally since Internet Explorer 6 and have gone through many different strategies for writing maintainable CSS (BEM, OOCSS, SCSS and multiple…

Funny, to me arguing for Tailwind is like arguing for copy pasting code around instead of using functions and classes, which the Tailwind devs literally tell you to do by the way. I mean, when I saw their official recommendation for maintenance of code and reusing styles was to use multiple cursors , I had to laugh out loud. https://tailwindcss.com/docs/reusing-styles

To me, it seems more like favoring composition of small parts over inheritance of everything.

That's what CSS is, a HUGE inheritance graph, just even more convoluted, because absolutely every "class" is part of the same graph.

Re: Konsta UI – Mobile UI Components Built with TailwindCSS

#195

Earlier quoted context omitted.

And many people don't work in components or scoped CSS. Utility classes help so much in those cases. The only problem with tailwind is it goes super overboard with the idea. You want to use probably 30% of tailwind and use their naming convention. But once people start to write some long on demand single classes its always better just name a class and use CSS. I think its because the authors need to be seem they are…

What I’ve found from our Tailwind codebase is this: If you have a design system, Tailwind.config can be used to both extend and limit the classes. Notably, we cut all tailwind colors out and only define theme colors. We also define all sizing, shadows, and text styles around our design system. This constrains your design down to only “legal” values. This doesn’t mean every design will be magically right, but it separ…

Twind could help you there:

https://twind.style/grouping-syntax

Re: Konsta UI – Mobile UI Components Built with TailwindCSS

#196
post #53

Earlier quoted context omitted.

Tailwind is literally someone else’s PostCSS output.

No, it's your own PostCSS output. At least if you want to only have the definitions you actually use.

OK I mean “someone else wrote the mixins” you mean “you ran the compiler and did tree shaking”.

Re: Konsta UI – Mobile UI Components Built with TailwindCSS

#197

Earlier quoted context omitted.

> Then just use CSS at that point, since the classes literally just map onto CSS properties anyway CSS is definitely a write-only language. I've yet to see anyone understand CSS in a large system and refactor it. You end up with dozens and hundreds one-off classes and overrides everywhere.

So, the same as Tailwind then? That's also why I'd consider Tailwind a write only language, except with CSS you at least have the chance of organizing it properly.

> So, the same as Tailwind then?

Worse.

With Tailwind you have a consistent set of classes scoped usually per component. Thos p-x, m-x, and others don't change from component to component or from project to project.

Hell if I know what `.chip-text__content` is, how it's different from `.icon-button__content`, why it interferes with my CSS, and what other 15 CSS classes I need on top of that to make it work.

Re: Konsta UI – Mobile UI Components Built with TailwindCSS

#198
post #189

There's two distinct camps talking past each other: - Devs who make relatively small e-commerce-type websites, who loves tailwind, bootstrap, etc. Good defaults, fast throughput, maintenance is less important - Devs who make relatively big web apps, who hates them. Everything ends up customized one way or another, maintenance is most of the work, tailwind and bootstrap end up only getting in the way. The problem here…

Problem is tailwind is not hard to maintain. I would argue it's easier. Folks look at it and it looks like a nightmare (the documentation even says so) but you have to actually give it a fair shake. I can always jump back into a tailwind codebase and not only do I know what mr-4 does I know where it is when looking at the rendered component. You find yourself having to do "Right click > inspect" a whole lot less ofte…

Tailwind is not easier to maintain than vanilla CSS in any way. There are no standards in Tailwind, tomorrow if they wanted they could rename everything. CSS actually has standards to adhere itself to. On top of this, Tailwind has to go through a process to adopt bleeding edge CSS changes, which makes maintenance a chore when you really wanted that new feature.

Tailwind is not easier than a custom internal design system either, as that has been tailored to your company and the maintenance of that system is integral to your design team. You might think that offloading to Tailwind is better, but you're just doubling up duties because someone internally is going to have to customize away from the defaults.

Tailwind can be easier to maintain than similar libraries. After trying most of these, I can't say whether that actually shows itself during development. I suppose if one was exclusively used to Vue or was brought up in the world of overzealous BEM, Tailwind might seem easier/refreshing. But if you've worked with Bootstrap or its alternatives (of the time), Tailwind isn't much different and can feel like a step back when you now have to rely on additional libraries like Konsta, Daisy, or Tailwind UI to create premade components for you.

Your example confuses me too, because why wouldn't your devtools be open anyways? You're in development so use the tools you have to make your job less of a guessing game. I guess what you say might be true, you can load a page and just tell a component has a margin right but you're going to be opening the devtools anyways to double check.

I still think Tailwind is great for solo devs, it's a design system with sane defaults they can rely on and get something in production very fast. Every other reason I've seen Tailwind devs give winds up confusing me about how they're actually working, or if they've ever bothered with anything else.

Re: Konsta UI – Mobile UI Components Built with TailwindCSS

#199
post #147

Earlier quoted context omitted.

> With Tailwind you’re forever jumping between components and figuring out what that one long line of class names is actually doing. Only if you already have no clue what CSS is. If you know CSS and can’t figure out what a given tailwind class does, then I don’t know if anyone can help you. That said, I do often feel that I might as well just write the css directly. Writing tailwind feels like another translation lay…

Your last paragraph is precisely what my point is. I simply don't understand why people like the indirection. Sure, it feels amazing to clap together a few classes and not have to think about naming them, until you later find that you don't know what the hell a given div is and have to spend a bunch of time parsing the one long line of Tailwind classes. If you try grouping the Tailwind classes using @apply for readab…

When I come back to a bit of code I haven't looked at for a long time, I find the class names I set on the individual elements extremely helpful, like comments that never go out of date. I can immediately orient myself and know which classes to look at (I use scoped/namespaced classes; not like BEM which is too dependent on HTML structure, just a namespace with the element class, like .Banner-icon).

I've never fully committed to TailwindCSS, but I have tried out my own utility classes on a smaller scale, and I found myself having to parse the entirety of the code to figure out what was going on.

My preference now is a mix of utility classes for super basic things that would be tedious to set a class on, and custom classes for everything else. Especially if media queries are involved, because good lord is that ever tedious to do with utility classes. If I find myself setting more than 2-3 utility classes on an element, I usually end up moving that to a CSS class for one reason or another. I don't define the utility classes until I need them, and I really don't use very many.

Re: Konsta UI – Mobile UI Components Built with TailwindCSS

#200

Earlier quoted context omitted.

Funny, to me arguing for Tailwind is like arguing for copy pasting code around instead of using functions and classes, which the Tailwind devs literally tell you to do by the way. I mean, when I saw their official recommendation for maintenance of code and reusing styles was to use multiple cursors , I had to laugh out loud. https://tailwindcss.com/docs/reusing-styles

To me, it seems more like favoring composition of small parts over inheritance of everything. That's what CSS is, a HUGE inheritance graph, just even more convoluted, because absolutely every "class" is part of the same graph.

If you're not using scoped styles, yes. However, in an apps these days most people use something like CSS modules or CSS in JS which automatically scope styles. Creating classes is to me more of a composable model that still preserves the ability to refactor easily as well as being able to be readable.
Post reply on HN