4 ms·

Okay I think I get it: 1. Define elements in script by extending htmlelement 2. Follow the allowed structure in the DOM so that the custom elements don't brea

by parksy 6y ago

Okay I think I get it: 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 :)

dmitriid 6y ago
In theory you wouldn't worry about idiosyncrasies of specific component libraries if they are based on web components because they would provide only a single interface: properties go in (as in customElement.myCustomProp = <some-value>), events go out (as in customElement.attachEventListener(<some-custom-event>, (e) => <do something in your callback>)). 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.
- parksy 6y ago
  Is the only thing that stops components from colliding literally naming convention? Like <fast-dropdown> != <my-homebrew-dropdown>? So it's basically a convention-based standard rather than a fixed standard? This feels like another example of the XHTML apocalypse coming full circle and we're trying to find objective approaches to loosely defined data. 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.
  - dmitriid 6y ago
    > Is the only thing that stops components from colliding literally naming convention? Like <fast-dropdown> != <my-homebrew-dropdown>? So it's basically a convention-based standard rather than a fixed standard? 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 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 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"

by parksy 6y ago

dmitriid 6y ago

In theory you wouldn't worry about idiosyncrasies of specific component libraries if they are based on web components because they would provide only a single interface: properties go in (as in customElement.myCustomProp = <some-value>), events go out (as in customElement.attachEventListener(<some-custom-event>, (e) => <do something in your callback>)). 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.

parksy 6y ago
Is the only thing that stops components from colliding literally naming convention? Like <fast-dropdown> != <my-homebrew-dropdown>? So it's basically a convention-based standard rather than a fixed standard? This feels like another example of the XHTML apocalypse coming full circle and we're trying to find objective approaches to loosely defined data. 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.
- dmitriid 6y ago
  > Is the only thing that stops components from colliding literally naming convention? Like <fast-dropdown> != <my-homebrew-dropdown>? So it's basically a convention-based standard rather than a fixed standard? 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 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 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"