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

271–280 of 391 posts

Re: Tailwind is a leaky abstraction

#271

Post by iamben »

azangru wrote: post #237
iamben wrote: post #227

Earlier quoted context omitted.

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 regr…

Reading your Tailwind example, I must confess that I have no idea what "p-4" or "pb-1" are; or what the border-radius will be for the "rounded" class, or what color the "white" will be in bg-white. > I've certainly worked on enough projects (and, mercy!) had to pick up enough projects where the 'vanilla' CSS was absolute spaghetti! And I am very guilty of having written such spaghetti in my first big project :-) But…

> I must confess that I have no idea what "p-4" or "pb-1" are ...

Of course! That's the Tailwind add-on, right? I guess the key being you can move between projects that use Tailwind and know it's a rem unit of padding all round and .25rem padding at the bottom. And when you come back to it 3 months later, you still know.

> And I am very guilty of having written such spaghetti in my first big project :-)

Oh, me too and not just the first! It's amazing how quickly things can turn to pasta when you're rushing to hit deadlines! :-/ But I think you're right, with good practice everything gets a bit more maintainable. Let's hope we get there eventually!

Re: Tailwind is a leaky abstraction

#272

Post by luxcem »

diob wrote: post #266
yellow_lead wrote: post #208

Earlier quoted context omitted.

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

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

Re: Tailwind is a leaky abstraction

#273

Post by luxcem »

theturtletalks wrote: post #188
hardwaregeek wrote: post #171

Earlier quoted context omitted.

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

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.

Re: Tailwind is a leaky abstraction

#274

Post by azangru »

verisimilidude wrote: post #258
azangru wrote: post #222

Earlier quoted context omitted.

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

That doesn't make any sense. Your classes in your project are not part of the CSS standard either, by your definition. Tailwind gives you CSS classes that you can use. Yes, you do need to learn them. But that doesn't mean it isn't CSS.

> Your classes in your project are not part of the CSS standard either, by your definition

Yes, but my classes, by definition, are defined by me. The behavior of classes of a css framework is defined by someone else, who exposes an api for you to interact with these definitions. An api that you need to learn, in addition to just CSS.

It is no different from React, Lodash, Rxjs, etc. being "just javascript". They provide an additional DSL on top of the language itself.

Re: Tailwind is a leaky abstraction

#275

Post by luxcem »

cormacrelf wrote: post #206
hbn wrote: post #198

Earlier quoted context omitted.

I've never understood the point of separating markup from the design. I've seen CSS Zen Garden and... neat? But I don't get the point in real-world use. I've never had to redesign a UI in a way where I'd only change CSS and not also be moving around markup in the process. And once you're changing both of those things, there's the overhead of cross-referencing and keeping names and hierarchy in sync. At that point I d…

The question of where to put the styles boils down to "do your content and style people work in completely separate teams?" For a newspaper, this is true. For someone who got their mate to set up their blog, this is true. Early days web was mostly like that. Not any more. If it's the same person doing it, put it in the same place. Separation will just be a hindrance.

It still is mostly like that, the content is not the html, the html is the presentation layer, as much as the css.

The content will be inserted from an API or with a templating system.

Re: Tailwind is a leaky abstraction

#276

Post by luxcem »

chrischen wrote: post #137
viddi wrote: post #119

Earlier quoted context omitted.

Maybe I'm going out of a limb here, but wasn't the whole point of CSS to not have to touch the markup when changing the styling? Not trying to talk Tailwind down, I have just missed a lot of the evolution of web design in the past 15 or so years.

Yes but the way we do HTML has also changed–for example by using JSX and reusable components. The issue of having to change markup in a lot of places to change styling doesn't exist anymore if you abstract that away in reusable components.

And using tailwind without a reusable components system is cumbersome to say the least. What is suggested in the documentation is to use editor features (multi-cursor, research and replace, ...) https://tailwindcss.com/docs/reusing-styles#using-editor-and...

Re: Tailwind is a leaky abstraction

#277

Post by jspash »

pcthrowaway wrote: post #102
anaganisk wrote: post #62

Earlier quoted context omitted.

I don't think that's true, just by importing the tailwind u add more bytes than plain css which you will end up writing.

Pretty sure tailwind has had the option to have the minimal CSS generated on-demand from the set of classes you actually use, for a year or so. I haven't actually tried using this feature yet though (haven't had time to upgrade tailwind in the project where I've been using it). I suspect writing your CSS by hand could still be more efficient in per-byte output, but not enough to justify the productivity loss from not…

Yes it does. You tell the compiler where your html lives and it keeps only the classes that you've actually used. This can be enhanced with a safelist of classes that might be generated by code. So you give it a regex to keep, for instance "all grid classes".

In development I like to generate ALL classes that are possibly available because it allows me to play around in the inspector and everything is available. But tailwind has that workflow in mind too with with Just-In-Time compilation. (I still prefer my way)

Anyhow, on a production site that I work on the final file size is 316KB (35kb gzipped). With a bit of tweaking the config I could get that down to around 250kb.

Re: Tailwind is a leaky abstraction

#278

Post by luxcem »

yurishimo wrote: post #114
jrochkind1 wrote: post #59

I haven't actually used tailwind yet. But writing CSS -- usually with SCSS, sometimes bootstrap, sometimes just totally DIY -- I have _never_ managed to keep my CSS well organized. It always eventually becomes an unholy spaghetti mess, including overrides of overrides. So my interest in tailwind or "utility" approach generally (I have started using bootstrap utility classes more), is not to avoid having to know CSS,…

I think Adam Wathan's (the creator of TW) article [0] sums up the issues you are likely having. Modern CSS has an inherent dependency on the structure of your markup. This is a newer byproduct of modern design. Back in the day, you'd add something like `a { color: orange; }` for your entire site and be done with it. As sites got more complicated and design became a feature rather than an afterthought for websites, ou…

It reminds me a lot of rationale behind htmx (https://htmx.org/essays/locality-of-behaviour/)

Re: Tailwind is a leaky abstraction

#279

Post by imbnwa »

HelloNurse wrote: post #191
yurishimo wrote: post #114

Earlier quoted context omitted.

I think Adam Wathan's (the creator of TW) article [0] sums up the issues you are likely having. Modern CSS has an inherent dependency on the structure of your markup. This is a newer byproduct of modern design. Back in the day, you'd add something like `a { color: orange; }` for your entire site and be done with it. As sites got more complicated and design became a feature rather than an afterthought for websites, ou…

This kind of "colocation" doesn't scale too well: a family of as little as two pages should share a stylesheet for their common classes, ids and common structures, not consistently repeat identical CSS in multiple files. The common technique of defining components encapsulating related markup and CSS makes repetitions in the output pages harmless because they are write-only, but it only moves the problem one abstract…

Isn't it still nonetheless better to arrive at that category of common classes as an outcome of 'component-first' co-location? These two needs don't seem mutually exclusive.

Re: Tailwind is a leaky abstraction

#280

Post by steve_adams_86 »

I don't mean this as a slight towards the author, but I don't see how this takes away from what Tailwind is good at. I never imagined it would be a one-size-fits-all utopian solution to CSS (an already great tool, in my opinion), but it is great at a set of things it sets out to be great at, which sometimes aligns well with my needs.

I don't think tailwind should be used everywhere. Sort of like a CRUD framework, it could really get in the way of doing bespoke or atypical things the underlying language can do but the framework or library explicitly wasn't intended for. Breaking convention can become a hurdle.

The reality is that the vast majority of API work (for example) does benefit from a CRUD framework of some sort, be it lightweight or otherwise. CSS is great, but do we need its full potential at every corner of the UI? Probably not. What we need, usually, is a consistent set of conventions we can shovel out an get good, repeatable, familiar results which benefit both devs and users in the long term.

Tailwind supports custom classes for exactly this reason. You need an escape hatch because it isn't the holy grail of all CSS projects. It's a helpful tool with well-known limitations.

If I need to batch out projects in my shop, I will build jigs and find the right blades and cutters for my machines. Then I'll rip through the various settings to get the pieces I need very quickly. This is like Tailwind in the workshop. If I need absolute control, I need various hand tools and a lot more time. Can I create something awesome? Absolutely. Is it inherently better? Not really. It depends entirely on what is needed in the end. Generally speaking, most of us just want a dumb box to put some stuff in. Tailwind will do that expertly, just as my table saw and router with jigs will.

Asking your tools to do something they weren't intended to do will cause headaches, yes, but it becomes more an issue of user error than tooling problems at that point.

Post reply on HN