Re: [WICG/webcomponents] DOM parts use outside of <template> seems unlikely (Issue #1035)

> If it isn't, and there are some missing API's that could make the browser update the fragments faster, why would we not want to consider adding that to the platform? 

I agree, but I don't understand how this is the case of this API if you omit the template use-case. Why would updating via DOM parts be faster than calling the lower-level `textNode.data = 'foo'` and `el.setAttribute('key', value)`? It's faster if you account for traversal requirements; but traversal is a requirement of templating. Maybe I'm missing something, so I would love an explanation.

> The answer to that question has little to no bearing on whether the platform should provide built in support for templating. It was agreed a while ago, that we needed this empirical question looked into, first, as we don't want to build higher level functionality (like templating) on top of a sub optimal API. Hopefully we will know the answer soon (January?), so we can move on either way.

This thread is my attempt to participate in that conversation. I was told that filing an issue was the way to do so. If not, what is?

> For server rendered 100% static HTML, these API's wouldn't be very useful, I agree (just as the existing api's, such as querySelectorAll, etc. aren't very useful). But even for extremely server-centric solutions, for example, solutions that use server sent events to update the UI, I have a hard time seeing why they wouldn't want to update the UI as fast as possible, which (we are hoping) is the primary mission of DOM parts, as I understand it.

I don't understand how this proposal leads to faster updates once you know the parts that need updating. I would love to understand that better. Thanks.

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

Message ID: <WICG/webcomponents/issues/1035/1802540689@github.com>

Received on Wednesday, 8 November 2023 19:44:27 UTC