Earlier quoted context omitted.
Asking sincerely because this take is surprising to me: which specs are you referring to? From my perspective—started front end, gradually went full stack, spent several years fully back end, dove back in a couple years ago—quite a lot of the APIs introduced in the period I was fully back end (and since) are excellent and vastly improve both development experience and the ability to deliver a better user experience.…
> Asking sincerely because this take is surprising to me: which specs are you referring to? I'd like to see the Web Components spec revisited: it has a) no API for passing non-string attributes to other web components, b) no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them. Without these, the raw web compon…
First, I agree both of these limitations make the spec less directly useful than a framework, and more likely to be APIs targeted by a framework (however formal or bespoke). That said, that’s pretty much the guiding design philosophy behind nearly all DOM APIs, and it doesn’t seem to me that makes anything worse, just incomplete. I suspect that richer APIs would make things worse. People would still use frameworks, but those frameworks would have to use much more opinionated and much less flexible APIs at a higher level of abstraction. All of that said,
> no API for passing non-string attributes to other web components
This is really a limit of HTML, and not new. But there’s plenty of precedent for raw string attributes to have a more meaningful representation in the DOM state. An area of the spec that seems really well suited to accommodate this is `part`[1]. Like `classList`, it’s a `DOMTokenList`, and has a corresponding CSS selector. It’s a string attribute, but it’s also structured data as a property. I have a long list of things I’m confident will benefit from this.
> no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them.
This really is a footgun, but I’m not sure what the appropriate alternative is. I don’t think any spec could accommodate the fact that people choose different declarative implementations for very different use cases, without essentially defining high level interfaces that expect to be overridden. Even then, those interfaces would almost certainly be ill-suited to some specialization or another. If your goal was purely creation, I’d agree that there should be a declarative API. But for updates? I can’t imagine a design which wouldn't be worse.
> Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework.
I don’t think the goal of any of these APIs should be to replace frameworks. At that point you’re just using a framework forever. It’s an enormous credit to the design behind all of these APIs and their overlapping specs that they continue to produce useful lower-level interfaces without overly steering the ship.
1: https://developer.mozilla.org/en-US/docs/Web/API/Element/par...