[dxchester]

The main reason is that they're too low-level to use directly.

They do a lot, but stop just short of being useful without something of a framework on top. I tried hard to use them directly, but found that it was untenable without sensible template interpolation, and without helpers for event binding.

Here's my shot at the smallest possible "framework" atop Web Components that make them workable (and even enjoyable) as an application developer:

https://github.com/dchester/yhtml

It's just ~10 SLOC, admittedly dense, but which make a world of difference in terms of usability. With that in place, now you can write markup in a style not too dissimilar from React or Vue, like...

    <button @click="increment">${this.count}</button>

Whereas without, you need to bind your own events and manage your own template interpolation with sanitizing, handling conditionals, loops, and all the rest.

If we could get something in this direction adopted into the spec, it would open up a lot of use cases for Web Components that it just can't address as-is.

[no_wizard]

Template Instantiation is suppose to be the answer at least in part, but it’s been held up since 2017[0]

The bigger problem is that the web platform stakeholders (IE the committees that industry influence and the browser makers) simply didn’t listen at all to what regular developers have been saying about what they want from the web platform w/r/t better built in platform provided primitives. It’s seems to me like web components have largely not taken lessons of component based development as everyone has come to expect. It’s still a weird imperative API with no rendering or data binding primitives

[0]: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

[jongjong]

You don't need reactive data binding. You can simply watch for HTMLElement attribute changes and invoke a render method whenever that occurs. It helps to improve your app architecture if you do this. Reactive rendering can be a foot gun and often leads to unnecessary double or triple rendering. It's better to be able to control the rendering explicitly from a single binding which is exactly what HTMLElement offers; you just need to adhere to good architectural principles.

Many modern devs are too deeply involved in the React cult to see past its many over-engineered and flawed abstractions and struggle to see the simpler approach which necessitates adhering to some basic but highly beneficial architectural constraints.

[pjmlp]

Basically the problem of any design by comittee stuff.

[thayne]

Supposedly more declaritive APIs and data binding are coming eventually. But who knows how long we will have to wait for that.

[jongjong]

You don't really need all that stuff. Sanitization is straight forward to implement and only required for user generated strings (since you want to make it HTML-safe). It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects.

As for events, binding is really very easy to do and it's already localised to the component so managing them is trivial.

Loops are also trivial; you can simply use Array.prototype.map function to return a bunch of strings which you can incorporate directly into the main component's template string. In any case, you can always use the native document.createElement and appendChild functions to create elements within the component and add them to its DOM or shadow DOM.

I've built some complex apps with plain HTMLElement as a base class for all my components and found is much simpler than React without any unexpected weirdness and using fewer abstract technical concepts. Code was much more readable and maintainable. I didn't even need a bundler thanks to modern async and defer attributes of script tags among others.

I think the reason why people are using React still is just marketing, hype and inertia. The job market which is gatekept by non-technical recruiters demands React. It's all non-tech people making the big decisions based on buzzwords that they don't understand.

[rezonant]

> Sanitization is straight forward to implement

I would not say it's easy. Considering your adversaries are very motivated to do XSS and the web platform is very complicated.

> It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects.

I don't think there's a substantial performance loss from doing a type check on a value to see that it's a number, and then putting it verbatim into the output (within your sanitization code).

I don't know what "system generated content" is, and I'd argue that neither does a framework. Which means the far safer route is to assume it came from a user by default and force the dev to confirm that it's not from the user.

> Loops are also trivial; you can simply use Array.prototype.map function to return a bunch of strings which you can incorporate directly into the main component's template string

Combined with the "it's fine" mentality on data sanitization, it's concerning that we're using the term "string" in relation to building DOM nodes here. I hope we aren't talking about generating HTML as strings, combined with default-trusted application data that in most applications, does in fact come from the user, even if you might consider that user trusted (because it's Dave from Accounting, and not LeetHacker99 from Reddit).

[contr-error]

Can you share an example?

[chrsjxn]

Yeah, that's where I'm at, too. Authoring web components directly is too low level to be practical. You can easily end up reimplementing a ton of existing framework logic around rerenders, reactivity, event handlers, etc.

And there are libraries that handle all of this for you! But then you have tooling and non-standard syntax that puts you a lot closer to other JS frameworks.

And once you're in that space, the benefits of web components may or may not stack up against all the features and your team's pre-existing knowledge.

[throwaway14356]

meanwhile Im like...

   <button onclick="innerHTML++">1</button>

[jagged-chisel]

GP comment shows a simple example, sure. And obviously it’s overkill just to implement incrementing a displayed value. But trivializing the example doesn’t reduce the “framework” to being pointless.

[LudwigNagasena]

Meanwhile I’m like… That’s a Content Security Policy violation.

[breadwinner]

Web Components are very easy to write, here's an example Web Component: https://github.com/wisercoder/uibuilder/blob/master/WebCompo...

You can even use React-like templates. You need a 500-line lib to do that: https://github.com/wisercoder/uibuilder/tree/master

[WA]

Thanks for sharing. Is there a non-golfed version of this that is understandable for grugbrained devs like me?

[Xeoncross]

Thanks for sharing, we need more libraries like this. Even htmx.org is 150kb library over what was a few lines of xhr + el.innerhtml=response.result 10 years ago.

Where is the next wave of tiny libs that can make the web feel responsive again?

[sandreas]

You could use `jsx` / `tsx`. Maybe it's worth for you to look at

https://github.com/cyco/WebFun/

Example for a `tsx` component:

https://github.com/cyco/WebFun/blob/master/src/ui/components...

Pure TypeScript / scss components.

[spankalee]

That approach destroys and rebuilds the entire DOM on every render. This would not work for large compound components and apps.

[_gabe_]

I've always wondered why this notion is so popular (is it just because of what react does)? Wouldn't the native browser be expected to handle a DOM re-render much more efficiently than an entire managed JS framework running on the native browser and emulating the DOM? Maybe in 2013 browsers really really sucked at re-renders, but I have to wonder if the myriads of WebKit, Blink, Gecko developers are so inept at their jobs that a managed framework can somehow figure out what to re-render better than the native browser can.

And yes, I understand that when you program using one of these frameworks your explicitly pointing out what pieces of state will change and when, but in my professional experience, people just code whatever works and don't pay much attention to that. In the naive case, I feel like the browser would probably beat react or any other framework on re-renders every time. In the naive case where developers don't really disambiguate what state changes like they're supposed to. Are there any benchmarks or recent blogs/tech articles that dive into this?

[thayne]

My question is why don't more frameworks use it, especially the more popular ones.