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 That's not wholly true. jQuery plugins and React components fail over time because they belong to their dependencies, not the other way around.
A properly encapsulated #webComponent can have just any dependencies it wants as long as they don't leak. In fact, the internal dependencies could be jQuery or React as long as the consuming app doesn't need to know about it.
There are performance realities there, but that's true today as much as it would on the last day of the web.
Hmm I'm wondering if declarative Shadow DOM in Web Components would open the path to new patterns of making nicer without-JS-fallback than with <noscript> elements
But some experiment gonna be… as always… for some other days
While we’re all trying to figure out best practices for web components, I think we need to also be discussing when they are the best solution for the situation.
I’ve been trying to use them to add a search input for a table of data, and based on styling and how the Shadow DOM works, I’m just not convinced this is actually a good use case. It has fragility hidden by the structure of web component technologies.
The latest EAP of #JetBrains#IDEs (2024.1) has a new “create a new file from snippet" button in the #AI Assistant chat. Select the folder in which you want to drop the file, then click the button.
Here, I created some boilerplate for a new #webcomponent.
Not only does Apple have documentation on how to style <button> elements to be an Apply Pay button (Safari cheekily comes with appearance: -apple-pay-button built in), but they also have their own #WebComponent to achieve the same effect. It even uses CSS Custom Properties to style it:
Technically, I think this is an interesting approach.
But having an actual navigation menu in a <dialog> instead of the main DOM also sounds like a bad idea -- how is accessibility of the navigational elements?
Once again facing that classic #designsystem conundrum: Theme and/or customize a 3rd party component library, or build one from scratch.
Actually, we need two component libs: A #WebComponent one for web products and a #ReactNative one for iOS & Android apps. We already have designs in #Figma and want to have parity in terms of design & naming across Figma, web & RN.
My gut and past experiences make me lean towards building from scratch.
I'm looking for suggestions how to attach actions to the menu items themselves. The markup below is upgraded with appropriate roles and behaviours. But in a generic component, what is the best strategy for supporting custom actions?
Free HTML Web-Component: <animated-details>. Like a regular <details> element, but, like, animated! It uses that 0fr/1fr trick to animate the height, the only reason it's a web component is that I'd sometimes only get the transition once, or not at all? So JavaScript, of course. Progressively enhanced, of course. Respects user's motion preferences, of course.
@eldamir tbh, JavaScript isn't the issue. If you follow the #webcomponent hashtag, you'll see how far the web platform has come and how build tools may soon be unnecessary.