Hacker News new | past | comments | ask | show | jobs | submit login

TL;DR: People love to hate CSS, but it's the reality. People have various solutions to deal with the major problems with CSS (i.e. cascading global styles mean impact of any is unpredictable) but recently people have begun tying the CSS to the particular HTML collection it applies to, and the author likes that and points out some particular implementations he likes (I'm assuming "Rich" is/identifies as male).



Scoped CSS really is the most forward-thinking CSS IMHO. It's 'plain' enough to be adopted into most workflows and it doesn't really stray very far from the original CSS language.


Scoping CSS is great, you can do static analysis, idiot-proof just-in-time stylesheet loading, and when done correctly it eliminates a lot of specificity issues. It doesn't scale well though. Eventually you develop http-call bloat, and unless your CSS is written by a single and very devoted person, consistency becomes nearly impossible to maintain.

Visual consistency begs for DRY CSS, and DRY CSS tends to bend back towards single global stylesheets.


The http call bloat is a by-product of how your build process works though — if your CSS lives in your components then you can easily bundle it just like you bundle your JavaScript. The ability to lazy-load individual components and their styles if you wish is a feature, not a bug.

It's fine to still have a (preferably fairly small!) global stylesheet that covers fonts, colours and so on. The key is to avoid your components potentially clobbering each other, which is what SFCs accomplish.


I don't think so. In fact, 'scale' is specifically when scoped CSS is its strongest. It allows you break things out and move quicker and develop easier to maintain styles.

1) http-call bloat is mitigated by a built process (which you would probably already have to use if you're using a Scoped CSS method like CSS Modules.

2) Visual consistency and DRY aren't affected. Think about it like regular code - when we want to repeat a unit of code we break it out into a seperate compassable function. We can do the same thing in CSS Modules with composes. You could also (carefully) introduce a preprocessor like LESS/SASS/Stylus/etc for variables and mixins and what not.


Totally agree with you. The style of a site or app is global after all. Consistency is key.


correct — he/his/him. Yes, exactly, the key here is that CSS is meaningless except in the context of markup: if you can statically analyze the two things together, good things happen.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: