5 ms·

"half-baked solution" Can you elaborate further ? Anything that removes dependencies from external libraries is a huge plus for me so I am curious as someone w

"half-baked solution" Can you elaborate further ? Anything that removes dependencies from external libraries is a huge plus for me so I am curious as someone who is not great at JS.

troupo 3y ago
> Can you elaborate further ? As you read the following, keep in mind that at this time Web Components have been in development for almost 12 years. The core is just three standards, CustomElements, Shadow DOM and HTML Imports (already deprecated and removed in favor of JS-only imports). And people will go out of hteir way to sell you the idea that this is lightweight, all that you need etc. However. They've already spawned half a dozen new web standards just to deal with issues they inflicted on themselves. None of these issues are present in any other solution/lib/framework that exists. These range from the fact that web components cannot participate in forms (fixed with a new spec: https://web.dev/articles/more-capable-form-controls https://web.dev/articles/more-capable-form-controls) to their inability to share stylesheets (fixed with a new spec: https://web.dev/articles/constructable-stylesheets https://web.dev/articles/constructable-stylesheets) to whatever else (hard to keep track). They will need at least 20 more new web standards to fix other issues that, once again, are not a problem for literally every other framework, library, or hand-written code under the sun: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html. Among my favorite ones: a web component button cannot be a submit button in a form; you cannot reference an id inside a shadow root, and that breaks ARIA. To call them half-baked is an understatement. They are badly thought-out, badly implemented APIs with no forethought or visible planning, and literally no end goal in sight. The people building this met to hash out what more is needed for them to be complete only last year, 11 years into development. All development before that looked like ad-hoc patches by people surprised that a yet another thing doesn't work, but is sorely needed.
- gitaarik 3y ago
  I think you are trying to impose a React workflow on Web Components. Some things that work in React indeed don't work in Web Components / Lit, but that is usually for good reasons. There are a lot of quirks with React too, for example I find it very cumbersome the way you reference elements in React. That's a lot nicer with Lit. But in Lit, input fields can't communicate to a form in a different Shadow DOM. In React you have your ways of dealing with it, in Lit also. Overall I think Lit is generally a lot cleaner than React, feels more native, less opinionated. That's logical of course because Lit is made to work with modern Web Component APIs, and React already existed before these technologies, so they had to implement those features into React itself.
  - troupo 3y ago
    Literally none of the issues I listed have to anything with React. > But in Lit, input fields can't communicate to a form in a different Shadow DOM Indeed. They break the most basic functionality that exists in the browser. This issue doesn't exist in anything else. And they need a separate new web spec to barely fix it. Does it have to do anything with React? No. > That's logical of course because Lit is made to work with modern Web Component APIs Yup, so modern that they creak basic browser functionality and need 20+ new web specs to fix issues that don't exist in literally anything else.
    - gitaarik 3y ago
      They don't break semantics, input fields work just fine within a single Shadow DOM. You have to understand that a different library has a different workflow. If you addopt the correct workflow, you won't have any of the issues you're having. But it takes some time to learn something new.
      - troupo 3y ago
        > They don't break semantics, input fields work just fine within a single Shadow DOM. Yes, yes they do break semantics. 1. If you just put the input in a web component, it will not appear in the form. You have to manually add it. https://web.dev/articles/more-capable-form-controls https://web.dev/articles/more-capable-form-controls 2. If you have an input in Shadow DOM, it cannot be referenced with a label from outside that shadow DOM. That breaks ARIA, and will be fixed god knows when with a new cross-root ARIA spec. This has nothing to do with libraries, or React, or whatever you imagine. These are basic browser behaviours that everyone expects to work out of the box, and they are broken. > that a different library has a different workflow. This has nothing to do with libraries. This is basic browser functionality. > If you addopt the correct workflow, you won't have any of the issues you're having. No "correct workflow" can cover the fact that these behaviours are broken, and need 20+ new specifications to fix. There's no correct workflow that will make cross-shadow ARIA work. There's no correct workflow that will make a custom component participate in forms if the author didn't add that functionality. There's no correct workflow that will make your custom button be able to work as a submit button. And so on, and so on, and so on, and so on. Edit. Note: if you took the time to actually read the report from people who shove webcomponents into the browser, you will see that even they admit how much of an issue all this is, and it has nothing to do with React or libraries, and everything to do with self-inflicted wounds by a badly thought-out design: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html (emphasis mine). Note how none of these are issues for anything built for the browser. These are issues only for the half-baked, badly-designed web components. --- start quote --- This document tries to highlight the main features that are lacking from the web components spec that either block adoption for more developers and frameworks, or cause pain points for existing developers. It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM. ... Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patterns outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. ... The form-associated APIs currently have no way for a developer to behave as a custom submit button. It is currently unclear how form-associated custom elements should participate in the autocomplete lifecycle despite there being an API for that purpose. ... Many web components could be implemented without JavaScript, taking advantage of encapsulated DOM and styles. However, web components cannot currently be rendered by users who have JavaScript disabled. ... ad infinitum ... --- end quote ---

"half-baked solution" Can you elaborate further ? Anything that removes dependencies from external libraries is a huge plus for me so I am curious as someone who is not great at JS.

troupo 3y ago

> Can you elaborate further ? As you read the following, keep in mind that at this time Web Components have been in development for almost 12 years. The core is just three standards, CustomElements, Shadow DOM and HTML Imports (already deprecated and removed in favor of JS-only imports). And people will go out of hteir way to sell you the idea that this is lightweight, all that you need etc. However. They've already spawned half a dozen new web standards just to deal with issues they inflicted on themselves. None of these issues are present in any other solution/lib/framework that exists. These range from the fact that web components cannot participate in forms (fixed with a new spec: https://web.dev/articles/more-capable-form-controls https://web.dev/articles/more-capable-form-controls) to their inability to share stylesheets (fixed with a new spec: https://web.dev/articles/constructable-stylesheets https://web.dev/articles/constructable-stylesheets) to whatever else (hard to keep track). They will need at least 20 more new web standards to fix other issues that, once again, are not a problem for literally every other framework, library, or hand-written code under the sun: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html. Among my favorite ones: a web component button cannot be a submit button in a form; you cannot reference an id inside a shadow root, and that breaks ARIA. To call them half-baked is an understatement. They are badly thought-out, badly implemented APIs with no forethought or visible planning, and literally no end goal in sight. The people building this met to hash out what more is needed for them to be complete only last year, 11 years into development. All development before that looked like ad-hoc patches by people surprised that a yet another thing doesn't work, but is sorely needed.

gitaarik 3y ago
I think you are trying to impose a React workflow on Web Components. Some things that work in React indeed don't work in Web Components / Lit, but that is usually for good reasons. There are a lot of quirks with React too, for example I find it very cumbersome the way you reference elements in React. That's a lot nicer with Lit. But in Lit, input fields can't communicate to a form in a different Shadow DOM. In React you have your ways of dealing with it, in Lit also. Overall I think Lit is generally a lot cleaner than React, feels more native, less opinionated. That's logical of course because Lit is made to work with modern Web Component APIs, and React already existed before these technologies, so they had to implement those features into React itself.
- troupo 3y ago
  Literally none of the issues I listed have to anything with React. > But in Lit, input fields can't communicate to a form in a different Shadow DOM Indeed. They break the most basic functionality that exists in the browser. This issue doesn't exist in anything else. And they need a separate new web spec to barely fix it. Does it have to do anything with React? No. > That's logical of course because Lit is made to work with modern Web Component APIs Yup, so modern that they creak basic browser functionality and need 20+ new web specs to fix issues that don't exist in literally anything else.
  - gitaarik 3y ago
    They don't break semantics, input fields work just fine within a single Shadow DOM. You have to understand that a different library has a different workflow. If you addopt the correct workflow, you won't have any of the issues you're having. But it takes some time to learn something new.
    - troupo 3y ago
      > They don't break semantics, input fields work just fine within a single Shadow DOM. Yes, yes they do break semantics. 1. If you just put the input in a web component, it will not appear in the form. You have to manually add it. https://web.dev/articles/more-capable-form-controls https://web.dev/articles/more-capable-form-controls 2. If you have an input in Shadow DOM, it cannot be referenced with a label from outside that shadow DOM. That breaks ARIA, and will be fixed god knows when with a new cross-root ARIA spec. This has nothing to do with libraries, or React, or whatever you imagine. These are basic browser behaviours that everyone expects to work out of the box, and they are broken. > that a different library has a different workflow. This has nothing to do with libraries. This is basic browser functionality. > If you addopt the correct workflow, you won't have any of the issues you're having. No "correct workflow" can cover the fact that these behaviours are broken, and need 20+ new specifications to fix. There's no correct workflow that will make cross-shadow ARIA work. There's no correct workflow that will make a custom component participate in forms if the author didn't add that functionality. There's no correct workflow that will make your custom button be able to work as a submit button. And so on, and so on, and so on, and so on. Edit. Note: if you took the time to actually read the report from people who shove webcomponents into the browser, you will see that even they admit how much of an issue all this is, and it has nothing to do with React or libraries, and everything to do with self-inflicted wounds by a badly thought-out design: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html (emphasis mine). Note how none of these are issues for anything built for the browser. These are issues only for the half-baked, badly-designed web components. --- start quote --- This document tries to highlight the main features that are lacking from the web components spec that either block adoption for more developers and frameworks, or cause pain points for existing developers. It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM. ... Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patterns outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. ... The form-associated APIs currently have no way for a developer to behave as a custom submit button. It is currently unclear how form-associated custom elements should participate in the autocomplete lifecycle despite there being an API for that purpose. ... Many web components could be implemented without JavaScript, taking advantage of encapsulated DOM and styles. However, web components cannot currently be rendered by users who have JavaScript disabled. ... ad infinitum ... --- end quote ---