Comment by JimDabell | Hacker News Reader

Comment by JimDabell | Hacker News Reader

Parent Full thread

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?

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.

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.

Reply on news.ycombinator.com