Hacker News Reader

Comment by Flenser | Hacker News Reader

What about theming/branding so that you can make your enterprise web-app fit in with each of your clients other web-apps?

If your class names are semantic like profile-card it's easy to have a branding css file for each client.

If your class names are functional like m-5 p-5 text-gray-light bg-gray-darker border border-gray-light you're going to... what? make code changes for each client?

Obviously if the website is only going to have one branding, this isn't an issue, but advice like "use semantic css" or "use functional css" needs to be put in context. What you do in an agency context for content sites would be different from an in-house web-app context, or a web-app for SAAS context.

View on HN

Even if you only have one client - do you really want to manually hunt down all profile-card instances and update the styling anytime you need to change the styling?

And if you had a bug related to profile-card styling, are you going to find all cards to update the styling? Are you sure you didn't forget some?

This approach seems to be based on the idea that design is completely immutable after the initial conception. This is... not how design usually works :)

It's unclear to me the problem you are addressing. Searching for places to make amendments is an important consideration when naming something. I would have thought that class names like "profile-card" would be easier to search for than "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light". Especially if you have some page elements which may look the same now but are functionally different and could look different in the future. How would you find one and not the other?

Is that the problem you were addressing or did you have something different in mind?

I was commenting on the original proposal, even in the single-client context. So, we're talking about the same problem - I just obviously wasn't very clear about it :)

So, yes, semantic names matter, and functional names are a bad idea in the long run, because they shatter maintainability.

It's all about tradeoffs, there are no silver bullets. If your class name is like profile-card then it could be simpler... until it's not. Because it turns out that one of your client profile-card needs to behave slightly differently on hover or whatever. In theory, profile-card is a great idea, in practice it can be a headache

What I'm saying is you have files client-alice.css and client-bob.css, and you define different profile-card:hover rules in each. But with functional css you have nothing to hang your rules on.

It's never not simpler.

You can use `text-primary` or `text-secondary`. Sure it's less obvious looking at the markup what something looks like but it allows for theming.

Reply on news.ycombinator.com