Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Evolution of Scalable CSS

frontendmastery.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: The Evolution of Scalable CSS

#11

Post by MrJohz »

matsemann wrote: post #9
jamescostian wrote: post #7

Earlier quoted context omitted.

For anyone else trying to understand how this fits in, it's either the "Inline Styles" section or the "CSS in JS" section, as long as you use typescript and follow the same rules mentioned here

If I were to explain it in terms of react, it would be to use everywhere. Except that you also can define nested stuff, media queries, hover/active states, pseudo-elements etc. So yeah, syntactically a bit more like CSS in JS / JSS, but much more ergonomic, and much more easily composable.

Fwiw, most CSS-in-JS libraries don't use `style` directly, and so also allow the same features. One thing I've seen often is to use a `css` pseudo-prop so that it looks a bit like using `style` (but you've still got access to the full force of normal CSS rules).

My favourite variation of this so far has been typestyle, which I believe works along essentially the same principles as in Elm.

Re: The Evolution of Scalable CSS

#12

Post by jamescostian »

matsemann wrote: post #9
jamescostian wrote: post #7

Earlier quoted context omitted.

For anyone else trying to understand how this fits in, it's either the "Inline Styles" section or the "CSS in JS" section, as long as you use typescript and follow the same rules mentioned here

If I were to explain it in terms of react, it would be to use everywhere. Except that you also can define nested stuff, media queries, hover/active states, pseudo-elements etc. So yeah, syntactically a bit more like CSS in JS / JSS, but much more ergonomic, and much more easily composable.

It sounds like you have experience with the string-heavy CSS in JS. Here's some examples showing how this can be achieved using `csstype.Properties` objects: https://emotion.sh/docs/typescript

I'm sure you can imagine how easy it is to compose functions that accept and return `csstype.Properties` objects, and then at the end, you call `styled` with it to make a styled component. You can even pass styled a function, which takes in runtime-adjustable props, and of course, that function can itself use other functions, passing around those same or some derived runtime-adjustable props.

That said, I have no idea what you mean when you talk about ergonomics being better, can you elaborate? I re-read your initial comment but there wasn't anything in it not achievable in TS using the kinds of things mentioned in the "CSS in JS" section, perhaps there's something else I'm just not aware of? I do not know elm, let alone have experience writing it in non-trivial production codebases, so a concrete example would be great

Re: The Evolution of Scalable CSS

#15

Post by matsemann »

jamescostian wrote: post #12
matsemann wrote: post #9

Earlier quoted context omitted.

If I were to explain it in terms of react, it would be to use everywhere. Except that you also can define nested stuff, media queries, hover/active states, pseudo-elements etc. So yeah, syntactically a bit more like CSS in JS / JSS, but much more ergonomic, and much more easily composable.

It sounds like you have experience with the string-heavy CSS in JS. Here's some examples showing how this can be achieved using `csstype.Properties` objects: https://emotion.sh/docs/typescript I'm sure you can imagine how easy it is to compose functions that accept and return `csstype.Properties` objects, and then at the end, you call `styled` with it to make a styled component. You can even pass styled a function, w…

Thanks for some explanation. And yeah, I'm probably not up to date on CSS-in-JS, just remember it being really clunky to use before I ended up in an elm-shop a few years back. I'd say that emotion does look similar to what I've described, and nearly there. And I don't think there is anything doable in elm that's not doable in TS/React (it's rather the opposite, elm is the restricted one, mainly on purpose). My point about ergonomics was mostly that it's just elm all the way. No strings or objects or new concepts. The CSS you write in elm is mostly indistinguishable from the other elm view code (html etc) you write, it's all the same syntax etc. While for emotion and others, there is a clear divide in what's React and what's styling, and difference in how you do stuff.

Re: The Evolution of Scalable CSS

#17

Post by abathur »

> Let’s take a break from all these principles and architectures, and remember that CSS is ultimately about implementing visual designs.

I enjoyed the overview (though the web component/shadow Dom bits others noted here would have been nice) but I feel like there's a missing realization lurking at the center of this history: the separation of concerns in the web stack was designed for documents, not layouts or visual designs.

Much of the struggling we've seen over the decades is because the separations aren't aligned with how we're using them. It makes sense for documents to have separate stylesheets. It doesn't make sense to fragment the implementation of a layout across several files and complexly-interacting languages.

This isn't really a fault of the article. I only just realized this in the past year myself and I've been writing html since the all caps era. I took a first swing at writing about this recently in: https://t-ravis.com/post/doc/what_color_is_your_markup/

Re: The Evolution of Scalable CSS

#18

Post by stevebmark »

Good article. I would have liked to see the article sternly advise against all CSS naming schemes like OOCSS. All CSS classes go into the global namespace, the solution is obviously not hand written naming conventions, it’s getting rid of the global namespace itself. OOCSS is like saying “we have to put our entire program in index.js at the top level, how do we name things to avoid conflicts?”

CSS is a fully solved problem: CSS modules combined with global utility classes. You probably want sass too, but the important thing is you’re writing CSS, and font have to figure out the DSL, translation, and plugins needed to use CSS features.

Re: The Evolution of Scalable CSS

#19

Post by spankalee »

stevebmark wrote: post #18

Good article. I would have liked to see the article sternly advise against all CSS naming schemes like OOCSS. All CSS classes go into the global namespace, the solution is obviously not hand written naming conventions, it’s getting rid of the global namespace itself. OOCSS is like saying “we have to put our entire program in index.js at the top level, how do we name things to avoid conflicts?” CSS is a fully solved p…

It's solved natively without build tools too: native CSS module scripts for importing and shadow DOM for applying the styles with scoping.

Re: The Evolution of Scalable CSS

#20

Post by dxchester »

azangru wrote: post #2

> The Evolution of Scalable CSS The evolution of practices described in this article is followed up to about ten yeas ago... and then stops, followed by Tailwind. Where is consideration of web components with shadow DOM, which solve the CSS encapsulation problem, the naming problem, and the dead code problem? Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? T…

We wrote about our journey[0] to sanity after Tailwind:

The answer is to do it all in strategic moderation: Use a subset of tailwind just for spacing and layout and revel in simple things being simple. Use modular CSS for UI patterns and revel in the readability of your HTML and visual consistency of your UI. And then use custom scoped CSS where required, and revel in interesting things being only as hard as need be, without ruining everything else along the way.

[0]: https://frameable.com/company/tech/how-we-found-sanity-in-a-...

Post reply on HN