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.
The discussion over on a thread by @chriscoyier spurred me to respond in the form of a blog post (and also finally add the seventh installment of the web component series I started in December).
I talk about how building dependency-free #WebComponents that last a life time does not have to mean a bad developer experience.
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.
@cferdinandi@chriscoyier I’m afraid that’s how the community works. Nobody is really going to get hyped about my handful of tiny Web Components, they’re getting doughy-eyed at the big shiny frameworks. And I’m kinda ok with that. If Web Awesome helps Web Components attain a bigger audience then great. At least then more people get to appreciate a slice of the benefits to #WebComponents
@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.
I know he didn't explain his position in details, so a 1800-word article sounds a little unfair, but I think dry and sharp statements need adequate context and analysis.