How do we employ progressive enhancement using custom elements? Given their reliance on JavaScript, as an old-school front-end developer, this feels like an unfortunate oversight.
The idea is much the same as server-rendering anything else: you give the components a first run to generate HTML server-side, send that first, and then let JS progressively enhance interactivity on top in the client if it can, or just stick with the initially rendered version if it can't.
(Server components is currently still on the V0 version of the spec, and this article is talking about V1, but they're very similar and we're migrating at the moment).
I don't see how this could possibly work even a little bit without Javascript. What would you fall back to? A static hunk of HTML? That could only work in the very specific case of a custom control that happens to have exactly the same utility on the page as an existing HTML element. And even then, you'd need to add a templating language, so you could express how to render that HTML chunk with a certain value or text. This templating language would not be Javascript, since you're trying to avoid that. So we add a new templating language to HTML for the benefit of rendering content for people who turn off Javascript?
I completely agree, but the question remains what experience do we provide when JavaScript is not available? (Progressive enhancement isn't just for "people who turn off JavaScript", it's an defensive approach to providing inclusive, universal solutions on the web. Something I feel is lacking in the modern, front-end developer's worldview.)
You're back to the case of having one static page and then having your javascript enhance things as you go. You'll be stuck replacing elements with your JS. I still think it's a great way to think about how we render on things like mobile. Ever get those slow-loading pages where the elements jump all over the place? Or half-way through reading an article the pop-up add finally renders? We need to build those into the baseline.
Fortunately, we can reliably depend on javascript now. What we cannot rely on is internet/processing speed.
I've always found progressive enhancement to work best as an additive process. You want to define the functionality of your page and then add enhancements and verify that the base functionality still holds. If you start from the most complex behavior it is a lot harder to reason about how removing functionality might hurt the page.
How would you do a progress bar without JavaScript? Well, you wouldn't. So custom elements don't affect progressive enhancement as far as I can see. They enhance the DOM when JavaScript is available and when its not they are essential a div.
The idea is much the same as server-rendering anything else: you give the components a first run to generate HTML server-side, send that first, and then let JS progressively enhance interactivity on top in the client if it can, or just stick with the initially rendered version if it can't.
(Server components is currently still on the V0 version of the spec, and this article is talking about V1, but they're very similar and we're migrating at the moment).