Re: [WICG/webcomponents] Template/part proposals should explain how and why they improve performance (#901)

Thanks, everyone, for contributing. Let me summarize and see if we can continue to make progress on this issue. 

All comments indicate we agree that an API for returning a set of references to cloned nodes of a subtree will be beneficial, improving performance via saving additional tree walks for node lookups.  We have two proposals on the shape of this API: 
1: 
>  const { clonedTree, clonedReferences } = clone(subtree, { giveMeReferencesToClonesOfTheseNodes: [node1, node2] }).

2:
> Part objects:  NodePart, AttrPart, PropertyPart.  

The low-level API [1] returns a set of references in the cloned tree, but it's missing some key features of the Parts API provide.
These include:
- mark a range of nodes and portions of an attribute.
- repeated updates without having the developer keep track of nodes or attributes. 
- extensible, support syntax in the future where the browser parser can attach parts. 

Both of these two API proposals have their benefits, and I think they can both exist. Having [1] doesn't eliminate the need for [2]. We can leave their usage to developers and framework authors. 

Coming back to the Parts API, do we agree that the ergonomic benefits, positive developers' reception, and performance gains are enough evidence to start working on these APIs?   

@smaug---- @annevk @justinfagnani 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/901#issuecomment-736895253