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.
"The random-source Web Component allows you to cycle randomly through different audio or video sources, utilising existing HTML elements and providing an elegant fallback experience.”
Enjoy insights from 22K responses about the state of the web platform, from HTML and interactivity to #webcomponents, PWAs, and a lot more.
This project is a monumental effort from people across the world. We even designed novel data collection UIs to gather the data we needed while minimizing friction, which I plan to write a case study about soon.
More ways to instantiate #WebComponents: "Last week, we looked at different ways to setup the HTML in a Web Component. One of the challenges with running your code in the constructor() is that sometimes the custom element is created, but none of the nested HTML inside it is ready yet. We looked at a few different ways to fix that, but today, I wanted to share two more. Let’s dig in!" https://gomakethings.com/more-ways-to-instantiate-web-components/
I thought I would take up the challenge of getting @enhance_dev#WASM working with #aspnetcore with the ability to SSR web components directly into the request pipeline.
Ok #WebComponents fam, question for ya. A well-known limitation of ::slotted() is that it only selects direct children. I’m making a component that wraps nested lists and I want to apply styles to all child slotted <ul>s.
Is it reasonable to work around this by having the component have the parent document adopt a stylesheet?
Been spending some time to make the project smaller, and make it easier to generate components for other projects! This wasn't possible previously, but with the newly released setHTMLUnsafe, we now can!
Also, new logo 🖌️
Check it out, and I'd love to know what you think of this way of creating Native Web Components!