Generic solution for serialization / deserialization of web components

Nobody has claimed this yet.

I am looking for a general purpose serialization and deserialization (rehydration) of custom elements including their declarative shadow DOM with server side rendering (SSR) being one important use case. I wonder what's in scope for [linkedom](https://github.com/WebReflection/linkedom/pull/211#issuecomment-1638188338), what goes beyond and if prior work exists that slices the problem right - in a generic, technology agnostic way, complete and maintained enough to be worth building on or if it's better to roll my own.

Since you are open to collaboration and referenced your project WESC in https://github.com/WebReflection/linkedom/pull/211#issuecomment-1638188338, I thought this would be the right place to start a discussion. I had a brief glimpse at WESC and would like to better understand how this contrasts with / complements other approaches. I think for a solution the key is how to slice the problem, it should be as much as possible technology and framework agnostic and just do what's needed, not more and not less so it is as agnostic, general purpose and reusable as can be, also giving it a higher chance of being of interest to and maintained by a larger community.

Since in the goals of WESC you describe declarative https://github.com/luwes/wesc#custom-element-server-side-rendering as your first goal, I wonder how it compares / contrasts to the existing approaches you reference. What does the renderToString function do in addition to what linkedom offers and how does WESC compare to the referenced existing solutions?

> [Linkedom](https://github.com/WebReflection/linkedom) - This project is powered by Linkedom.
> [Ocean](https://github.com/matthewp/ocean) - Web component server-side rendering.
> [Web Components Compiler (WCC)](https://github.com/ProjectEvergreen/wcc) - Experimental native Web Components compiler.
> [custom-elements-ssr](https://github.com/thepassle/custom-elements-ssr/) - Renders Lit custom elements on the server.

First observation that Ocean and custom-elements-ssr are both built on top of linkedom., so only the web components compiler seems to be standalone. I will dive a bit deeper to see what they offer and where they potentially fall short or are too specific.

- Ocean is deno only for now and last has been contributed to 2 years ago. Streaming and rehydration sound interesting, though I would have to dive deeper to judge this solution. The [author](https://twitter.com/matthewcp) works on https://github.com/withastro/astro, and it might be worthwhile to see how astro solves this issue in a generic way. Regarding Ocean, while I am sympathetic to Deno, I think it would be great to have a runtime agnostic solution as much as possible. I referenced a way to potentially make it compatible with node https://github.com/matthewp/ocean/issues/41#issuecomment-1637142668
- custom-elements-ssr is actually not rendering lit custom elements, but aims to be generic, using a linkedom polyfill:

> custom-elements-ssr
> This package contains an Astro SSR integration to render vanilla custom elements on the server, as well as a [@lit-labs/ssr](https://www.npmjs.com/package/@lit-labs/ssr) compatible ElementRenderer for usage with [@lit-labs/ssr](https://www.npmjs.com/package/@lit-labs/ssr).
>
> Enables server-side rendering and client-side hydration for your [Lit](https://lit.dev/) custom elements.
>
> Try it on [Stackblitz](https://stackblitz.com/edit/github-hcspcv-ccu1fd?file=src/pages/index.astro)
>
> Differences with lit SSR
> It could be the case that you were hoping the Lit SSR package would also support vanilla Custom Elements, and were surprised to find that it didnt. The reason for this is that to render custom elements on the server side, we need some browser APIs to be available in a Node.js environment. Lit however, makes surprisingly little use of browser APIs to be able to do efficient rendering. This means that the DOM shim that Lit SSR requires is really, really minimal, and doesn't include a bunch of things, like for example querySelectors. This package instead makes use of [linkedom](https://github.com/thepassle/custom-elements-ssr/blob/master) to shim browser functionality on the server, which does include the required browser APIs to render custom elements on the server.
>
> Additionally the ElementRenderer for vanilla custom elements is a little bit different from Lit elements.

Since this is not lit specific, it might be worth looking into the pros and cons of this solution, which seems to go in a generic direction.

I haven't seen WCC before, so I cannot comment much on that.

No repository files, tests, or concrete entry points are named. Start by reading the WESC goals and the linked Linkedom discussion, then compare the referenced SSR approaches and the existing renderToString behavior; done would require an agreed, technology-agnostic scope rather than an implementation patch.

Written by the indexing model from the issue text.