I always saw web components as the missing leaves to the root that CSS frameworks embody.
HTML Web Components
21–30 of 247 posts
Re: HTML Web Components
#22Doesn't this create some nasty coupling since your web components look like a div but can actually require an arbitrarily complex HTML schema underneath? Can I write that down somewhere?
We've abstracted away soup
Re: HTML Web Components
#23For those who read to the end... Angular still uses XMLHttpRequest and not fetch, IIRC.
Funny, huh.
Re: HTML Web Components
#24Doesn't this create some nasty coupling since your web components look like a div but can actually require an arbitrarily complex HTML schema underneath? Can I write that down somewhere?
If things like slots are used, it isn't necessarily nasty coupling. But I agree this approach does make more a more complex tree structure than something you would see in a typical JSX/TSX file.
That said, I think the author's bigger point was that augmenting, rather than replacing/abstracting away basic web elements will win out long-term. Some degree nastier-looking coupling is a worthwhile trade over more opaquely-operating render libraries. I suspect augmented web components fail more gracefully too.
Re: HTML Web Components
#25Also read these articles for more on the idea of "HTML Web Components": 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://adact…
I just don't get the point. They are cumbersome to use, so now you need a lightweight framework on top of the built in framework such as Lit (which btw is larger than Preact). Then they solve none of the real problems like state management, routing, etc... so you'll likely need to pull in more. Sure you can get re-usable components. But are you going to pull in a re-usable web component that might use say Vue underne…
I think there's a lot of value for classic server-side web applications rather than SPAs. That handles routing, state, etc. I'm personally a fan and hope that the server-based application renaissance happens as some predict.
Re: HTML Web Components
#26> they can render before JavaScript. React components cannot do this — full stop Not a full stop; SSR means they could render before client-side JS. The example is a bit too simple to make the author's point IMO. A web component that handles changes to state would be a better comparison, and make for a better argument.
This is the main issue for me with webcomponents, they are not SSR friendly.
Re: HTML Web Components
#27Earlier quoted context omitted.
If you find a way to deliver a website without running any code, let me know!
I just think SSR is kind of missing it because web components allow a static frontend bundle to have a power that was previously reserved for SSR or HTML-only apps. Moving the render off the client is nice, but removing the prerender altogether is something much cooler.
If you have a static frontend bundle, isn't that just SSG (static site generation)? And if you can generate the site at build time, what's the fundamental difference between any of the non-web component SSG solutions and a web component SSG solution? Sure, you can pretend like there will be "no build step". But only if you're fine with "no proper cache headers" (and a long tail of other things). So in practice - hopefully there _will_ be a build step anyhow.
Re: HTML Web Components
#28Re: HTML Web Components
#29https://lnsy.dev/blog/custom-html-components.html
Here is my blog post about custom HTML Elements. It covers state changes, etc.
P.S., I am looking for a Front End project, preferably writing vanilla JS. My email is on the page.
Re: HTML Web Components
#30> they can render before JavaScript. React components cannot do this — full stop Not a full stop; SSR means they could render before client-side JS. The example is a bit too simple to make the author's point IMO. A web component that handles changes to state would be a better comparison, and make for a better argument.
This is the main issue for me with webcomponents, they are not SSR friendly.
Do you want SSR for SEO, or for fast first interaction? Because if the latter, then arguably some form of webcomponents might be theoretically better optimizable by browsers than DOM-element soups.