I like to think that I didn't reinvent it (just like react, et al didn't reinvent it), I only refined the concept into the simplest form that works :-)
After all, a custom element that takes a front-end newcomer 30m to write is absolutely preferable to a large infrastructure-based standard that, after 22 years, is still not included in the spec.
Look at the options for including HTML fragments in web pages:
1. Complex client-side react/vue/etc,
2. A server language ,
3. A build-step including a non-spec bundler/packer,
4. A `<remote-fragment src="..." />
My point is that webcomponents make quite a lot of complicated things redundant for particular use-cases. As time goes on I see the fat front-end frameworks having more of their functionality being replaced with less complex (to use) custom elements.
(Hence my experiments with value propagation using custom elements)
After all, a custom element that takes a front-end newcomer 30m to write is absolutely preferable to a large infrastructure-based standard that, after 22 years, is still not included in the spec.
Look at the options for including HTML fragments in web pages:
1. Complex client-side react/vue/etc,
2. A server language ,
3. A build-step including a non-spec bundler/packer,
4. A `<remote-fragment src="..." />
My point is that webcomponents make quite a lot of complicated things redundant for particular use-cases. As time goes on I see the fat front-end frameworks having more of their functionality being replaced with less complex (to use) custom elements.
(Hence my experiments with value propagation using custom elements)