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

Custom Elements v1: Reusable Web Components

developers.google.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Custom Elements v1: Reusable Web Components

#21

Post by romaniv »

euyyn wrote: post #20
romaniv wrote: post #15

Components with extensibility through inheritance written in a prototype-based language. Having worked with around a dozen component-based systems over the years I'm not particularly enthusiastic. I think it would be much better for the web if browsers had a sane API for extending behaviors of any tag via attributes. This would make things easily composable and eliminate most problems of traditional component-based s…

> It would be even better if people working on these specs spent some time reading research papers on how a sane component-based system could work. I don't know the people working on these specs, but presuming that they aren't aware of research in the area, and moreover of what has worked in practice and what hasn't, is audacious.

It's true that I don't know for sure, but I haven't seen any citations, or verbal references, or any similarities in the APIs that would indicate familiarity with the relevant research I had in mind.

Also, a lot of research in this field is done through working proof-of-concept systems, so there is no point in implying that those designs don't work "in practice".

Re: Custom Elements v1: Reusable Web Components

#22

Post by romaniv »

reificator wrote: post #19
cztomsik wrote: post #13

please correct me if I'm wrong but it seems that custom elements still do nothing about dependency hell (it's not possible to use same lib in different versions)

Why would they be expected to?

It's one of the biggest problems in fronted development right now and it's something conceivably can be addressed by the... well, let's call it "guiding structural paradigm" for the lack of a less pretentious term.

Re: Custom Elements v1: Reusable Web Components

#23

Post by reificator »

romaniv wrote: post #22
reificator wrote: post #19

Earlier quoted context omitted.

Why would they be expected to?

It's one of the biggest problems in fronted development right now and it's something conceivably can be addressed by the... well, let's call it "guiding structural paradigm" for the lack of a less pretentious term.

I don't know, in my frontend experience dependency hell is less about conflicting dependencies and more about literally installing 690 packages after one `npm install `.

Fixes need to happen in the broader npm ecosystem, not the standard for creating reusable components.

Re: Custom Elements v1: Reusable Web Components

#24

Post by quest88 »

megous wrote: post #18

Is it possible to nest custom elements? I suppose it should be, but how would it be seen in DOM? How can I get notifications in my-container when someone from outside adds another child to it?

Yes, it would be see by the DOM as Shadow DOM I believe. https://developers.google.com/web/fundamentals/architecture/...

You can get notifications through the mutation observer API: https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...

Re: Custom Elements v1: Reusable Web Components

#25

Post by zackbrown »

megous wrote: post #18

Is it possible to nest custom elements? I suppose it should be, but how would it be seen in DOM? How can I get notifications in my-container when someone from outside adds another child to it?

I think MutationObserver[1] would be the with-the-grain answer here

[1] https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...

Re: Custom Elements v1: Reusable Web Components

#26

Post by ergo14 »

megous wrote: post #18

Is it possible to nest custom elements? I suppose it should be, but how would it be seen in DOM? How can I get notifications in my-container when someone from outside adds another child to it?

You can emit normal events (they bubble up normally), you can use a notification bus, redux, whatever you want. And your elements are visible in DOM normally like all other elements.

Re: Custom Elements v1: Reusable Web Components

#27

Post by ergo14 »

romaniv wrote: post #15

Components with extensibility through inheritance written in a prototype-based language. Having worked with around a dozen component-based systems over the years I'm not particularly enthusiastic. I think it would be much better for the web if browsers had a sane API for extending behaviors of any tag via attributes. This would make things easily composable and eliminate most problems of traditional component-based s…

I think apple opposed is="" and its not implemented in their browsers.

Re: Custom Elements v1: Reusable Web Components

#28

Post by euyyn »

romaniv wrote: post #21
euyyn wrote: post #20

Earlier quoted context omitted.

> It would be even better if people working on these specs spent some time reading research papers on how a sane component-based system could work. I don't know the people working on these specs, but presuming that they aren't aware of research in the area, and moreover of what has worked in practice and what hasn't, is audacious.

It's true that I don't know for sure, but I haven't seen any citations, or verbal references, or any similarities in the APIs that would indicate familiarity with the relevant research I had in mind. Also, a lot of research in this field is done through working proof-of-concept systems, so there is no point in implying that those designs don't work "in practice".

By working in practice I don't mean "unimplementable or not", I mean the difference between CORBA and gRPC: One can argue endlessly about the benefits of one vs the other, but it's practical experience what's informed the latter of how and why the former sucked.
Post reply on HN