4 ms·

> Web components get imported and registered at the global level. This also means if two different libraries have a component called my-button, you can’t use bo

> Web components get imported and registered at the global level. This also means if two different libraries have a component called my-button, you can’t use both of them. In my opinion, fundamental problems like these really ought to be addressed before things become part of the web platform.

esprehn 2y ago
It's debatable if that's a fundamental problem. The entire Objective-C ecosystem was a flat namespace with prefixes too. Web Components trace their history to trying to explain how the web platform itself works. HTML is also a flat namespace, and the goal was to empower developers to do all the same things the platform does and in the same way. We hotly debated namespaces when designing the API and in the end decided to omit them but require at least one dash. You can think of the prefix kind of like the namespace in that sense. And in practice with reasonable prefixing practices we find folks rarely (if ever) collide, the same as ObjC. (Not that things couldn't be better: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...)
- jamesfinlayson 2y ago
  > We hotly debated namespaces when designing the API and in the end decided to omit them but require at least one dash. You can think of the prefix kind of like the namespace in that sense. Ah. I feel like the demos and examples that I've seen never have the first word as the pseudo-namespace so I had no idea that was the intention.
- continuational 2y ago
  Thank you for your answer. It makes sense in a historical context. But then, all languages since Objective-C seem to agree that namespacing is a good idea. There's no debate there. Even JavaScript has modules now. So I can't help but wonder what makes web components unique in this regard.
  - akira2501 2y ago
    They link to the DOM and they can be instantiated purely from a source HTML file.
  - afavour 2y ago
    Programming languages, perhaps. HTML not a programming language, it’s markup. The best comparison I can think of is XML: it does have namespacing and in my experience it’s more annoying than not having it.
    - eyelidlessness 2y ago
      It’s really only annoying because it has exceedingly fussy semantics. And even then, it usually fades into background noise unless you’re using the exceedingly fussy semantics with minimal constraints. If you generally tend to use the same N set of namespaces and always use the same prefixes with them, it’s mostly just fine after you copypasta some boilerplate (or have tools do the boilerplate for you). (Yeah I work with XML day to day, yeah I might have some amount of Stockholm Syndrome associated with that.)
- troupo 2y ago
  > It's debatable if that's a fundamental problem. Fundamental enough to be included in the list of things to still fix for web components: https://w3c.github.io/webcomponents-cg/2022.html#scoped-element-registries https://w3c.github.io/webcomponents-cg/2022.html#scoped-elem...
paulddraper 2y ago
XML had namespaces; HTML does not. Simple as that.

esprehn 2y ago

It's debatable if that's a fundamental problem. The entire Objective-C ecosystem was a flat namespace with prefixes too. Web Components trace their history to trying to explain how the web platform itself works. HTML is also a flat namespace, and the goal was to empower developers to do all the same things the platform does and in the same way. We hotly debated namespaces when designing the API and in the end decided to omit them but require at least one dash. You can think of the prefix kind of like the namespace in that sense. And in practice with reasonable prefixing practices we find folks rarely (if ever) collide, the same as ObjC. (Not that things couldn't be better: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...)

jamesfinlayson 2y ago
> We hotly debated namespaces when designing the API and in the end decided to omit them but require at least one dash. You can think of the prefix kind of like the namespace in that sense. Ah. I feel like the demos and examples that I've seen never have the first word as the pseudo-namespace so I had no idea that was the intention.
continuational 2y ago
Thank you for your answer. It makes sense in a historical context. But then, all languages since Objective-C seem to agree that namespacing is a good idea. There's no debate there. Even JavaScript has modules now. So I can't help but wonder what makes web components unique in this regard.
- akira2501 2y ago
  They link to the DOM and they can be instantiated purely from a source HTML file.
- afavour 2y ago
  Programming languages, perhaps. HTML not a programming language, it’s markup. The best comparison I can think of is XML: it does have namespacing and in my experience it’s more annoying than not having it.
  - eyelidlessness 2y ago
    It’s really only annoying because it has exceedingly fussy semantics. And even then, it usually fades into background noise unless you’re using the exceedingly fussy semantics with minimal constraints. If you generally tend to use the same N set of namespaces and always use the same prefixes with them, it’s mostly just fine after you copypasta some boilerplate (or have tools do the boilerplate for you). (Yeah I work with XML day to day, yeah I might have some amount of Stockholm Syndrome associated with that.)
troupo 2y ago
> It's debatable if that's a fundamental problem. Fundamental enough to be included in the list of things to still fix for web components: https://w3c.github.io/webcomponents-cg/2022.html#scoped-element-registries https://w3c.github.io/webcomponents-cg/2022.html#scoped-elem...

paulddraper 2y ago

XML had namespaces; HTML does not. Simple as that.