> This is a branding problem as much as it is an education problem. Neither the HTML standard nor the DOM standard mentions the term “web components” anywhere. And yet it’s present everywhere in documentation and learning material.
Basically, if you want to have (say) a bootstrap.css which is referenced inside multiple shadow roots, previously you'd run into a gnarly perf cliff (I measured ~160x perf degradation just for 100 shadow roots). This is now fixed!
I'll also point out that this is why it's important to test in multiple browsers. A lot of people will run some perf experiment in Chrome, find it's slow, and conclude "OK, I guess the web is just slow at this."
But if you test Safari and Firefox and find they're fast, then congrats! You have a perf bug you can file on Chrome. I filed it and it got fixed 2 weeks later.
update: ¡sí se puede! la prueba preliminar es que puedo ir convirtiendo componentes pequeños uno a uno. Ya probé los atributos y ahora siguen los eventos.
Very clear pattern forming in a few of my #WebComponents, creating a <template> element outside of the component code itself for reduced repetition and performance. I'm effectively polyfilling for Declarative Shadow DOMs inability to be defined once for many instances. Though I guess I'm also polyfillnig for a lack of “Declarative Light DOM" too 🤔
> This is a branding problem as much as it is an education problem. Neither the HTML standard nor the DOM standard mentions the term “web components” anywhere. And yet it’s present everywhere in documentation and learning material.
One of the teams I've been working with to climb the performance management maturity ladder is...Edge!?!
We build a lot of the browser out of web "stuff" these days (think bookmarks, history, downloads, settings, new-tab-page, etc.), and moving away from React to a modern Web Components + HTML-first architecture has had a huge benefit for users, particularly folks on low-end hardware:
But the framework isn't what makes the difference; actually looking and caring about the performance is what has enabled this work to deliver 40-75% wins.
@josh Well, it's not just react vs web components.
They also rearchitected their code; and as a side effect of moving away from react, they can have code optimized for the most recent Edge when react needs to support many more browser engines and versions (something you definitely want for most web apps).