Hacker News Reader

Comment by DougBTX | Hacker News Reader

And then looking at it the other way, the equivalent JS is:

    backgroundColor: "blue"

which as an isolated bit of code is no more or less understandable than the CSS.

The problem I've had with CSS is answering the question, "If I change this code, what will happen?" It is so easy for the answer to be "random other things break" that keeping CSS organised is really hard. At least with CSS-in-TS a "Find all references" will tell you where the style is used.

View on HN

> If I change this code, what will happen?

This is why I love single file Vue components[1] with scoped CSS/SASS. The styling for the component in question is right there with the markup and JS, and you know it's not effecting any other HTML with it's declared classes/styling. Breeds a lot of confidence when making changes without having to follow more rigid and fragile paradigms.

Obviously you will still have global styles and themeing but figured this is at least worth a mention.

1 - https://vuejs.org/v2/guide/single-file-components.html

You can organize using a class hierarchy, which make it possible to have separate rules for .foo button and .bar button. To over-rule something you make it more specific like .foo form button, .bar form button

I think the core of the problem is that CSS is applied to the whole page, so it makes thinking about local changes hard.

CSS Modules[1] tries to help by introducing "local" CSS, then there are other approaches like BEM[2] that bake a namespace system into the class names, then there's OOCSS[3] that tries to break it down into separate .foo and .bar "objects" a bit like your example, then others going in the opposite direction like Atomic CSS[4] that try to make all the CSS rules so narrow that it is OK that they are global, then have multiple class names used on each HTML element to make the usage local.

Really, it is quite hard, lots of smart people trying to make it work.

Personally I've found the approach of CSS-in-TypeScript the easiest to work with, since I'm very familiar with TypeScript and it allow re-using the same tools to solve different problems (and my usecase wouldn't be a good fit for static HTML in the first place, so depending on JS for rendering is OK), but I can see how people not familiar with TypeScript might prefer a different approach to handling the complexity.

[1] https://medium.com/front-end-developers/css-modules-solving-... [2] http://getbem.com/introduction/ [3] https://www.keycdn.com/blog/oocss [4] https://acss.io/

Reply on news.ycombinator.com