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

Certain benefits can’t be realized when building [2] on top of [1] in the userland. Let me illustrate with a couple of examples.

#### Example 1. Replace a range of child nodes. Ex: a paginated list with static top and bottom nodes.
Here's a node tree. After cloning with [1], cloned references of `start` and `end` nodes are returned. 
```text
container
├─start
├─ A (to be replaced)
└─ end
```
A userland function that replaces all the nodes between `start` and `end` has to remove all the existing nodes, then insert new nodes in between. For removal, use the range object: 
```javascript
range.setStartAfter(start);
range.setEndBefore(end);
range.deleteContents();
```
Then insert a list of replacements, nodes, either with a loop -- `container.insertBefore();` -- or insert a dummy childNode and use `childNode.replaceWith(...nodes);`.   

However, with Parts API, replacing the range of nodes is straightforward.
```javascript
childNodePart(container, start, end);
childNodePart.values = nodes;
childNodePart.commit();  
```
The userland solution requires more script. Thus, it’s less performant due to additional trips through the binding layer, possibile calls to synchronous mutation events, etc.

#### Example 2.  Minimize side effects of setting attributes with `Parts` batching. Ex: <img> element and its reactions to [DOM mutations](https://html.spec.whatwg.org/multipage/images.html#reacting-to-dom-mutations).

The order of modifying DOM attributes can create side effects that [1] doesn't address. Changing <img>'s `crossorigin`, `referral` attributes will [cancel pending request](https://html.spec.whatwg.org/multipage/images.html#reacting-to-environment-changes) (step 15). Framework authors have to take special precautions to [minimize their impact](https://github.com/developit/unified-element-properties-proposal/blob/master/readme.md#api-sketch). 

With the attribute Parts API, relevant mutations can be batched together to minimize side effects and improve performance. In addition, it reduces the developers' need for a deep understanding of all the potential side effects.


Overall, I think Parts API promote better programming practices by streamlining DOM updates and reduces the likelihood layout thrash where property reads can intertwine with updates.  I hope these examples show their benefits.

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