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

331–340 of 367 posts

Re: Tailwind UI

#331

Post by inopinatus »

tomc1985 wrote: post #246
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…

How is that any different from setting CSS in the style attribute of your tag? What happens when you need to update all the "text-sm text-gray-700" to something else? Seems like a step backwards at worst and identical to Bootstrap/Foundation at best. Everyone provides class primitives like that What you're describing offends separation-of-concerns

> What happens when you need to update all the "text-sm text-gray-700" to something else

You update it in the one place (template/render function/component/helper/view/partial) that you wrote it.

> What you're describing offends separation-of-concerns

The entire HTML/HTTP/CSS/Javascript web schmozzle offends separation of concerns and is shot through with layering violations and dependence on the specific rather than on abstractions.

Tailwind responds to that particular shitshow by refactoring style at the point of HTML generation, which (particularly in a template-driven world) makes a crapload more sense than trying to build higher-order style abstractions in a language that was explicitly intended to not be Turing complete.

If the HTML ERB had chosen DSSSL instead of CSS, we wouldn't need this.

When it comes to developer productivity and happiness, composition beats inheritance, even in declarative paradigms.

Re: Tailwind UI

#332

Post by uk_programmer »

cageface wrote: post #282
phponpcp wrote: post #100

Earlier quoted context omitted.

This is so much easier to parse too. If you need more rigidity, add BEM on top then you're good to go.

It's easier to parse but what does "hero" actually do? You need to go digging around in all your stylesheets to figure it out and in most cases actually load up the page and inspect it. That overhead is gone in a functional approach.

If you build things as components as you are supposed to (every backend and frontend framework has been geared around since the late 90s) Your CSS styling should correspond directly to your components (whether they are JS or a MVC partial view). So it should be obvious.

> You need to go digging around in all your stylesheets to figure it out and in most cases actually load up the page and inspect it.

When are you changing CSS and not inspecting the page at the same time? You are going to have to check your work. This doesn't happen if you keep things tidy as you go along. Working in a large team and/or scrum is no excuse for checking-in poor code.

Re: Tailwind UI

#333

Post by have_faith »

CGamesPlay wrote: post #311
luketheobscure wrote: post #295

Tailwind is fantastic. Everyone goes through the initial shock of complaining about the "ugly markup", the violation of separation of concerns, etc. But I've worked in enough large codebases to tell you that the ones that use Tailwind have a more consistent UI, with much less handwritten CSS. Bootstrap sites inevitably devolve into a soup of custom CSS and Bootstrap framework. You end up with lots of verbose class de…

I agree with you about Tailwind, but had to call you out on this: > BEM seems to be the worst of both worlds, both abandoning the "cascading" part of "Cascading Style Sheets" and still requiring verbose class names! BEM doesn't abandon the cascade (or really care about it). What BEM is actually pushing back on is rule specificity. For example: #navbar a { color: blue } /* Can't do this, it doesn't change my navbar-su…

I think BEM is often misunderstood, it's not immediately obvious to beginners why it's helpful. Specificity is one problem it helps solve as you mentioned but the biggest thing for me is it forces you to think about what an element is and who it belongs to.

If someone writes '.nav a' they're saying "select all links inside of nav", but what they really wanted to say was "select all nav menu links, and nothing else", a class like '.nav__link' will never select other links that happen to be in the nav (CTA buttons, logo links, etc) and will survive markup restructuring, something like ".nav > ul > li > a' will not survive minor markup changes as it doesn't express what someone wanted to select in the first place. I think this way of thinking brings a lot of benefits that most CSS frameworks don't give.

Re: Tailwind UI

#334

Post by tjholowaychuk »

luketheobscure wrote: post #295

Tailwind is fantastic. Everyone goes through the initial shock of complaining about the "ugly markup", the violation of separation of concerns, etc. But I've worked in enough large codebases to tell you that the ones that use Tailwind have a more consistent UI, with much less handwritten CSS. Bootstrap sites inevitably devolve into a soup of custom CSS and Bootstrap framework. You end up with lots of verbose class de…

Personally I think css utils are better suited for layout related stuff, acting more like layout primitives (hbox, vbox) etc since those tend to be pretty ad-hoc.

As far as concrete UI components go, I'm not sure this technique is any better, especially since you often need pretty ad-hoc styling with pseudos etc.

I think if CSS had built-in mixin support you could have the best of both worlds pretty easily, still crossing my fingers we get that some day, would be nice to drop all these build systems.

Re: Tailwind UI

#335

Post by saagarjha »

mike1o1 wrote: post #173
squeaky-clean wrote: post #169

Earlier quoted context omitted.

(Also not a Tailwind user) I guess the common response to this is that well chosen semantic names usually help later down the line after these kinds of changes happen, especially with devs coming in and out. I've actually come across C code that had "#define ONE_THOUSAND_TWENTY_FOUR 4096" because that was the audio buffer size and later had to be increased to 4096 but the macro name was never changed. AUDIO_BUFFER_SI…

If I wanted to change all links from gray to blue/underlined, the best practice there would probably be to use a different utility class (text-blue-500 and underline) and update my templates/partials/whatever. I think for your specific example, I would use the `@apply` directive to apply certain utilities to all links. I've used Tailwind on large, complex apps with around 50 screens (so far), and using extracted comp…

What if I had two types of links, both of which were currently "text-blue-500 and underline" but I wanted to make one italics at some time in the future?

Re: Tailwind UI

#336

Post by saagarjha »

koboll wrote: post #135
joaodlf wrote: post #12

When I first learned about Tailwind I though "wow this is amazing!", but it quickly became obvious I was more or less learning another "language", which I really didn't need when re-entering the crazy world of frontend. I might reconsider it again once I am more comfortable with what frontend has become, but that is still quite a bit away.

Tailwind's draw seems to be in its name -- it helps you work faster. So for people whose bottleneck is writing lots and lots of HTML/CSS, it's probably great. I'm guessing most of the naysayers here work in the web applications world with component-based architectures, where the HTML/CSS is a small portion of the total time they spend coding, so they can't understand why someone would sacrifice readability, maintaina…

> Tailwind's draw seems to be in its name -- it helps you work faster.

And the argument is that this comes at the expense of maintainability.

Re: Tailwind UI

#337

Post by adamleo »

luketheobscure wrote: post #295

Tailwind is fantastic. Everyone goes through the initial shock of complaining about the "ugly markup", the violation of separation of concerns, etc. But I've worked in enough large codebases to tell you that the ones that use Tailwind have a more consistent UI, with much less handwritten CSS. Bootstrap sites inevitably devolve into a soup of custom CSS and Bootstrap framework. You end up with lots of verbose class de…

Agreed, after switching to tailwind, writing CSS became very rare for me.

Re: Tailwind UI

#338

Post by arcosdev »

I don't see the point of Tailwind. Why not just write inline styles and get straight to making an manageable mess right from the start? No need for a framework to help you with that. Most developers will abuse Tailwind and created nonsensical class names like `font-size-20px` or `margin-left-15px` instead of kicking the naming can down the road (as others have pointed out).

Re: Tailwind UI

#339

Post by aniforprez »

ronyfadel wrote: post #179

Stealing these components would be a very shitty thing to do, but I'm wondering as to how the authors can protect their CSS library from piracy? (esp. considering the 249$ asking price). Legal action? I'm considering open sourcing a software product I'm working on, but it could mean that I'll be bending over backwards to monetize it, as people can just run straight from source.

In this case they're not even trying to stop piracy cause as with their book "Refactoring UI" none of this stuff is locked behind DRM. You can possibly copy all the HTML and spread it around if you have access but that would be scummy and it's great that the devs here trust the users to not help such an effort and have not added intrusive methods to protect this. The license is also very permissive. For what we potentially get as this is closer to full release, it's well worth the cost

Re: Tailwind UI

#340

Post by thrownaway954 »

deltron3030 wrote: post #219
thrownaway954 wrote: post #139

in my opinion tailwind really only works when used with a component based framework like Vue, React or ActionView::Component. the issue to me is that you have to add sooooooooo many classes to make a button look good that you get fatigued very quickly. when using a component based, you can build a button component and just reuse that. this isn't an issue with something like bootstrap where a single class makes a butt…

You can extract components: https://tailwindcss.com/docs/extracting-components/ And you can store and access components as code snippets within your code editor (e.g. VSCode), that's how I'd store the bigger Tailwind UI components. When I need a component then I just use a shortcut and pick from a component menu.

i think you're missing the point.

extracting "component" as code snippets does nothing if one day your boss tells you to change all the size and colors of all the buttons. you still have to go through your entire site and make the changes manually at every instance... or have the foresight to have a class on every button that you can reference through pure css to make the change without breaking tailwind... but at that point, why would have use tailwind to begin with.

Post reply on HN