[📖] Create "Qwik web components" page

[PatrickJS]

Suggestion

we need a page to talk about using web components with qwik and the different trade-offs and ways to load in web components. right now if you search for "qwik web components" you are taken to a github issue with no context

[devinrhode2]

Copying my comment from the other thread:

I have googled “qwik web components” a few times now, and for the second time, I am looking at this thread.

I would love to be able to roll with Qwik City as a meta-framework but still be able to use some react or solid or vue components. Full-ish react interop would make migration of existing apps truly feasible for most projects.

Perhaps we need a fresh take on web components that support ssr, a sort of universal “RSC”. Cc @mhevery

[PatrickJS]

The issue is that Qwik is optimized for the web, unlike web-components. It’s ironic, considering “web” is in the name of web-components. Qwik only needs to download code that the user will actually use, so by definition, none of the web-components, if made in Qwik, will need to be downloaded to run (assuming most are presentational components). If the primary benefit is having a centralized design-system, that’s acceptable. However, if most components are web-components, the benefits are questionable. You still gain from the Qwik wrapper, but you’re always going to include the design-system web-components javascript on the page. Either way, it’s still better than other frameworks, where you need to include even more js.

[devinrhode2]

I feel like I discovered this psge from RyanSolid https://custom-elements-everywhere.com/ I don't think I see Qwik on this page.

This is seriously just a box checking exercise. There's lots of things happening in the js ecosystem so we just want to be able to check the box here.

We saw how successful the original web components spec was, basically nobody uses this for anything with a basic level of urgency (some would say "real work" but I hate that term). Standards are not holy, but what is truly fantastic is being able to use react components instead qwik. Similarly, if we could use Solid components (or web components) inside Qwik, it's easier to make the decision to use Qwik City, because you can still use Solid if you need maximum rendering performance (like for a large table)

[adaliszk]

I have been using Web Components since Polymer 0.5, but they still are not really ready for the usual application development, mainly because they are not HMR compatible. While some might also say that SSR is also a missing feature, that one is a bit harder to see as that is only a problem if you construct your application entirely from Web Components even when the views of your app does not need to be.

I would not say that they are not optimised for the Web, but they are not optimised for Web Development within complex applications as you need to refresh the page every time you change something.

The main reason to use Web Components in my opinion is to create UI frameworks that work with any runtime environments while their logic can be ignored on the server-side. Additionally, they are great as a wrapper when you want to share micro-frontends as they can act as a re-usable boundary that isolates its DOM and Styles. However I think that recent API adoptions are enabling newer use-cases.

As as I understand it, there are two angles to the problem:

1. Qwik Components as Web Components
2. Web Component usage within Qwik

The easier one is using Web Components within Qwik, as that works pretty much fine - at least the last time I tried - but you need to use React wrappers and qwikify those or ignore all type checks and just use plain HTML and their common events. For that it would be nice if there was a qwikify way to just simply declare a component and pass its param interface so that there would be no need for multiple layers of transformations. Maybe additionally Qwik automation can be to also include the import path for each individual component so that by usage the optimizer would able to create page bundles to load.

As for wrapping Qwik into Web Components, not sure how would that work. The main place where I see a benefit is with components that are used 10s if not 100s of times on the page. When you upgrade one of them, the browser would able to upgrade all of the instances at once so it would essentially resume all of the same interaction boundary assuming that the user would interact with them all. Think of an action on a table entry, when one of them hovered, it is likely that others will be hovered too.

Now, to use Web Components for Qwik, they would need to be able to paused and resumed, so they would need to be SSR compatible and the state - including the Shadow DOM - needs to be serialised. The state of the data is a solved problem, the main challenge is the Shadow DOM. Luckily, it is now viable to use a Declarative Shadow DOM to serialise and then resume on demand.

So as a TL;DR, I see a few opportunities here:

• Add a qwikify to allow plain Web Components to gain intellisense and convert their events into Qwik events.
• Maybe also provide a way to point to a component bundle that would be de-duped and bundled for each page.
• Alternative way to render Qwik components by serialising their state using Declarative Shadow DOM and upgrade them to full capabilities upon resume.
• Wrap Qwik Components as Resumable Web Components for things like micro-frontends or embedding Qwik into other frameworks.