RFC: getTemplateHTML / vanilla render + SSR + hydration / bundlesize

[luwes]

Background

media-chrome's custom elements render on the client side only by default. There are several benefits in rendering the shadow DOM of media-chrome's elements on the server already. The biggest reason is the speed the control is visible to the end user. There won't be any FOUC anymore if the controls are SSR'ed, the components will be immediately visible on page load.

Note: to SSR in the first place a (meta) framework has to support server side rendering and is on us to provide logic to render the declarative shadow dom in the right place. Something ce-la-react (https://github.com/muxinc/ce-la-react) does for Media Chrome's React wrappers.

Proposal

We already started doing this in media-elements and some elements in Media Chrome (e.g. https://github.com/muxinc/media-chrome/blob/main/src/js/media-chrome-dialog.ts). Just wanted to re-iterate it in writing here.

The proposal is to provide a MyCustomElement.getTemplateHTML(attrs, props) on each custom element in Media Chrome which makes it very easy to get the shadow DOM template as a string on the server (https://github.com/muxinc/ce-la-react/blob/main/src/ce-la-react.ts#L294-L312) and fits our vanilla render approach on the client as well with minimal changes to our current architecture.

Potential benefits

One of the downstream benefits of our current architecture and this proposal is the possibility to exclude much of the HTML + CSS template code in the client Media Chrome JS bundle if the elements were SSR'ed. Imagine when an app SSR's Media Chrome two bundles media-chrome-core.js and a media-chrome-templates.js bundle is used instead of the default one. If the templates are already in the page the media-chrome-templates.js bundle can initially be left out. (Until in a rare case a custom element is created dynamically in JS. Then this templates bundle would have to be dynamically imported. Possibly this bundle could be imported lazily in any case on the browsers idle event or some other event.)

This is only possible because our current architecture uses no framework (like) render engine which in most cases require the complete templates in the client to do hydration. Media Chrome currently creates a template element, sets its innerHTML to our string template and is appended to the shadow dom of the custom element. The DOM is then imperatively manipulated throughout the life of the custom element. This is different than most modern render engines where the views are rendered declaratively, the holes (dynamic parts) in the template are then with things like vdom or fine grained updates updated which requires most of the time the whole template in JS with the holes identified.