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

191–200 of 235 posts

Re: The Failed Promise of Web Components

#191

Post by baybal2 »

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…

> Here's what killed web components: lack of native databinding on the web.

We have one, and it's called DOM, and XSLT to expand XML data into full fledged documents.

It's just browsermakers collectively conspired to sabotage declarative features to push their numerous JS based "bicycle reinventions."

We also had XForms, but this is an even longer story.

Re: The Failed Promise of Web Components

#192

Post by claytongulick »

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…

As somone who builds large apps via web components, I couldn't disagree more.

I'm able to compose components into higher order screens and get an enormous amount of reusability across projects.

I have a set of components, screens, etc... that I've built up over time and I can mix and match them and whip out an app extraordinarily fast.

Additionally, there are some great design systems and component libraries like Ionic built on top that make this even easier.

I can write a component for a client, and they can use it anywhere in their ecosystem, regardless of technology.

Re: The Failed Promise of Web Components

#193

Post by claytongulick »

coder543 wrote: post #10
dheera wrote: post #7

Earlier quoted context omitted.

... and it suffers from the same oversight every other web component library (polymer, mdl) suffers from: - I can't swipe left/right between the tabs - I can't pull the menu out from the left by swiping the entire page right Two of the most basic touch navigation metaphors aren't supported. To be fair, Polymer and MDL don't support the above either. But this is why HTML5 apps are still not up to par with native apps.…

> it suffers from the same oversight every other web component library (polymer, mdl) suffers from: > - I can't swipe left/right between the tabs > - I can't pull the menu out from the left by swiping the entire page right Most native apps don't do either of those two things either... at least on iOS. I can't speak to how Android apps behave these days. Maybe these are your favorite interaction modes, but it really h…

I work around it by using sms notifications.

Not ideal, but when I describe pros/cons of PWA vs App store, and the only downside is sms notifications, they have so far always been willing to make the sacrifice.

Re: The Failed Promise of Web Components

#194

Post by la_fayette »

azangru wrote: post #144
la_fayette wrote: post #88

Earlier quoted context omitted.

React is a nightmare when it comes to performance or energy efficiency... Downloading 500kb of js and processing this is just a nogo. The best advice to anyone interested in page speed, dont use this crap. https://youtu.be/plt-iH_47GE

> Downloading 500kb of js and processing this is just a nogo. React + react-dom is under 40kb minified gzipped. The other 460kb are your responsibility.

The reality shows totally different numbers https://perf-track.web.app/react

Re: The Failed Promise of Web Components

#195

Post by la_fayette »

ricksharp wrote: post #126
la_fayette wrote: post #117

Earlier quoted context omitted.

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.

That is really a great website. Why didn't you built that site with HTML?

Just check the stats here: https://perf-track.web.app/react

Re: The Failed Promise of Web Components

#196

Post by claytongulick »

sam_goody wrote: post #68

If there was a way to write JS within the component, I think that they could have taken off - just see how well components are in React, Vue et al. And to get that to happen, all you would need is the ability to refer to `this` within the component. Aside for that, treat the JS within the component as a module, ability to access global vars, but within scope. But instead, you are expected to put the relevant JS in th…

I'm not sure what you mean?

All my components are totally encapsulated, and each module is self registering.

All I have to do is import "path/some-component.js" and I can then use in any markup I want.

Re: The Failed Promise of Web Components

#197

Post by onion2k »

trufas wrote: post #85
goatlover wrote: post #71

Earlier quoted context omitted.

But why should developers have to use a framework like React to do something the browser could provide for them? Not everyone is writing a JS application. Some just need to add some custom HTML, CSS and little bit of JS.

I don't think the GP was arguing against that. If you're already committed to an existing build process building new components as web components doesn't really have many advantages vs a component built in react. It's just adding needless complexity.

Web components can be built separately to the rest of an application as standalone components and included by adding a tag, and then using them is as straightforward as using an HTML tag. You need a build process for the component (or the author of the component does..) but you don't need one for the website you're using it in. You can do that with a React component as well but you don't get the benefits of things like styled components if you do. You do with web components.

Re: The Failed Promise of Web Components

#198

Post by djstein »

earthboundkid wrote: post #157
robocat wrote: post #146

Earlier quoted context omitted.

> Many modern web UIs are on par with native apps I strongly disagree. Form/ fields are one of the areas that a native app can slaughter HTML, even if using a WebView within an app. For example, just showing the correct keyboard layout is a nightmare, and heaven help you if you need to do something slightly custom. Another example: browsers do funky shit with scrolling and zooming on input focus. Try using the best H…

> For example, just showing the correct keyboard layout is a nightmare It’s literally just an attribute on the input element?

Agree with you. Not sure what this page doesn’t cover https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

Re: The Failed Promise of Web Components

#199

Post by soperj »

ricksharp wrote: post #153
withinboredom wrote: post #143

Earlier quoted context omitted.

I’d be interested in checking out your site. I normally only have a 2G connection on my phone, I’d love to be able to read something that’s NOT HN. This site is the only site I know that takes less than 5-10 mins to load, if it loads at all.

Ok, here it is https://ricklove.me Here is a post that explains some of the content that is interesting: https://ricklove.me/cool-stuff Let me know how it does on a slow connection.

I'm quite sad that hunter2 isn't in your passwords.txt

Re: The Failed Promise of Web Components

#200

Post by tannhaeuser »

tarkin2 wrote: post #137

The death of HTML imports killed web components for me. With HTML imports, you would import a HTML file. In that file would be css, html and the js to make the component. Then you’d use HTML as usual in your main file. Finally you could create custom components easily while keeping yourself dealing primarily with HTML. Instead, you were forced to use bizarre js import systems. And at that point you were in JS land. F…

What's the point though to bake that into HTML if you need tons of JavaScript to make it happen anyway? You can just as well use the flexibility of JavaScript to build up component graphs. HTML, or rather SGML, has an established method of syntactically composing fragments using SGML entities that is well integrated into the process of editing HTML using plain text editors, not to speak of extending the vocabulary with new elements and their content models in powerful ways. Introducing elements into markup using script rather than declarative means only serves to complicate parsing, with questionable benefits.
Post reply on HN