When we say "#WebComponents are just #HTML and the DOM", we don't mean that web components just render out HTML to the DOM.
That's what *every other component format does*. React, Solid, Svelte, Vue, etc. They are all JavaScript objects which sit *outside* the DOM, trying to peer into the DOM to make a change. Some do a better job of that than others.
That's not what web components do.
A custom element *is* a node within the DOM.
That gives it unique superpowers. Nothing else can top that.
You may have come across some sort of spicy take like "web components aren't 'components'".
Well here's a spicier take. 🌶️
React components aren't components.
Neither are Solid, Svelte, or Vue.
They are ephemeral constructs in memory which technically have no direct relationship to HTML at all.
As far as the browser is concerned, the *only* sort of component it can be made aware of is a web component. It knows nothing—can know nothing—of anything else.
Here's where things get _really_ interesting.
You could mount React/Vue/Svelte/Angular/etc. "components" inside of web components if you wanted to.
Write <my-happy-react-land></my-happy-react-land> and mount React right there!
Heck, I might even argue that's the only way you *should* use React. Little React "islands" everywhere. It's the only way to fly!
But, again, the browser knows nothing of that. All it knows about are elements inside of DOM trees—whether built-in or custom.
This isn't an academic subject. Whether we're talking about islands architecture, "microfrontends", framework interop, or any other of the various techniques quickly becoming default approaches to ambitious website projects, there's one common denominator.
The days of "I build my sites using [Insert Framework]" are over. The idea of a global <div id="root"></div> and mouting the whole world inside of it is past its prime.
Frameworks should learn to live *inside* of web component-scoped trees.
You can learn how to build web components from scratch which will mount small framework-specific applications. But I'd recommend getting started first with an off-the-shelf solution. Something like <is-land>.
https://github.com/11ty/is-land
I personally would *never* reach for a frontend framework without first encapsulating it within something like this.
That's why I always scratch my head when people talk about a framework comsuming a web component now and then.
I'd flip that script on its head!
@jaredwhite this is all super interesting. I’d really like to get familiar with web components, but have mostly stuck with frameworks and meta frameworks.
If you were building a statically generated blog site that had some js driven experiences (like a rich text editor), how would you approach that?
@ThePaulMcBride At the risk of sounding like a broken record…
There's a web component for that!™️ 😆
@konnorrogers is working on a really cool one called Rhino Editor. https://rhino-editor.vercel.app/tutorials/getting-started
@justinfagnani wrapped CodeMirror in an elegant way:
https://github.com/justinfagnani/codemirror-elements
Any editor I might ever use, if they don't supply me with a WC directly, I'll write one to wrap it.
@jaredwhite @ThePaulMcBride @justinfagnani I also have a codepen-like editor I plan to extract the "editor" portion out of. Its a ~20kb plain text editor with syntax highlighting compared to CodeMirror's 100kb just to get started.
https://konnorrogers.github.io/light-pen/components/light-pen/
"There's a web component for that" needs to become a thing
@jaredwhite @konnorrogers @justinfagnani very cool!
What is the backend/server side story for this like? Just pick whatever and have it render those custom elements?
That’s one of the things that keep web frameworks popular I think. There is a tightly integrated full stack flow. I’m going to have to play around with web components to really get an idea of what I do and don’t like about them!
@ThePaulMcBride @jaredwhite @justinfagnani Right now its per-component specific.
The ones you see here use Lit and can take advantage of Lit SSR.
Base web components from the "platform" dont really have a backend / server side story, so its largely up to the maintainer how they structure their component.
Declarative Shadow DOM is bridging the gap, but if your render functions require JS for things like sizing, obviously you can only get so far.
@jaredwhite re: frameworks consuming a web component
I think this is actually a positive thing, not something to criticize. Typically I have seen this approach where the app is consuming the web component as a library rather than another framework component. Call it a trojan horse if you like, but it gets folks used to consuming web components which should be the goal.
@jaredwhite manually, for example with intersectionObserver when one of the island element `isIntersecting` : app.mount(element)
```typescript
```
@heydon @jaredwhite Eleventy Island can pre-render them to a degree.
@zachleat Worked with Vue for about a year and gained experience.
Note also, that the end of sponsorship meant another focus for Eleventy (not sure whether the new employer meant another change OTOH).
@heydon I think the original idea of the island was that it could come with some static markup and then get "hydrated" independently of any other island, if I'm reading @developit's original post right.
I'm not sure what we call it if it's maybe more of a little shell that can kick off a wad of client-side rendering.
Jared White (ResistanceNet ✊)
Paul McBride
Konnor Rogers
McNeely
P4
Ryuno-Ki
Pascal
Large Heydon Collider
Jason Miller 🦊⚛️
Zach Leatherman
Chris Ferdinandi