> 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.
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:
Started writing a decision log for our #DesignSystem. Documenting why we chose to build plain ol' #HTML and #CSS where we can and #WebComponents where client-side #JS is needed is turning into a bit of a manifesto. Essentially we're using (and encouraging others to use) #ProgressiveEnhancement 😉
A Web Component for filtering items using a text input. Made this for a friend a while back and thought I should wrap it up into a neat package to go alongside my other #WebComponents.
jQuery plugins depended on jQuery, and when jQuery went out of favor, they ended up in the junkyard.
There is all sorts of componentry built exclusively on React, limiting it to React-based sites. As React goes out of favor, they will end up in the junkyard. (Same with any framework-specific extension.)
But with Web Components... it seems like the story will end differently. If they are built without dependencies, they might just live as long as the web does.
@chriscoyier I think that, more than just a "dependency", jQuery for jQuery plugins is a prerequisite. Just like React is for React component libraries.
OTOH, Web Component libraries have Lit (or FAST or Stencil...) as a "real" dependency, meaning they uses it for reactivity and such. Even if Lit goes out of favor, the components built with it will always be usable in whatever environment. That's a key difference.