10:20:34 RRSAgent has joined #webcomponents 10:20:38 logging to https://www.w3.org/2025/03/26-webcomponents-irc 10:20:39 RRSAgent, do not leave 10:20:40 RRSAgent, this meeting spans midnight 10:20:40 RRSAgent, make logs public 10:20:41 Meeting: Scoped custom element registry 10:20:41 Chair: Ryosuke Niwa 10:20:41 Agenda: https://github.com/w3c/breakouts-day-2025/issues/18 10:20:41 Zakim has joined #webcomponents 10:20:42 Zakim, clear agenda 10:20:42 agenda cleared 10:20:42 Zakim, agenda+ Pick a scribe 10:20:44 agendum 1 added 10:20:44 Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy 10:20:44 agendum 2 added 10:20:44 Zakim, agenda+ Goal of this session 10:20:45 agendum 3 added 10:20:45 Zakim, agenda+ Discussion 10:20:45 agendum 4 added 10:20:46 Zakim, agenda+ Next steps / where discussion continues 10:20:47 agendum 5 added 10:20:47 Zakim, agenda+ Adjourn / Use IRC command: Zakim, end meeting 10:20:47 agendum 6 added 10:20:47 breakout-bot has left #webcomponents 10:27:40 tidoust has joined #webcomponents 13:47:13 bkardell_ has joined #webcomponents 13:53:10 keithamus has joined #webcomponents 13:53:10 jcraig has joined #webcomponents 14:07:56 annevk has joined #webcomponents 14:58:42 rniwa has joined #webcomponents 16:00:21 oriol has joined #webcomponents 16:06:31 spectranaut_ has joined #webcomponents 16:24:28 lea has joined #webcomponents 20:57:07 xiaoqian has joined #webcomponents 21:04:46 rniwa has joined #webcomponents 21:04:52 rniwa has changed the topic to: DOM Parts 21:05:40 masonf has joined #webcomponents 21:05:45 scribenick: masonf 21:05:46 simon has joined #webcomponents 21:05:52 present+ 21:06:18 present+ 21:06:18 zakim, start meeting 21:06:18 RRSAgent, make logs Public 21:06:20 please title this meeting ("meeting: ..."), xiaoqian 21:06:28 meeting: DOM Parts 21:06:29 present+ 21:06:33 present+ 21:06:39 scribenick: masonf 21:06:59 rniwa: this is about DOM Parts. We worked with Google on this. Point to specific location in the DOM to update it easily. 21:07:20 rniwa: people use comment nodes as markers to do this, and use regular mutation stuff to mutate them. Need to maintain the comments, etc. 21:07:31 rniwa: performance benefit maybe. Based on Mason's experiment, no. 21:07:54 present+ xiaoqian, dandclark, smaug, rniwa, Monhamed_Mansour 21:08:36 masonf: it depends. Some benchmarks it wins, some it loses, by 10-20%. 21:08:54 rniwa: are there other benefits? Might still be worth adding. Or best leave to userland. 21:09:19 rniwa: issue filed in DOM (link?) about document fragments whose nodes do not get removed when inserted 21:09:31 rniwa: like a wrapper documentfragment that stays in the tree 21:09:52 rniwa: similar to DOM parts, they're isomorphic. Different semantics, but same concepts and use cases. 21:10:27 rniwa: it came up that maintaining start/end comment nodes can be tricky. Those could be removed. DOM Parts - stays in the DOM tree. 21:10:42 rniwa: still ergonomic benefit. 21:11:53 masonf: we need to figure out how much to do. Losing some things (like maintaining references) was slower. 21:12:02 rniwa: different use cases need different featuresets 21:12:08 rniwa: though that makes it more complicated. 21:12:17 rniwa: Olli was concerned about complexity already. 21:12:34 rniwa: maybe there's a simple proposal that we can implement 21:12:53 smaug: the other documentfragment proposal might be simpler? 21:13:14 rniwa: proposal has a polyfill, so it is concrete to some extent 21:13:20 smaug: some open issues 21:13:57 masonf: a new node that looks like display:content 21:13:59 rniwa: also doesn't get seen by querySelector 21:14:15 rniwa: and doesn't affect rendering 21:14:40 rniwa: insert and remove nodes - same capacity 21:15:10 smaug: that might complicate things - new node type isn't really there but is there. But shadow dom - does it slot? Etc. 21:15:31 rniwa: we did consider this when we thought of DOM Parts. We came to the conclusion that the complexity is harder than it seems. 21:16:07 rniwa: once you try to nail down all the details, it might be more complicated than DOM Parts. Might be can of worms. 21:17:11 rniwa: new node type - selectors only work with elements, not Nodes, so maybe that's easy. Direct selectors parent>child might be tough. 21:17:20 rniwa - what about nesting these things 21:17:49 smaug: likely surprising performance consequences 21:18:13 rniwa: both approaches have downsides, particularly performance. 21:19:07 mmansour: for dom parts, placing variables inside. Let's say we want for loops and when conditions? 21:19:30 mmansour: todo app, put the template for that into the DOM - replace the variables. But let's say you want a todo list - many items. 21:19:45 mmansour: nested DOM Parts? Append each one? 21:20:31 mmansour: I'm building a web component framework - SSR in any language - isomorphic apps. Template parts works nicely. Define templates on serving time, on hydration - to add new item, take template from main document, add variables, done. 21:20:42 mmansour: for development, we need for loops and conditions. 21:21:32 masonf: JS object as state, arrays of strings, add those to DOM Parts 21:21:46 rniwa: this might be more template instantiation more than DOM Parts 21:22:14 rniwa: browser engine has native template engine - in the future. This (DOM Parts) is just a piece of that. 21:22:30 rniwa: template instantiation is hard, so break into pieces we can build 21:22:40 mmansour: because it's opinionated? Is it the syntax? 21:22:59 rniwa: that plus it's complicated. Need to do looping/conditionals, standardizing that plus customization is tough. 21:23:41 mmansour: I'll share proposal we (Edge) have with a WebUI framework. Treats HTML/JS/CSS as main foundations, rather than React. 21:24:10 mmansour: built in rust, looks through web components, generates entire declarative shadow DOM. Can be any language. Render entire website at once. 21:24:29 mmansour: tough part - we have to do JS manipulation to do for loops and conditionals. 21:24:49 mmansour: we believe react and angular are making the web slower, and if we use the platform, it'll be faster. 21:25:17 smaug: DOM Parts aren't better in terms of performance. 21:26:08 mmansour: I'll build a template for for loops, but that'll make it harder for the user. This is my template for todo list, a list of template parts, need to develop in a different way. 21:26:40 rniwa: is there still something implementable? 21:26:59 smaug: as of now, it doesn't look promising for anything 21:28:03 smaug: this would complicate things 21:29:51 masonf: maybe someone else can make it fast 21:30:09 masonf: I don't want my perf feedback to be the thing that kills this API 21:30:25 rniwa: maybe if the author feedback is good - if this helps the developer experience, maybe worth it. 21:30:39 rniwa: if this really is a building block toward template instantiation 21:30:59 rniwa: just like custom elements provided a way to define components, we could do the same thing for templates. 21:31:23 masonf: is this a building block toward template instantiation? 21:31:53 rniwa: we tried to make it that, yeah. But if there isn't value to DOM Parts by itself, maybe we can just skip ahead to template instantiation. 21:32:06 smaug: if it's template instantiation that people want, then maybe 21:32:49 masonf: some frameworks have components but don't use templates 21:33:17 rniwa: in DOM parts there seems to be a kernel of something useful. Ability to have a comment-like object that marks positions. Frameworks might like it. 21:33:27 rniwa: would that be beneficial to add to browsers? 21:33:39 rniwa: adds a bunch of complexity, but no performance gain, maybe not worth it. 21:34:42 rniwa: there are a ton of people on issue 736 - maybe shows interest in this concept. 21:35:09 rniwa: something useful. Not clear what people need exactly. Ask people on 736 - what are you looking for? 21:35:30 masonf: you might get lots of feedback. 21:36:17 taylore: question about DOM Parts - for ease of implementation - is it worth it? Just for organization purposes? Does it make the developer experience better? 21:36:53 taylore: maybe ship it but it won't improve performance. But we can use it as a building block. Provides another mechanism for developers to use. 21:37:25 rniwa: we've added things that improve ergonomics but not performance in the past. E.g. querySelector() 21:37:54 rniwa: need to balance the cost also 21:38:53 masonf: queryselector might be a good model - it got optimized over time. Maybe that'll happen for DOM Parts. 21:39:18 rniwa: for 736 - if we add DOM Parts or special documentfragment, will it get used in a lot of frameworks? If yes, let's pursue. If not, we shouldn't do this. 21:40:33 masonf: maybe don't ask generally on 736, but since we've decided DOM Parts and the special document fragment are similar complexity, just ask on 736 if they like DOM Parts as-is? 21:40:41 rniwa: we need more framework authors to get involved. 21:40:49 rniwa: maybe that's a good idea to ask on 736 21:41:00 smaug: ask what DOM operations are slow currently, maybe 21:41:06 smaug: then also ergonomics 21:41:42 rniwa: latest discussion on 736 was maybe formalize comment node hack. Identify comment nodes in a certain format and manipulate those. 21:42:18 smaug: API implementation might be simpler 21:43:06 masonf: the API isn't that complicated, keeping track of nodes is the hard part. So that sounds the same maybe? 21:43:39 rniwa: next step: go to 736 and ask about DOM Parts. Would people use it? Why not? Or why not but you would use the documentfragment thing? 21:43:48 rniwa: what's the difference - that's the interesting question 21:44:05 rniwa: it's easy to hand-wave a solution, but the devil is in the details 21:44:21 masonf: I agree 21:44:40 rniwa: I'll try to come up with a proposed question and share the question before asking 21:45:15 taylore: existing frameworks - if we do DOM Parts, frameworks will adopt that and abandon their existing implementations. 21:45:49 masonf: don't change the developer-facing side, but change the guts 21:45:59 rniwa: maybe more interoperable components could be built thought 21:46:03 s/thought/though 21:46:36 taylore: helpful because you might be able to build more things like mmansour - interoperable components 21:46:57 rniwa: I agree. 21:47:11 smaug: but the native parts implementation must be faster. They won't use if it isn't faster. 21:47:33 rniwa: for framework authors there needs to be a benefit. Just a different thing won't fly. 21:47:45 rniwa: we'll have to see 21:47:52 mmansour: is it slower because of looping through 21:49:37 rniwa: we have all JS knowledge, so it should be able to be faster 21:49:54 mmansour: queryselector the nodes and replace the content 21:51:23 {discussion about performance} 21:52:03 {discussion about lack of attendance here} 21:52:19 mmansour: to ask developers: if you have DOM Parts, and you're compiling templates, could you make it faster? 21:52:45 rniwa: if you're building on the server, you're doing a bunch of work anyway 21:53:05 mmansour: it'll be similar for template instantiation. 21:53:11 rniwa: maybe good segway 21:54:03 mmansour: the FAST framework (similar to Lit) - declarative templates. To support hydration for SSR web components, can't depend on JS templating. Do declarative templating, with "repeat" and "when" conditionals and loops. 21:54:50 mmansour: walking through template tag to see where the special conditions are. Do a build step - produce a JS representation, and maybe template parts help. Walk character by character to parse the template string. 21:55:32 rniwa: if you have to do that client-side, DOM Parts helps. Avoid tree walks. But if you're server-side compiling, benefits diminish. 21:55:57 mmansour: I'll ping the FAST people 21:56:07 5 minute break 21:57:00 RRSAgent, make minutes 21:57:02 I have made the request to generate https://www.w3.org/2025/03/26-webcomponents-minutes.html xiaoqian 22:00:41 rniwa has changed the topic to: Template Instantiation 22:01:02 RRSAgent: start meeting 22:01:02 I'm logging. I don't understand 'start meeting', rniwa. Try /msg RRSAgent help 22:02:18 Zakim, start meeting 22:02:18 RRSAgent, make logs Public 22:02:19 please title this meeting ("meeting: ..."), rniwa 22:02:39 meeting: Template Instantiation 22:04:02 rniwa: this is the ultimate crown jewel - create templates and make the result more usable and mutable via easy JA 22:04:06 s/JA/JS 22:04:19 rniwa: a while ago we (Apple) made a proposal 22:04:31 https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md 22:05:04 rniwa: it's been a while. Would be good to come back to it soon. Template engine use case seems clear. 22:05:28 rniwa: want to replace content and update content. Bidirectional bindings. DOM to JS and back 22:05:32 Jamie has joined #webcomponents 22:05:42 rniwa: allow for loops and conditionals in template engines 22:06:08 rniwa: original proposal was to make a template processor. Hook for the library author to hook into template engine in the browser and customize behavior. 22:06:15 rniwa: callbacks for template clone, etc. 22:06:50 rniwa: that stuff seems still useful because the semantics need to be delegates to the template engine, because that would be overkill and too opinionated. 22:07:02 rniwa: questions? 22:07:26 mmansour: two ways to do that. 1 is do everything declaratively in the DOM. 2 is build time produce JS representation of template. 2 is react. 22:07:32 mmansour: which one is faster? 22:07:58 mmansour: assume startup performance isn't an issue. Now you need to add another item to the DOM, like a banner. Which is faster? 22:08:10 mmansour: is precompiled JS always faster? 22:08:27 rniwa: we haven't done perofrmance testing extensively. 22:08:47 {the answer might be here? https://github.com/krausest/js-framework-benchmark) 22:09:23 rniwa: when you make a big list, you have a lot of repetition. You need to repeat all of the
  • elements. 22:09:43 rniwa: potential benefit: you could say I just want 10
  • 's and only transfer one of them. 22:10:35 mmansour: I've prototyped this kind of thing. Yes, if you build a web component with 1000 items. Yes, the template is repeated 1000 times. You're assuming you're using slots for things like the name, etc. You're dependant on slots. 22:10:56 mmansour: slots are only element based. You can't slot things like an attribute. 22:11:21 mmansour: broken for my use case. I want 1000 components, and need to replace the attributes for each. 22:11:28 rniwa: attributePart is exactly that 22:11:54 rniwa: drive update from JS. Because attributes are exposed as a JS property, that's do-able. 22:12:28 rniwa: all updates come from JS object. You can update attribute or content value. 22:12:40 mmansour: how without JS? 22:12:57 rniwa: you're relying on object attributes - what you're using to render the component. 22:13:18 mmansour: if you're SSRing 1000 contacts. You want each one to have a tel attribute. How do you render that? 22:13:32 rniwa: embed a JSON object and render from the JSON 22:13:52 rniwa: can be implemented in the browser, so avoid a flash 22:14:09 mmansour: isn't there a cost to switching to/from JS? 22:14:27 rniwa: want a blob of JSON, then a bunch of templates that all use that single JSON to generate the DOM tree 22:14:41 mmansour: that's the proposal? 22:14:44 rniwa: yes 22:15:08 rniwa: initial proposal maybe doesn't have all of that, but that's where we want to go. 22:15:22 rniwa: one feedback from Mozilla was that it was too complex. That's why we wanted DOM Parts first. 22:15:49 rniwa: because DOM Parts wasn't necessarily a performance win, maybe come back to this 22:15:56 rniwa: might be a win 22:16:57 mmansour: I do like what you said. One thing: s if you render a header slot, then a bunch of HTML and then another default slot. When you render the page. It'll render the template and slots without the children, then the children. 22:17:11 mmansour: if you use slots a lot, that's bad. 22:17:42 Slots are streamable - replace the slot and it changes. Slots - no attributes - just entire elements can be replaced. 22:18:06 mmansour: managing slots was good, except for no attribute support. 22:18:34 mmansour: but I like the JSON at the start, templates at the end approach. I don't know how lists work. One for every element item. 22:18:47 rniwa: lists we didn't tackle in the proposal yet. Rest was complicated enough. 22:19:10 rniwa: the browser can tackle the list. Then we just have a blob of data and some templates and the browser constructs the DOM tree. 22:19:29 rniwa: should be a performance win 22:19:54 mmansour: what about experimentation. Swap one button out for another button component, without reloading the page. 22:20:13 rniwa: dynamic reloading? For that, scoped custom element registries is best 22:20:25 mmansour: refresh the template in real time? 22:20:40 rniwa: yeah, just replace the template and the JSON populates the templates automatically 22:20:57 mmansour: good for developer hot refresh use cases 22:21:06 rniwa: much faster than diffing virtual DOM also 22:21:29 mmansour: ship it 22:21:38 rniwa: in a perfect world, great 22:21:44 mmansour: svg support? 22:22:23 rniwa: in theory yes. One template with N instances, each referring back to the original. 22:23:01 mmansour: SVGs get heavyweight everytually. You can use , but can't do that cross-root. 22:23:20 mmansour: would you get a new copy of the SVG? 22:23:28 rniwa: yes, duplicate the tree, so not shared. 22:23:55 rniwa: but automatic. So if you update the top level template, the rest propagates automatically. 22:24:37 rniwa: maybe we go back to the drawing board that we can build directly, without going through DOM Parts first. 22:25:03 dandclark: I agree finding smaller pieces is a good idea, but I'm not sure which part 22:26:08 masonf: DOM Parts is lower level, so it doesn't have most of this stuff. 22:26:37 mmansour: I'd love to have this 22:27:09 mmansour: what can you strip out of the proposal to make it shippable? 22:27:09 https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md 22:27:19 rniwa: go to section 3.1 22:27:38 templateInstance, and an update function 22:27:59 rniwa: keep calling update to update the DOM tree, from the JS object. Automatically replace mustache syntax with JS content. 22:28:18 mmansour: I used a dotted syntax for my framework 22:28:51 mmansour: this is flattened JSON structure, right? What if you have a large user object, user.name - do we support structures? 22:29:10 rniwa: that's the intent. Not in the proposal. But chaining support is natural. 22:29:19 rniwa: if you go to 3.2, there are template parts, and custom callbacks 22:29:49 mmansour: maybe that's something that can be chopped out. Not needed for SSR. 22:30:15 mmansour: for SSR we just need to hydrate and remove duplicate nodes 22:30:34 rniwa: section 3.3 is conditionals and loops. 22:30:45 mmansour: you used handlebars 22:31:02 rniwa: go to just before section 4 - use the directive attribute, 22:31:49 mmansour: I just used template called for, etc. What about explicit tags like 22:32:28 mmansour: lots of tooling with ASTs - if you see a non-tag character, syntax highlighting breaks, etc. 22:32:43 rniwa: nice to bring it to the platform, IDEs will get updated so this gets recognized. 22:33:01 rniwa: ergonomic benefit of bringing this to the web 22:33:15 mmansour: no includes any more, just use components 22:33:31 mmansour: in handlebars, you include template. Web components don't need that. 22:34:37 rniwa: we want to tackle this because we think it'll benefit the platform. 22:35:09 mmansour: 3.2 can be cut. 3.3 just needs more clarity on what's needed. 4 is how it works. 22:35:39 mmansour: template parts with conditions and instances. Dan, can you implement that? 22:36:20 mmansour: I wonder what happens with React - they won't use this. FAST, Lit, regular developers who don't use frameworks - they will 22:36:33 rniwa: if there is a performance win, others might use it also, as a compile target. 22:36:55 rniwa: once you have looping and conditionals, server side rendering will be much better than anything today. 22:37:43 mmansour: at build time in Rust, we create a native handler that renders the entire page. On the runtime side, it'll call that function. It's just a bunch of functions concatenated, with holes in the middle for data 22:38:48 rniwa: yep, that's what we were going for - this might change the web in a good way. Let the platform do the work. 22:39:33 mmansour: I trust the web platform fro rendering and interactivity, but not good at waiting for JS to load 22:40:08 dandclark: we've been involved, but not currently trying to drive it 22:40:23 rniwa: we made the proposal, but haven't put effort into it really. Doing other things. 22:40:40 rniwa: we're now interested in putting effort into this area. 22:40:50 mmansour: I can help also, I'm passionate about this stuff. 22:41:24 rniwa: there seems to be some goodness here that might be worth doing. 22:41:34 rniwa: we need to understand the benefits also. 22:42:22 masonf: rniwa maybe implement it? 22:42:33 rniwa: there's a polyfill somewhere, perhaps dig that up and update it? 22:42:41 rniwa: prototyping would be a good idea 22:43:56 rniwa: every framework invents templating, why isn't this in the browser? 22:44:10 mmansour: next thing people will ask is data bindings 22:44:47 mmansour: after that, reflection - getting API schema from web components 22:45:28 rniwa: once we implement, more things will come out, naturally. 22:50:47 {discussion of scoped custom element registries} 22:55:01 RRSAgent, make minutes 22:55:02 I have made the request to generate https://www.w3.org/2025/03/26-webcomponents-minutes.html xiaoqian 04:55:30 fantasai has left #webcomponents 09:40:51 RRSAgent, bye 09:40:51 I see no action items