←back to thread

218 points mdhb | 1 comments | | HN request time: 0s | source
Show context
jlukic ◴[] No.44393980[source]
It’s worth noting this was written by maybe the person with the most experience in the space i can think of—-the primary author of Lit / Polymer working at web components on Google and contributing on many core DOM specs that have become part of the web platform.
replies(1): >>44394620 #
troupo ◴[] No.44394620[source]
> It’s worth noting this was written by

by one of the people wrecklessly barging forward with half-baked specs that introduced significantly more problems than they solved, pushed a "solution" that requires 20+ new web specs to barely do all the things user-space is already doing while completely ignoring and gaslighting anyone who wasn't 100% on board with what they were doing.

Safari argued that there should be a declarative ways for this 15 years ago

replies(3): >>44395627 #>>44396018 #>>44402550 #
JimDabell ◴[] No.44395627[source]
Web components were such a big disappointment. 200% the complexity for 20% of the functionality. Everything coming out of that area seems to be hideously over-engineered while failing to solve the problems people wanted them to.

My feeling is that they were focused on designing something that is aimed at building form controls, not the kinds of components web developers use in practice. They are designed to make browser vendors’ lives easier, not web developers. That’s often excused with “web components excel at ‘leaf‘ components” when what is actually meant is “web components are bad at everything else”.

I would expect an actually good solution that fits in with the web’s architecture to come from the direction of HTMX, not web components.

> Safari argued that there should be a declarative ways for this 15 years ago

True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).

replies(3): >>44395735 #>>44402549 #>>44403481 #
_benton ◴[] No.44402549[source]
Im not sure what you're referring to, they seem pretty straightforward to me. Create a class that extends HTMLElement, implement stuff in connectedCallback and attributeChangedCallback. Return a list of attributes in static observedAttributes. Or use some extended class if you want, there are plenty and they're easy to create your own.
replies(2): >>44403506 #>>44405353 #
troupo ◴[] No.44403506[source]
You mean other than the 20+ web specs they added to platform (often to "fix" problems that they themselves introduced and/or that no one else has)? https://w3c.github.io/webcomponents-cg/2022.html (this list appeared after half a dozen or more specs had already been rammed through)

Or that their mere existence infects nearly every spec in existence delaying and needlessly complicating actual useful specs like Scoped CSS?

replies(1): >>44403677 #
_benton ◴[] No.44403677[source]
I don't think it's surprising that a feature like web components would require new specs, isn't that how standard web features work?
replies(1): >>44408419 #
1. troupo ◴[] No.44408419[source]
Usually a new feature:

- doesn't require 20+ web specs

- doesn't forget and then scramble to fix the most basic expected functionality like form participation

- doesn't pollute the space so badly that actual useful specs like Scoped CSS are delayed for years because now they have to deal with all the web coponent shenanigans

- hopefully doesn't take 15 years to barely do what others have been doing since time immemorial