Jan 2024 DOM Parts Quarterly Meeting

[rniwa]

During 2023 TPAC F2F, we discussed that we want to have a regular sync up for DOM parts discussion. We're currently proposing to have a meeting around early morning in PDT and evening in CET.

Date & Time: Jan 24th, 11am through 2pm PST / Jan 24th 7pm through 10pm UTC

Refer to a comment below for meeting details.

[tbondwilkinson]

I think we would be planning to meet in January. We want to bring the results of prototyping the library and performance results.

Can you put together a survey for times in january?

[rniwa]

Here's when2meet.

[rniwa]

From when2meet, the following timeslots are most available:

• Jan 8th 6:30pm to 10pm UTC
• Jan 10th 6:30pm to 10pm UTC
• Jan 15th 6:30pm to 10pm UTC
• Jan 19th 7pm to 8pm UTC
  It looks like web components f2f will take place on Jan 10th and 15th so perhaps we should pick Jan 8th 7pm to 10pm UTC.

[eemeli]

I am interested in joining this call (context: #1034). I should be able to make all of the proposed timeslots.

[eemeli]

Is there a decision yet on the time of the call? The #1031 calls are now scheduled for Jan 8 & Jan 10, and Jan 15 is MLK day in the US.

[Westbrook]

@rniwa I'm happy to get Jan 19th, 7pm to 8pm UTC on the WCCG calendar if you want to organize this that way.

[rniwa]

Hm... I have a conflict on Jan 19th 7pm to 8pm now. I guess we should do another round of when2meet.

[rniwa]

New when2meet: https://www.when2meet.com/?23049035-SYv8n

[rniwa]

Looks like the leading candidate is Jan 24th, 11am through 2pm PST (Jan 24th 7pm through 10pm UTC).

[eemeli]

@rniwa Is that the meeting time, then? I'd like to get it reserved in my calendar to pre-empt conflicts.

[rniwa]

yeah, let's make the call.

[justinfagnani]

I'll go ahead and make a Google Meet from my corp account so we get unlimited time.

Should we start building up an agenda too?

[justinfagnani]

Google Meet info

DOM Parts Quarterly Meeting
Wednesday, January 24 · 11:00am – 2:00pm
Time zone: America/Los_Angeles
Google Meet joining info
Video call link: https://meet.google.com/hqh-ojss-dre
Or dial: ‪(US) +1 503-755-4301‬ PIN: ‪888 845 859‬#
More phone numbers: https://tel.meet/hqh-ojss-dre?pin=1101773069910

---

I've added those here who's email I have to a calendar event. If you want to be added, email me at my GitHub username at google.com

Agenda

I think that @mfreed7 wants to give a presentation on the state of the Chrome prototype. @eemeli would like to discuss #1034. I would like to see if we have rough agreement on goals, rationale, and bars for the proposal to clear; and discuss a bit about the expression syntax space if we have time.

I can maintain an agenda table here if people give me the data to fill in:

Topic	Speaker	Time	Reference
Chrome prototype update	@mfreed7	20 min	slides
Localization	@eemeli	20 min	slides
Goals alignment	@justinfagnani	5 min
Expressions	@justinfagnani	15 min

[mfreed7]

I think that @mfreed7 wants to give a presentation on the state of the Chrome prototype

👍 happy to give a quick status update. Might be good if this is first on the agenda. I'll post slides here when I have them, which will hopefully be before Wednesday.

[EisenbergEffect]

I think the top two things on my mind are basically covered here:

• Status and lessons learned from the Chromium prototype
• Expression syntax

I'd love to be able to come away with a sense of whether we think this is something we can really move forward, and enough information to play with some compiler/polyfill ideas.

[eemeli]

I probably won't have time to prepare any new slides for Wednesday, but here's my presentation on DOM Localization at TPAC: https://docs.google.com/presentation/d/1cvvNcC2jMKztYKFIAg1Q5JPWrMCd0q8Ac2m7P1RYhOc/edit?usp=sharing

[mfreed7]

Here are the slides I'll present tomorrow. See you all then!

@EisenbergEffect I think this will at least get the conversation started about your questions, if not provide some answers.

[justinfagnani]

I updated the agenda table with some guesses about time. Let me know if you want other changes!

[rictic]

Taking notes in this doc: https://docs.google.com/document/d/1eohXGOxI1ZPiC8ndTCe5h2MZ8ILcEDFnO7nD2ycPbFY/edit

[rniwa]

@mfreed7 : Would you be able to share how you tested bindings speed between engines? I'm curious how you accounted for per-engine C++-side differences

[rniwa]

Closing the issue now that the meeting took place earlier today. See the minutes for details.

[rniwa]

See #1047 for the next meeting :)

[mfreed7]

@mfreed7 : Would you be able to share how you tested bindings speed between engines? I'm curious how you accounted for per-engine C++-side differences

Hi @rniwa, sure, happy to share. This is my benchmark:

https://main--earnest-semifreddo-71f4ac.netlify.app/benchmark.html

It includes a bit of a description of the methodology on the page itself. Certainly it has a lot of built-in assumptions, but most are semi-defensible. I'm very interested to hear if you have any feedback about the methodology!

[rniwa]

@mfreed7 : thank you!

[rniwa]

It includes a bit of a description of the methodology on the page itself. Certainly it has a lot of built-in assumptions, but most are semi-defensible. I'm very interested to hear if you have any feedback about the methodology!

One feedback we can immediately give is that using the same n across browsers would be better so that there won't be differences in things like compilation time, GC pauses, etc... Using n=200,000, the difference between Safari & Chrome seems somewhat smaller. I'd remember to share any additional feedback we find as we analyze this test :)

[mfreed7]

One feedback we can immediately give is that using the same n across browsers would be better so that there won't be differences in things like compilation time, GC pauses, etc... Using n=200,000, the difference between Safari & Chrome seems somewhat smaller.

Yeah, that's fair. I was trying to equalize the noise level and the overall runtime of the test. But you're right that this will cause differences in the GC pressure overall. I'll update it...

I'd remember to share any additional feedback we find as we analyze this test :)

Thanks!

[mfreed7]

Yeah, that's fair. I was trying to equalize the noise level and the overall runtime of the test. But you're right that this will cause differences in the GC pressure overall. I'll update it...

Done - new version published.