Hacker News Reader

How do you cope with page URLs, with JavaScript classes, variables, methods, Git branches, CSS filenames, image filenames, directory structure, etc.?

I know the joke is that naming things is hard, but it really isn’t and every web developer successfully and effortlessly names things all day long without even thinking about it.

If I have a sidebar, coming up with the name “sidebar” for a CSS class is not a serious problem I need Tailwind to help me avoid. I don’t find it plausible that other people genuinely feel pain over this one particular instance of naming things without demanding solutions for all the other things they have to name. Can you point to many Tailwind advocates who complain about how difficult it is to pick filenames, or page URLs?

I think it’s really strange Tailwind advocates latch onto this one particular thing – naming things is a problem – when they seem to successfully name things all day long in every other context. It doesn’t feel like a real problem. What happens when you need to create a file? Do you get paralysed by the myriad choices of filenames available? Or do you just pick a name and move on?

Naming things involves creating an ontology that makes sense. In the context of URLs, that’s an hierarchical structure of things that’s self-describing; in the context of code, it’s a direct model of the domain logic underlying the problem, at least for the most part: There’s lots of code involving "managers" and "containers" and "controllers" and "factories". That’s where it starts to get murky. Meanwhile, CSS classes require creating an ontology of things that’s both reusable, and at the same time referring to small or partial aspects of a thing, sometimes a thing that shows up in other parts of the code, sometimes as a variation, or just a one-off occurrence. If you do it properly, that means you’ll need to find a shared vocabulary for button attachments, centered max width wrappers, field hints, list items, and so on. It’s draining, because it’s not productive. The end result is just hopefully maintainable style sheets.

It's draining because you're over-complicating things. CSS is for styling HTML. So however you structure your HTML, CSS closely follows (hierarchy of components/partials). Then you consider variants. After that, parents influencing children styles. Then on top of that, you add a reset (because small browser incompatibilities) and maybe a grid utility.

I don't do front end these days and don't really have a dog in this fight, but most code is nouns and verbs, while design choices are adjectives and adverbs. When the business decides that we need to run, not walk, you can just change the name of the function from walk to run instead while changing the code, if that seems appropriate. With CSS selectors, when the business decides we need to change the "feel" of the page from "spiky" to "gentle," you might only want to change some subset of the design that was built up around the "spiky" concept, while leaving others as they are. There is not a comprehensiveness and absoluteness to the changes, and it's a lot harder to reason about "pure functions".

Add to this that CSS is like a codebase built on try/catch and throwing errors for its primary control flow mechanism, where the only thing that tames this is the naming conventions employed, and you've got a situation where the names really matter in a way that they don't when we're doing other programming, because the names are the only connective tissue to help you reason about the "control flow" once your css starts getting complex.

Using webcomponents there is no problem with identifiers, you can repeat the same identifier as many times as you need.

I still don't understand how not naming things is a benefit over inline styles? With inline styles, instead of class="bg-blue" you'd write style="background-color:blue" and then you could remove an entire build step and an entire dependency because the browser already supports this.

You can override bg-blue with a more specific selector or a user stylesheet, which you cannot do with inline styles.

That; and also adjacent selectors, pseudo elements, media queries, variants, dark mode handling, state handling (hover, focus, etc.), and much more.

So you make the bg-blue style make things yellow?

No, but your designers have decided instead of cornflower blue, they want it to be aqua instead. Have fun searching for all variants of the color in your stylesheets—including CSS varsity, hex codes and rgba variants. In Tailwind, all you need to do is update the config file, and it'll apply to backgrounds, text, shadows, anything.

Well that's why we use CSS variables and any change would apply everywhere and also give us semantic information with naming like color-primary or color-surface.

So you write a rule to say that blue buttons are actually yellow?

Then someone sees the code for a button which is clearly marked as blue and will be surprised it's yellow.

Try to imagine that was an example. There was even another response mentioning different shades of blue. Imagine one might override it locally, just for one widget. Imagine one had a style (something other than color, even) that wasn't designed to reference a CSS variable ahead of time. Imagine there's no heaven.

Do you treat your JS and TS the same way, eschewing semantic clarity?

Why do you assume there's no semantic clarity?

Tailwind is made for the age of apps and components. The semantics are on component level.

So you can name a component, but you cannot name the styles attached to that component?

It’s naming one component, perhaps a sidebar, versus naming the fifteen children of the sidebar and their state transitions, in a way that’s consistent with the other 137 components that comprise your app.

It’s not about not being able to name all these things, it’s that it’s pointless to do so.

You don't need to name subcomponents in a way that is consistent with the rest of the app, or even at all. That's what nesting is for. You can use simple names, or anonymous tags, that don't overlap because they live in a top level component with its own class/id.

Isnt that what scoping is for? So you name you conponent and use selectors for styling sub components.

My issue with most styling is that they want to use composition when it does not make any sense. Like spliting styles and using the pieces on things that has no relation to each other. If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive.

Tailwind is an extreme case of this, and like all extreme things, it’s a path to ruin.

> If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive.

That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less.

> Tailwind [is] a path to ruin.

Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat.

For me, styling on the web is solved.

I get your point, but isn't this contingent on the colors and other properties being stable? I don't see why this can't be achieved with pure CSS instead of adding a (big) set of names as a layer of abstraction and then optionally pruning the build for performance.

Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS.

> style bundling an issue unheard of

But then you need to have a component system to have any benefit from that (if you're using the raw classes name from Tailwind). Which was easily done with just naming the component (class or ID) either automatically or not.

> Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS.

So, every class now repeats the same properties and values (because CSS has no mixins or composition), there are dozens of classes that try to replicate scoping and nesting through BEM or similar, styles are completely divorced from actual components where they are used...

This is what I highlighted in a previous comment. If you have a drop shadow or some padding on a component, that does not mean another component which have the same values automatically have a relation between them. So it’s mostly a syntactic shortcut at this point. And the end result has no semantics.

I've not used Tailwind yet, so please forgive me for not knowing how you achieve these things with it.

As I understand it, you add a drop-shadow to an element by writing a bunch of classnames that hook into Tailwind and apply the styles. If you want several components to use the same drop shadow, how do you _not_ repeat all those classes on all those components? If you are repeating the classnames, you're just pushing the "problem" of repeating your style rules out to the components. I'm sure there's a Tailwind way to solve this, but I don't know what it is yet.

My experience with several UI libraries and general react usage suggests you might make a new component (`<CompanyApprovedShadow/>) that applies the drop-shadow, and then each component which wants the shadow would use `<CompanyApprovedShadow/>`. But what if one's an `article`, another a `button` etc? What if one's blue and another's red? This gets complicated real fast and/or you end up with so may properties on your style components for customisation that you've lost the benefit you originally sought.

The point of repeating style directives under different classnames, in raw CSS, is that you often want to customise things. The shared values should be provided by the cascade, or variables/--custom-properties.

``` .company-button, article, .card { box-shadow: whatever; } ``` Is pretty reasonable CSS, imo. I confess I've not used this in a large project, but _every time_ I use something like styled-components, and most UI toolkits, as soon as I have to customise something I wonder why I've agreed to the abstraction.

> Isnt that what scoping is for?

The one that hasn't been available in CSS until 2023?

> So you name you conponent and use selectors for styling sub components.

So how can you do that with CSS?

> So how can you do that with CSS?

The old:

  .card > .card-header

> The one that hasn't been available in CSS until 2023?

That was nesting, IIRC. Sugar syntax, so you don’t have to fully specified the whole selector.

> .card > .card-header

And we know that it never worked well. That's why BEM and many other naming strategies exist: to try and replicate scoping purely through naming discipline.

> That was nesting, IIRC. Sugar syntax, so you don’t have to fully specified the whole selector.

Nesting partly solves the naming and the "keep all of a component's style close together".

The other partial solution is CSS Scoping: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope

And this still doesn't solve the issue of repetition where every component has to spell out the margins, the paddings, the borders, the...

Because you honestly don't need to, and shouldn't need to.

CSS missed out on scoping, nesting, and composition even though most of these things have been available elsewhere (notably, SASS) for 20 or more years.

What you really want is to have a component and all styles scoped to it. In the absence of that you want as few names replicating scoping, nesting, and composition, as possible. And you want to compose repeatable patterns across all of your components (something that is possible with mixins, and is impossible with vanilla CSS). So you cut down on repetition across class names until you're left with utility classes and a separation of concerns that cuts a different way: https://x.com/simonswiss/status/1664736786671869952

Note: no one is stopping you from having your own arbitrary classes when you need to. See e.g. Cube CSS approach https://piccalil.li/blog/cube-css/

What I’m arguing about is that composition isn’t necessary in most cases. Because all components evolve independently. Also nesting is syntactic sugar, nice, but orthogonal to these discussions. And scoping is done with selectors.

CSS isn’t an imperative language. It’s a declarative one. And what’s most important is understanding what it is trying to solve (mostly not styling elements with tag’s style). Which is what Tailwind is replicating.

Tailwind may help you in some cases, but not because of a defect in CSS. It’s like using an ORM, then past a certain treshold, you find yourself doing (badly) SQL but in $language.

> Also nesting is syntactic sugar, nice, but orthogonal to these discussions.

What is it with you and nesting? We were talking about scoping styles to a component.

> CSS isn’t an imperative language. It’s a declarative one.

So what? Doesn't mean you can't provide nice declarative ways of doing things. Like SASS has provided for 20+ years.

> Which is what Tailwind is replicating.

I fail to see the logic or, indeed, the meaning of your assertion.

> What is it with you and nesting? We were talking about scoping styles to a component.

I get where you coming for. But the issue that the scoping[0] you're referring to on your other comment is something I've never encountered or heard someone complain about.

In my mental model, an element owns it subtree in terms of styling. Meaning that, if I a component can be placed either statically or dynamically, then it belongs to all the elements that may be its parent. And if it want independent styles, then I reset it at the root of the component. So I assumes, any style property that is not set at the root of any element is inherited from the parent.

No need for elaborate syntax and mechanisms that just drive up the complexity of the code.

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scoping

> But the issue that the scoping[0] you're referring to on your other comment is something I've never encountered or heard someone complain about.

Why do you think BEM exists? Or CSS-inJS? Why do you think web components exist?

All these are attempts to actually do what you claim css is already doing: to make sure that the element owns its subtree in terms of styling.

CSS is global.

> So I assumes, any style property that is not set at the root of any element is inherited from the parent.

Of course not. The hint is in the name: Cascading stylesheets. Your "owned" subtree is owned by every single element above up to and including document root.

> No need for elaborate syntax and mechanisms that just drive up the complexity of the code.

There's nothing complex about Tailwind. It actually reduces all the complexity to a set of small primitives. And since it's still CSS, you can write your own CSS as you wish.

Here's a good overview of how and why you would use it: https://piccalil.li/blog/cube-css/

> It’s a truly elegant solution for authoring web pages.

It's an ugly hack that undoes a lot of the benefits of CSS.