[jongjong]

I used Web Components (HTMLElement) recently and did not encounter any of these issues. I found it more snappy and reliable than frameworks like React or VueJS in terms of adding and removing components dynamically. I did find that it provides a lot more flexibility than front end frameworks (more ways to make mistakes?) and the code was more verbose. If I had to start a project from scratch today, I would consider going straight for Web Components.

[tekkk]

Are you serious? Using vanilla Web Components is just god awful and I can't recommend them to anyone with a straight face. Not having had experience with "normal" web frameworks like Svelte, React or Vue.

You have to invent all your own wiring and passing of events, state-management et cetera if you go that route.

[replygirl]

it's not that much to invent. have frameworks really made it so easy that we can't bear to work with native events, manage the dom, or build reactivity with proxies or subjects? gp says there's a performance objective, sometimes it's worth building a solution that only does what you need

edit: no one is saying a purpose-built framework needs to do everything that a mass-market framework ecosystem does. it's disingenuous to think there aren't circumstances it would make sense, not all of us make forms for a living.

[dmitriid]

> we can't bear to work with native events, manage the dom, or build reactivity with proxies or subjects

I mean, you can do all that. And either spend your time writing tons of boilerplate code, or reinventing half of those frameworks and libraries anyway.

And still having to deal with issues like having to remember that they don't participate in forms (more JS to each component), that a11y can suddenly be broken (when your label references an element inside shadow dom), that wcs are not extensible to SVGs (which is important if your field is data visualisation) etc.

At which point you will go "why bother".

[jongjong]

I wouldn't say that you need to reinvent any framework. I was able to build a simple application using HTMLElement directly. I just had to define a handful of utility functions to do things like escape HTML tags for user-generated content... The main critique I can think of is that Web Components provide many ways to do things; for example, you can create elements using vanilla JS or using template strings (or even a combination of both)... When it comes to event handlers; you can also define them using vanilla JS or inline inside the tags as part of the template string (or both). There is no single standard way to do anything so that was the real challenge but this can easily be solved through project-based coding style guidelines. There aren't that many gotchas.

[dmitriid]

> I wouldn't say that you need to reinvent any framework.

You do, when you need at least slightly more complex.

> The main critique I can think of is that Web Components provide many ways to do things

Nope. The main critique is that Web Components is 2010s tech solidified in the platform when the rest of the world has moved on and is now exploring fine-grained reactivity and trying to remove components as a unit of work/ui. That they are 12 years in the making and still have issues that no framework has (see links here: https://news.ycombinator.com/item?id=34346269). That their design now poisons the rest of the platform that needs to add countless new workarounds for their shortcomings, and seemingly unrelated standards (like scoped CSS) now have to take them into consideration...

Well, there is not just one main critique, there are many main critiques

> There aren't that many gotchas.

Just because you haven't run into them it doesn't mean there aren't any gotchas. And there are plenty.

[tekkk]

Hah hah. You make me laugh. Sure boss, not much. If you're doing it for fun and on your own time, okay. For real work, don't know who wants to pay you to invent your own framework.

[nathias]

are you normally a c# or a java coder?