Hacker News Reader

Comment by hbn | Hacker News Reader

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 (HTML + CSS) for a description of a single layout.

I started using Tailwind at my job I started 2.5 years ago and after the learning curve of memorizing the commonly used class names I have yet to run into a situation where I wished we weren't using it. I also started adopting it in all my personal projects because it makes me so much faster at getting work done and the code is easier to maintain.

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.

View on HN

> 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.

Libraries that have a scope defined implicitly by what accidentally works or doesn’t work can still be very annoying.

_this_

It's not like the `style` object is far away. Nothing about Tailwind prohibits you from using normal classes.

Yes tailwind let's you reach through and apply some CSS directly. Almost like its an abstraction that exposes, or leaks, that which it attemps to abstract. A "leaky abstraction" if you will.

Honestly - I find this opinion misguided. It's like saying a for loop is a leaky abstraction over a while loop.

Which... is asinine. One is simply a redacted and simplified expression of the most common implementation of the other case.

Tailwind falls into the same bucket - in my opinion. Like most frameworks, it's not there to handle your niche and complex use-cases. It's there to provide bumpers that push you into a pit of success for common use cases.

When you need to do something that's not common - use the escape hatches that are built in. That's not leaking - that's giving you the flexibility to fall back to a custom implementation.

The goal just isn't "abstraction" from css. It's common-sense, local, and consistent styling for common cases. I can build most lego sets from single square blocks - but it's nice to have a bigger selection available. Does that mean I need to understand those bigger pieces to make sure they fit, don't have weird gaps, and line up? Absolutely. Does that mean I shouldn't use them? No, probably not. But it does mean that sometimes I still need single square blocks.

I think the opinion here comes from other compile-to-x languages.

Let’s look at typescript, or sass. There is (afaik) no construct in the underlying js or css that cannot be represented using them.

You could conceivably never learn javascript, learn typescript and basically be fine.

So when people say “leaky abstraction” they seem to be assuming that tailwind, which is a framework will allow you to represent every possible css output.

…which it can’t do, obviously, and was never intended to do.

All I’m pointing out is that the expectation that it could might not be quite so daft when viewed from the lens of “I expected tailwind to be a framework in the same way sass is” or perhaps “the same way this framework that compiles using sass is”.

It’s like if I was using vue, and found that the template language can’t express complex logic without writing js (h() expressions) and not using the template language at all.

It’s wrong to say it’s a leaky abstraction; but it’s maybe not completely asinine to say, it a bit rubbish that you have to do that as soon as you hit any non trivial use case…

> Like most frameworks, it's not there to handle your niche and complex use-cases. It's there to provide bumpers that push you into a pit of success for common use cases.

…but as you say. Quite so. Im just saying I can see the frustration people encounter when they have the naive expectation that those edge cases are rare enough they’ll never hit them, and then immediately run into them.

I guess I see it as the opinion of someone who hasn't used it, or doesn't really understand the value.

I don't love Tailwind, but I can understand the spot it's trying to fit in, and I value the things it's trying to offer (locality, consistency, sane guidelines).

I think the sweet spot for that value proposition is projects where the designs don't need to be pixel perfect or extra fancy - they just need to work, quickly. I've used it successfully several times in those cases. Not to mention personal projects where just having a decent template made that I can tweak is great.

I would probably not use it anywhere you have real UI constraints or concerns, and you care a lot about specific animations or exact pixel placement. I tend to reach for styled-components in those spots these days. Since it gives me a fair share of the same value proposition (locality, consistency) but removes the guidelines/bumpers.

They play pretty nicely together (with some constraints), though - again, use the different lego blocks where they make sense. Stop trying to treat everything like a tailwind shaped nail you have to beat in with just that hammer.

Tailwind is just css classes. It was never meant to abstract anything.

poor take - tailwind is not trying to abstract CSS away from you. Abstracting away CSS would be painful and pointless - theres no way a higher-level language could emerge that would give the user the same feature parity.

You can play this "leaky abstraction" game with almost any concept, without the ability to reach down an abstraction level you lose flexibility. Its not a smell to be slightly leaky.

Based on this reasoning, C is a leaky abstraction because you can inline asm into a C program.

That's true. To borrow from another famous quote:

All abstractions are leaky; some are useful

Wise words.

Yeah I agree and someone could probably write a whole article about making expectations from users on your libraries.

They allow plugins to add features. I'm sure if enough use the plugin, it would get added to the core.

Which is exactly what is explained in the article : "with the official recommendation being to just write a custom JavaScript plugin to implement it."

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 think its possible to forget some of the exact names, but most of the Tailwind classes are just shorthands for the CSS styles. Furthermore, even if you develop in Tailwind, you still see the normal CSS style names when using browser tools.

If you decided to do a project in vanilla CSS, I'm sure the style names would come back very quickly.

I should clarify, I wasn't a beginner when I started using Tailwind. I already had frontend experience, it's just my current job already had started using Tailwind in all their webapps before I started.

I don't think Tailwind is the place to start learning CSS. Tailwind is just a more efficient way to write CSS, and you should be aware of what's going on under the hood. It doesn't mean if you're writing your CSS in Tailwind you're never gonna look at normal CSS. There's plenty of times when I'm iterating on a design and I'll hop into the "Styles" section of my console and directly edit the element.style{} section, writing normal CSS to mock something out before translating it back into Tailwind in my editor.

So I certainly haven't forgotten normal CSS names. Not to mention the Tailwind names generally match up pretty closely with the underlying CSS names. It's only minor translations to go between the two, and maybe a special case here or there. The documentation[1] is very good with a quick search can type CSS or Tailwind names into to find what you want, and it'll show both the Tailwind name and the CSS attributes/values it outputs so I tend to keep that open in a tab while I work.

[1] https://tailwindcss.com/docs/

For me Tailwind is sort of a shortcut to learning best practices. If I had to research and figure out best practices on my own it would take ages. Instead I can just see what Tailwind does. E.g. when to use em vs px. That kind of stuff.

Honestly I just don't see how it's possible to 'forget CSS' with Tailwind. I mean, the classes mostly map 1:1 to CSS properties.

As someone who has been writing CSS for approximately a billion years (actual number more like 13 years) I'm a fan of Tailwind and don't see how it's a 'beginner' thing at all. It solves real-world problems building web applications, and actually many of those problems only come up when you're building large, long-lived applications with many contributing developers which is precisely the kind of thing beginners aren't in charge of.

Tbh a lot of times when people say beginner they really mean “this is way easier than the way I’m used to, and that freaks me out because it means the old way is redundant, so I’ll claim this is for beginners”

By beginners, I meant people who know HTML and some CSS, but not enough to design a great UI. Tailwind allows them to add a few classnames and the page looks great. On the flip side, you have a developer who can design using CSS. Tailwind comes along and, although it’s great, you’re learning new classnames and now you’re no longer using web standard properties (CSS).

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.

Justifying using Tailwind, Typescript, JS Framework, etc. comes down to how much value they provide to each user and how much time they save.

For example, building your own type system or JS framework would require a lot more code and man-hours than using margin: 4px vs m-2.

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 the frankly excellent example sites[1]. You can click through numerous examples, all load quickly and without ads, that give you numerous variations of components, layouts, and even full pages. You can spin up a vanilla HTML or React app and ship good looking pages very quickly, esp. if you are bad at design.

[1]: https://tailwindui.com

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

Just an FYI, the logo on the site you posted gets deformed on mobile when there’s not enough space for it and the buttons on the right to live all on the same line.

This makes no sense. Tailwind is just another way of writing CSS, it's not premade styles.

> Tailwind allows them to add a few classnames and the page looks great

How is this the case any more than "raw CSS allows them to add a few styles and the page looks great"? You can't just haphazardly throw styles onto the page and it'll magically look good cause it was made in Tailwind. You design the exact same way you would if you were writing raw CSS, it's just you're putting the styles in the HTML class tags instead of modifying the CSS directly.

A person who's bad at CSS is not gonna be any better with Tailwind.

I wonder if the parent is mixing tailwind-ui and tailwind itself.

I don't see how tailwind makes it easy to design beautiful pages, not in an easier way than CSS.

What it does is ensuring Locality of Behaviour, and css properties not leaking in other component of a web application.

It's essentially the same as css scoped to a single component.

> I don't see how tailwind makes it easy to design beautiful pages, not in an easier way than CSS.

If you copy the examples in the Tailwind docs it looks like your ripped off Stripe. If you copy the examples in the MDN css docs it looks like you ripped off a decade old govt site.

Making your own class names arent a standard either. I dont see why you would reinvent and abstract things over and over again in every project?

> 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.

That's why the wink ;)

I used to sort of like CSS-in-JS, but on larger projects it also quickly devolves into "I know we have a design system, no idea what we have there, here are one-off CSS styles for this particular component"

Everything is with its trade-offs alas sigh

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?

I use Mantine[0] which uses Emotion[1] for styling. I like keeping the CSS properties in a neat JSON object instead of a long string like Tailwind does. With the object approach, conditional styling is easier too. With Tailwind, you have to use cx or another package to do this and it makes the code a little hard to read.

Emotion isn't without it's flaws though. The company that created Emotion doesn't use it anymore because of runtime overhead[2] so Tailwind may be the future after all.

[0] https://mantine.dev

[1] https://emotion.sh/docs/introduction

[2] https://www.infoq.com/news/2022/10/prefer-build-time-css-js/...

Vanilla-Extract is CSS-in-TS that compiles to raw CSS.

https://vanilla-extract.style

Use CSS modules then. The largest CSS file in the largest application I'm working on is around 200 lines (I prefer splitting everything into small components — easier to test, easier to reuse).

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.

It’s definitely not limited to beginners. Huge companies are using Tailwind in production. I prefer CSS-in-JS and haven’t faced enough issues to switch.

Have you ever had the 'pleasure' of maintaining someone else's non-trivial, non-framework CSS? I have, and it was no fun at all. For all the crap they get, frameworks allow for knowledge transfer across projects/teams/employers.

I've had the pleasure of trying to maintain a tailwind codebase written by 2 junior devs over a year and let me tell you, that wasn't easy either

I know CSS and have been using it for over two decades. I found that using Tailwind was like having a mental burden taken from me. I don't care about exact pixel values, most of the time, I just want a consistent UI with "some level of spacing". I don't want to do strange niche stuff 99% of the time. Tailwind's strength is the constraints and defaults it provides you.

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.

Exactly. No matter what, this person decided before they even used tailwinds that it was going to be bad. They used their time with the tool to point out obscure cases so they could say "see, I was right, it leaks". They then try to tie together at the end with a "I'm not saying it was bad".

This type of drama or negative style of writing needs to stop. Be objective, there is good and bad everywhere.

> I love not having to bounce between and cross-reference 2 (or more!) files (HTML + CSS) for a description of a single layout.

Oh wow. Literally this is the exact argument I use for not using tailwind - not having my styling logic split between classes in my HTML and tailwind’s own files implementing the styles (which appears in DevTools and most other places).

Not saying either of us is right or wrong it’s just odd how different people perceive things.

Does your framework do CSS in it’s component files? If not, maybe that’s the problem?

So just to be clear: your argument is that you like to cross reference multiple files before you know what is applied, when?

And for the record, tailwind was never meant to be used exclusively. Most arguments against it are centered around edge cases which are tiresome with tailwind... But they're usually pretty silly as you were never meant to abstain from using css if it makes sense.

And yes, that means you'll still have to check multiple files if something behaves differently then you'd expect, it's just less frequent then without a utility css framework

How does Tailwind require bouncing between multiple files? Everything is in the HTML in the form of class names.

Yes, you will have to know what the classes do, but where that isn't already intuitive it's just a one-off lookup, and then you know.

HTML + CSS can simply not be parsed without hoping between multiple files. Unless you inline all of your CSS, of course.

I think the point in the comment you are replying to is that they _prefer_ having markup and styles in separate files.

You can still do that though. I swear half the Tailwind haters haven't used it for more than 30 minutes, or at all.

Then what's the advantage of Tailwind?

Standardised and clean CSS syntax. The benefits in that context are debatable, a component based frontend architecture is where it absolutely shines. If you end up using it in that context you won't need to ask this question, it quickly becomes clear that it's the optimal path.

What can't pure CSS do here and that Tailwind does ? The CSS syntax is already clean and standardized if you use it properly and don't name every little piece of interface. It is a genuine question, by the way...

CSS is standardized…

No, I have HTML and CSS in the same component file. I prefer having styling in one place (the CSS inside the component file) rather than two (the HTML of the component and tailwinds’s own postcss files that implement the styles).

Fwiw styled and emotion both offer ways to have css in the same file as html/js

Yep Svelte and Vue do too. It seems like not having CSS in their components is the actual problem many people are trying to make better.

> How does Tailwind require bouncing between multiple files?

You have styling split between the classes and the actual CSS tailwind implements, which every team I know that has used tailwind absolutely does have to look at.

It's a vocabulary you quickly get used to, and when paired with editor plugins, it's a non-issue in my experience.

Yeah, and it's much better than trying to figure out what random class names some dev made up are doing.

I agree that ‘div soup’ is a problem - I’ve seen a lot of react code by new developers that resembles GWT generated DOMs. But ‘div soup’ has other problems too - way over complicated doms are hard to edit and debug - and the problem is better solved by learning CSS basics to avoid all the wrapper divs you see in React apps made by junior front end developers.

Most of the time I know the CSS already I have to convert it to tailwind - and devtools uses the same syntax so (as the article mentions) the abstraction leaks.

The other cool thing is that you can code up your design system in the tailwind config and never have to worry about devs not using the correct sizes/colours/etc.

I recall there being Stylelint rules for linting against hardcoded values. I can't seem to find the link rn though.

You can do exactly the same with pure CSS. This is not a Tailwind advantage.

How much effort does it take to set up, though? I thought the CSS variable system was pretty rudimentary.

> How much effort does it take to set up, though?

Practically none. And any designer is prone to reuse the same spacings from project to project. So you bring the language file with you. Something like this :

:root { --spacing-sm: 1rem; --spacing-md: 2rem; --size-tall: 32px; ... }

And you can do some pretty nice things with these pure CSS tokens. Without any hassle or dependency.

This seems more annoying than using tailwind.

One thing that has been an absolute deal breaker for me is adding variants for components.

Say I have a button component with different variants, these variants change styles across multiple elements in the component.

Using scss and BEM this is incredibly simple, add a parent class and I can modify nested elements easily. But using tailwind I have to make an mess of things to get this working or recreate the component.

I’d love to hear how anyone solves this issue.

Disagree, an example with margins (the second example in the article) is not complicated or rare.

Tailwind acknowledges the limitation [1] and also provides gap utilities [2]:

  <div class="flex gap-x-2">

which translates to

  display: flex;
  column-gap: 0.5rem;

[1]: https://tailwindcss.com/docs/space#limitations

[2]: https://tailwindcss.com/docs/gap

Edit: formatting

I've looked at tailwind as an individual, but their pay-for-documentation model is absolutely bullshit. And it doesn't seem to be doing anything different from Bootstrap or 99% of the other CSS frameworks out there.

Also, it makes me sad to see people so eager to throw away separation of concerns :( Yes everything describing it is on one screen but now your HTML is filled up with hundreds of words of awful classnames and markup that should have been put elsewhere!

> Also, it makes me sad to see people so eager to throw away separation of concerns

I don’t think it has ever lived up to expectations, HTML+CSS in that way is simply broken. You can’t really write CSS without hard-coding the HTML structure, so you might as well do it in one file.

No, I think people just suck now. While you can't eliminate all structural concerns in CSS (think nesting selectors), sensible class naming and adhering to the structure of the medium (instead of fighting it by trying to directly translate a photoshop mockup or w/e), this is entirely possible.

But now you just have a single-use html+stylesheet, as I wrote. No separation of concern anywhere, and both html and css can only be written by knowing the other part.

Why is the stylesheet single use? The classes can be used anywhere, as they should be. Make components in the CSS and call them by their classname in HTML. You are building generic components here.

I don't see the issue with 'separate files', do people not use split view mode in their IDE?

edit- this comment in another thread: https://news.ycombinator.com/item?id=33789859

> Why is the stylesheet single use? The classes can be used anywhere, as they should be. Make components in the CSS and call them by their classname in HTML. You are building generic components here.

The problem with reusing CSS comes, when the style you’ve previously created, is almost, but not exactly perfect for the current component. Changing it to better fit you current need risks breaking existing layouts, and so you are left with overriding it. But when you do that, you eventually end up with a lot of override classes just to change one or two things. So, what do you name these classes? If you name them for what they are intended for (ie. “semantically”), you are bound to end up with a lot of differently named classes, that all do the same or nearly the same thing, because it turns out that we commonly want to override the default styling in very similar ways. You end up with dozens of one-rule classes that all just set float to right or display to none. Alternatively, you name these overrides for what they do. This way, whenever you need to float something right, you just add the `float-right` class to the element. You can now eliminate all those redundant semantically names override classes. But if you go back to the classes you started with, it also turns out that those would have been a lot more reusable if they’d contained fewer rules to begin with. This makes sense, because more rules = more specific, and fewer rules means more general. At this point, I’m sure I don’t have to point out to you, that you’re well on your way to reinventing Tailwind.

But you aren't building a generic product. You are building something specific.

I'm my experience the _vast_ majority of CSS never gets reused. Sure if all you are building is marketing websites or landing pages then I suppose some generic "cards" or whatever will get you pretty far, but for anything even moderately more complex... no chance

I fought against this for a long time, but I have to agree. CSS right next to your HTML/Components makes it a lot easier to keep track of.

Maybe it would've been possible to build tooling around using CSS files that created the same benefits, but now we just don't have to any more.

Honestly a style tag always seemed like a pretty good idea for local styling, despite pretty universally being condemned as "the wrong way".

> their pay-for-documentation model

Yikers this comment sets the stage for a real bad game of phone tag! I think you're mistaking TailwindUI[0], the set of proprietary UI component cheat codes based on top of TailwindCSS, with TailwindCSS[1], the actual CSS library being discussed here.

[0] https://tailwindui.com/

[1] https://tailwindcss.com/

Fair enough, odd that a link to the other isn't somewhere visible on the front page.

I'd give the makers of Tailwind the benefit of the doubt here. TailwindUI was very much launched well after Tailwind CSS was popular, and they probably assumed you'd only find it after you'd kicked the Tailwind CSS tires a bit.

Separation of concerns went out of the window a long time ago when frameworks (i.e. React) showed that it's better to combine business logic + markup into a neat encapsulated package.

Having a neatly encapsulated component that does everything is fine in most setups. Your main challenge will be not growing these components too big.

(( I really dislike Tailwind btw, mostly because I am just translating CSS into something else all the time which feels like a waste of mental effort; and the long lines of cryptic classnames is just bizarre to gain such a big popularity. I loathe it, it's a maintenance hell. I imagine all frontend devs liking this grew up using Bootstrap or something and mostly do small projects ))

that's the power of functional cohesion

Reply on news.ycombinator.com