News for hackers. Stuff that matters.
Re:The Failed Promise of Web Components by jchw on Wednesday September 30, 2020 @02:47PM (#24642185)
The webcomponents supporters seem hell bent on placing the blame somewhere other than webcomponents themselves. In the “truckload of dependencies” they fail to ask why those dependencies are really there, and in that required JS they fail to ask why its really needed. The webcomponents model isn’t just broken, its thoroughly broken, and I actually hold the opinion that it was never even a good idea, because it’s simply the wrong abstraction layer to be extending on.
Re:The Failed Promise of Web Components by brundolf on Wednesday September 30, 2020 @02:54PM (#24642292)
> In the “truckload of dependencies” they fail to ask why those dependencies are really there, and in that required JS they fail to ask why its really needed

Yes, this is what I meant when I said the post is too snarky, but I don't think it's fair to take that as representative of all "webcomponents supporters". That JS exists to fill a gap left by the platform, and it's a gap that should be filled by the platform, but it's also a gap that isn't filled by the platform.

> I actually hold the opinion that it was never even a good idea, because it’s simply the wrong abstraction layer to be extending on

I disagree. HTML is a profoundly intuitive and accessible standard which reaches far outside the normal bounds of software developers. This is evidenced by the thriving diversity the web has experienced (before everything moved to closed platforms, that is). For static content it already provides an exceptional balance between expressiveness and accessibility, and the dream of web components was to bring that over to apps as well. And I really do think that idea is still a good one.

Re:The Failed Promise of Web Components by isochronous on Wednesday September 30, 2020 @05:28PM (#24644116)
I mean, we're using web components to build large web apps at my workplace, and in my experience 95% of the dependencies of web components are... other web components. Which makes sense for anything more complex than a simple button. The whole point of web components is to create portable, reusable code that can be encapsulated within an HTML tag, so if I'm writing an app that needs buttons, inputs, date pickers, etc, obviously I'm going to import components for those things where native controls don't meet my needs. I don't understand why "it has dependencies" is a valid criticism.
Re:The Failed Promise of Web Components by hunterloftis on Wednesday September 30, 2020 @11:27PM (#24647018)
> in my experience 95% of the dependencies of web components are... other web components

Sure, and in a single project at a single company that's probably fine. You've all agreed to standardize on a single version of Lit-Element and compile the whole project at once, so no worries.

But if the goal is to make Web Components standard units of UI across the web, such that you can grab a `color-picker` component and a `webcam-video` component and put them together into your `video-color-filter` component... well, if color-picker depends on vue and webcam-video depends on lit and you write video-color-filter in LWC, your project now depends on three web component libraries.

Re:The Failed Promise of Web Components by pjmlp on Thursday October 01, 2020 @04:17PM (#24655733)
Given that React is the exception in regards to WebComponents support.....