3 ms·

The point is that browsers will do a lot of work that JavaScript frameworks might need to do now, enabling framework developers to make their frameworks simpler

The point is that browsers will do a lot of work that JavaScript frameworks might need to do now, enabling framework developers to make their frameworks simpler, and their execution faster.

troupo 2y ago
And yet, very few frameworks use them as their foundation because they don't actually do any of the work that frameworks/libraries actually do, and introduce a ton of issues (some of them unresolvable).
- gitaarik 2y ago
  Well, because of the true encapsulation, which solves real problems when looking at a global web level which you should do if you make a browser wide component framework, it becomes harder to do things that are simple if you have a global DOM like in the traditional component frameworks. So a new way of dealing with certain problems is required, which requires a mindset change. For most developers it doesn't add value right away to break out of their framework cage and share their components with each other. But eventually we will all benefit from web components because they will work in any environment without them ever breaking. You won't be able to say that about traditional framework components.
  - troupo 2y ago
    > So a new way of dealing with certain problems is required, which requires a mindset change. It's not a new way (components is not a new idea), and no, it doesn't require a mindset change (again, components are not a new idea). Web Components have so many issues that they are nearly useless to frameworks, and Shadow DOM is the cause of many of those issues. > For most developers it doesn't add value right away to break out of their framework cage and share their components with each other. Ability to share components has nothing to do with suitability of web components for frameworks/libs. > But eventually we will all benefit from web components because they will work in any environment without them ever breaking. Except they are breaking a11y, selections, forms; they can't be lazily rendered; they cause waterfall HTTP requests; they... Well, they literally need 20 more web standards (on top of a dozen or so existing ones) to fix issues that no frameworks have, and many of which exist only because of web components themselves: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html The only useful web spec that may come out of this slow moving train wreck is DOM Parts which enables batched updates to the DOM. And even then it depends on how blind the spec authors are to the actual needs of developers. And up until 2022 they weren't just blind, they were intentionally and militantly blind.
    - gitaarik 2y ago
      You know I think you have interesting arguments, but at the same time I feel like somehow you are just very anti web components, and want to break them down. I understand you're issues with it, but I also think that implementing web standards is a different thing from a framework, in the sense that you shouldn't break current standards. I believe the committees of the creation of the standards spend a lot of time to come to consensuses. That is not easy with the web today. So these standards evolve very slowly and take many iterations to become mainstream in a world that is already used to the common frameworks. And I think that for most new projects it's still a sensible choice to go for the common frameworks. But at the same time I also feel like we should be engaged in a positive way with making certain patterns more integrated with the browser, so that the web basically becomes more native. And that can be implemented as a new possibility alongside the common frameworks. And those frameworks can even adapt to it. You seem to know a lot about and be very engaged with this subject. Maybe instead of breaking it down you could help make it better? I'm personally not involved with the web component development, but I find their ideas interesting and worthwhile exploring. Web standards evolve slow but stay long. It's good to know what's coming.
      - troupo 2y ago
        > You know I think you have interesting arguments, but at the same time I feel like somehow you are just very anti web components Yes, I am, hence the arguments. I'm not the only one against them. There are multiple reasons why even the people who originally modeled their frameworks after web components and were very pro-web components are not at best completely indifferent towards them: Svelte, Vue, Solid JS. > I understand you're issues with it, but I also think that implementing web standards is a different thing from a framework Yes, yes, it is a very different thing, and that's why you should be very careful when implementing anything, and listen to people who have to deal with these standards. People working on these standards would ignore, berate, denigrate and gaslight anyone who would point out glaring and obvious issues with the design of web components. They would throw more and more standards at the problem trying to patch holes that were caused by the design of web components. In 2022 they finally relented, sat down and wrote what more is needed to bring web components barely on par with existing userland solutions. And admitted that many of the issues that still need to be solved are the direct result of their design. > But at the same time I also feel like we should be engaged in a positive way with making certain patterns more integrated with the browser People have tried to do that. As I say, they were ignored, belittled and gaslighted. The people who were the most vocal proponents are now at best indifferent and will not touch web components with a 10-mile stick.

The point is that browsers will do a lot of work that JavaScript frameworks might need to do now, enabling framework developers to make their frameworks simpler, and their execution faster.

troupo 2y ago

And yet, very few frameworks use them as their foundation because they don't actually do any of the work that frameworks/libraries actually do, and introduce a ton of issues (some of them unresolvable).

gitaarik 2y ago
Well, because of the true encapsulation, which solves real problems when looking at a global web level which you should do if you make a browser wide component framework, it becomes harder to do things that are simple if you have a global DOM like in the traditional component frameworks. So a new way of dealing with certain problems is required, which requires a mindset change. For most developers it doesn't add value right away to break out of their framework cage and share their components with each other. But eventually we will all benefit from web components because they will work in any environment without them ever breaking. You won't be able to say that about traditional framework components.
- troupo 2y ago
  > So a new way of dealing with certain problems is required, which requires a mindset change. It's not a new way (components is not a new idea), and no, it doesn't require a mindset change (again, components are not a new idea). Web Components have so many issues that they are nearly useless to frameworks, and Shadow DOM is the cause of many of those issues. > For most developers it doesn't add value right away to break out of their framework cage and share their components with each other. Ability to share components has nothing to do with suitability of web components for frameworks/libs. > But eventually we will all benefit from web components because they will work in any environment without them ever breaking. Except they are breaking a11y, selections, forms; they can't be lazily rendered; they cause waterfall HTTP requests; they... Well, they literally need 20 more web standards (on top of a dozen or so existing ones) to fix issues that no frameworks have, and many of which exist only because of web components themselves: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html The only useful web spec that may come out of this slow moving train wreck is DOM Parts which enables batched updates to the DOM. And even then it depends on how blind the spec authors are to the actual needs of developers. And up until 2022 they weren't just blind, they were intentionally and militantly blind.
  - gitaarik 2y ago
    You know I think you have interesting arguments, but at the same time I feel like somehow you are just very anti web components, and want to break them down. I understand you're issues with it, but I also think that implementing web standards is a different thing from a framework, in the sense that you shouldn't break current standards. I believe the committees of the creation of the standards spend a lot of time to come to consensuses. That is not easy with the web today. So these standards evolve very slowly and take many iterations to become mainstream in a world that is already used to the common frameworks. And I think that for most new projects it's still a sensible choice to go for the common frameworks. But at the same time I also feel like we should be engaged in a positive way with making certain patterns more integrated with the browser, so that the web basically becomes more native. And that can be implemented as a new possibility alongside the common frameworks. And those frameworks can even adapt to it. You seem to know a lot about and be very engaged with this subject. Maybe instead of breaking it down you could help make it better? I'm personally not involved with the web component development, but I find their ideas interesting and worthwhile exploring. Web standards evolve slow but stay long. It's good to know what's coming.
    - troupo 2y ago
      > You know I think you have interesting arguments, but at the same time I feel like somehow you are just very anti web components Yes, I am, hence the arguments. I'm not the only one against them. There are multiple reasons why even the people who originally modeled their frameworks after web components and were very pro-web components are not at best completely indifferent towards them: Svelte, Vue, Solid JS. > I understand you're issues with it, but I also think that implementing web standards is a different thing from a framework Yes, yes, it is a very different thing, and that's why you should be very careful when implementing anything, and listen to people who have to deal with these standards. People working on these standards would ignore, berate, denigrate and gaslight anyone who would point out glaring and obvious issues with the design of web components. They would throw more and more standards at the problem trying to patch holes that were caused by the design of web components. In 2022 they finally relented, sat down and wrote what more is needed to bring web components barely on par with existing userland solutions. And admitted that many of the issues that still need to be solved are the direct result of their design. > But at the same time I also feel like we should be engaged in a positive way with making certain patterns more integrated with the browser People have tried to do that. As I say, they were ignored, belittled and gaslighted. The people who were the most vocal proponents are now at best indifferent and will not touch web components with a 10-mile stick.