The Failed Promise of Web Components • Hacker News Board

Re: The Failed Promise of Web Components

#121

Post by isochronous » Wed, Sep 30, 2020, 9:56 PM UTC

spankalee wrote: post #15

pfraze wrote: post #6

I completely agree with the author that WCs fail to push more behaviors into HTML. As she describes, you really want to be able to import the WC's script and then have new useful HTML tags. I use LitElement pretty extensively, which is a wrapper around WCs, and I like it quite a bit - but it's only a minor improvement in my mind compared to React, and that improvement is just reducing the abstractions from the DOM AP…

The important thing about web components is that we _can_ import the component's script and then have new useful HTML tags. You can drop this on a page and it _just works_: And this is built with LitElement. Live demo: https://jsbin.com/kicelemara/2/edit?html,output Having dependencies doesn't change the external interface to an element, or prevent it from being drop-in. Dependencies are very often good, because they…

Yes, thank you. I don't know why "they have dependencies" is a valid criticism. Literally any complex thing where the developer didn't write 100% of the code has dependencies. Most of the dependencies for the web components we use at work are... other web components, which is EXACTLY THE POINT of web components: reusability, portability, encapsulation.

I'll agree with a few of her points, but as far as this point goes, I have to wonder what components she's trying to use here. And if she wants to see the full markup of the shop demo, all she has to do is use "inspect element" on it rather than "view source."

Re: The Failed Promise of Web Components

#122

Post by Glyptodon » Wed, Sep 30, 2020, 9:57 PM UTC

jeroenhd wrote: post #61

brundolf wrote: post #20

This post is needlessly snarky, but I don't disagree with the basic premise. Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that i…

I'm a strong proponent of separation of duties on the web (style and visuals in CSS, layout in HTML, anything interactive in JS). Enabling data binding in HTML would only serve to blur those lines. With some minimal JS, you can update each web component already. Is writing nameField.innerText = response.name really that difficult? What problem does it solve to make a standard for it? As for (de)serialization, JS has…

If, as you say, css is style and visuals, layout is html, and interaction is JS, isn't there a missing data layer? I'm not sure I exactly agree with the categories you name, but I think there's very much an argument that if HTML is layout, then it isn't content or data, and the content/data (and its connection to html/JS) would then be a missing 4th piece.

Re: The Failed Promise of Web Components

#123

Post by nwienert » Wed, Sep 30, 2020, 10:04 PM UTC

isochronous wrote: post #110

nwienert wrote: post #75

Earlier quoted context omitted.

Web Components are a total mess and impossible to build anything of significance with. I can't even imagine how anyone would get anything done with them. It's like an Angular developer, an artist, and a mid-2010s neural net walked into a bar and sketched out a spec by taking shots and passing it clockwise. Separation of languages is a silly way to separate things. You're building components : logic, structure and sty…

Weird, because we're using web components at my workplace to build complex web applications. We use Lit-Element as a base class and have come up with a top-down functional state pattern for data that removes the need for two-way binding. If a sub-component needs to update its state due to DOM interaction, it just fires off an event with info about that DOM interaction, and the data store for that component (another w…

Lit-Element puts lipstick on the low level pig, but React excels in many ways beyond it. Consistency between props (vs attributes), can render server side, awesome side effect system that makes it world class at hmr.

I think WebComponents have left a horrible taste in the mouth because they came well after React and others existed, didn’t take any inspiration or provide any abstractions that would help, did basically everything worse and seemingly without any discussion with real world devs, and then were hyped and pushed on everyone for years while they basically lacked all necessary features. Now, years later they have evolved and added libraries on top to smooth over all the weirdness, and if you squint they look similar, but the web would have been a better place if they had just provided some VDOM abstractions, style containment in a simple way, and so on rather than master-planned a High Modernist dystopia and then slowly painted over it until it resembled something like the organic cities that already existed.

Re: The Failed Promise of Web Components

#124

Post by ssorallen » Wed, Sep 30, 2020, 10:05 PM UTC

domenicd wrote: post #38

ssorallen wrote: post #9

Earlier quoted context omitted.

Thanks for the link. This library unfortunately highlights further challenges with Web Components like mixing custom WCs with native form elements. To use Shoelace form elements at all, you'll end up writing a bunch of JavaScript. > Shoelace forms don't make use of action and method attributes and they don't submit the same was as native forms. To handle submission, you need to listen for the slSubmit event as shown…

This is fixable, using the form-associated custom elements feature that's specified in HTML. (Introduction: https://html.spec.whatwg.org/multipage/custom-elements.html#... ) However, that's only currently shipping in Chrome, despite the other browsers being positive on it. Similar capability gaps that we're working to close are accessibility ( https://html.spec.whatwg.org/multipage/custom-elements.html#... , same sit…

That’s great, thanks for the links.

Re: The Failed Promise of Web Components

#125

Post by nwienert » Wed, Sep 30, 2020, 10:07 PM UTC

jeroenhd wrote: post #82

nwienert wrote: post #75

Earlier quoted context omitted.

Web Components are a total mess and impossible to build anything of significance with. I can't even imagine how anyone would get anything done with them. It's like an Angular developer, an artist, and a mid-2010s neural net walked into a bar and sketched out a spec by taking shots and passing it clockwise. Separation of languages is a silly way to separate things. You're building components : logic, structure and sty…

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

Writing inline styles != rendering inline styles, look at “atomic style extraction” which with a compile step gives you far better results: automatic dead code elimination, automatic partial loading that’s tied directly to your usage, and no more jumping between the thing you’re styling and the the thing itself.

The nitpicks you have on Twitter are on specific behaviors (video and jumping and slow fetch) that have nothing to do with React. The site itself is lightweight and runs fast.

Re: The Failed Promise of Web Components

#126

Post by ricksharp » Wed, Sep 30, 2020, 10:09 PM UTC

la_fayette wrote: post #117

ricksharp wrote: post #109

Earlier quoted context omitted.

My website which is entirely built in react (and uses Gatsby). Takes 4kb to full page render (1 file - static only - JavaScript disabled). That’s smaller than most any html+css especially if using some css library. Of course once that is loaded and if JavaScript is enabled, then it will start to load interactive stuff and prefetch (which is around 100kb - but I have a lot of interactive stuff - including a zork style…

Check the time to interactive. Rehydration creates a massive cpu increase. https://developers.google.com/web/updates/2019/02/rendering-...

In lighthouse, I see a score of 100 performance and time to interactive at 1.8secs.

This is comparable to hacker news home page (which is purely static), but my first contentful paint was slightly faster (probably because my site is slightly smaller).

Both sites were about 4 times faster (TTI) than google home page and typescript home page.

Re: The Failed Promise of Web Components

#127

Post by c-smile » Wed, Sep 30, 2020, 10:18 PM UTC

sergeykish wrote: post #102

Web Components were crafted for jQuery world. $("#datepicker").datepicker() Custom elements resolves problem we had with XHR HTML response, it instantiates automatically. Problem solved. Widgets were popular and easily broken by CSS, solved by Shadow DOM.

Shadow DOM does not solve any real life problem.

sDOM is spherical horse in a vacuum, my pardon.

Re: The Failed Promise of Web Components

#128

Post by dmix » Wed, Sep 30, 2020, 10:20 PM UTC

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 just the reality of the current JS world and just how it continues to get done for practical and profressional reasons.

The dream is having small self-contained web components and can just drop in to your site (the whole whole anti-JS stuff is a whole other beast and IMO unrelated to practical shortterm goals of getting web components at the browser.

What the components end up doing is still heavily dependent on a JS component building world that was built with a framework in mind and native web component integration as a future ideal implementation system. But otherwise there is no getting away from components being tied together in a wider system with heavy JS dependencies.

Basically nothing has failed. Other than maybe React and Vue et al turned out to be more practical for the above reasons and full native web components are an afterthought. They've been sufficiently simulated where it's not a big deal.

Re: The Failed Promise of Web Components

#129

Post by ChrisMarshallNY » Wed, Sep 30, 2020, 10:26 PM UTC

yourapostasy wrote: post #25

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…

> There's often a fair bit of 'tude, where I am looked at with condescension, for not knowing something "obvious." This is a huge red flag for systems design to me. Whenever and whereever I've seen this abundance of assumed implicit knowledge instead of documented or introspectable configuration, the systems have invariably been excessively difficult and/or time-consuming to troubleshoot once in operations. This is o…

> Here's to hoping better dependency management like from the Nix folks makes it into the mainstream platforms.

Apple's SPM is off to a good start (It's the one I use). Carthage is too primitive, and CocoaPods is...CocoaPods.

Re: The Failed Promise of Web Components

#130

Post by pembrook » Wed, Sep 30, 2020, 10:39 PM UTC

systemvoltage wrote: post #43

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…

> BTW: This lady has a Masters from MIT. She def knows her way around things. I agree with all of what you said until you bought up this unnecessary credential wrapper. It leaves a bad taste - statements like this. I don't know why. Going to MIT is doesn't make you an automatic genius nor does it mean that they know their way around things. It bothers me.

> It leaves a bad taste - statements like this. I don't know why.

Probably because those statements are logical fallacies, this one specifically is known as argumentum ad verecundiam in Latin, or "an appeal to authority."

The fact that the arguer holds a prestigious title (or wears a fancy crown) cannot prove or disprove any given statement.

The inability of humans to think logically has bothered people for thousands of years, read up on Aristotle for more info.