https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... - "So there you have it: a few thousand words on my journey through coming to understand and work with these fully-Light-DOM web components, otherwise known as custom elements. Now all they need is a catchy name, so we can draw more people to the Light Side of the Web."
https://adactio.com/journal/20618 then suggests the catchy name.
Sure you can get re-usable components. But are you going to pull in a re-usable web component that might use say Vue underneath when you use React? It just doesn't make any sense.
The best example is a multi-select box, or a searchable select box with autocomplete (what W3 calls the combobox pattern https://www.w3.org/WAI/ARIA/apg/patterns/combobox/) which in jquery was usually via https://select2.org/
For example, on my company website there's a timezone select box with 151 options. Asking a user to scroll through 100+ options is a big ask vs typing a few characters and hitting enter. There really is no static server-side way to solve this problem (I tried hard to think of one)... without creating a multi-page Wizard for what should be a single field on a larger form.
If you're building a SaaS product there are many UI requirements that demand high-interactivity and and there's really no better mainstream solution atm than static-first sites with small "islands" of React/Vue/etc components (ideally with hydration).
People still abuse React/Vue of course and the trend is 100% moving back to "mostly static" rather than slow SPAs but IMO JS-powered components are not never going away unless browsers start offering a broad selection of built-in complex web components like comboboxes, datepickers, tooltips, etc.
You maybe don't get full control over the rendering style of it, but it's a still significantly more usable than the Angular Material autocompletes.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
It's a shame clicking on it doesn't show the options like a select box though.
> Recommended values in types text, search, url, tel, email and number, are displayed in a drop-down menu when user clicks or double-clicks on the control.
https://adrianroselli.com/2023/06/under-engineered-comboboxe...
> People still abuse React/Vue of course and the trend is 100% moving back to "mostly static" rather than slow SPAs
I'm not seeing this at all, in fact I can't remember the last React project I worked on that wasn't a full blown SPA. I don't see anyone starting or advocating for static sites with islands unless they're using a framework like Astro or something.
Do you have any example sites or codebases using this approach?
> const app = h('h1', null, 'Hello World!');
With Web Components no build step is required and you're still able to intermix HTML with JS just like JSX. See the code below this section: https://github.com/kennyfrc/cami.js#key-concepts--api
It is not completely the same, but far better than that h function madness.
Meanwhile, "use the platform":
- all form components written before form participation landed in browsers are broken
- all web components written before cross-root ARIA (not even a spec yet) are potentially broken due to shadow DOM
- ... you may continue this list at your own leisure ...
The issue is just some sort of "front end bad" feeling at this point, imo. It's like some people think web components are the answer to the popular perception of the frontend being a mess of yearly novelties. When again, you can just use react and could have done so for a decade now.
I wonder what minimal solutions to state management and routing might look like in Hyphen: https://github.com/00000o1/-
So much of the beauty & elegance of the web was how declarative everything is, as that grants such observability & malleability. Shadow dom felt such an enterprise desire, to build much higher encapsulation walls, to layer in so much certainty, and that never felt like a goal I shared.
This article shows how light dom work can compose. I want to see light dom advocacy go further. It always seemed clear to me a web component/custom element could and should just self-modify the dom inside of it, move children around, build new content. Another example in the comments talks about maybe the user avatar element adding a div with the users name... Maybe the page or framework adds the icon, and the custom element then inserts that name, or that name and some aesthetic embellishment.
I guess my one concern with light dom / html web components is it seems like there have been - in some cases - some good performance wins from shadow dom. This wouldn't change what I go for unless I was desperate, but as a dev, in my head I see how shadow dom can scope down and reduce the number of elements that have to be traversed for a css specifier. and I want that win to be available somehow to me.
Really elating to see a lighter take on custom elements / web components. Thanks for the great links Simon!