The Good, The Bad, and The Web Components - Zach Leatherman | JSHeroes 2023

There has been no shortage of both fair and unfair criticism toward Web Components from a wide range of folks that build for the web, including but not limited to JavaScript Framework authors in supposed competition with the platform. In this talk I’ll show you how to navigate and simplify the multifaceted landscape of web components, satisfying common criticisms and showing how you can Use the Platform most effectively today.

[@antonio_carvalho]

Great talk, a pleasure to watch, thank you!

[@CodecrafterArtemis]

I'm a bit miffed that, when they talk about "server-side" they specifically talk about NodeJS-exclusive solutions and static site generators instead of things that can integrate with backend frameworks (Rails, Flask, Django, etc).

[@patricknelson]

With you on this. I run mostly PHP on the server side, but implement web components + Svelte on the client side. What’s more is that there are other JS runtimes and environment types (e.g. Cloudflare workers or WinterJS/WinterCG). Interestingly, runtimes _like_ those which are WinterCG compatible offer opportunities for SSR of JS-bound things (like web components) without necessarily having to have JS as your “back-end”. In this case, there are 3 total layers now (a traditional back-end, traditional front-end and a middleware layer of some sort to perform component SSR). It’s something I’m working on myself in my free time (sorta rare, but still an ongoing thing). 😅

[@andypsolomon]

this guy is hilarious, so much that i didn't learn anything i was just laughing the whole time. gonna have to watch again.

[@sambines3463]

I am moving away from a lot of these frameworks to web components. I got sick of the constant bullshit with vue/angular/react specific crap.

[@patricknelson]

Web components, while not quite as elegant in some ways as modern frameworks, they have one *huge* thing going for them: They’re a standard. That means that they’re here to stay. They work great to sorta bridge the gap as well, in many different ways, including between heterogeneous back-ends (like Ruby, PHP, Python, etc) and even between JS frameworks which support rendering custom elements.

[@heybran_]

:host-context() selector is depreciated I believe, there is a github issue for that.

[@ZachLeatherman]

Do you have a link?

[@nathanmiddleton1478]

I'm no expert, just a foggy from the 90s. How is it "server rendered"? The server doesn't layout the page, the server doesn't calculate the DOM. All the server is doing is caching and pushing data. Rendering of everything else is on the client, yes?

[@benighted2]

The term/phrase has come to mean declaring/generating markup dynamically on the web server vs the client.

[@hellerbarde]

You can think of it like "rendering" a template. You're right that none of the layouting-related decisions are done on the server's side.

[@patricknelson]

To add to that: With the “server rendered” declarative shadow DOM, the component will take on the appearance defined in that HTML/CSS even if JavaScript isn’t even enabled. This is in contrast with the traditionally “client rendered” version where JS would still be required to execute and set the contents of the shadow DOM.

[@antonio_carvalho]

It's rendering the *html code* in the server, instead of using javascript locally. It's not about the visual rendering that the browser does.

[@emberchord]

common yellow tint