Comments (4)
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:
- Qwik Components as Web Components
- 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.
from qwik.
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
from qwik.
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.
from qwik.
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)
from qwik.
Related Issues (20)
- [β¨] API Routes support
- [β¨] Please let us disable __image__info HOT 6
- [π] Bug in Link component (SSG) HOT 18
- [π] Add a testing guide section HOT 2
- [π] Vite+Qwik JavaScript template preset not working HOT 1
- [π] Link component, automatically redirects when you put a URL that doesn't exist HOT 3
- Enhance Qwik CLI to allow migrating automatically from Qwik 1 the Qwik 2 HOT 9
- [β¨]Adding visual clue in the docs TOC HOT 16
- [π] The tagged function depending on the signal value doesn't make reactive. HOT 2
- [π] CSS modules not being linked in the build. HOT 3
- [π] Vanilla Node Server Adapter - Cannot find package 'undici' HOT 6
- [π] Form's onSubmit and onSubmitCompleted type definition broken HOT 1
- [π] How to access the current url / path from the root context HOT 3
- [π] `qwik-prefetch-service-worker.js` 404 in dev mode HOT 2
- [π] `q-bundle-graph-dev....json` 404 in dev mode HOT 3
- [π] PrefetchServiceWorker throws `insufficient resources` when navigating while prefetching HOT 7
- [π] 404s are thrown when interacting with the page in dev mode with the PrefetchServiceWorker
- [π] An unknown symbol is fetched in preview which returns a 404 with the PrefetchServiceWorker HOT 3
- [π] Getting "Failed to construct 'URL': Invalid URL" on nx monorepo on dev serve HOT 12
- [π] SyntaxError: The requested module `[email protected]` does not provide an export named 'renderToString' HOT 14
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from qwik.