Re: [w3c/webcomponents] Discussion: Templates that Don't Destroy Element References (#777)

> If I do not want an updat-able template . . . if all I want is DOM from the template tag function, then why must I call a template function that returns a template result which is NOT DOM? It seems like some efficiency would be gained from not returning something that facilitates more than I need.

hyperHTML works this way if you want that. lit-html returns a light-weight result object so that the cost of creating DOM is only done when rendering. You can convert the template approach to the immediate DOM approach easy enough:

```js
import {render} from 'lit-html';
export const renderFragment = (v) => {
  const fragment = document.createDocumentFragment();
  render(v, fragment);
  return fragment;
};
```

As for the intermediate `<template>` that's created in these libraries (and so far would be in Template Instantiation), it's mainly there because for components we assume you'll need to create more than one, and subsequent clones and instance prep will be faster than the initial parsing and template prep.

It may be possible to create another code-path that directly creates DOM without the `<template>` (though I suspect updateable attributes will be tricky) but since the HTML string needs to be parsed either way, all we're really saving is the `.clone()`. As soon as you do this for more than one instance of a non-trivial component, I suspect the repeat parses will cost more than the repeat clones.

I should note that with lit-html you don't need to re-render at all. If you give a template your dynamic elements and only change those, that technique will work. Using a `<template>` under the hood should still be a performance improvement for multiple component instances.

If you think that re-parsing the HTML string is faster than cloning for multiple instances, it'd be good to verify that with some benchmarks. I'd be curious about the results.

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