The problem with Web Component libraries I've seen (including this) is that the moment you use any external libraries, you lose the entire point of Web Components. That is, to have fully native reusable bits of code that can be built upon and used interchangeably with any other tech stack just like an <a> tag or an <input>. As soon as you start using libraries with a build process you might as well just use React or Vue or whatever else.
The benefit of web components is interoperability. It doesn't matter what build tools you might or might not use to make web components, you consumer them the same way:
1. Load the definition
2. Create an element with any DOM API or HTML.
Nothing about web components says you shouldn't use dependencies or build steps.
>Can you elaborate a bit on what you mean plz? What's the link between "interchangeably" and having a build process?
My point is that as soon as you introduce a build process, imported dependencies, etc. then you might as well just use React components. The power of web components is that you can just drop them on a page and use them with zero dependencies or proprietary APIs to learn.
But a build process ensures you can use imported dependencies internally AND use them with zero dependencies on your page (other than the JS component definition itself). Even if you don't have a build process and just use ES6 modules, the Web Component manages its own dependencies such that you don't have to worry about it (the only friction there being if folks use bare import modules). Whereas with React components, you'll always be dependent on a React runtime.
There are various techniques you can apply in these cases. Like deduplicating dependencies or apply a build/babel plugin that makes sure the names are unique.
Imho scoping elements at the template/element level sounds more promising. Here is an experiment archiving exactly this https://open-wc.org/scoped-elements/
There are still some improvements to be made but it's actively been worked on - so something lion might consider in the future.
That's great, that would've saved us so much trouble back when I worked with Web Components with many different teams. The problem it describes are exactly what we ran into, and solution 2 was extremely painful in terms of overhead and being demotivating:
> Synchronizing updates of shared dependencies - e.g. make sure Team Blue & Team Green always use the same version when releasing. This can be a viable solution however it comes with a high organizational overhead and is hard to scale up (for 10+ teams)
I'm not sure whether it's still the case with lit-html, but back when Polymer was a thing, you'd better make sure all Web Components on your page were compatible with the same version, and also didn't build on top of incompatible versions of the same shared component. This really made it a pain in the behind to integrate many different components built by many different teams into the same application, especially if there also was a library of shared components used by all teams.
Anyone from ING present who can share whether this is still the case?
I think you mean you can't have same element redeclared? Then yes this is still the case, and at least for now it will be - for any library that can output custom elements. Every component is a real interactable HTML element, imagine <div> or <p> would work differently. I believe there is some work for multiple component registries but I'm not tracking the progress on that. This is HTML thing - it is not a library specific problem. It might get solved eventually https://github.com/w3c/webcomponents/issues/716.
I come from python world where you have same restriction for all packages so it never occured to me as a serious problem :) We just pin ranges in libraries. And application itself pins specific versions in place.
Yes. I come from React, and if two components I depend on each depend on different versions of the same component, I can load them both no problem. When I worked with Web Components, that required that I contacted the authors of both components to get them to upgrade to the new version of the same time - which of course became exponentially more effort as we used more components.
