4 ms·

I read the article and don’t understand the example. So every time I want to use the avatar component (let‘s say inside a navbar, in a profile page, in an arti

I read the article and don’t understand the example. So every time I want to use the avatar component (let‘s say inside a navbar, in a profile page, in an article header etc.) , I‘d have to include the <img> tag. Because it’s basically a required „input template“ of the web component. And when the web component changes, I‘d have to go through all the places I use it and adapt the <img> tag to the new requirements of the web component…? that‘s… ridiculous?

aatd86 3y ago
Agreed. It's weird. If the goal is to extend HTML elements, should just send the compound elements definition with the html. The image should just be refered by a src attribute of user-avatar. But in any case, you still want javascript if you have to change something dynamically. People are hell-bent on using a static markup language designed for static documents even if it doesn't fit. Ok it's slow but that's another problem.
simonw 3y ago
Right. It's the difference between this: <user-avatar src="https://www.jim-nielsen.com/.well-known/avatar" alt="Profile photo of Jim Nielsen" width="32" height="32" title="Jim Nielsen" /> And this: <user-avatar> <img src="https://www.jim-nielsen.com/.well-known/avatar" alt="Profile photo of Jim Nielsen" width="32" height="32" title="Jim Nielsen" /> </user-avatar> I will argue that the extra <img> there is worth it for the benefits you get in terms not just of no/slow-loading JavaScript but also better semantics - code that process images in an HTML document will know what to do with the latter, it will be unable to handle the former.
- regularjack 3y ago
  What if next year you decide to change the img tag to an svg?
  - riquito 3y ago
    You have to go back to your codebase and edit every implementation of the component under the sun. <user-avatar> content is both a view and an interface, which is not obvious
  - simonw 3y ago
    Use find and replace.
uallo 3y ago
The difference is not what you write, but what ends up in your user's DOM. You can still use custom components in your static site generator or in your backend code. Abstract it however you want. You could use React Server Components with whatever component and interface you'd like. But the result in the SSRed or SSGed DOM should be the one from the article.

aatd86 3y ago

Agreed. It's weird. If the goal is to extend HTML elements, should just send the compound elements definition with the html. The image should just be refered by a src attribute of user-avatar. But in any case, you still want javascript if you have to change something dynamically. People are hell-bent on using a static markup language designed for static documents even if it doesn't fit. Ok it's slow but that's another problem.

simonw 3y ago

Right. It's the difference between this: <user-avatar src="https://www.jim-nielsen.com/.well-known/avatar" alt="Profile photo of Jim Nielsen" width="32" height="32" title="Jim Nielsen" /> And this: <user-avatar> <img src="https://www.jim-nielsen.com/.well-known/avatar" alt="Profile photo of Jim Nielsen" width="32" height="32" title="Jim Nielsen" /> </user-avatar> I will argue that the extra <img> there is worth it for the benefits you get in terms not just of no/slow-loading JavaScript but also better semantics - code that process images in an HTML document will know what to do with the latter, it will be unable to handle the former.

regularjack 3y ago
What if next year you decide to change the img tag to an svg?
- riquito 3y ago
  You have to go back to your codebase and edit every implementation of the component under the sun. <user-avatar> content is both a view and an interface, which is not obvious
- simonw 3y ago
  Use find and replace.

uallo 3y ago

The difference is not what you write, but what ends up in your user's DOM. You can still use custom components in your static site generator or in your backend code. Abstract it however you want. You could use React Server Components with whatever component and interface you'd like. But the result in the SSRed or SSGed DOM should be the one from the article.