I disagree. The simplicity of Web Components forces you to plan ahead a little bit more and to architect your app in a certain way which turns out to be beneficial in the medium and long term as it makes it much easier to maintain.

With many frameworks, I find that most of my debugging work is related to framework-specific gotchas. For example, just this week, I was debugging a VueJS app and it would run validation rules on an input field before it was ready and it caused a flickering red error border around the input box. It was a case where the content of the input field had to be sanitized; that input field needed a second rendering if the user pasted content directly into it (as opposed to typing). It took me a while to come up with a workaround because VueJS controlled the timing of when the validation rule would be enforced (on render) and I couldn't control the timing. I had to create an additional reactive 'isInputReady' variable and use it inside the validation function that I provided to the VueJS input component through the rules attribute... Kind of hacky but there is no friction-less way (without the browser prompting the user) to intercept clipboard data before the content was inserted into the input field; the only way to do sensitization of pasted data was through a re-rendering but I could not stop the red flicker without adding this extra isReady variable and making it part of the validation rule...

Anyway my point is that when using a framework, you run into these types of tricky issues all the time and you have to come up with equally tricky workarounds. I don't run into these issues when using Web Components because I have full control over the rendering. I don't need to make a component reactive for cases where reactivity gets in the way.

> The simplicity of Web Components forces you to plan ahead a little bit more and to architect your app

Not really. The perceived simplicity of Web Components makes you deal with issues that you should never have to deal with, and reinvent your own libraries and frameworks for even the simplest things, and you will still run into unexpected gotchas.

Especially if your components will be used by others (cross-root ARIA, SSR, styling, proper form participation etc.).

But even for what are not even supposed to be issues. It's a good thing you mentioned an input box. Properly re-rendering an input box in response to certain events or state changes will be either lots of tedious manual work, or running into issues like losing focus, user input, and values. And there's literally nothing in web components to help you with that: use or create your own library to deal with it.

The behaviour you described for Vue is surprising though...

> I don't run into these issues when using Web Components because I have full control over the rendering.

Not really you don't. For example, web components are eagerly rendered, and there's really not much you can do to prevent a rendering cascade when in reality you want something to load and render lazily.

You can't coordinate between various components on the page, so they will all have their own idea of when to render.