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

HTML with Superpowers: An Introduction to Web Components

htmlwithsuperpowers.netlify.app

Post reply on HN
Print view View original

101–110 of 130 posts

Re: HTML with Superpowers: An Introduction to Web Components

#101

Post by logankeenan »

esprehn wrote: post #32
logankeenan wrote: post #13

I evaluated web components a few months ago. Everything was great except event propagation. Let’s say I have a component which is a DIV that wraps a label and an input. How can a consumer listen to the onchange event of the component which should map to the inputs onchange event. I could never come up with a holistic solution that would work for all components. It’d require a lot manual work mapping the input event t…

That's handled by shadow dom event retargeting. When the events pass over the boundary of the component the target becomes the component itself instead of the input.

Yea, that’s been my biggest problem. The target is now different, so I can’t call event.target.value

Re: HTML with Superpowers: An Introduction to Web Components

#102

Post by Existenceblinks »

psygn89 wrote: post #100
Existenceblinks wrote: post #83

Earlier quoted context omitted.

In almost a decade I never understand why anyone would use Shadow DOM. What's the point of scoped style solution here. Why can't I just™ styff ? .. admittedly I never scope style because I never have to add 3rd party components with style in it.

One of the key goals in components is the ability to use it anywhere. Shadow DOM helps with that but also feels like a big thorn in the side for a lot of designers and developers to operate within. It makes more sense to design components this way when you're starting fresh and creating a library to be used anywhere. Controversially, I'd say it's often easier to just write CSS rules that fixes these conflicts and tha…

Even as a 3rd party, somehow reusability here strangely is in form of unconflict instead of shared functionality. Reusable should include customizable style, headless is probably even better. I think Custom element's light DOM with Bring-Your-Own-Style is better for party interop.

Re: HTML with Superpowers: An Introduction to Web Components

#104

Post by dmitriid »

microflash wrote: post #98
dmitriid wrote: post #96

Earlier quoted context omitted.

> but it is still better than being in a continuous churn of UI frameworks. Is there a continuous churn? React is 10 years this year. Vue is 9 years. Angular which feels positively ancient is 7 years (if we only count Angular 2.x). Yes, there are newcomers like Svelte and Solid, but it's hardly a churn. Besides, they explore valuable corners that are left untouched and unexplored by other frameworks. Things like gran…

There's definitely a churn in the frameworks like React, Angular, Vue, etc. New APIs, breaking changes, etc are certainly a thing every year. But as always, this is both downside and upside: you get great features and valuable advances at the cost of such rapid changes. The good news is that the tooling around the Web components is evolving even when the standard itself may moving at glacial pace.

React is compatible to its first version :)

> The good news is that the tooling around the Web components is evolving

You mean web components are growing their own frameworks at the same pace :) With new APIs and breaking changes

In 12 years web components had:

- original lib, polymer. Breaking changes 1.0-> 2.0, then completely deprecated

- lit is 4 years old, already had breaking changes in each version update 1.0->2.0->3.0 (and "potential breaking changes" even in patch releases), and adds new APIs with every release

- stencil is 5 years, has already had breaking changes in 1.0->2.0, but is probably the most stable of them all

etc.

Looks on par with the rest of the industry :)

The sad thing is that web components as a standard don't allow is for actual iteration of ideas. While Solid, S, Marko et al are exploring granular reactivity, web components are stuck in 2010. And all the tools around them are doing what the rest of the tools have been doing for the DOM since time immemorial: invent new, better ways that are only hampered by the underlying platform.

Re: HTML with Superpowers: An Introduction to Web Components

#105

Post by nathias »

jongjong wrote: post #26
qwtel wrote: post #22

Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable. It offers nothing in way of ensuring that custom elements behave like builtin HTML elements. Half the elements I've come across will break or perform no-ops when you update an attribute or set a propety after it was attached to the DOM. Nevermind detaching and reattaching to t…

I used Web Components (HTMLElement) recently and did not encounter any of these issues. I found it more snappy and reliable than frameworks like React or VueJS in terms of adding and removing components dynamically. I did find that it provides a lot more flexibility than front end frameworks (more ways to make mistakes?) and the code was more verbose. If I had to start a project from scratch today, I would consider g…

are you normally a c# or a java coder?

Re: HTML with Superpowers: An Introduction to Web Components

#106

Post by asurty »

dmitriid wrote: post #97
pjmlp wrote: post #94

Earlier quoted context omitted.

I think it is a culture issue, as far as I understand the underlying issue, the React community is not so impressed with having to deal with Web Components.

Realistically, there's almost no community that is impressed with having to deal with Web Components. In this discussion I keep reiterating: there are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation. At best they can consume/embed them and perhaps compile to them. And even that is rife with problems.

Web components seem like a good idea to me. I would imagine there are a lot of libraries out there (eg/ calendars, styling frameworks) that would benefit from reuse across applications. The browser could cache it even if served from a different CDN.

I'm curious what the problems are with web components that you see? Is it specifically related to how they might be used (or useless) in the major frameworks?

Re: HTML with Superpowers: An Introduction to Web Components

#107

Post by dmitriid »

pjmlp wrote: post #99
dmitriid wrote: post #97

Earlier quoted context omitted.

Realistically, there's almost no community that is impressed with having to deal with Web Components. In this discussion I keep reiterating: there are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation. At best they can consume/embed them and perhaps compile to them. And even that is rife with problems.

If we ignore the fact that everyone else supports them, regardless if they are their foundation or not. https://custom-elements-everywhere.com/

> everyone else supports them

That's what I said: At best they can consume/embed them and perhaps compile to them.

> regardless if they are their foundation or not.

And the fact that they are not forming the foundation of these frameworks should be examined and fixed, not ignnored. However, wc proponents ignore this entirely.

Re: HTML with Superpowers: An Introduction to Web Components

#108

Post by esprehn »

logankeenan wrote: post #101
esprehn wrote: post #32

Earlier quoted context omitted.

That's handled by shadow dom event retargeting. When the events pass over the boundary of the component the target becomes the component itself instead of the input.

Yea, that’s been my biggest problem. The target is now different, so I can’t call event.target.value

Right, if you want `value` to be part of the public interface of your component you need to add a value property to expose it.

Re: HTML with Superpowers: An Introduction to Web Components

#109

Post by dmitriid »

asurty wrote: post #106
dmitriid wrote: post #97

Earlier quoted context omitted.

Realistically, there's almost no community that is impressed with having to deal with Web Components. In this discussion I keep reiterating: there are multiple reasons why none of the major frameworks and very few of the new frameworks have WCs as their foundation. At best they can consume/embed them and perhaps compile to them. And even that is rife with problems.

Web components seem like a good idea to me. I would imagine there are a lot of libraries out there (eg/ calendars, styling frameworks) that would benefit from reuse across applications. The browser could cache it even if served from a different CDN. I'm curious what the problems are with web components that you see? Is it specifically related to how they might be used (or useless) in the major frameworks?

> I'm curious what the problems are with web components that you see?

Bitesized explanation from Rich Harris, the author of Svelte: https://twitter.com/Rich_Harris/status/1198332398561353728 It's from 2019, but all the issues are still there. When/If they are going to be solved, it will be by increasingly complex standards that require more and more Javascript for them to just barely function (like they couldn't even participate in form events without additional Javascript).

See also a larger discussion by the author of Solid: https://youtu.be/BEWkLXU1Wlc?t=5837 (if the link doesn't open at the timestamp, skip to "Failed Promise of Web Components" at 1:37:17). It's a bit rambling because it was unrehearsed and on stream, but still good. He also shows and discusses other articles like Rich Harris' https://dev.to/richharris/why-i-don-t-use-web-components-2ci... and his own https://dev.to/ryansolid/maybe-web-components-are-not-the-fu... You can read them directly, but Ryan gives excellent additional context.

Re: HTML with Superpowers: An Introduction to Web Components

#110

Post by bobthepanda »

chiefalchemist wrote: post #66
bobthepanda wrote: post #14

Earlier quoted context omitted.

Marketing is one portion of web design. At a lot of BigCos, the designs are supposed to be standard outside of the once in a generation refresh. One of the advantages of a big brand is a consistent, known quantity, and so things have to be harmonious; Starbucks is not out there making crazy new cups for every new drink they sell, every McDonald's location looks more or less the same, etc. A lot of the variation we've…

Yes. To my point and yours, SB's hero or product card can have exactly the same underlying markup as McDee's. Where those brands, and brands, are able to part is the CSS. The irony is, marketing agencies that do web design work for multiple clients should be looking to leverage web component bricks. The majority I've seen, are not; at least not yet.

Eh, brands are internally consistent but rarely consistent with each other to the point where that would be less trouble than it’s worth. If you tell a client they’re not compatible with you, they’ll just find someone else to hire.
Post reply on HN