Web Components Aren't Framework Components
kgscialdone.substack.com
Web Components Aren't Framework Components
1–10 of 42 posts
Re: Web Components Aren't Framework Components
#2So for example, some of the HTML in the "template:" section of a VueJS component would be tags which are defined by web components...
Re: Web Components Aren't Framework Components
#3I read the article and I am trying to understand it better. So do you mean that Web Components should be used just like normal HTML to code Component, together with frameworks such as VueJS or React? So for example, some of the HTML in the "template:" section of a VueJS component would be tags which are defined by web components...
A framework component is effectively a reusable block of code. It's an organizational principle more than anything; modular and reusable, but not meaningful to the browser in its own right once rendered. A web component, on the other hand, is very literally a new HTML element, and is treated by the browser as such. Once defined, the browser itself sees that component as a meaningful entity in its own right.
While the difference between those two ideas is fairly subtle on the surface, there's a whole nest of smaller differences that result from it. For just one example, web components are perfectly AJAX-compatible with no extra strings attached - you simply add the HTML tag representing a component to the DOM, and it works out of the box, no matter when or from where you got it. Achieving that with a framework component requires some additional work at best, which may or may not have been done for you by the framework authors.
That's not to say one is necessarily better than the other either, to be clear - they're just different, and treating them as if they were the same does both a disservice.
Re: Web Components Aren't Framework Components
#4On nice use, that took me maybe 30m to code up, is a `` element.
simply retrieves the specified file and adds it to the DOM where the `remote-fragment` is declared.No need for server-side scripting to include common parts of the HTML page.
There's a bunch of similar use-cases currently satisfied by fat client frameworks or server-side languages that simply go away when you have custom elements.
So, yeah, you can do components with webcomponents they way you do much of react components, but there's some stuff that you can do with webcomponents that just makes life a little bit better[1].
[1] Experimenting with propagating state throughout a (client-side) application using only declarations in HTML, with custom elements performing stuff.
Re: Web Components Aren't Framework Components
#5I read the article and I am trying to understand it better. So do you mean that Web Components should be used just like normal HTML to code Component, together with frameworks such as VueJS or React? So for example, some of the HTML in the "template:" section of a VueJS component would be tags which are defined by web components...
I think if you are new to webcomponents[1] it might help if you list all the useful functionality you get from a front-end framework, and look up how to achieve the same thing using webcomponents (Custom element, templates, slots).
[1] As I am. I am, in fact, new to front-end in general.
Re: Web Components Aren't Framework Components
#6I read the article and I am trying to understand it better. So do you mean that Web Components should be used just like normal HTML to code Component, together with frameworks such as VueJS or React? So for example, some of the HTML in the "template:" section of a VueJS component would be tags which are defined by web components...
Not exactly. While they can be used in tandem, I'm not necessarily suggesting that they should be; rather, the two serve different purposes and solve different problems. A framework component is effectively a reusable block of code. It's an organizational principle more than anything; modular and reusable, but not meaningful to the browser in its own right once rendered. A web component, on the other hand, is very li…
I think that, for me as a newcomer to front-end development, this is the biggest takeaway: a framework component is a reusable block of javascript while a webcomponent is a reusable HTML element.
As a newcomer[1] it does not make sense to even learn the front-end frameworks. As an example, the time spent in learning the entire framework simply so I can 'watch' an element's value for changes, or propagate an element's changed value to other elements is going to be order of magnitudes greater than simply writing 3 custom elements that monitor and propagate values for any child element.
(PS. I like your post. I think a followup blog post with two concrete examples may make sense in refining your thesis:
Example 1. This is a popular React mechanism to do $FOO, here's how it is easier in a webcomponent.
Example 2. This is a complex webcomponent, here's how it is easier in React.)
[1] One who is not looking to put "react", "vue", etc on their CV.
Re: Web Components Aren't Framework Components
#7I've found much use out of custom elements. On nice use, that took me maybe 30m to code up, is a ` ` element. simply retrieves the specified file and adds it to the DOM where the `remote-fragment` is declared. No need for server-side scripting to include common parts of the HTML page. There's a bunch of similar use-cases currently satisfied by fat client frameworks or server-side languages that simply go away when yo…
Re: Web Components Aren't Framework Components
#8I've found much use out of custom elements. On nice use, that took me maybe 30m to code up, is a ` ` element. simply retrieves the specified file and adds it to the DOM where the `remote-fragment` is declared. No need for server-side scripting to include common parts of the HTML page. There's a bunch of similar use-cases currently satisfied by fat client frameworks or server-side languages that simply go away when yo…
It seems like you reinvented Edge Site Includes ( https://en.m.wikipedia.org/wiki/Edge_Side_Includes ).
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 `
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)
Re: Web Components Aren't Framework Components
#9I've found much use out of custom elements. On nice use, that took me maybe 30m to code up, is a ` ` element. simply retrieves the specified file and adds it to the DOM where the `remote-fragment` is declared. No need for server-side scripting to include common parts of the HTML page. There's a bunch of similar use-cases currently satisfied by fat client frameworks or server-side languages that simply go away when yo…
Re: Web Components Aren't Framework Components
#10I read the article and I am trying to understand it better. So do you mean that Web Components should be used just like normal HTML to code Component, together with frameworks such as VueJS or React? So for example, some of the HTML in the "template:" section of a VueJS component would be tags which are defined by web components...
Not exactly. While they can be used in tandem, I'm not necessarily suggesting that they should be; rather, the two serve different purposes and solve different problems. A framework component is effectively a reusable block of code. It's an organizational principle more than anything; modular and reusable, but not meaningful to the browser in its own right once rendered. A web component, on the other hand, is very li…
So is a web component…