1. Define elements in script by extending htmlelement
2. Follow the allowed structure in the DOM so that the custom elements don't break / conflict with anything
3. Use CSS to make the custom element look nice.
Then, basically what we have is:
1. A class-based way to attach event listeners in a standard interface (which is nice)
2. what we always had to do anyway (unless framework forces using JS to inject HTML at runtime)
3. what we always had to do anyway
4. Can't use custom events anymore... Encapsulation fTW.
But now that brings us to a situation where, essentially, it comes down to which htmlelement classes take precedence in our dependency hierarchy. Some libraries are probably compatible but you can't guarantee it because there's no explicit package dependencies between different implementations, so if you choose two different component libraries you may end up with unexpected behaviours and bugs.
So if I were to build a component library that is "compatible" with all major component libraries, essentially what I'd have to build is a shit-ton of "mappings" and exceptions that define an order of precedence of which component variants my library should interact with or cede to? I don't really like the idea of "just magically working with incompatible libraries" right?
Does that seem about right?
I think I learned something new and fundamental today, and the overall approach makes sense if you pick a single library to build your application but I can't see it having any realistic value if you're to try and jimmy it into existing products, in fact I can see that being an extremely expensive exercise and potentially adding a load of overheads to maintain and configure.
Also I can see now why no one really answered the question about ARIA tab orders and accessibility, it's not the job of these libraries.
I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain :)
This is definitely true for "dumb" components aka leaf components such as labels, footers, links, basic inputs. However, since you need more (for example, data-binding and reactivity), this may become a question of interoperability, and I don't really know how that plays out in the real world.
> I'm not a very smart person, thanks again to you and everyone else jumping on my thread to take the time to explain :
No stupid questions, right? :) And the whole web components discussion is extremely muddied. Mostly because people expect you to already know what they are about, and talk about and use libraries on top of them: lit-html, stencil etc.
I do feel I am exposing myself to some ridicule for being out of style and I regret my attitude in my original reply but it felt honest at the time, I am glad that we have had this conversation in general because it's given me a lot to think over.
My main fear that I developed over the years is we end up developing frameworks for frameworks instead of delivering tangible results. I've been on projects that ended up taking far, far longer and costing way more to maintain simply because we had to nurse the framework rather than deliver the results.
Anyway thanks for taking the time out again, I need to percolate for a while and look into some of the ideas that have been expressed here.
Yup :) They decided to go for a flat namespace where all that distinguishes between components is their name. I'm guessing this already leads to collisions between different versions of the same element. And there has been an open issue for it for three years now: https://github.com/w3c/webcomponents/issues/716 And the "solution" seems to be "let's add more Javascript": https://github.com/justinfagnani/scoped-custom-elements
> I do feel I am exposing myself to some ridicule for being out of style and I regret my attitude in my original reply
It's perfectly fine :) I've been way more rude about web components before (and still am :) )
> My main fear that I developed over the years is we end up developing frameworks for frameworks instead of delivering tangible results.
Indeed. That's my main gripe with web components, really: instead of providing tangible benefits to developers, they ended up being "an API primarily for library and framework developers"
> one of them is already deprecated, and v0 of another one is also already deprecated.
Sometimes you swing and you miss. Instead of moving forward with the initial design, they iterated and improved it. That’s how software works.
> The API is so bad, that the official stance is "the API is aimed at library and framework developers, and you are not expected to write your components using this API".
It’s not because the API is bad, it’s because the term “component” has become ubiquitous with framework components and that’s caused A lot of confusion. Web components are lower level than React/Vue components by design, but people hear “component” and have the same expectations. Having worked with web components almost exclusively for more than a year, I feel like the APIs are thought out fairly well. They’re not perfect, but they are good and there’s momentum to continue improving them (e.g. declarative shadow DOMs).
> You cannot extend some (most?) of the built-in components. And even if you can, your custom implementations will not participate in form events
It’s still pretty new, but it’s coming. These things take time to get right and become supported by all browsers. Search for form-associated custom elements, for example.
> They break accessibility
Only if misused, which is also possible to do in any framework or even plain HTML.
> They don't work without JavaScript
I’m so tired of hearing this. How well does your React/Vue/Angular/Alpine/jQuery-based app work without JavaScript?
Browsing the web in 2020 with JavaScript disabled is like driving your car down the road without any wheels. Things just aren’t going to work right. The experience will be inferior even the when effort is made, but IMO it’s not reasonable to expect developers to accommodate the < 1% of users who might actually do this.
> They cannot be rendered server-side
I’m no expert in SSR, but Stencil offers some examples of how to achieve this with their compiler, which is a joy to use. [1]
> They are not strictly HTML, but a subset of it, because you can't provide callbacks for their custom events
It wouldn’t make sense to provide an “onclick” style prop for custom events, but you can attach listeners with `addEventListener` like any other event. The syntax is identical.
> And on the social side of things, their proponents will very rarely acknowledge or discuss these issues in public
I’m a proponent and I’m happy to discuss these things in public.
It seems, however, there are a lot of misconceptions about the underlying specs. Maybe that’s deserved — it took a long time for web components to get this far and it’s been a bumpy road. That doesn’t mean it hasn’t gotten much better.
I’d encourage anyone who hasn’t explored custom elements, shadow DOM, et al recently to take another look. We’re building some awesome things with them!
Reality:
- WebComponents is a collection of 4 web standards, one of them is already deprecated, and v0 of another one is also already deprecated.
- The standards provide a verbose, error-prone imperative API that leaks implementation details left and right
- The API is so bad, that the official stance is "the API is aimed at library and framework developers, and you are not expected to write your components using this API". And if you look at the frameworks, they try to not even compile/transpile down to this API
- Since all WebComponents basically have is DOM APIs, the official stance is basically "yeah, they are good for implementing leaf nodes" (that is basic dump components like an simple input field, or a label) because you still need a full-fledged lib/framework for anything else
- You cannot extend some (most?) of the built-in components. And even if you can, your custom implementations will not participate in form events, so you have to create workarounds if you want to submit values from your components
- They break accessibility
- They don't work without JavaScript
- They cannot be rendered server-side
- They are not strictly HTML, but a subset of it, because you can't provide callbacks for their custom events (you can do onClick, but you cannot do onSomeCustomEvent)
- And on the social side of things, their proponents will very rarely acknowledge or discuss these issues in public (even though there are dozens if not hundreds of issues with extensive discussions on GitHub), but will spend not an inconsiderable amount of time and energy bashing non-webcomponent libraries and frameworks