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

I've created at test called the 10,000 Button Test. Basically, it generates a template that has 10,000 expressions containing button elements with a little text in between each button.

I wanted to see how my code, that I wrote before posting this issue 777, compared with the "self-replacing custom elements" (proof of concept) in my last post above.

Well, it turns out that my first attempt (that replaces comments) is faster than the one where custom elements replace themselves.

[Comment Replacement Code](http://chickenpecktech.com/LonnieBest/TemplateTesting/Comments/) - finishes in 35ms.
[Self-Replacing Custom Elements](http://chickenpecktech.com/LonnieBest/TemplateTesting/Commentless/)- finishes in 79ms
[lit-html](http://chickenpecktech.com/LonnieBest/TemplateTesting/lit-html/) - finishes in 59ms
[hyperHTML](http://chickenpecktech.com/LonnieBest/TemplateTesting/hyperHTML/) - finishes in 7s

@justinfagnani and @WebRefection : If I've used these library improperly, I will update this comment to reflect proper usage per any suggested optimizations you might make.

Comparing my code to lit-html or hyperHTML is like comparing a prison shank to a Swiss Army Knife. 

However, my point is: in additional to offering fully updatable templates, it would also be nice if web standards offered a performance optimized tagged template literal that can simple allow users to mix ${elementNodes}, ${fragments}, ${textNotes} with strings to produce DOM (without any of the overhead that comes with facilitating a fully updatable template. To me, it seems like syntax that specifies you're only wanting these limited capabilities (upfront) will out perform code designed to handle updating attributes and all the other tough things that lit-html and hyperHTML make updatable.

let element = dom`<h1>String with ${elementNode}.</h1>`; //returns DOM without template.

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

Received on Friday, 14 December 2018 06:56:08 UTC