Integration/qwik svelte

[raymondmuller]

What is it?

• [x] Feature / enhancement
• [ ] Bug
• [ ] Docs / tests

Description

Qwik Svelte allows you to add Svelte components into an existing Qwik application. There are still some issues, but it hopefully is a good start.

Use cases and why

• 1. Use Svelte components inside Qwik to get the keep the DX from Svelte
• 2. Improve adoption of the framework

Checklist:

• [ ] My code follows the developer guidelines of this project
• [ ] I have performed a self-review of my own code
• [ ] I have made corresponding changes to the documentation
• [ ] Added new tests to cover the fix / functionality

[stackblitz[bot]]

Run & review this pull request in StackBlitz Codeflow.

[raymondmuller]

One known issue:

https://user-images.githubusercontent.com/3808818/199841659-3b223003-81ca-4b4d-99c1-7f1cdeb5a52e.mov

As you can see in the video, when I browse to the page (using the Link component from Qwik City), the page is empty, however when I refresh the page, the components show up.

[manucorporat]

This week i will have time to help with this!

[mhevery]

Hey @raymondmuller, this is a fantastic piece of work! Thank you!

We are figuring out the best way to integrate this and get it into the hands of our users. We have some ideas and we would like to hear your thoughts.

Option 1: Merge this into our mono repo

As you can imagine merging things into our mono repo has to meet a very high bar:

• It has to be production ready. Now that we have announced v1.0 we have to be sure that what goes in is of sufficient high quality.
• The implication of the above is that we are now on the hook to maintain that code. We may not be the right experts for maintaining it. Issues will be filed against our repo, and we may not be the best people to fix this issue.
• We don't think this is scalable because we can imagine a world where many people will want to add many features to our monorepo, and we would be on the hook to maintain it. A more distributed way of doing this would be better.

Option 2: Merge this into Qwik Labs

• This would be better as it would mean that we don't have to worry that it is of v1.0 quality.
• However, it still means that we would be on the hook to maintain the code. Issues would be field with us etc...

Option 3: Have a community organization

• Have a https://github.com/QwikDev organization that can publish to @qwikdev/____ The nice part of the org is that it still has the "seal" of Qwik without passing on the cost to the Qwik core maintainers.
• This way, the core Qwik team is not on the hook to support the feature long time (as most of the time, they are not the experts)
• Qwik core team is not involved in having to review the PR and make a judgment call if the quality is good enough (given that hey are not the experts in that area)

---

Would love to hear your thoughts.

[gioboa]

I close this PR because it's stale. @raymondmuller thanks for your commitment.