5 ms·

> And also blew a huge opportunity with the APIs for web components How? I really don't understand this sentiment. The web components API is a gajillion times

> And also blew a huge opportunity with the APIs for web components How? I really don't understand this sentiment. The web components API is a gajillion times less complex to me than, for example, react. Coupled with a light weight rendering library like lit-html, a basic component takes seconds. - Make a class that inherits HTMLElement - Create a rendering template in connectedCallback using your favorite templating/rendering library. - Add class properties that call render() when they're changed. The cognitive load is a fraction of what's needed for frameworks like angular or react.

troupo 3y ago
> The web components API is a gajillion times less complex to me than, for example, react. And then you go on to list multiple complex things: - Create a rendering template in connectedCallback using your favorite templating/rendering library. So you need to bind together a connectedCallback and some rendering library - Add class properties that call render() when they're changed. So you have to manually wire class properties to manually call render. In comparison, React alreayd handles all of that for you. > The cognitive load is a fraction of what's needed for frameworks like angular or react. Since you mentioned lit-html, that "lightweight rendering library" has all the "cognitive load" of React, and is getting more complex
- claytongulick 3y ago
  > So you need to bind together a connectedCallback and some rendering library It's no different than jsx, you just get to pick whatever you want. I honestly believe that 90% of the dislike for WC comes from the name "connectedCallback". If they'd named it "onCreate" or something, everyone would be using it. It's named that because it's the lifecycle method for when a component becomes connected to the DOM, so it's technically correct - a component can be created and function without being connected to the DOM. But people really hate that name for some reason. It's all the same stuff. You have to do all the same things regardless of framework. You declare a template somewhere, you define the props that will cause a render on change, and you keep track of the internal state of the component. With React or angular or vue or whatever, you still have to do all this, you just incur the cost of a massive framework too. > So you have to manually wire class properties to manually call render. Yeah, 1 line of code. And in exchange you get to avoid a whole framework, get much better performance and have real control over your component's render cycle. Also, you still have to do this with react, it's just a different syntax. > Since you mentioned lit-html, that "lightweight rendering library" has all the "cognitive load" of React, and is getting more complex Huh? Lit-html is simpler than handlebars. Are you confusing it with LitElement?
  - troupo 3y ago
    (( I've split my reply into three parts to avoid a wall of text in a single comment. I may run into "you're posting too fast, so not all part may appear at the same time" )) Part 1. > I honestly believe that 90% of the dislike for WC comes from the name "connectedCallback". If they'd named it "onCreate" or something, everyone would be using it Of course not. None of the criticism towards Web Components ever mentions "connectedCallback", or how it should be named differently. Do you know the actual reason so few are using them? Let's skip the atrocious not-really-high-level not-really-low-level imperative API that they offer. How about: - 13 years after introduction they still need 20 more specs to try and patch just some of the holes in their original design: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html - Shadow DOM is infecting every spec so that the actual useful specs like Scoped CSS have to be delayed almost indefinitely to try and figure out how to work with this abomination of a design To quote the report linked above, "many of these pain points are directly related to Shadow DOM's encapsulation" - The amount of specs that are required to make them work, barely, and be "good web citizens". And the amount of APIs. Oh, you want your custom input to a) be able to send its data in a form, and b) be accessible to a label outside of your component? Well, there's a separate API for a) and there's some separate future API for b). And meanwhile your custom button won't be able to submit your form, sorry, it's a 4-year old issue with no solution: https://github.com/WICG/webcomponents/issues/814 https://github.com/WICG/webcomponents/issues/814 And all that despite the fact that there are already a dozen specs covering web components, and dozens more on their way. - Web Components ar HTMLElement. It means you cannot use them inside SVGs. This is impossible: <svg> <x-axis min="2000" max="2019"/> <y-axis min="0" max="100"/> <scatter-plot points="..."/> </svg> This makes them unsuitable to a huge swath of graphics- and visualisation-related applications. - A smattering of other issues: -- They cannot be easily used when progressive enhancement is required: SSR story is still non-existent, you can't easily update the original DOM in a custom element without trashing it. -- They cannot be easily lazy-loaded because slotted content is eagerly loaded: <p>Toggle the section for more info:</p> <toggled-section> <html-include src="./more-info.html"/> </toggled-section> `html-include` will load in its entirety even if you never toggle the section. And yes, this causes a cascading loading of multiple resources, too. -- they share a flat global namespace. Of course this will be solved in the next five years by a yet another spec. -------------- If any userland framework had these many issues, it would be laughed out of the room. And yet here we are with people trying to argue that they are good now actually and all that stops them from being used is "connectedCallback" name. These are also the reason why most framework authors that initially supported web components (Vue, Svelte, Solid) are now at best completely indifferent towards them.

troupo 3y ago

> The web components API is a gajillion times less complex to me than, for example, react. And then you go on to list multiple complex things: - Create a rendering template in connectedCallback using your favorite templating/rendering library. So you need to bind together a connectedCallback and some rendering library - Add class properties that call render() when they're changed. So you have to manually wire class properties to manually call render. In comparison, React alreayd handles all of that for you. > The cognitive load is a fraction of what's needed for frameworks like angular or react. Since you mentioned lit-html, that "lightweight rendering library" has all the "cognitive load" of React, and is getting more complex

claytongulick 3y ago
> So you need to bind together a connectedCallback and some rendering library It's no different than jsx, you just get to pick whatever you want. I honestly believe that 90% of the dislike for WC comes from the name "connectedCallback". If they'd named it "onCreate" or something, everyone would be using it. It's named that because it's the lifecycle method for when a component becomes connected to the DOM, so it's technically correct - a component can be created and function without being connected to the DOM. But people really hate that name for some reason. It's all the same stuff. You have to do all the same things regardless of framework. You declare a template somewhere, you define the props that will cause a render on change, and you keep track of the internal state of the component. With React or angular or vue or whatever, you still have to do all this, you just incur the cost of a massive framework too. > So you have to manually wire class properties to manually call render. Yeah, 1 line of code. And in exchange you get to avoid a whole framework, get much better performance and have real control over your component's render cycle. Also, you still have to do this with react, it's just a different syntax. > Since you mentioned lit-html, that "lightweight rendering library" has all the "cognitive load" of React, and is getting more complex Huh? Lit-html is simpler than handlebars. Are you confusing it with LitElement?
- troupo 3y ago
  (( I've split my reply into three parts to avoid a wall of text in a single comment. I may run into "you're posting too fast, so not all part may appear at the same time" )) Part 1. > I honestly believe that 90% of the dislike for WC comes from the name "connectedCallback". If they'd named it "onCreate" or something, everyone would be using it Of course not. None of the criticism towards Web Components ever mentions "connectedCallback", or how it should be named differently. Do you know the actual reason so few are using them? Let's skip the atrocious not-really-high-level not-really-low-level imperative API that they offer. How about: - 13 years after introduction they still need 20 more specs to try and patch just some of the holes in their original design: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html - Shadow DOM is infecting every spec so that the actual useful specs like Scoped CSS have to be delayed almost indefinitely to try and figure out how to work with this abomination of a design To quote the report linked above, "many of these pain points are directly related to Shadow DOM's encapsulation" - The amount of specs that are required to make them work, barely, and be "good web citizens". And the amount of APIs. Oh, you want your custom input to a) be able to send its data in a form, and b) be accessible to a label outside of your component? Well, there's a separate API for a) and there's some separate future API for b). And meanwhile your custom button won't be able to submit your form, sorry, it's a 4-year old issue with no solution: https://github.com/WICG/webcomponents/issues/814 https://github.com/WICG/webcomponents/issues/814 And all that despite the fact that there are already a dozen specs covering web components, and dozens more on their way. - Web Components ar HTMLElement. It means you cannot use them inside SVGs. This is impossible: <svg> <x-axis min="2000" max="2019"/> <y-axis min="0" max="100"/> <scatter-plot points="..."/> </svg> This makes them unsuitable to a huge swath of graphics- and visualisation-related applications. - A smattering of other issues: -- They cannot be easily used when progressive enhancement is required: SSR story is still non-existent, you can't easily update the original DOM in a custom element without trashing it. -- They cannot be easily lazy-loaded because slotted content is eagerly loaded: <p>Toggle the section for more info:</p> <toggled-section> <html-include src="./more-info.html"/> </toggled-section> `html-include` will load in its entirety even if you never toggle the section. And yes, this causes a cascading loading of multiple resources, too. -- they share a flat global namespace. Of course this will be solved in the next five years by a yet another spec. -------------- If any userland framework had these many issues, it would be laughed out of the room. And yet here we are with people trying to argue that they are good now actually and all that stops them from being used is "connectedCallback" name. These are also the reason why most framework authors that initially supported web components (Vue, Svelte, Solid) are now at best completely indifferent towards them.