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)

Reference