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

Tailwind is a leaky abstraction

jakelazaroff.com

Post reply on HN
Print view View original

221–230 of 391 posts

Re: Tailwind is a leaky abstraction

#221

Post by antihero »

theturtletalks wrote: post #128
hbn wrote: post #47

These are fairly complex use-cases that aren't needed for 99.9% of CSS people write. In most cases I'm throwing together a handful of components in a flex container or right-aligning some buttons or something. And for that typical CSS usecase, I find Tailwind way better both for quickly iterating and for hopping into code someone else wrote. I love not having to bounce between and cross-reference 2 (or more!) files (…

Tailwind is honestly great for beginners since it "simplifies" CSS into short-hand classes. The people that know CSS don't want to learn new classnames when they can use CSS and that is a standard. I'm personally scared of forgetting CSS if I use Tailwind extensively. I also don't like the aesthetic of all the classnames being bunched together, but Tailwind does have value.

I’m not sure why it’s limited to beginners. I’ve been writing CSS for 20+ years and found it tedious, error prone, difficult to manage, and irritating. Tailwind honestly made me enjoy doing web again.

Re: Tailwind is a leaky abstraction

#222

Post by azangru »

lcrz wrote: post #5

> You still need to know CSS. Yes. Tailwind CSS is just CSS: > A utility-first CSS framework It is not a leaky abstraction, because it isn't an abstraction. It's a only a special syntax for applying predefined blocks of CSS to HTML elements.

> Tailwind CSS is just CSS

This is simply not the case. In order to use Tailwind, you need to know names of Tailwind classes, which are not part of the CSS standard. To say that Tailwind is just CSS is like saying that Ramda is just javascript.

Re: Tailwind is a leaky abstraction

#223

Post by tevon »

Tailwind isn't intended to be a CSS replacement (like you stated in the article).

It serves well, even in large code-bases, when you aren't doing bespoke transforms and object selection.

I've built large UIs using it and its magic. For the most part what you want is consistent spacing and reasonable defaults; Tailwind nails this.

Re: Tailwind is a leaky abstraction

#224

Post by neovive »

hbn wrote: post #47

These are fairly complex use-cases that aren't needed for 99.9% of CSS people write. In most cases I'm throwing together a handful of components in a flex container or right-aligning some buttons or something. And for that typical CSS usecase, I find Tailwind way better both for quickly iterating and for hopping into code someone else wrote. I love not having to bounce between and cross-reference 2 (or more!) files (…

I agree that the use cases shown are not representative of the vast majority of projects. After using Tailwind for almost two years, I find the biggest strengths are: a common set of naming conventions (don't underestimate how hard it is to name classes well and consistently across projects); bundling of commonly used features (autoprefixing, purging unused classes); and how well it works with component libraries. Beyond that, Tailwind is just CSS — unlike pre-compilers like SaaS and LESS that actually extend CSS.

Re: Tailwind is a leaky abstraction

#225

Post by tevon »

theturtletalks wrote: post #204
dmitriid wrote: post #202

Earlier quoted context omitted.

> The people that know CSS don't want to learn new classnames when they can use CSS and that is a standard. And then they end up with dozens (and in big project hundreds) of bespoke CSS class names that no one can remember or keep track of, and just add new ones to the ever expanding file ;)

This is not the way either. I use CSS-in-JS which has its own flaws, but CSS stays with the component.

I'm curious, if you're using CSS-in-JS already why not jump to tailwind? Its slightly more restrictive, but I've found the more opinionated style incredibly helpful.

What are the benefits you're getting from CSS-in-JS?

Re: Tailwind is a leaky abstraction

#226

Post by lewisflude »

nsonha wrote: post #92

let's not forget the HN mob is mostly back-end devs who will cheer for anything that gives them a quick and dirty way to style websites. These people have never needed to maintain a front-end codebase nor think about design systemically.

Senior front-end engineer here! I hated, HATED Tailwind for ages. It made me super angry that it was glossing over everything that makes CSS great. The ability to write great, maintainable styles seemed lost.

But after a couple of projects using Tailwind, I actually think it's a really solid way to implement styling that scales well as a project/team grows. It's maintainable because it's tightly coupled to markup (like styled APIs), has great first class support for design tokens and once you learn the syntax it can let you express specific css rules in a way that's more clear and concise.

I don't know if it'll have much staying power as the front end community continues to explore how we want to define styles. But what is clear from Tailwind's success is people want high levels of performance, styles tightly coupled to markup, a first-class way to utilise theme tokens etc.

For now if I was to start a new project, I'd likely pick Tailwind unless there was a good reason not to.

Re: Tailwind is a leaky abstraction

#227

Post by iamben »

azangru wrote: post #220
iamben wrote: post #218

I love CSS, I'm relatively good at it. Didn't enjoy Tailwind until I really did. Working on a frontend project with other people Tailwind is fantastic. Everyone can see and understand what I've done and there's no trying to understand other people's style sheets, or see what they've done or anything else (especially with the VSCode plugin that orders the Tailwind classes properly). Sure, pure CSS does some bits bette…

> But it's great knowing that the next dev we hire can pick it up and go from day one. Presumably the next dev you will hire will be a frontend engineer? CSS is a core competency for a frontend engineer, whereas Tailwind is an add-on. If I were choosing a frontend engineer for my team, I would make sure there core competencies are up to snuff.

Presumably, yes. And assuming they have Tailwind skills as a 'add-on' I'd argue it's easier for them to understand and get going straight away with:

  class="rounded shadow p-4 pb-1 bg-white"
than:

  class="blog__rounded-box blog__rounded-box--padding-fix"
But I get your point. It's the same as the article, right? You still need to understand CSS to use Tailwind, so why bother? I guess each to their own. Maybe we'll regret this in a few years, but it works very well and feels much more maintainable for us now. I've certainly worked on enough projects (and, mercy!) had to pick up enough projects where the 'vanilla' CSS was absolute spaghetti!

Re: Tailwind is a leaky abstraction

#228

Post by jasonduba »

cloverich wrote: post #217
graydsl wrote: post #193

Earlier quoted context omitted.

By that definition it would be hard to justify anything besides HTML, JS and CSS. That would also exclude TypeScript and every JS Framework there is on earth. That's hard to justify from every angle (development and business wise) imho.

That's not quite the definition they are positing. Many of the classes in Tailwind have near or actual 1:1 mappings to CSS, but with slightly different names or semantics. A better JS analogy might be something like Coffeescript; I remember avoiding it because it felt a bit superfluous and hence not worth the tax (of adding a tool). With Tailwind, whatever the actual merits, the biggest points of traction (IMHO) are…

I use Tailwind for a SaaS app because of TailwindUI and I'm pretty happy with it. I also used the Marketing page examples to put together a website[1] pretty quickly. When the app UI gets more complicated the need for design skills definitely creeps in. But, taking a step back, using a wireframing tool like Balsamiq, and having another look through the component catalog has gotten me pretty far. I'm happy with our ability to ship quickly.

[1]: https://truerev.com

Re: Tailwind is a leaky abstraction

#229

Post by nsenifty »

gemstones wrote: post #160
nailer wrote: post #116

Earlier quoted context omitted.

You could just use that subset of CSS though. If fact it’s a genuinely good idea to do so. Grid first, using paddings and gaps can do almost everything you can draw 1:1 without hacks. No margins, no clear fixes, no floats needed.

There's a meaningful difference to my workflow of doing versus doing .mycomponent__wrapper { padding: 0 1rem; // Don't forget the time to look up whether it's vertical | horizontal or horizontal | vertical because I forget all the time } then and toggling between files, and making sure the team knows my preferred CSS layout structure in the general case. Plus, the solution for more complicated CSS is to just write it…

> Don't forget the time to look up whether it's vertical | horizontal or horizontal | vertical because I forget all the time

padding and margin go `top right bottom left` just like in a clock. So it always start at top and go clockwise. The two argument shortcut is just `top right` with bottom=top and left=right.

Re: Tailwind is a leaky abstraction

#230

Post by onion2k »

yellow_lead wrote: post #208
hbn wrote: post #47

These are fairly complex use-cases that aren't needed for 99.9% of CSS people write. In most cases I'm throwing together a handful of components in a flex container or right-aligning some buttons or something. And for that typical CSS usecase, I find Tailwind way better both for quickly iterating and for hopping into code someone else wrote. I love not having to bounce between and cross-reference 2 (or more!) files (…

> I really feel like people start with their conclusion that they don't like it because it's weird and foreign and then look for excuses to justify why they think it's bad. At least from this article, I get the impression the author used tailwind for a bit and kept running into these issues where he had to go in and fix it manually in CSS. After enough of these, you get annoyed.

After enough of these, you get annoyed.

If they're typical things that you'd expect a library to solve, sure. If they're "I want my element to rotate in 3D" then most developers would think they're just working outside of the scope of the library.

Post reply on HN