The Failed Promise of Web Components • Hacker News Board

Re: The Failed Promise of Web Components

#171

Post by hunterloftis » Thu, Oct 01, 2020, 3:27 AM UTC

isochronous wrote: post #115

jchw wrote: post #42

Earlier quoted context omitted.

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 simp…

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…

> 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

#172

Post by divbzero » Thu, Oct 01, 2020, 3:30 AM UTC

cdata wrote: post #107

This article is tailored to attract the web components haters. IMO it does not foster a constructive thread of discussion, and some of the critique just as easily applies to the JavaScript ecosystem overall. Web components have some distance to go before they are ideal for all of their envisioned use cases. In particular, I am awaiting declarative shadow roots, declarative custom elements and template instantiation (…

> This article is tailored to attract the web components haters. IMO it does not foster a constructive thread of discussion, and some of the critique just as easily applies to the JavaScript ecosystem overall.

I think you missed reading to the very end! She concludes on a hopeful note that we can do a better job with Web Components, with a few specific proposals on what a better future could hold.

Re: The Failed Promise of Web Components

#173

Post by ricksharp » Thu, Oct 01, 2020, 3:39 AM UTC

kingdomcome50 wrote: post #160

jeroenhd wrote: post #82

Earlier quoted context omitted.

I have never used SwiftUI so I can't comment on it. However, separation of concerns doesn't need to take extra development time. Inlining all CSS and JS is like dropping the MVC model because creating all the necessary classes is taking too much time; focusing on short term gains only lead to a mediocre end result, one that nobody wants to maintain five years down the line. Good React is fine for large applications,…

I think the irony here is that MVC in its original form has largely fallen out of fashion the last few years. And it is precisely because physically separating all of the functionality into a model/view/controller files doesn't actually make development easier. This makes sense right? Logically it's all coupled, so separating the pieces, even if they are functionally responsible for different things, doesn't really p…

MVC - because spending 50% Of your time looking for the other file with the almost identical name is fun... wait now we need the view... nope back to the controller again... why can’t these files be next to each other...

It’s ironic that this is done in the name of “Separation of concerns“ -

You know what separates concerns: having everything that affects this component - in one place. That’s true separation of concerns.

I’ve worked in multiple frameworks in multiple languages and nothing does it better than modern react (especially with webhooks).

Re: The Failed Promise of Web Components

#174

Post by hunterloftis » Thu, Oct 01, 2020, 3:41 AM UTC

isochronous wrote: post #132

verisimilidude wrote: post #19

Fully agree with the author. My biggest complaint about web components is that I don’t see a lot of advantages over using React, Svelte, or some other JS library. The author hints at this: if I’m already committing to a big JS build process, why wouldn’t I reach for one of these more ergonomic JS tools? Warm fuzzies for trying to use open standards isn’t enough to convince most people to switch away from more popular…

Because then you don't have to pass a huge framework library down the wire along with all of your custom code? Look at it the other way, if you don't get a big advantage over web components by using React, Svelte, etc then why would you use them? Web components are natively supported by modern browsers. Using a fairly simple base class like Lit-Element to provide some template niceties and lifecycle hooks gives us al…

> Using a fairly simple base class like Lit-Element to provide some template niceties and lifecycle hooks gives us all the extras we need. We've figured out a really nice top-down functional state pattern for data that eliminates the need for two-way binding and requires very little "framework" level code - it's probably like 100 lines if you take out whitespace and comments.

I'm also a fan of LE, which I'm using to build my current side-project.

However, the data doesn't back up this claim. A component built with LitElement gets about 19 KB added to it when bundled:

https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...

Re: The Failed Promise of Web Components

#175

Post by divbzero » Thu, Oct 01, 2020, 3:43 AM UTC

It’s hard to tell from the comments here, but the author actually ends her article on a hopeful note and offers concrete proposals on how we could fix the shortcomings of Web Components and fulfill its promise:

– No dependencies beyond one tag

– Syntax and API in line with conventions of built-in HTML elements

– Accessible by default via ARIA

– Themeable via ::part(), selective inheritance, and custom properties

– Only one component of each type in the directory

Which proposals would be beneficial is up for debate (esp. the last one IMO) but they’re worth highlighting and discussing.

Re: The Failed Promise of Web Components

#176

Post by hunterloftis » Thu, Oct 01, 2020, 3:48 AM UTC

eterps wrote: post #116

pkukkapalli wrote: post #81

Earlier quoted context omitted.

Agree with this 100%. It's called Web Components since it's best used for writing individual components that be dropped into larger apps. I did a side project with LitElement recently, and just could not find the value add over React. That's when I realized that was never the intention anyways. I think the desire to make Web Components a React competitor also comes in part from the movement towards 100% static sites,…

My thoughts exactly. For some reason people tend to think that a web component should stand on its own from high level. But that's just not how HTML works. Something like should be seen as an anti-pattern IMO. I see web components as a compositional approach for dealing with complexity. Something else that is extremely powerful that people seem to forget is that you can add a src attribute to your web component that…

In what way does not deal with complexity through composition? It is a component, composed of other components, which in turn are composed of further components.

At what arbitrary level of complexity should we stop composing?

Re: The Failed Promise of Web Components

#177

Post by xyzzy_plugh » Thu, Oct 01, 2020, 3:59 AM UTC

tashoecraft wrote: post #64

ChrisMarshallNY wrote: post #14

I love her description of using a dependency-laden component: > Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”. Many steps are even omitted, likely because they are “obvious”. Often, you wade through the maze only to find the component doesn’t w…

This is everywhere in programming. Just trying to setup vim involved learning an insane amount of information that is scatter documented with every person recommending different ways to accomplish the same task. You feel stupid for not knowing one tiny part.

Setup vim? You literally type `vim`

You can customize it to your hearts content, but that's absolutely not necessary to use it proficiently.

Plenty of software tools work out of the box, are turnkey, etc.

Re: The Failed Promise of Web Components

#178

Post by c-smile » Thu, Oct 01, 2020, 4:00 AM UTC

cdata wrote: post #166

c-smile wrote: post #156

Earlier quoted context omitted.

> @event decorator is built upon the EventTarget In Sciter it is not. @event there is not calling Element.addEventListener but declares event handlers as static table associated with class. Essentially components are attached to DOM elements by calling Object.setPrototypeOf(element, MyComponent) - no memory allocation is happening (modulo code in componentDidMount) - very fast and lightweight. Yet, in your sample, yo…

The web components in Chrome and Edge are both implemented in the open source Chromium project. So, it is free for all to read, use and modify as they wish (in accordance with the terms of the license https://chromium.googlesource.com/chromium/src/+/master/LICE... )

Here is running campaign to Open Source Sciter: https://www.kickstarter.com/projects/c-smile/open-source-sci...

By donating there you can help to make it happen, your move?

That will be real Open Source. Edge and Chrome are not Open Source, they are users of it.

Re: The Failed Promise of Web Components

#179

Post by xmprt » Thu, Oct 01, 2020, 4:53 AM UTC

taytus wrote: post #30

dejavuagain wrote: post #24

Earlier quoted context omitted.

It's sad to see the sexism in the need to preemptively back her up.

I don't think people are "backing her up" because of sexism. I saw it more as: "She knows her shit. Dear devs, pay attention" And yes, Lea is pretty awesome.

Yup. All too often I see posts just like this from someone who self taught themselves javascript two years ago and after building a few personal projects, thinks they're an expert on it.

Re: The Failed Promise of Web Components

#180

Post by rektide » Thu, Oct 01, 2020, 4:54 AM UTC

WorldMaker wrote: post #18

rektide wrote: post #4

It would have helped a lot if JS had a working modules systems on the web. > What hope do those who can’t write JS have? Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”. JS has been in a dark & ugly spot, & WebComponents feeling janky & weird is…

caniuse statistics say that ES2015 module support has reached something like 92% of browsers: https://caniuse.com/es6-module

this deserves a good write up, because it's complicated.

it's not that hard to write a es6-module. it's pretty easy, and you can ask for it, and it'll work, behave like a ecmascript module in an ok way.

but. but if that module has other modules that it wants to pull in, the author of that module has to hardcode a bunch of assumptions about how & where that module that it depends on is. the module, in short, is not modular, because there's no way for users of that module to help it find the modules it depends on.

the best example of a work-around for this absolutely tragically-impotent pretty-much-useless es6-module system is dynamic rewrite engines like unpkg.com javascript cdn, which, on their home page mentions the ?module query parameter you can ask for. this will dynamically resolve & re-write all the dependencies of a module, to point to other unpkg.com modules. let me re-iterate: it has to re-write each module you ask for in a way where all of that module's depenencies are now also resolved unpkg modules, who themselves will also be rewritten such that their dependencies are also solved, & so on & so on, until the whole tree of modules is all rewritten to use unpkg modules. each module has to be rewritten such that there's now some kind of way to import dependencies. es6-modules provides no means to do that. each module has to resolve it's dependencies fully, ahead of time. so modules here are not actually modular: each host is left to copy, resolve, & modify the original module & make it their copy of the module, resolving dependencies however the consumer can figure out.

this is completely hosed & absolutely unbearable. modules are not modular. es6-modules are ok syntax, are ok language, but they are categorically useless on the web. it's truly tragic; es6-modules stopped while being only 33% of the way done. for what it's worth, import-maps is the only work anyone has suggested to resume progress & let modules work in any kind of inter-operable manner, & i have heard no good protest against it: i sincerely wish it would advance much much faster & be released so we can stop being stuck with terrible, unusable, non-modular modules on the web.