Hacker News Reader

Comment by crad | Hacker News Reader

I recently brought this up with my team. As an "old-school" web developer, I buy in to the whole CSS as design thing, while the front-end engineers @ work switched to using styled react components. As we look to make substantive design changes, now we have multiple places to make the CSS changes, only now it's the SASS project and all of the React components / projects. I must be missing something about how hip and cool styled components are, but they'll never be as cool as the CSS Zen Garden :)

View on HN

I think different parts of the page need to be treated differently.

In a typical webpage, you'll have lots of "chrome" (menubars, sidebars, footers, logos, etc.) and "content well" of some sort. For the content well, the content is probably going to come in through some sort of CMS with Rich Text Editor that can handle bold, italics, links, headers, blockquotes, etc. by outputting plain HTML.

The content well should be designed to work without classes on the items. It should be able to take the <a href> and <em> tags and make it look correct. The tags themselves have a semantic meaning, and you can imagine this same content surviving through multiple redesigns of the site.

But for the chrome HTML, the tags are only there as part of the current design. When you redesign the site, there's no reason to expect the same tags to be used. It may or may not be possible depending on the goals of the redesign, but either way, it's not a goal, the way that reusing the content well HTML is.

I think this is what leads to the disconnect. If you're new school web dev making CSS-in-JS components or whatever, you're expecting your components to be thrown out when a new design comes along in five years. If you're designing the content well, you expect the HTML to live essentially forever or at least as long as the business.

Well said

I also started coding when CSS Zen Garden was the best thing ever but sorry, CSS in JS is better.

With classes and a separate stylesheets, there are no statically analyzable connections between them. You typo a class name? Too bad. You're no longer using that class anywhere? No compiler will tell you it's dead code. You want to increase the padding in this one place? There's no way to be confident what else it will affect.

And all the "benefits" that stylesheets tout are also offered by components. No one is adding <font> tags on all on all of their headings. With components, you just set the font once on the heading component.

Same, started doing frontend back in the CSS Zen Garden days, and CSS-in-JS has been a godsend. Having the tooling do static analysis on your components and their corresponding styles has made life so much easier. Reference a color that doesn't exist? Error. Reference a component that doesn't exist? Error. etc...

Also, in response to GP: CSS-in-JS does not take away the ability to roll out global CSS changes without updating individual components. It actually gives you more tools to easily share styling across components.

> No one is adding <font> tags on all on all of their headings.

Ok? I'm not sure the official documentation is encouraging factoring out things like font styles to a central place, so you for example easily change the look from serif to sans, or adopt a signature font?

Am I missing something?

https://reactnative.dev/docs/text

The original argument for CSS from 20 years ago was:

Instead of saying: `<font size="20"><b>Some heading</b></font>` 100 times, CSS proponents would tell you to just write `<h2>Some heading</h2>` 100 times with styles defined separately as `h2 { font-size: 20pt; font-weight: bold; }` so if you need to change it to 22pt, you can make one change instead of 100.

Components give the same benefit. Just write `<Heading>Some Heading</Heading>` 100 times with the definition `function Heading(props) { return <h2 style={{fontSize: 20pt; fontWeight: bold}}>{props.children}</h2>; }`. If you need to update it to 22pt, it's still just one change; not 100.

* replace `style=` syntax with your CSS-in-JS framework of choice for better performance.

Right, but in the example linked from the official docs, the css/style is in the component. So you need to change all your comp, rather than the body font style?

(obviously you can mix and match, it just seems that the official documentation/sentiment is towards self contained components that don't support page/application level theming/styling)

You're subscribing to the notion that it's good to put all your styles for all components in one file. Since the invention of variables, that is wrong.

Theming is no longer a valid argument for centralized style sheets. If you declare one central set of variables for, eg., colours or fonts, then you can still do "application level theming" (changing those colours/fonts in one place), without having to mash all the styles for every element in the entire app together in one file.

The advantage of using JS variables to represent this is you can easily ask your IDE to "find all references" to that variable. It's much easier for humans than reasoning about CSS inheritance and the cascade.

Reply on news.ycombinator.com