Comment by TimTheTinker | Hacker News Reader

Comment by TimTheTinker | Hacker News Reader

Parent Full thread

At scale, the priority is isolation of components. This allows things to be composed, moved, etc. without affecting each other.

We accomplish this in our web app (over 500 kloc) by simply giving each component’s top-level element a unique, formulaic, memorable CSS class (which is very easy to do with SASS/SCSS). And each component gets its own CSS (or .scss) file, HTML file, JS file(s), and I18n directory. The app loads each component’s CSS when that component is loaded at run time (which could be during startup or later). I just don’t see how one could get more straightforward than this for a large app.

We do have some classes that are included in the base-level stylesheets and shared among components, but we only use those when it would result in less code than not, or when necessary for themeing.

It may take a lot of effort to build this kind of architecture, but once you’re there it’s a breeze to create, compose, and maintain UI components.

The problem with isolation of components is that then the stylesheets are no longer cascading -- each component needs to be re-designed to fit within a design framework, and there's no CSS reuse between components is entirely copy-and-paste. Good luck re-styling anything for "dark mode" without having to hand-visit each component's JavaScript and CSS.

Plus, component isolation has really slow polyfills. None of the Google stuff as of late runs on anything other than Chrome for like a year after launch because it's too slow and broken -- everything is being rewritten in Polymer, which relies on browser support for component isolation.

We're not using any Web Components APIs, thus no slow polyfills are required (see my comment for how we isolate component CSS).

As for eschewing the style cascade, yes, that is happening when we isolate each component's CSS. However, wouldn't using Web Components proper have the same problem? And yes--it would be a very large task to add a dark mode, as you say. Each component would have to be visited. However, when we drop IE11 support, CSS custom properties will make this potentially much easier.

We don't copy-and-paste CSS often (remember we're re-using components and composing them everywhere). If there's enough commonality for CSS copy/paste to be tempting, it's probably time to either revisit how components are being composed (do we need to create a new component, or maybe have these 2 similar components inherit from a base JS class?), or add those styles to a top-level stylesheet and use shared CSS classes.

Avoiding the cascade is kind of the point, although I'm sure that sounds antithetical. IMO, the cascade should be treated with an "opt-in" approach, where you have a fine degree of control over what, precisely, is cascading and why.

In general, with component CSS, you will tend to avoid the cascade, except within your component. This is actually where utility classes have some value - if they're scoped very tightly to the parent, and their effects are well-understood - then your single purpose class can add an easy way to do simple updates.

That being said, for my part, and on my own website (doggos.com) we do not use any form of utility classes whatsoever. The entire website depends upon isolation, and through this isolation, I have a degree of control that I've not found in applications that have opted for other methods.

In short, it's worked very well for us.

As for your dark mode example... you should take a look at how Apple made dark mode a reality with their new Mojave update. I think you will be surprised at the level of isolation their interface demands and, although we're no longer talking about the web here, just how easy it was for them to implement...relatively speaking.

In short, I can make a site go dark with components, no problem.

Reply on news.ycombinator.com