Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Failed Promise of Web Components

lea.verou.me

Post reply on HN
Print view View original

41–50 of 235 posts

Re: The Failed Promise of Web Components

#41

Post by spankalee »

brundolf wrote: post #36
gavinray wrote: post #27

Earlier quoted context omitted.

To be frank, I think in large part this is due to React. I'm not an authority in this area, but I seem to recall that because React uses a synthetic event system, it won't interoperate with Web Component bindings and emitted events. (I know React doesn't work well with Webcomponents, the part I'm unsure of is whether it's specifically due to this). React also doesn't have an easy means of turning React components int…

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

> That means your app will take twice as long to load

Preact is like 3k minzipped. Just loading it will not make your app take twice as long to load.

Re: The Failed Promise of Web Components

#42

Post by jchw »

brundolf wrote: post #36
gavinray wrote: post #27

Earlier quoted context omitted.

To be frank, I think in large part this is due to React. I'm not an authority in this area, but I seem to recall that because React uses a synthetic event system, it won't interoperate with Web Component bindings and emitted events. (I know React doesn't work well with Webcomponents, the part I'm unsure of is whether it's specifically due to this). React also doesn't have an easy means of turning React components int…

> 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 simply the wrong abstraction layer to be extending on.

Re: The Failed Promise of Web Components

#43

Post by systemvoltage »

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.

Re: The Failed Promise of Web Components

#44

Post by ChrisMarshallNY »

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.

Cool. I'll remove it. Not necessary for the narrative.

Re: The Failed Promise of Web Components

#45

Post by brundolf »

spankalee wrote: post #41
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…

> That means your app will take twice as long to load Preact is like 3k minzipped. Just loading it will not make your app take twice as long to load.

Preact is one of the very smallest frameworks. A full-fledged Vue bundle is ten times that size, and Angular is another 2x Vue's size. When I said "twice as long" I meant on average: taking some framework X and adding another framework Y.

Re: The Failed Promise of Web Components

#46

Post by ChrisMarshallNY »

dejavuagain wrote: post #24
lazyjeff wrote: post #21

Earlier quoted context omitted.

> BTW: This lady has a Masters from MIT. She def knows her way around things. Moreso than that, Lea is near the end of a Ph.D. in David Karger's group, an expert on CSS, and overall amazing researcher and developer for the web.

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

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

You have GOT to be kidding me. Tell me that this was a joke.

Re: The Failed Promise of Web Components

#47

Post by elcritch »

spankalee wrote: post #17
elcritch wrote: post #8

Earlier quoted context omitted.

Another "big issue" (for me as I develop first on FF) is that Firefox developers refused to implement HTML import. That'd simplify much of using web-components. I include it and the browser can automatically use HTTP2 to load all the components quickly. It'd be interesting to see how much web-components could be pushed using only CSS via things like the "space toggle" trick ( https://github.com/propjockey/css-sweeper…

The JS module system is actually better suited for this. And ultimately HTML imports don't solve any of the cross-package import issues that JS modules are still trying to solve.

Perhaps, but as a web developer html imports let me pull in and use web-components without writing any Javascript. Give an HTML editor to a 15 year old, some links to a decent web-component library and they're off to the races without mastering JS.

Re: The Failed Promise of Web Components

#48

Post by dheera »

coder543 wrote: post #40
dheera wrote: post #37

Earlier quoted context omitted.

> Pulling a menu out from the left certainly cannot be implemented on iOS Safari Mobile Well HTML5 apps will never be a good experience on iOS then. On Android you can do almost anything UI-wise with Chrome, which paves the way to HTML5 installable apps.

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.

Re: The Failed Promise of Web Components

#49

Post by brundolf »

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…

> 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

#50

Post by coder543 »

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.

https://caniuse.com/?search=webrtc

I think WebRTC is supported on iOS? Maybe it's missing some important features? I'm not personally familiar with what's going on there.

Web Bluetooth doesn't seem to be going anywhere fast, for better or worse.

Post reply on HN