7 ms·

Use web components for what they’re good at

99 points by chriskrycho 3y ago

nightowl_games 3y ago
I haven't done any serious webdev since 2013. I thought Knockout.js was pretty slick at the time. I don't know how react works. I don't know how svelte works. This article is so basic to me that I makes me wonder wtf these frameworks are actually doing and why this article even came to exist.
- tomByrer 3y ago
  From the creator of SolidJS (heavily inspired by Knockout.js by his own confession) & worked on eBay's Marko framework: https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh https://dev.to/ryansolid/maybe-web-components-are-not-the-fu...
- LAC-Tech 3y ago
  Front-end web dev heavily skews junior. People like Nolan really stand out.
- earthboundkid 3y ago
  TBF, Web Components were invented in 2013 and have not really changed since then.
  - troupo 3y ago
    The idea of web components was presented in 2011 https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell https://fronteers.nl/congres/2011/sessions/web-components-an... Since then they've become the complete antithesis of that vision
- jongjong 3y ago
  I think everyone got caught up in the mania. I've been coding for 15 years and I was a full stack dev throughout. TBH I thought Google's PolymerJS (which was closer to Web Components) would take the crown but React came out of nowhere and everyone jumped on that bandwagon en masse and the complexity of all front end frameworks just kept increasing year after year. In the meantime, browsers were forging ahead with a lot of nice features that had been planned for a long time and which would make the frameworks redundant and now that these features are available, the frameworks have gained a lot of inertia and it's hard to people to accept that you don't need them anymore due to large scale sunk cost fallacy... Not to mention all the vested interests (platform providers) who built on top of React.
  - troupo 3y ago
    > the frameworks have gained a lot of inertia and it's hard to people to accept that you don't need them Yes, yes you do. Even with all the nice things there are very few things that are actually useful and usable. Even web components are no longer advertised as "framework replacements", but as "yeah, they are aimed at library and framework authors" (and vanishingly few libraries and frameworks use them due to their many shortcomings)
    - jongjong 3y ago
      I disagree. The simplicity of Web Components forces you to plan ahead a little bit more and to architect your app in a certain way which turns out to be beneficial in the medium and long term as it makes it much easier to maintain. With many frameworks, I find that most of my debugging work is related to framework-specific gotchas. For example, just this week, I was debugging a VueJS app and it would run validation rules on an input field before it was ready and it caused a flickering red error border around the input box. It was a case where the content of the input field had to be sanitized; that input field needed a second rendering if the user pasted content directly into it (as opposed to typing). It took me a while to come up with a workaround because VueJS controlled the timing of when the validation rule would be enforced (on render) and I couldn't control the timing. I had to create an additional reactive 'isInputReady' variable and use it inside the validation function that I provided to the VueJS input component through the rules attribute... Kind of hacky but there is no friction-less way (without the browser prompting the user) to intercept clipboard data before the content was inserted into the input field; the only way to do sensitization of pasted data was through a re-rendering but I could not stop the red flicker without adding this extra isReady variable and making it part of the validation rule... Anyway my point is that when using a framework, you run into these types of tricky issues all the time and you have to come up with equally tricky workarounds. I don't run into these issues when using Web Components because I have full control over the rendering. I don't need to make a component reactive for cases where reactivity gets in the way.
      - troupo 3y ago
        > The simplicity of Web Components forces you to plan ahead a little bit more and to architect your app Not really. The perceived simplicity of Web Components makes you deal with issues that you should never have to deal with, and reinvent your own libraries and frameworks for even the simplest things, and you will still run into unexpected gotchas. Especially if your components will be used by others (cross-root ARIA, SSR, styling, proper form participation etc.). But even for what are not even supposed to be issues. It's a good thing you mentioned an input box. Properly re-rendering an input box in response to certain events or state changes will be either lots of tedious manual work, or running into issues like losing focus, user input, and values. And there's literally nothing in web components to help you with that: use or create your own library to deal with it. The behaviour you described for Vue is surprising though... > I don't run into these issues when using Web Components because I have full control over the rendering. Not really you don't. For example, web components are eagerly rendered, and there's really not much you can do to prevent a rendering cascade when in reality you want something to load and render lazily. You can't coordinate between various components on the page, so they will all have their own idea of when to render.
graypegg 3y ago
I’ve actually done that “web components as the interoperability layer”! It was this old angular 1.8 app with new features being written in angular-hybrid-ized angular 8. Ripping out angular-hybrid and separating the angular 1.8 routes from the modern angular routes was difficult, but now they were totally separate. The only thing linking them together was an object with some RXJS streams in it for state, and a little in-house wrapper “app” which just loaded one component or the other with some attributes depending on the URL and a hash of routes for config. (I’d probably use SingleSPA [1] now. Same thing really.) We could deploy them separately since the build just ends up being another JS file somewhere that just gets included with a script tag at runtime. No version bumping! No big mega build! We started replacing the remaining “old” routes 1 by 1 with a “new” counter part. That was the easiest part, and went at a pace devs were comfortable with (fast enough) and business folk could tolerate. (modular enough to not HAVE to be done all at once) Last I checked, the angular 1.8 stuff is gone years ago. :) [1] https://single-spa.js.org/ https://single-spa.js.org/
nonethewiser 3y ago
Well this is shocking > It might also surprise you to learn that, by some measures, React is used on roughly 8% of page loads, whereas web components are used on 20%. https://mastodon.social/@westbrook/110774427407999573 https://mastodon.social/@westbrook/110774427407999573 I suppose it’s because you can probably use web components on top of frameworks.
- benatkin 3y ago
  I looked at vercel.com and reddit.com - just React, no customElements. Then at nytimes.com I found React and this: Yp = function(a, b) { var c = window; var d = void 0 === d ? wb : d; var e; if (c.customElements && null != (e = c.Reflect) && e.construct && !c.customElements.get("google-product-ad")) { Real elegant. After that I checked ask.metafilter.com and saw it has neither.
  - MBCook 3y ago
    Figures. After seeing those numbers I couldn’t imagine custom components being more popular, so I figured it must be some popular library that people are using that uses them underneath. Of course it’s ad-tech.
    - benatkin 3y ago
      I use and like Web Components. But yeah this ratio doesn't bear out in articles and conversations with devs. Edit: github.com has matches for both "react\b" and "customElements", and I expected that because I've read about Web Components on their blog.
      - MBCook 3y ago
        I see people talk about React, Vue, and jQuery all the time. I occasionally see people talk about straight JS with no libs or Svelte. I may be able to recognize other framework names. I literally can’t remember the last time I saw a mention of web components online, let alone an article about them. Which is one of the reasons I was so interested to read this one.
canvascritic 3y ago
I appreciate the author's attempt to contextualize web components, but I have a few bones to pick, having seen web components used to a pathological extent in various projects First, the idea that one of web components' strengths is bypassing serverside rendering is a bit misleading. SSR has been foundational to reducing time to first meaningful paint, ensuring accessibility, and improving seo. to argue that bypassing it is an advantage seems antithetical to best practices, even when using client-side tech like web components. Second, the transition example from react to svelte highlights the use of web components as a bridge, but I fear it oversimplifies the reality of such transitions. Its true that web components might provide a superficial level of interoperability, underneath, the application architecture, state management, and data flow can differ vastly between frameworks. Simply plopping an old component with a new one doesn’t mean they’ll play nice without substantial architectural considerations. Finally, the mention of "no bundler, no transpiler" as an advantage is curious. in practice, the modern web development ecosystem has moved towards using tools like bundlers and transpilers to optimize delivery, reduce overhead, and facilitate modular development. this isn't about complexity, but rather about efficiency and best practices. Web components certainly have their place and, used judiciously, can certainly add value. It's just essential to approach them with a nuanced understanding and not as a silver bullet.
- jongjong 3y ago
  - Server side rendering is essentially a hack to work around web crawlers' inability to parse dynamic single page apps... My first issue with this is that it doesn't make sense to me why someone would build a high-exposure public website/landing page as a dynamic single page web app, what you really need is a website; these are much more lightweight, easier to cache and deliver over CDN and they use up far fewer resources (no need to serve libraries which are not necessary for the current page). Also, why would you want web crawlers to parse a dynamic application (e.g. dashboard and private areas)? It shouldn't even be visible unless the user is authenticated (which the crawler is not!). What should you show the web crawler in that case? Do you really need Google to see all your apps' form templates with all the empty input fields? SEO is for marketing; in this case, you need a website with a landing page and potentially a blog, not a dynamic single page app. - About bundling, the current reality is that frameworks like React come with a huge amount of dependencies/boat... On the other hand, native Web Components require no dependencies. Web Components will generally load much faster even without bundling than React + all dependencies in a bundle because those bundles are often huge... Not to mention that nowadays, tags expose some nice attribute which let you control the loading and execution order of scripts in a highly fine-grained way (e.g. async and defer attributes on the script tag). That's even without going into the fact that since HTTP2, servers have the ability to preemptively push resources to the client without any round-trip latency. Also, loading resources separately allows for more fine-grained cashing with CDNs; you share some components between some pages and you only need to load what you need explicitly as needed.
dclowd9901 3y ago
> Now, some people get squeamish at the idea of two frameworks living on the same page Yes, yes. Years of trying to cut off the long tail of a migration will make you a bit squeamish.
andirk 3y ago
Web components can be used without a front-end JS framework (Vue, React, etc.) which I think is one of its best features. There is a mild complexity to it since it encompasses the javascript and HTML including creating the HTML element type (or whatever it's called). > This is about as close as you can get to the original vision for web components, which is that using <fancy-element> should be as easy as using built-in HTML elements.
- MBCook 3y ago
  But how many people who would want the additional features they could get with web components over strict HTML aren’t already using a framework?
  - JodieBenitez 3y ago
    count me in :)
- troupo 3y ago
  The original vision also included "we don't need JS do display <fancy-element>" and "we shouldn't have a curse of empty <body> tag where everything is filled by javascript", but here we are. Dozens of JS-only standards to make web components work, with 20 more JS-only standards to fix deficiencies and holes in the original design: https://w3c.github.io/webcomponents-cg/2022.html#cross-root-aria https://w3c.github.io/webcomponents-cg/2022.html#cross-root-...
MBCook 3y ago
I’m aware of web components, but I’ve never seen them in person (as a dev). Honestly I assumed they were dead. I never see them discussed or suggested to solve problems. I see libraries of components/widgets offer versions for React and Vue and other things, never a web component version. No matter how good they may be they seem to have almost no mindshare. All major browsers appear to have supported autonomous custom elements since ~2019. That said based on this page this is a nonstarter at my company. If it doesn’t work easily React, it’s dead. The fact you can’t pass objects or functions would be a huge pain. Of course you can’t pass objects to traditional HTML elements either (outside react) or functions (basically) so I’m not sure why I’m surprised at that. But being able to do that is what makes using React components so easy. Having to add listeners sounds like going back to the battle days of early jquery to me. Additionally having poor accessibility support in 2023 is also a non-starter. We’re required to provide that in everything we do. It’s not web components’ fault if React doesn’t fit their model, or browsers have poor accessibility support when web components are involved. But it’s still a blocker. I can think of a at least one thing we do that being able to ship it as a web component would be very useful for. But we need to be able to pass objects in and out, which I guess would require marshaling and unmarshalling JSON. And that destroys ease of use. Others have already mentioned the bundler problem. Unfortunately the tone of this piece kind of reads as “come on, they’re not that bad, really“ instead of the cheerleading piece I was expecting. It had to mention a number of big caveats up front. I’m glad it did to provide an accurate picture. But unfortunately I think it actually reinforced to me the exact feeling they were trying to argue against.
- MobiusHorizons 3y ago
  You should be able to pass objects or functions as properties (at least at the dom layer). I have not personally tried it with react, but I know angular supports this.
  - MBCook 3y ago
    Seems it doesn’t work in React, everything is sent as a string. There was a link in the article that shows how well web components work with various frameworks. https://custom-elements-everywhere.com/ https://custom-elements-everywhere.com/ You can see how React fares for itself.
dang 3y ago
Recent and related: If Web Components are so great, why am I not using them? - https://news.ycombinator.com/item?id=36976670 https://news.ycombinator.com/item?id=36976670 - Aug 2023 (181 comments)
dgb23 3y ago
My preference in web dev is to lean into standards. Web components give us a way to structure and re-use dynamic (client side) rendering and event handling. However two things are bad about them: 1. They break the otherwise consistent dynamism of JS. You can’t re-register custom elements. This is incredibly disappointing. 2. The shadow dom is a separate concept lumped together with the rest, which is painful. A typical case of people anticipating specific usage instead of making a modular, simple design.
ttfkam 3y ago
There have always been interesting aspects to custom elements seamlessly integrated into the DOM of browsers, but let's be honest, the current API is… shall we say somewhat unwieldy. Little known fact: adding one line of code turns your Svelte component into a custom element (aka web component). https://svelte.dev/docs/custom-elements-api https://svelte.dev/docs/custom-elements-api
reverseblade2 3y ago
Just as a side info, the profile card in Microsoft Teams does use Web Components.

99 points by chriskrycho 3y ago

I haven't done any serious webdev since 2013. I thought Knockout.js was pretty slick at the time. I don't know how react works. I don't know how svelte works. This article is so basic to me that I makes me wonder wtf these frameworks are actually doing and why this article even came to exist.

tomByrer 3y ago
From the creator of SolidJS (heavily inspired by Knockout.js by his own confession) & worked on eBay's Marko framework: https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh https://dev.to/ryansolid/maybe-web-components-are-not-the-fu...
LAC-Tech 3y ago
Front-end web dev heavily skews junior. People like Nolan really stand out.
earthboundkid 3y ago
TBF, Web Components were invented in 2013 and have not really changed since then.
- troupo 3y ago
  The idea of web components was presented in 2011 https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell https://fronteers.nl/congres/2011/sessions/web-components-an... Since then they've become the complete antithesis of that vision
jongjong 3y ago
I think everyone got caught up in the mania. I've been coding for 15 years and I was a full stack dev throughout. TBH I thought Google's PolymerJS (which was closer to Web Components) would take the crown but React came out of nowhere and everyone jumped on that bandwagon en masse and the complexity of all front end frameworks just kept increasing year after year. In the meantime, browsers were forging ahead with a lot of nice features that had been planned for a long time and which would make the frameworks redundant and now that these features are available, the frameworks have gained a lot of inertia and it's hard to people to accept that you don't need them anymore due to large scale sunk cost fallacy... Not to mention all the vested interests (platform providers) who built on top of React.
- troupo 3y ago
  > the frameworks have gained a lot of inertia and it's hard to people to accept that you don't need them Yes, yes you do. Even with all the nice things there are very few things that are actually useful and usable. Even web components are no longer advertised as "framework replacements", but as "yeah, they are aimed at library and framework authors" (and vanishingly few libraries and frameworks use them due to their many shortcomings)
  - jongjong 3y ago
    I disagree. The simplicity of Web Components forces you to plan ahead a little bit more and to architect your app in a certain way which turns out to be beneficial in the medium and long term as it makes it much easier to maintain. With many frameworks, I find that most of my debugging work is related to framework-specific gotchas. For example, just this week, I was debugging a VueJS app and it would run validation rules on an input field before it was ready and it caused a flickering red error border around the input box. It was a case where the content of the input field had to be sanitized; that input field needed a second rendering if the user pasted content directly into it (as opposed to typing). It took me a while to come up with a workaround because VueJS controlled the timing of when the validation rule would be enforced (on render) and I couldn't control the timing. I had to create an additional reactive 'isInputReady' variable and use it inside the validation function that I provided to the VueJS input component through the rules attribute... Kind of hacky but there is no friction-less way (without the browser prompting the user) to intercept clipboard data before the content was inserted into the input field; the only way to do sensitization of pasted data was through a re-rendering but I could not stop the red flicker without adding this extra isReady variable and making it part of the validation rule... Anyway my point is that when using a framework, you run into these types of tricky issues all the time and you have to come up with equally tricky workarounds. I don't run into these issues when using Web Components because I have full control over the rendering. I don't need to make a component reactive for cases where reactivity gets in the way.
    - troupo 3y ago
      > The simplicity of Web Components forces you to plan ahead a little bit more and to architect your app Not really. The perceived simplicity of Web Components makes you deal with issues that you should never have to deal with, and reinvent your own libraries and frameworks for even the simplest things, and you will still run into unexpected gotchas. Especially if your components will be used by others (cross-root ARIA, SSR, styling, proper form participation etc.). But even for what are not even supposed to be issues. It's a good thing you mentioned an input box. Properly re-rendering an input box in response to certain events or state changes will be either lots of tedious manual work, or running into issues like losing focus, user input, and values. And there's literally nothing in web components to help you with that: use or create your own library to deal with it. The behaviour you described for Vue is surprising though... > I don't run into these issues when using Web Components because I have full control over the rendering. Not really you don't. For example, web components are eagerly rendered, and there's really not much you can do to prevent a rendering cascade when in reality you want something to load and render lazily. You can't coordinate between various components on the page, so they will all have their own idea of when to render.

graypegg 3y ago

I’ve actually done that “web components as the interoperability layer”! It was this old angular 1.8 app with new features being written in angular-hybrid-ized angular 8. Ripping out angular-hybrid and separating the angular 1.8 routes from the modern angular routes was difficult, but now they were totally separate. The only thing linking them together was an object with some RXJS streams in it for state, and a little in-house wrapper “app” which just loaded one component or the other with some attributes depending on the URL and a hash of routes for config. (I’d probably use SingleSPA [1] now. Same thing really.) We could deploy them separately since the build just ends up being another JS file somewhere that just gets included with a script tag at runtime. No version bumping! No big mega build! We started replacing the remaining “old” routes 1 by 1 with a “new” counter part. That was the easiest part, and went at a pace devs were comfortable with (fast enough) and business folk could tolerate. (modular enough to not HAVE to be done all at once) Last I checked, the angular 1.8 stuff is gone years ago. :) [1] https://single-spa.js.org/ https://single-spa.js.org/

nonethewiser 3y ago

Well this is shocking > It might also surprise you to learn that, by some measures, React is used on roughly 8% of page loads, whereas web components are used on 20%. https://mastodon.social/@westbrook/110774427407999573 https://mastodon.social/@westbrook/110774427407999573 I suppose it’s because you can probably use web components on top of frameworks.

benatkin 3y ago
I looked at vercel.com and reddit.com - just React, no customElements. Then at nytimes.com I found React and this: Yp = function(a, b) { var c = window; var d = void 0 === d ? wb : d; var e; if (c.customElements && null != (e = c.Reflect) && e.construct && !c.customElements.get("google-product-ad")) { Real elegant. After that I checked ask.metafilter.com and saw it has neither.
- MBCook 3y ago
  Figures. After seeing those numbers I couldn’t imagine custom components being more popular, so I figured it must be some popular library that people are using that uses them underneath. Of course it’s ad-tech.
  - benatkin 3y ago
    I use and like Web Components. But yeah this ratio doesn't bear out in articles and conversations with devs. Edit: github.com has matches for both "react\b" and "customElements", and I expected that because I've read about Web Components on their blog.
    - MBCook 3y ago
      I see people talk about React, Vue, and jQuery all the time. I occasionally see people talk about straight JS with no libs or Svelte. I may be able to recognize other framework names. I literally can’t remember the last time I saw a mention of web components online, let alone an article about them. Which is one of the reasons I was so interested to read this one.

canvascritic 3y ago

I appreciate the author's attempt to contextualize web components, but I have a few bones to pick, having seen web components used to a pathological extent in various projects First, the idea that one of web components' strengths is bypassing serverside rendering is a bit misleading. SSR has been foundational to reducing time to first meaningful paint, ensuring accessibility, and improving seo. to argue that bypassing it is an advantage seems antithetical to best practices, even when using client-side tech like web components. Second, the transition example from react to svelte highlights the use of web components as a bridge, but I fear it oversimplifies the reality of such transitions. Its true that web components might provide a superficial level of interoperability, underneath, the application architecture, state management, and data flow can differ vastly between frameworks. Simply plopping an old component with a new one doesn’t mean they’ll play nice without substantial architectural considerations. Finally, the mention of "no bundler, no transpiler" as an advantage is curious. in practice, the modern web development ecosystem has moved towards using tools like bundlers and transpilers to optimize delivery, reduce overhead, and facilitate modular development. this isn't about complexity, but rather about efficiency and best practices. Web components certainly have their place and, used judiciously, can certainly add value. It's just essential to approach them with a nuanced understanding and not as a silver bullet.

jongjong 3y ago
- Server side rendering is essentially a hack to work around web crawlers' inability to parse dynamic single page apps... My first issue with this is that it doesn't make sense to me why someone would build a high-exposure public website/landing page as a dynamic single page web app, what you really need is a website; these are much more lightweight, easier to cache and deliver over CDN and they use up far fewer resources (no need to serve libraries which are not necessary for the current page). Also, why would you want web crawlers to parse a dynamic application (e.g. dashboard and private areas)? It shouldn't even be visible unless the user is authenticated (which the crawler is not!). What should you show the web crawler in that case? Do you really need Google to see all your apps' form templates with all the empty input fields? SEO is for marketing; in this case, you need a website with a landing page and potentially a blog, not a dynamic single page app. - About bundling, the current reality is that frameworks like React come with a huge amount of dependencies/boat... On the other hand, native Web Components require no dependencies. Web Components will generally load much faster even without bundling than React + all dependencies in a bundle because those bundles are often huge... Not to mention that nowadays, tags expose some nice attribute which let you control the loading and execution order of scripts in a highly fine-grained way (e.g. async and defer attributes on the script tag). That's even without going into the fact that since HTTP2, servers have the ability to preemptively push resources to the client without any round-trip latency. Also, loading resources separately allows for more fine-grained cashing with CDNs; you share some components between some pages and you only need to load what you need explicitly as needed.

dclowd9901 3y ago

> Now, some people get squeamish at the idea of two frameworks living on the same page Yes, yes. Years of trying to cut off the long tail of a migration will make you a bit squeamish.

andirk 3y ago

Web components can be used without a front-end JS framework (Vue, React, etc.) which I think is one of its best features. There is a mild complexity to it since it encompasses the javascript and HTML including creating the HTML element type (or whatever it's called). > This is about as close as you can get to the original vision for web components, which is that using <fancy-element> should be as easy as using built-in HTML elements.

MBCook 3y ago
But how many people who would want the additional features they could get with web components over strict HTML aren’t already using a framework?
- JodieBenitez 3y ago
  count me in :)
troupo 3y ago
The original vision also included "we don't need JS do display <fancy-element>" and "we shouldn't have a curse of empty <body> tag where everything is filled by javascript", but here we are. Dozens of JS-only standards to make web components work, with 20 more JS-only standards to fix deficiencies and holes in the original design: https://w3c.github.io/webcomponents-cg/2022.html#cross-root-aria https://w3c.github.io/webcomponents-cg/2022.html#cross-root-...

MBCook 3y ago

I’m aware of web components, but I’ve never seen them in person (as a dev). Honestly I assumed they were dead. I never see them discussed or suggested to solve problems. I see libraries of components/widgets offer versions for React and Vue and other things, never a web component version. No matter how good they may be they seem to have almost no mindshare. All major browsers appear to have supported autonomous custom elements since ~2019. That said based on this page this is a nonstarter at my company. If it doesn’t work easily React, it’s dead. The fact you can’t pass objects or functions would be a huge pain. Of course you can’t pass objects to traditional HTML elements either (outside react) or functions (basically) so I’m not sure why I’m surprised at that. But being able to do that is what makes using React components so easy. Having to add listeners sounds like going back to the battle days of early jquery to me. Additionally having poor accessibility support in 2023 is also a non-starter. We’re required to provide that in everything we do. It’s not web components’ fault if React doesn’t fit their model, or browsers have poor accessibility support when web components are involved. But it’s still a blocker. I can think of a at least one thing we do that being able to ship it as a web component would be very useful for. But we need to be able to pass objects in and out, which I guess would require marshaling and unmarshalling JSON. And that destroys ease of use. Others have already mentioned the bundler problem. Unfortunately the tone of this piece kind of reads as “come on, they’re not that bad, really“ instead of the cheerleading piece I was expecting. It had to mention a number of big caveats up front. I’m glad it did to provide an accurate picture. But unfortunately I think it actually reinforced to me the exact feeling they were trying to argue against.

MobiusHorizons 3y ago
You should be able to pass objects or functions as properties (at least at the dom layer). I have not personally tried it with react, but I know angular supports this.
- MBCook 3y ago
  Seems it doesn’t work in React, everything is sent as a string. There was a link in the article that shows how well web components work with various frameworks. https://custom-elements-everywhere.com/ https://custom-elements-everywhere.com/ You can see how React fares for itself.

dang 3y ago

Recent and related: If Web Components are so great, why am I not using them? - https://news.ycombinator.com/item?id=36976670 https://news.ycombinator.com/item?id=36976670 - Aug 2023 (181 comments)

dgb23 3y ago

My preference in web dev is to lean into standards. Web components give us a way to structure and re-use dynamic (client side) rendering and event handling. However two things are bad about them: 1. They break the otherwise consistent dynamism of JS. You can’t re-register custom elements. This is incredibly disappointing. 2. The shadow dom is a separate concept lumped together with the rest, which is painful. A typical case of people anticipating specific usage instead of making a modular, simple design.

ttfkam 3y ago

There have always been interesting aspects to custom elements seamlessly integrated into the DOM of browsers, but let's be honest, the current API is… shall we say somewhat unwieldy. Little known fact: adding one line of code turns your Svelte component into a custom element (aka web component). https://svelte.dev/docs/custom-elements-api https://svelte.dev/docs/custom-elements-api

reverseblade2 3y ago

Just as a side info, the profile card in Microsoft Teams does use Web Components.