Why?

[mattblackdev]

@treshugart Your repo popped up on StackShare.io and I am intrigued. I looked at the Shadow-Tree spec and I can't say I understood a bit of it. But I feel like from what I do understand, Web Components is en route to really disrupt things, am I right? Since you've done this work I'm curious what does this mean for React and even CSS-in-JS? Why did you build this project? Is this the future of component based web development? If you have time to answer any of this thanks so much.

[treshugart]

I looked at the Shadow-Tree spec and I can't say I understood a bit of it.

I feel for ya. It's quite obtuse if you're completely new to the idea. The way I like to look at it is that it enables a way for you to write things like a native button, for example. It has it's on template / DOM to give it a particular look and feel. It allows you to specify children and it takes that content and displays it somewhere in the button. As the consumer, though, you have zero concerns about how it does that. All you know is that you've given it some children. This idea can be applied to complex examples like page layouts.

But I feel like from what I do understand, Web Components is en route to really disrupt things, am I right?

I've been closely following the web component specs since their inception in 2011 and the core concept hasn't changed. There's been a lot of drama, coming from many different sources, that has been designed to both bolster and hinder their progress. It's, unfortunately, created a lot of misinformation. The core concept is actually broken down into separate specs:

1. ✓ Shadow DOM - encapsulation (DOM and CSS)
2. ✓ Custom Elements - element lifecycle
3. ✗ HTML Imports - declarative loading of element definitions - being re-worked
4. ✓ HTML Templates - inert DOM (finished a long time ago)

They're all designed to do something different and complement each other. The main concept is that they act as lower-level primitives for building on top of. They're not meant to disrupt anything, or have a huge, dramatic entrance into the web development scene. Fad APIs usually don't last very long. Both getAttribute and setAttribute have seen tons of frameworks come and go. While they cop a lot of crap, web components, aren't supposed to look "cool" as an API. They just need to support the things that want to look cool.

Sorry if I'm explaining something you already know.

Since you've done this work I'm curious what does this mean for React and even CSS-in-JS?

What this means is that React can now have both DOM and CSS encapsulation using the native APIs. CSS-in-JS doesn't need to worry about encapsulation and head-mounting performance anymore. All any library would need to do is output a minified string in a style tag and put it in the shadow root. You can still have the nice ergonomics of using object literals, but a lot of the internal overhead is gone.

Why did you build this project?

I originally did it to test some assumptions and to experiment with the possibilities on an unrelated issue. After doing so, it's reinforced why I think this particular declarative API for shadow roots is superior to what's being proposed (My proposal is here), because it lends itself to idiomatic usage, and bots don't need to have Shadow DOM support when rendered on the server.

Is this the future of component based web development?

I have no idea. If I use React on any personal projects, I'll be using this exclusively, though.

---

Thanks for the questions :). Hopefully I've been able to answer them. I'll close this now, but feel free to continue the conversation if it helps you.