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

TailwindCSS v2.0

blog.tailwindcss.com

Post reply on HN
Print view View original

191–200 of 474 posts

Re: TailwindCSS v2.0

#191

Post by omnimus »

adamwathan wrote: post #124
omnimus wrote: post #114

Earlier quoted context omitted.

It's so cringe i was thinking thats joke at first. I guess that happens when you invest and hire some outside help and sometimes it ends up a bit... unsophisticated? I am big Tailwind user btw.

Framework author here, yep it is a joke. We literally had the music scored for us by a friend with the goal of making it as outrageous as possible. There's a real opera singer chanting "utility first" in Latin at the end. It's a parody of itself :)

I thought its because of your love of heavy metal!

Re: TailwindCSS v2.0

#192

Post by maciekmm »

keithnz wrote: post #169
maciekmm wrote: post #159

Earlier quoted context omitted.

What I'm struggling with is consistency across pages, especially if you are not using a component framework. I'll often end up with 50 similar, but different looking buttons. On the other side when using a component framework, re-implementing all components when there are solutions already available (i.e. very similar in terms of look and feel Ant [1] or even Material-Ui [2]) sounds counter-productive. Didn't you stu…

you can make common styles for things like buttons, if you watch adams tutorials videos, they cover this reasonably early on

It works for simple single-element components.

When you have things nested it gets out of control really quickly.

Re: TailwindCSS v2.0

#193

Post by wolco2 »

_jjkk wrote: post #164
kolektiv wrote: post #137

Earlier quoted context omitted.

Ok, so I could mark everything as "brand-dark" and then change the definition of that in the CSS? Mmm. Ok. How about layout and sizing? A lot of that looks a lot more defined - I'll pick a random example from their own homepage then: "border-b border-gray-200 py-6 flex items-center justify-between mb-16 sm:mb-20 -mx-4 px-4 sm:mx-0 sm:px-0" - if I wanted to change my approach to centring, justification, and sizing, it…

Layout tends to be a property of a particular component, and semantic classes don't work well there either. In a complicated codebase with multiple devs, the number of times you could confidently make a "one-place-CSS-change" to a semantic layout class is very small. It's likely that in one place or another, some dev made an assumption about your `sub-container` class or whatever, which causes your change to break th…

Instead of repeating "d-flex justify-content-center..." everywhere is it possible to define that once and inherit those properties in Tailwind?

Re: TailwindCSS v2.0

#194

Post by singemonkey »

byte1918 wrote: post #121
seancoleman wrote: post #57

Earlier quoted context omitted.

You're likely missing 2 things: 1) you probably haven't delved into Tailwind on a non-trivial project and 2) the nuanced difference is between infinite possibilities (style attribute) vs. discrete, "hard-coded" options (Tailwind classes). Think of strings vs. enum values when describing "types" in an application.

Apologies if this seems snarky but it would be far more useful if you could explain your point rather than a generic condescending "[you] haven't delved into Tailwind on a non-trivial project".

I don't think they were being condescending – there's a lot of material out there on why Tailwind is good, it's easy to find via Google, but nothing beats trying it out.

If you don't want to do that then you could watch some of Adam Wathan's screencasts on YouTube where he uses Tailwind to recreate pages or build new ones.

https://www.youtube.com/c/AdamWathan/videos?view=0&sort=p&fl...

Re: TailwindCSS v2.0

#195

Post by onion2k »

youngtaff wrote: post #66
seancoleman wrote: post #52

"Incompatibility with IE11, so you can tell the man upstairs 'sorry boss it's out of my hands, blame Tailwind'..." I know it's said tongue-in-cheek, but popular frameworks taking this stance is valuable when convincing clients, leaders, authority, etc. to not require IE support. I've consulted on dozens of front-end projects, and showing the stance of "industry leaders" is the most convincing argument.

That's the tail wagging the dog though… I've got clients whose customers using IE11 represent 1-2% of revenue i.e. $1M+ / year

How much could they increase the revenue from the 98-99% by if they dropped IE11 and moved faster, spent less time on supporting old browsers, or embraced new features? It's possible (even likely) that simplifying the code by supporting fewer targets that need additional work would increase the overall profit.

Re: TailwindCSS v2.0

#196

Post by lemonberry »

JxLS-cpgbe0 wrote: post #115
lemonberry wrote: post #23

The things I love the most about TailwindCSS: 1. After purged the CSS file is really, really small. 2. Hopping into all of my projects and not having to remember new class names. 3. Not having to come up with new class names. 4. Not worrying about making a change in a class and having unintended consequences. 5. Not skipping back and forth between HTML or CSS files. That said, if you don't dig it, there are plenty of…

> 5. Not skipping back and forth between HTML or CSS files. What? I thought the point of this was for use with composable JS components. You're manually writing and updating attributes like this?! class="text-4xl sm:text-6xl lg:text-7xl leading-none font-extrabold tracking-tight text-gray-900 mt-10 mb-8 sm:mt-14 sm:mb-10" How could you possibly manage this without components? Ctrl-F "lg:text-7xl" and replace?

Sometimes I extract to component classes, but in Laravel or Statamc the html element and the classes have already been extracted to a component so there's only one place to make the change anyway. When doing WordPress sites I extract to component classes more often.

Re: TailwindCSS v2.0

#197

Post by fareesh »

samuelstancl wrote: post #108
timdorr wrote: post #27

For those complaining about dense HTML using Tailwind, the headline feature of 2.0 should be @apply for everything: https://tailwindcss.com/docs/functions-and-directives#apply It lets you move all of those excessive class attributes into your CSS, where it realistically belongs. And that makes your CSS look a little more like CSS. But you get guard rails on it by applying a known set of properties to each rule. It's…

> It lets you move all of those excessive class attributes into your CSS, where it realistically belongs No. Adam said multiple times that he basically added the feature to make onboarding people smoother. The right way to use Tailwind is to extract components, for example in Vue. That way you have the markup, behavior, and styling in self-contained in a single file, that can be used anywhere, without leaking any int…

Can you help me understand the architecture a bit better? I have some reservations.

If you extract components then you require JS (low lighthouse score, lots of JS processing on slow devices, likely SEO problems) or SSR to render the page and then serve it (high TTFB)

Ideally you would have some kind of build step that can pre-process all the vue components and spit out pre-rendered HTML for all pages but preserve the interactive parts of the component scripts.

Re: TailwindCSS v2.0

#198

Post by markdown »

aarondf wrote: post #72
markdown wrote: post #7

Earlier quoted context omitted.

What homepage? This website makes one of those noob mistakes that many off-domain blogs do, in that their logo doesn't link to tailwindui.com. I wonder why they used a blog off-domain in the first place. blog.foo.com is so 2005. foo.com/blog makes more sense.

Come on, surely you know I'm talking about https://tailwindcss.com .

Now that you've confirmed it, yes. They have two websites and two home pages: foo.com and blog.foo.com

Re: TailwindCSS v2.0

#199

Post by sam_goody »

1. Tailwind is awesome.

2. I hate the new website, sorry. The old one was clean, focused and clearly portrayed what TW does. The new one is IMHO big, loud, and a lot less focused.

3. I have had endless issues compiling with npm[1], and am using yarn just because of tailwind. Anyone else with this issue?

4. 30 minutes to upgrade is a lot when you manage thirty sites. Though if it is not worth it, no one is forcing me to upgrade.

5. There are some really awesome tools out there that complement tailwind, like tail-animista.vercel.app and tailwind.ink, and some collections like bestoftailwind.com.

6. tailwindui is really nice, and gives the best of both worlds compared to something like uikit.

Partly I feel that the creation of tailwindui took the wind out of the sails of sites like tailwindcomponents.com (of which there are quite a few) which is a shame, since a community can do more than even a dedicated team.

But partly I wish they would filter, organize and promote all the neat tools that there are on tailwindui.

[1]: https://github.com/tailwindlabs/tailwindcss/discussions/1891

Re: TailwindCSS v2.0

#200

Post by _jjkk »

JxLS-cpgbe0 wrote: post #189
_jjkk wrote: post #164

Earlier quoted context omitted.

Layout tends to be a property of a particular component, and semantic classes don't work well there either. In a complicated codebase with multiple devs, the number of times you could confidently make a "one-place-CSS-change" to a semantic layout class is very small. It's likely that in one place or another, some dev made an assumption about your `sub-container` class or whatever, which causes your change to break th…

but my Cards are design components, they don't have semantic classes. How is ctrl+f "border-b border-gray-200 py-6 flex items-center justify-between mb-16 sm:mb-20 -mx-4 px-4 sm:mx-0 sm:px-0" better than changing .myCard__title{} ?

I guess it depends on the project, but I can't recall one time I've had to do a CTRL F like you've mentioned.

Of course if you have a very simple page with just some cards, a couple page layouts, that is one thing. Probably can get by with just a myCard class that works everywhere on the site.

But in most projects, as the number of custom components grows, nobody wants to go back and touch (break?) old CSS, so they end up just writing a bunch of fresh stuff for this new feature and throwing it on the pile.

This problem happens often, while the refactor-in-one-place case happens very little.

Post reply on HN