The Failed Promise of Web Components • Hacker News Board

Re: The Failed Promise of Web Components

#221

Post by pjmlp » Thu, Oct 01, 2020, 8:17 PM UTC

jchw wrote: post #42

brundolf wrote: post #36

Earlier quoted context omitted.

> To me, it represents a huge failure on the part of the developer community not to make publishing web components the standard The problem is that if you're writing a Vue app, and you import a web component that was written in Preact, you're now loading both Vue and Preact onto your page. That means your app will take twice as long to load. That is a huge downside to weigh against the inconvenience of having to find…

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…

Given that React is the exception in regards to WebComponents support.....

Re: The Failed Promise of Web Components

#222

Post by vitalyx » Thu, Oct 01, 2020, 11:01 PM UTC

ricksharp wrote: post #173

kingdomcome50 wrote: post #160

Earlier quoted context omitted.

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

Could you give a few examples of those languages and frameworks just to understand what you are comparing React to?

Re: The Failed Promise of Web Components

#223

Post by int_19h » Fri, Oct 02, 2020, 2:00 AM UTC

hunterloftis wrote: post #176

eterps wrote: post #116

Earlier quoted context omitted.

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?

At the level where the overhead from it exceeds the benefits of componentizing. It's a subjective judgment, sure, but that doesn't make it any less real.

In particular, if something is never going to be re-used, what's the point of componentizing it?

Re: The Failed Promise of Web Components

#224

Post by int_19h » Fri, Oct 02, 2020, 2:06 AM UTC

For the past 10 years or so, every time I read one of those articles on the state of modern web development, I'm thankful that I've dodged that bullet. Coming from the desktop world, it feels like the amount of complexity exposed to the end users of all those frameworks is quite insane compared to what they're getting from them.

Re: The Failed Promise of Web Components

#225

Post by ricksharp » Fri, Oct 02, 2020, 2:57 AM UTC

vitalyx wrote: post #222

ricksharp wrote: post #173

Earlier quoted context omitted.

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

Could you give a few examples of those languages and frameworks just to understand what you are comparing React to?

Here’s a decent list through time for JavaScript frameworks: http://todomvc.com/

For my own experience with things that were specifically MVC or MVVM:

In C#: Asp.net MVC, WPF (with/without Prism)

In Typescript: Knockout, Angular 2.0+ (I guess it wasn’t mvc really - I disliked it for other reasons)

React (with hooks) on the other hand is the embodiment of a pure Functional Programming UI.

I can literally write a component with a single import and a single function.

For every reason functional patterns beats OOP patterns, react beats mvc - and achieves true separation of concerns (feature aligned concerns).

Re: The Failed Promise of Web Components

#226

Post by hackerfromthefu » Fri, Oct 02, 2020, 5:16 AM 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.

Contrasting anecdote - the credential signalling was useful to provide context, else on JS topics it's rational to assume there is a fair to middling chance the writer really doesn't have a grasp of the wider industry body of knowledge, which quite evidently is fairly common for JS topic writers.

I value the additional factual information over removing useful information to try and avoid upsetting anyone at all. I wish more people realised how much real value is lost when everything is filtered.

Re: The Failed Promise of Web Components

#227

Post by hackerfromthefu » Fri, Oct 02, 2020, 5:22 AM UTC

ChrisMarshallNY wrote: post #134

pembrook wrote: post #130

Earlier quoted context omitted.

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

Just to set the record straight, here's why I mentioned it: I like her writing style. She writes in a pithy vernacular that belies her educational credentials. She writes like a cranky old man (takes one to know one). I think we need more writing like that, as opposed to the usual buzzword bouillabaisse that makes up a significant chunk of the tech WordSphere. When someone writes like that, it can be easy to dismiss…

Absolutely, it's time to just ignore the hecklers. They are subtracting from the value that the producers create! When the dead mass of hecklers and pc twitter twatters gets too high our civilisation will fall behind or fail because of it. Healing the pc overgrowth crisis is becoming important for our future prosperity and possibly survival.

Re: The Failed Promise of Web Components

#228

Post by lootsauce » Fri, Oct 02, 2020, 7:28 AM UTC

nwienert wrote: post #123

isochronous wrote: post #110

Earlier quoted context omitted.

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…

Yes, every word

Re: The Failed Promise of Web Components

#229

Post by hackerfromthefu » Fri, Oct 02, 2020, 8:13 AM UTC

int_19h wrote: post #223

hunterloftis wrote: post #176

Earlier quoted context omitted.

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?

At the level where the overhead from it exceeds the benefits of componentizing. It's a subjective judgment, sure, but that doesn't make it any less real. In particular, if something is never going to be re-used, what's the point of componentizing it?

In some contexts, decomposition into easily workable scope of complexity.

Re: The Failed Promise of Web Components

#230

Post by hackerfromthefu » Fri, Oct 02, 2020, 9:00 AM UTC

dheera wrote: post #48

coder543 wrote: post #40

Earlier quoted context omitted.

My hot take: hamburger menus are a really bad UX paradigm in almost all cases, and bottom tab bars are much better. So, I disagree entirely: iOS can easily support fantastic HTML5 mobile apps... if push notifications ever become available. From what I remember, Google started switching to bottom tab bars a couple of years ago, even on Android. But, when you have a bunch of features, it's much easier on the developer…

Side note -- I do wish iOS would get ahead with Bluetooth and WebRTC support, both of which I use heavily on my (private) HTML5 apps. Push notifications would be necessary for a complete feature set too, although I don't really use them for my private apps since I disable almost all push notifications on my phone.

Its clear Apple wants to force people to native apps where they can extort, err charge, 30% (of the revenue, much larger share of the profit).

So these features almost certainly won't be delivered, in a working state, until they are irrelevant to making useful apps which could move money out of the ios appstore.