4 ms·

In 18 years I have never once actually used a Web Component. What is the point?

by dbbk 2y ago

dylanjha 2y ago
Not everyone has to use everything. In my 13 years there are a lot of technologies I've never used. Maybe there was opportunities where you could have, or maybe things are working just fine for the problems you're solving and you don't need it, which is fine too.
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]
barkbyte 2y ago
They didn’t exist for the first 8 of those years and didn’t have real support until even later so…
mickael-kerjean 2y ago
The example I see all the time is creating design systems and dumb components but the major benefit is its a standard that work everywhere and isn't tied around a particular framework (hem react).
gitaarik 2y ago
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.

In 18 years I have never once actually used a Web Component. What is the point?

by dbbk 2y ago

In 18 years I have never once actually used a Web Component. What is the point?

Not everyone has to use everything. In my 13 years there are a lot of technologies I've never used. Maybe there was opportunities where you could have, or maybe things are working just fine for the problems you're solving and you don't need it, which is fine too.

deleted 2y ago
[deleted]

deleted 2y ago

[deleted]

barkbyte 2y ago

They didn’t exist for the first 8 of those years and didn’t have real support until even later so…

mickael-kerjean 2y ago

The example I see all the time is creating design systems and dumb components but the major benefit is its a standard that work everywhere and isn't tied around a particular framework (hem react).

gitaarik 2y ago

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.