> You could easily do this a different way

Yes, but that you have to make a choice means the design is poor. That's why stuff like React (imo) is a failure: there's a kajillion ways to do the same thing which end up creating dogma and sloppy/inconsistent code (read: bugs). Web Components—as far as I've seen—are making the same mistakes, but even worse, as a standard.

As a web standard, Web Components should have been more carefully crafted. There's zero reason the spec couldn't have allowed me to wrap a normal <li> tag in the example above. That it doesn't means, somewhere along the road, a compromise was made that shouldn't have been made.

The problem with all of that is when you introduce new web developers (who start by learning vanilla HTML, CSS, and JavaScript), as soon as they get to wanting to build more complex stuff (read: components), they essentially have to "unlearn" much of what they learned.

Why does that matter? Paraphrasing Uncle Bob: because the rate of new developers doubles roughly every five years, that means half the programmers in the world have < 5 years experience. If they're learning bad/inconsistent patterns from day one, that means the quality of the software they build (and God help us, the tools they create later) is on a permanent downward slope.

Literally any framework that allows attributes/props, and child components has various ways this could be done. Vue, React, Svelte, Angular, all of them.

There are many issues with Web Components, but I don't think this is one of them. The real pain doesn't start until you want to do something like:

  <form>
    <my-input></my-input>
    <my-button></my-button>
  </form>

and have everything behave as expected.

> There are many issues with Web Components, but I don't think this is one of them.

You described another version of the problem I'm getting at. You should be able to use vanilla HTML, but you can't without hoop jumping.

That's not another version of the problem.

It's pretty clear that you don't have a substantial amount of experience with Web Components, but have a strong opinion about them nonetheless.

You could do the same weird attributes thing with props in React. Does that make React's design equally poor?

I don't know how you can prevent bad component designs like this.

    const EditableList = ui.component({
      render: ({ props }) => {
        return `
          <ul>
            ${each(Object.keys(props).filter((p) => p.startsWith('list-item-')), (p) =>
               `<li>${props[p]}</li>`
             )}
          </ul>
        `;
      },
    });

    // Usage:
    ${component(EditableList, {
        ['list-item-0']: 'First item on the list',
        ['list-item-1']: 'Second item on the list',
        ['list-item-2']: 'Third item on the list',
        ['list-item-3']: 'Fourth item on the list',
        ['list-item-4']: 'Fifth item on the list',
    })}

edit: used each(), which doesn't change the point that you can make a bad component API in any framework.

Re: your edit, that's not a bad component API, that's bad JavaScript (intentionally written by the author, in this case).

This is exactly my point. The MDN element is bad (the component has a bad API), and made bad by the component author, not the web components APIs.

Which highlights that there is a lack of clear prescription around how to handle a list in a component at the (Web Components) API level. Contrast that with what I linked from my own framework where there's zero uncertainty as to how to handle a list.