7 ms·

Web components are a half-baked solution. It only becomes useful with another framework (even if it's very lightweight) like lit. At which point I might as well

Web components are a half-baked solution. It only becomes useful with another framework (even if it's very lightweight) like lit. At which point I might as well use vue/react/svelte since I am already brining in a library. Tech like preact is really lightweight as well, and given the popularity of react, is enough to offset any benefits web components have. I would really like it if we reached a point where a web project only had a single dependency that's a bundler like vite that you point to an index file, and that's it.

OJFord 3y ago
I think we're going in the opposite direction though - everyone wants to hide what's going on and use some magic CLI that just takes care of everything for you, don't worry about how or when or what to do if it goes wrong, just run `flyctl deploy`, `wrangler publish` (Cloudflare), `npx wizzle wazzle` :sparkles: :tada: never `git commit -m '(chore): [...]'` again! Oh and here's a readme example of how to set that up if you're using pnpm v42 with sveltekit v2 and webpack v99. For any other combination of the 5 packagers, 19 bundlers, and 56 frameworks commonly in use and giving examples like this recommending each other - have fun.
reidjs 3y ago
I use them for a basic website (no build step) for things like navigation components and page templates. They are great for that, but not much else in my experience. Once you have a complex UI or multiple devs on a project it’s probably better to just use a full framework
codegeek 3y ago
"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 ---

OJFord 3y ago

I think we're going in the opposite direction though - everyone wants to hide what's going on and use some magic CLI that just takes care of everything for you, don't worry about how or when or what to do if it goes wrong, just run `flyctl deploy`, `wrangler publish` (Cloudflare), `npx wizzle wazzle` :sparkles: :tada: never `git commit -m '(chore): [...]'` again! Oh and here's a readme example of how to set that up if you're using pnpm v42 with sveltekit v2 and webpack v99. For any other combination of the 5 packagers, 19 bundlers, and 56 frameworks commonly in use and giving examples like this recommending each other - have fun.

reidjs 3y ago

I use them for a basic website (no build step) for things like navigation components and page templates. They are great for that, but not much else in my experience. Once you have a complex UI or multiple devs on a project it’s probably better to just use a full framework

codegeek 3y ago

"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 ---