Hacker News Reader

Comment by manxman | Hacker News Reader

Is it just me or has the underlying purpose and value of “cascading” in CSS been lost within these abstractions.

The only real limitations with CSS imho was just lack of variable support for easily passing in variables to set color schemes and/or dimensions etc.

These seemed to be readily fixed with SCSS and the various options for embedding CSS in JS using styled components and the like.

Tailwind seems to be all about making it easy to “pixel f*k” your way to getting the design you want in one given place at the expense of having consistency and maintainability.

E.g. with a proper CSS template I can ensure all fonts and sizes and colors are consistent across an app. With Tailwind everything starts to be like the 1990s where all your design was hard coded into table and font elements mixed into your markup!

This does NOT seem like progress!

View on HN

The underlying purpose for the “cascading” was customizing the look of documents by the user. We seldom have truly static web documents any more and this use case is non-existent even for those.

In my experience cascading is simply not a great idea even in itself — you can’t reasonably share part of your design between different components, it causes way too close coupling, breaking some non-intended component on some other page. What can reasonably be shared is variables and a color palette, which you can specify at a single place with tailwind.

But my point, design seems to primarily think in components - so just create a component in your framework/webcomponent, design it locally (e.g. by tailwind) and reuse that widget where you want.

I don’t think it’s about “documents” versus “components”. It’s about consistency and maintainability.

Keep the local styling for the component local to its place in your repository - absolutely. Give it sensible defaults - for sure. But if you’re using it in something complex where the overall design may evolve it’s a maintainability nightmare to hardcode the styling at the component level and/or designing by classname.

I get why initial development is faster BUT… if you want to make a simple style change on a 100 component site - do you really want to be editing a load of components for every change down the line?

Out of curiosity, have you used Tailwind and does your criticism come from having used it and not experiencing the progress or does your criticism come from reading how it works and not "feeling" it? I don't intend to follow up with discussion that convinces/dissuades/criticizes you in any way, I just ask purely out of curiosity.

I had the chance to use Tailwind recently. I don’t think it’s disputable that in a sense it mocks the “cascading” part of CSS, though I’m not sure I’d hold that against Tailwind. It often felt as taking a shortcut to me, but it could be a worthy tradeoff and so far I have not noticed Tailwind overly complicating maintenance and development of an average project. That said, I don’t think I would choose Tailwind if I could use, e.g., web components with scoped styles or something similarly more in line with the spirit so to speak.

I'm not the one you're asking but, I messed around with it a bit and it really left a bad taste in my mouth. There is just much hype behind it though, so I bought the book to really get a feel for it. I liked the book. I used it in a project and after going back to code written by a few members of the team, it just felt like an unmaintainable mess. The common response whenever I share this sentiment is one of:

* You don't know what you're doing * You're doing it wrong * You're an idiot.

It really kinda feels like the old AngularJS 1.x days as those were the typical responses to anyone who didn't fall down and worship it as a framework masterpiece. I've decided for myself, I'll sit this one out. Judging by history, most of the things we were fanatical about at first, we tend to look at with disdain in a few short years. jQuery, AngularJS, Bootstrap, Redux... It would be foolish to think this library/framework won't go the same way.

If you use it, and it works for you and your team, that's great. I would never try to tell you NOT to. For me, I'd rather not.

Yea I’ve used and I think it’s cool for prototyping quickly but the idea of coming back and making edits to it in production code a year from now terrifies the bejeezus out of me.

If you apply it to a component that you reuse then how is it unmaintainable?

It depends on how your components get reused.

In most organizations I’ve been in components are used in applications that share a brand identity/style. Even if there are different brands consistency matters for each brand’s look/feel.

If styling is to be consistent then it’s way more maintenance to change each component to reflect branding changes than it is to have the brand/house style defined in one place and passed into the components.

E.g. decide that all the outlines around inputs, certain boxes etc. are going to be wider - that’s something you probably want to be able to change in one place not 20 or 100 down the line. Sure you “could” find and replace for some stuff but that could easily match the wrong stuff if you use tailwind on something big/complex… at least that’s my concern looking at it for stuff beyond quick prototyping.

Tailwind is much, much faster than building your own stylesheets with deeper abstractions.

In most cases, it is faster to use Tailwind than customizing an existing UI framework.

SCSS and CSS in JS are more complex solutions than Tailwind.

Maintainability is generally better with Tailwind because you don’t need to remember all of your abstractions and any hidden structures, eg this div.className always needs to be nested a certain way. Onboarding is trivial because Tailwind can be mastered in two afternoons.

Tailwind might not be for everyone, but the features it provides allow for rapid development and easy maintenance. The author has issues with Tailwind in React, but these seem mire like React complexity than Tailwind.

I’ve liked the CUBE methodology since I first saw it. It takes all the ideas of these utility classes, but combines it with a BEM-lite approach to work with the cascade, not against it.

https://cube.fyi

Yes! Use Tailwind for the "U"

Well, yeah, the entire point of Tailwind is to not use CSS like it was supposed to be used.

Some people like this better. It reminds me of people that used to adjust the format of every single text area on Word instead of using styles. And on some contexts, that's even objectively better.

But most of the time it's just a bunch of developers arguing against generalization and encapsulation. I don't understand it either.

Anyway, just to add a bit:

> The only real limitations with CSS imho was just lack of variable support for easily passing in variables to set color schemes and/or dimensions etc.

Nowadays CSS has variables support that you can use for that.

> Is it just me or has the underlying purpose and value of “cascading” in CSS been lost within these abstractions.

For app-like websites CSS cascade offers little and is often harmful as an innocent change to a top layer will unpredictably cascade down to everything below.

> at the expense of having consistency and maintainability.

Compared to what. Every single website devolves into a nightmare of incomprehensible class names, or one-off CSS-in-JS solutions everywhere.

Compared to that the actually consistent names enforced by Tailwind are both consistent and maintainable.

I find that using utilities where appropriate is a win, not everything need be extracted into a stylesheet or component.

Having a standard library of utilities makes sense because if you don't use one you end up writing the exact same thin since they are mostly one liners.

What I don't understand is why you'd want to build a design system component out of utilities much less build everything out of utilities.

Here's an example that might give an idea: https://tailwindcss.com/#component-driven

tbh, tailwind feels like the worst thing that happened to frontend dev since coffee script.

Arguably coffeescript was a big push to move JS spec forward into ES6 and beyond.

Have you seen "The modern way to write TypeScript"? https://github.com/DanielXMoore/Civet

*runs for cover*

omg. ok, adopting some F features is an interesting idea. but why are they trying to make that thing with syntax happen?

hehe, I guess they loved CoffeeScript and/or minimalism. But if I want F# features I'd rather use F# and compile to JS with Fable, or simply use ReScript which is more sound than TypeScript any way. If I should learn a new syntax, why not get a better type engine in the process?

> Is it just me or has the underlying purpose and value of “cascading” in CSS been lost within these abstractions.

I think you have a point. I think the cascading part was ignored for containment purposes during authoring, so it would scale and be predictable for larger teams. But ideally, I think we'd want to author using something like utility classes (or repeated style props?), but then compile them away to abstractions that cascade accordingly during runtime (least amount of kB sent over-the-wire as there would be as few as possible duplicated classes in the HTML, but also presuming that browsers using the cascade is more runtime performant than applying lots of atomic utility classes..?). Then we'd get abstractions without the cost of dealing with author-time abstractions (and having to name them). But then again.. there would then be a disconnect between what CSS classes you see when you author and what you see when you inspect the HTML/DOM... At least the utility classes are 1-to-1...

There's an ideal and there's reality. In reality, CSS always ended up spaghetti and horrible to maintain. Even with BEM and other proposed solutions. Human nature and all that.

I'm not advocating for vanilla CSS and I agree BEM isn't really a solution.

But CSS in JS, SCSS/SASS etc. take the things that work about CSS and add variables etc. to give you something that's useful in the modern world while also giving you a way to keep things maintainable.

I worry Tailwind is kind of like the 'fast food' for styling. Tastes good in the moment and satisfies the need for quick calories but ain't gonna be healthy in the long term especially if you do too much of it.

This is the same repeated criticism that gets repeated over and over and over again about Tailwind. It's misguided and getting a bit tiresome.

I agree it has a place for rapidly prototyping a design. But it pukes in the face of the “DRY” principle and wouldn’t keep it around in production. Use it to get the look right, take the styles and abstract to a sensible place in the design system or component hierarchy passing in the values so you can change one thing not a load.

Just following the idea that making life easier for yourself six months from now when you don’t have the current project “context” in your head is way better for lowering technical debt.

Oh and we will probably be into another fashionable styling framework by then! ;-P

It's been explained in many blog posts as well as in the Tailwind documentation itself. It's meant to be used with components (or partials). There's no copy-pasting involved and is very well-suited for production code.

And this applies to any utility-based CSS framework.

Reply on news.ycombinator.com