To be honest, I have experience with only a very small portion of the topics discussed below.

But I believe these conversations will be worth being documented for my future reference.

Reasons for using Web Component (in Drupal) ?

(presentation by Brynn from Pragma)

  • web component is a set of JavaScript API to create custom HTML tags, since it is using standard vanilla JavaScript it is not going to mutate as quickly as common library/frameworks such as Vue.js or React.js, as any changes will need to be discussed and agreed by all parties using it (browser companies, developers, communities, etc); even there is a update, it is likely going to be backward compatible.
  • since it is built-in as a part of the vanilla JavaScript API they can be used anywhere, whether it is inline javascropt, within a vanilla javascript file, or in certain framework (and you can build it once, and bring it anywhere, everywhere you go)
  • its style and data is encapsulated, what’s defined in the shadow dom won’t be able to be accessed at the document level, hence they can be reused wheerever you like without fear of code collisions
  • in comparison, though single directory component in Drupal try to approach the same “component” ideaology, it is dependent on Drupal, and does not provide encapsulation of style and functionalities (its style may impact the global styling, and same does the other way around)

Reasons for NOT using Web Component (in Drupal) ?

(my summary after talking to David from Morpht)

mostly business side of consideration:

  • the cost of developing web component will likely go beyoung the budget of most client, this is posed by both development complexity and management overhead
  • if you would like to build a set of standardised library of component and use it across different product (e.g. public facing website, internal portal, sharepoint) then this library will inevitably have dependency with all teams in the organisation, making extra cordination / communication required beforehand producing a component (This may also pose challenge in maintenance and future extendability)
  • the set of components / features required for different part of a organisation is not the quite the same: public facing website only need eye-catching visually pleasing component, whilst a sharepoint or internal website may need to cater for more complex business logic of uploading files, set event date, notify users etc. (there is little overlap for the set of component that they use, hence making a standard (web) component library to use across different organisation becomes a bit useless)

Reasons for NOT using Web Component (in General) ?

(post by ryan solid’s article: “Web Components Are Not the Future” (on DEV.to: link))

  • standards aren’t always a silver bullet
    • when you standardise something too much, it can limit innovation
    • if everyone are forced to assume: “this is how you build components” then their alternative, possibly better ways will never get explored.
    • standards also don’t necessarily means consensus – frameworks still have very different ideas of how component should work.
  • real cost of abstraction
    • web component are build on the DOM (custom DOM element), but the idea “components” are much much more than just DOM elements – they contain logic, reactivity, state, and lifecycle
    • interfacing with DOM always has constraints (for instance, attributes are strings, but JS obj or reactive state don’t map clearly, and rendering DOM element in SSR requires more wrapping or extra layers)
  • performance & overhead
    • shadow dom complications: it brings isolation and modularity, but have its costs: certain event behavior will not bubble past boundaries, and framework may struggle to integrate it naturally
    • developing your own custom elements means there will be more code the manage: template, attribute-property reflection, lifecycle handling, etc (all of which introduces hidden tax – more code shipped, more runtime checks)
  • portability isn’t a free win
    • while web component is more portable across frameworks, it have its own mental model which are oftentimes not 100% compatible with the frameworks’s (if you are already familiar with the mental model, you might as well use the native component from that framework)
    • if you try build everything in web component, you might end up paying more in JS size, complexity, and compatibility issues than your gained prtability
  • opportunity cost
    • loosing flexibility: once you implement your solution in web component (or really any other higher-level abstraction), it is both costly and hard to go back and change the underlying assumption
    • the time and effort you spent on web component may as well be used on other frameworks

he also raised a few points where web component may actually work:

  • legacy or non-JS websites (purely server rendered) where you want to drop in components
  • situations where different teams or system (or even different companies) need to share UI component through a common, framework-agnostic “tag” API

Reference