March Meeting Agenda and Scheduling

[Westbrook]

For those of you who would like to take part in the March meeting of the Web Components Community Group, please share your availability here as we work to schedule the right day/time to gather. Don't forget, all WCCG events are listed on this calendar. 📆

The earlier in the month that we can meet, the more time we have for breakouts (like these) before we meet with implementors in April.

Some topics for conversation may come directly from the WICG/webcomponents#1031 (comment) that were gathered at the Q1 Face-to-face with implementors that happened this week. Anyone interested in supporting the completion of the Action Items should speak up below or on Discord. 🗒️

Please share your thoughts below as to subjects that you'd like to cover during the February meeting! 🙇🏼

[trusktr]

s/February/March :)

[thescientist13]

Made an issue for seeing if there is any interest in a community spec'd / maintained DOM shim for SSR use cases - webcomponents-cg/community-protocols#55

[Westbrook]

Current agenda:

• Reminder: breakouts are happening everywhere, join in the conversation!
• Community Protocols:
  • SSR protocol, both @thescientist13 and @EisenbergEffect are interested in pushing something here
  • defer-hydration, lots of good conversation, what's the most productive path forward
  • slottable-request, we're investing in research into this at Adobe, what would the community like to be comfortable with it graduating to "Draft" status
  • Other administrivia of protocols at large.
• April Face-to-face
  • appropriate response to January action items
  • new/expanded topics we might want to bring to implementors

Hop into the comments below to add more topics!

[Westbrook]

Meeting set:

WCCG: March Meeting
Monday, March 11 · 12:00 – 1:00pm
Time zone: America/New_York
Google Meet joining info
Video call link: https://meet.google.com/jdj-bveo-zxn

Don't forget that all events are tracking in this calendar and discussed in Discord.

[Westbrook]

Thanks for a lively conversation on all subjects at today's monthly meeting. It's exciting to see more and more invested voices joining the conversation each month. Don't forget to bring your friends next time to continue to dig deeper on so many valuable topics!

If you missed the meeting, you can read the meeting notes to catch up.

Action items for the day:

• there are lots of breakouts coming up, so don't miss the conversation in Discord
  • share your availability for DSD Prototype Sharing today, before the invite goes out tomorrow morning
  • Open Styling meeting available issue coming soon!
• SSR Protocol: @thescientist13 to continue the conversation in the issue. There might be two types of protocols to come out of this: a DOM shim and an SSR protocol
• defer-hydration: more investigation is needed on this, but the best way to unlock that is to move this protocol to "Proposal" status, the first status of the project. We will be making that transition in 2 weeks, so get any blocking concepts into the PR discussion, soon.
• slottable-request: same as above. Moving something to "Proposal" is just the beginning of the discussion and should allow for more focused and productive conversation on specific parts of each protocol.
• We're looking at lowering the barrier to Community Protocols becoming "Proposals" so we can raise the bar for later statuses in the project. April's monthly meeting will target a definitive path forward on this as we begin to expand an understanding of how protocols work their way through the various status levels.

Meeting chat hidden within...

You
11:03 AM
#83
https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit#heading=h.o7ktx8ibksxi
Jesse Jurman
11:05 AM
Please feel free to type over me / fix / add things!
You
11:06 AM
#84
Jared W
11:07 AM
apologies, hoping some network issues clear up for me
You
11:07 AM
https://discord.gg/KSbbpeyfnE
Owen Buckley
11:09 AM
it's like ocean's eleven where they just loop a frame on the cameras
You
11:10 AM
Current issue for discussion: webcomponents-cg/community-protocols#55
You
11:12 AM
Reminder: raising hands to join the queue is a great way to know who would like to discuss the topic as hand!
Owen Buckley
11:13 AM
also serverless and edge environments, where a full browser like Puppeteer would seem like overkill
Brian LeRoux
11:17 AM
it might be worth asking if this is the right way to server render. we have enhance running in any backend now because we deliberately sides step implementing a bunch of the DOM which would only be noops anyhow.
You
11:18 AM
Would love to hear a very high level of what that looks like in the discussion Brian.
Rob Eisenberg
11:18 AM
The main thing I need as a server implementor, is a way to hand off to a 3rd party component and have it render within my system. In a sense, I don't care what it's base class. For my own components, I have a specifically designed server base class.
Nolan Lawson
11:19 AM
Steve: we did a similar thing, no JSDOM on our side fyi
Jared W
11:20 AM
having audio issues on Dave's mic
Owen Buckley
11:21 AM
@dave
WCC for example can support both Light DOM and (Declarative) Shadow DOM. It's just if the developer chooses to use
Rob Eisenberg
11:21 AM
Streaming is pretty important.
So, it's not render to string most of the time.
Brian LeRoux
11:21 AM
Lit is all DSD and a bunch of meaningful comments
Nolan Lawson
11:22 AM
Brian: Enhance doesn't generate s correct?
Brian LeRoux
11:22 AM
@nolan, no it can
Sasha Firsov
11:22 AM
streams fits well in DCE in pure declarative form
Brian LeRoux
11:23 AM
thats called Progressive Enhancement
Owen Buckley
11:26 AM
hydro active
Brian LeRoux
11:26 AM
its really easy to build out from PE to a fullying client rendered thing. its nearly impossible to go the other direction.
Steve Orvell
11:27 AM
It's fair that the Lit system first and foremost set out to tackle rendering of otherwise client focused components on the server. These are elements that render their own DOM to a shadowRoot...
Jared W
11:29 AM
One example of thinking required here is that JS template literals are great for libraries like Lit where you can essentially go the isomorphic route, render the "same" on client or server…but for split components and support for other server-side languages, you must have a different method of defining component templates and handling the handoff between a server-rendered wad of HTML, and the JS which then resumes (maybe not even hydrates in the classical sense!)
Steve Orvell
11:30 AM
Do you need a community protocol for use cases other than "render client focused components on the server" ?
Nolan Lawson
11:30 AM
LWC also went the route of isomorphic, like Lit... I can see the case for avoiding the DOM APIs entirely, but at that point aren't we just building a templating engine?
Sasha Firsov
11:30 AM
state serialization for hydration . Use cases SSR, off-load, shared across sessions state, UX-prepared state...
Brian LeRoux
11:30 AM
depends on whether you resuse those templates on the client
Owen Buckley
11:30 AM
For example, WCC has a DOM Shim, but its API exposes your classic renderToString DX
Brian LeRoux
11:31 AM
*reuse
Steve Orvell
11:32 AM
Lit has integrations with things like Next where the integration point is just "give me your HTML please"
Brian LeRoux
11:37 AM
https://enhance.dev/docs/conventions/components
You
11:39 AM
...closing the queue for this topic...
Rob Eisenberg
11:43 AM
We're in a sort of strange in-between time with, definitely.
You
11:43 AM
https://github.com/webcomponents-cg/community-protocols/pull/15/files
Brian LeRoux
11:44 AM
SHIP IT
😂
You
11:46 AM
webcomponents-cg/community-protocols#45
Nolan Lawson
11:49 AM
Steve: we (LWC) implemented our own Vue-style scoped slots for the same reason... slottable-request seems potentially a workable replacement tho
Steve Orvell
11:50 AM
Cool, it'd be great to try to align on... since it's a potentially much richer api...
Owen Buckley
11:54 AM
https://github.com/webcomponents-cg/community-protocols?tab=readme-ov-file#status
Brian LeRoux
11:54 AM
gotta bounce: thx all