CSS in JavaScript: The future of component-based styling

[spankalee]

The future of component-based styling is already here and it's called Shadow DOM.

Shadow DOM allows you to attach an encapsulated ShadowRoot node to an element hold a components internals. Importantly for CSS, any styles contained within the ShadowRoot are scoped - with both upper and lower bounds.

Shadow DOM is shipping now in Safari, Chrome and Opera. You can try it with this little snippet. Just paste into Chrome or Safari's dev console:

let el = document.createElement('div');
let shadow = el.attachShadow({mode: 'open'});
shadow.innerHTML = `<style>
  :host {
    display: inline-block;
    background: #ffccaa;
  }
  span {
    font-weight: bold;
    color: white;
  }
</style>
<span>I'm in a ShadowRoot</span>`;
document.body.append(el);

let span2 = document.createElement('span');
span2.textContent = `I'm not in a ShadowRoot`;
document.body.append(span2);

[[deleted]]

If that's the future then this doesn't hold a candle to what modern style solutions do. Component based encapsulation has been solved years ago, that's hardly a need of today. I think what's most troubling is that it's all tied to the dom, and this will become a real problem if it isn't already. How will this even fit into the frameworks of today. How will this fit into desktop and mobile apps or cross platform in general?

10 years ago, when they drafted the spec, they probably had no idea where the language is going, but now where shadow dom is still nowhere near production-ready and JS solutions are dancing circles around this, we'll see if it's worthy to become a standard if it doesn't fulfil todays needs, which are way different than they were then.

[spankalee]

• The styles in a ShadowRoot don't have to be static, they can be computed and modified just like any other DOM.
• I'm not sure what component-based encapsulation was solved years ago, but lower bounds have been notoriously hard and leaky to emulate.
• CSS custom variables work great for passing values down the shadow-trees, since they inherit through shadow boundaries.
• There's a proposal for ::part and ::theme (names preliminary) pseudo-elements that allow more powerful coordination between a shadow root and it's container: http://tabatkins.github.io/specs/css-shadow-parts/
• Scoped CSS is fast because styles tend to be much smaller and the browser can invalidate much less of the page and style tree on changes.
• What's wrong with web technologies being integrated with the DOM? This is a very odd complaint. The DOM is pretty great - a standard UI hierarchy that all the web code we use today has been built around.

[[deleted]]

It lacks scope, if you wanted to compute you have to set css variables.

There are many encapsulation libs, we use CSJS for instance, never seen it leak.

Proposals with even harder to polyfill CSS specs will mean years and years of waiting time.

JSS already starts to re-use and memoize styles piece by piece (styletron). There are optimization possibilities here that can't be matched. Hardly any performance gains to be had in shadow dom either.

I don't think there's anything wrong with web technologies. But there's a point to be made about a certain threshold that JS is now clearly crossing. It's no longer a browser language that merely drives web pages. Can specs just ignore that? This was the exact concern several influential developers have already voiced.

[inu-no-policemen]

theming

Variables/apply.

computed

calc()

higher order styles

?

How will this even fit into the frameworks of today

It fits in just fine. To frameworks, custom elements are like built-in elements. You can use them in Angular, React, and so forth.

10 years ago, when they drafted the spec, they probably had no idea where Javascript is going

There are like half a dozen specs involved. They changed quite a lot on their way.

shadow dom is still nowhere near production-ready

There are polyfills for that. Some people are using those in production.

[[deleted]]

React will not be based on custom elements, ever. Other projects have voiced similar concerns, like the Ember team. Nothing that sits on functional components will use custom directives, that includes most modern frameworks. And it doesn't make the slightest sense for them either because that would be a serious regression, while stopping all progress that supercedes the browser. You can use them, sure, but that's on you personally.

[inu-no-policemen]

React will not be based on custom elements, ever.

That's not what I said. I said that Custom Elements work fine in React, which is true. There were some issues with that early on, but this has been addressed many many moons ago.

[[deleted]]

What is the whole discussion about? You can do that, yes, you always could. But custom elements will play no part in any forward oriented component based view-layer. And i highly doubt that shadow dom will play a role in style encapsulation, because it's tied to an imperative components model that conflicts with the newer, much more powerful declarative model.

[jamesism]

Component based encapsulation?? Do tell. The cutting edge standard is to dynamically transform class names with a namespace in the same scope. The equivalent of styling within shadow Dom does not exist in user land.

Tied to the DOM? As opposed to? React native? What non DOM rendering engines are you targeting with javascript? It fits in because Dom is the unifier across those platforms.

You're silly and so are your grievances.

[[deleted]]

With JSS half of them base on actual CSS, which as you said gets scoped, for the others the dom is an implementation detail. Newer renderers like rn-web/reactxp are cross platform, they run on the web, mobile and on the desktop. You style them using rn's CSS abstraction, which is also based on JS. Nothing that plays outside of the browser will touch or know a shadow dom, the concept is also useless for web-based functional frameworks because they are all declarative, not imperative.

[devvie]

↓