7 ms·

Web Components Aren't Framework Components

33 points by KatrinaKitten 3y ago

zubairq 3y ago
I 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...
- KatrinaKitten 3y ago
  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 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.
  - lelanthran 3y ago
    > A framework component is effectively a reusable block of code. 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.
    - SkiFire13 3y ago
      > than simply writing 3 custom elements that monitor and propagate values for any child element. I feel like you're underestimating how easy this is to skrew up.
      - lelanthran 3y ago
        You're probably correct in your assessment of my estimation. However, it's far far easier for a newcomer to screw up when approaching react or cue than when approaching a custom html element. Time will tell as I use my experiment in more domains, more often and in larger apps.
        mst 3y ago
        I rather like https://lit.dev/ https://lit.dev/ for web components so far. For the reactivity stuff, you might want to read https://frontendmasters.com/blog/vanilla-javascript-reactivity/ https://frontendmasters.com/blog/vanilla-javascript-reactivi... - it shows a bunch of no-library-required patterns that, while in a number of cases I'd much rather use a library myself, all seems at least -basically- reasonable to me and will probably be far more comprehensible to you than whatever I'd reach for, and frameworks are always much more pleasant to approach after you've already done a bunch of stuff by banging rocks together first.
    - DrScientist 3y ago
      > a framework component is a reusable block of javascript while a webcomponent is a reusable HTML element. Web components/custom elements are reusable behaviours/functions - which can contain custom js, all bundled as a reusable HTML element. Think of it a bit like an object in an object orientated programming language - the object has both data/state (DOM) and code/functions to manipulate that state.
  - youngtaff 3y ago
    > A framework component is effectively a reusable block of code. So is a web component…
    - lelanthran 3y ago
      Do you think that there is a distinction between "reusable block of JavaScript" and "reusable HTML element"? To me there is a larg distinction but I do concede that to others there may be no difference.
      - LudwigNagasena 3y ago
        Both Web Components and Framework Components utilize JS and HTML.
        lelanthran 3y ago
        > Both Web Components and Framework Components utilize JS and HTML. If you're writing them, certainly. For web designers, using Web Components means not having to know JS, not having to know React, not having to know hooks, not having to know usememo, etc. That's, to my mind, a large enough distinction: the requisite knowlege to reuse a framwork's components needs a full time developer. The knowledge required to reuse a web component is ... HTML (and maybe CSS?)
- lelanthran 3y ago
  > 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? 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.
lelanthran 3y ago
I've found much use out of custom elements. On nice use, that took me maybe 30m to code up, is a `<remote-fragment>` element. <remote-fragment src=/fragments/topbar.htmlf /> 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.
- nesarkvechnep 3y ago
  It seems like you reinvented Edge Site Includes (https://en.m.wikipedia.org/wiki/Edge_Side_Includes https://en.m.wikipedia.org/wiki/Edge_Side_Includes).
  - lelanthran 3y ago
    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)
    - nesarkvechnep 3y ago
      Refined the concept into the simplest form that works… as long as you have JavaScript enabled.
DylanSp 3y ago
It's not directly related to the article, but there's a question I've had for a while, related to this line: > [Framework components] usually consist primarily of JavaScript, with only a very thin layer of HTML and CSS to provide their structure and are usually compiled away on the server side before they ever reach the DOM [...] Is there any decent data on how many sites built with SPA frameworks end up using SSR, or even just anecdotal reports? A decent amount of what I read online seems to assume devs are using SSR, but I'm not sure if that's an accurate representation or just hype/pushing newer technology.
vladsanchez 3y ago
"Their JavaScript API is clunky, esoteric, and hard to understand for devs" I loved her opinion, I've always shared that sentiment but I was afraid of saying it. I also wish there was a way to develop such abstractions (WebComponents) with/in HTMX.
- KatrinaKitten 3y ago
  I actually recently contributed Shadow DOM support to the HTMX cobebase for 2.0! Once that drops, linking Facet and HTMX will only take a simple mixin. <template mixin="htmx" global> <script on="connect">htmx.process(root)</script> </template>
  - vladsanchez 3y ago
    Wow, just wow! 100x simplicity accomplished! THANKS a TON!!! <3
EricE 3y ago
A great example of their power is the US Web Design System (USWDS) https://designsystem.digital.gov https://designsystem.digital.gov
lakomen 3y ago
Author of such amazing discoveries like, the sun doesn't always shine and the sky isn't always blue. Are you new or something? Web components are so 2012
- KatrinaKitten 3y ago
  Thanks for filling my "only read the headline and made a snarky comment anyway" bingo square!

33 points by KatrinaKitten 3y ago

I 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...

KatrinaKitten 3y ago
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 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.
- lelanthran 3y ago
  > A framework component is effectively a reusable block of code. 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.
  - SkiFire13 3y ago
    > than simply writing 3 custom elements that monitor and propagate values for any child element. I feel like you're underestimating how easy this is to skrew up.
    - lelanthran 3y ago
      You're probably correct in your assessment of my estimation. However, it's far far easier for a newcomer to screw up when approaching react or cue than when approaching a custom html element. Time will tell as I use my experiment in more domains, more often and in larger apps.
      - mst 3y ago
        I rather like https://lit.dev/ https://lit.dev/ for web components so far. For the reactivity stuff, you might want to read https://frontendmasters.com/blog/vanilla-javascript-reactivity/ https://frontendmasters.com/blog/vanilla-javascript-reactivi... - it shows a bunch of no-library-required patterns that, while in a number of cases I'd much rather use a library myself, all seems at least -basically- reasonable to me and will probably be far more comprehensible to you than whatever I'd reach for, and frameworks are always much more pleasant to approach after you've already done a bunch of stuff by banging rocks together first.
  - DrScientist 3y ago
    > a framework component is a reusable block of javascript while a webcomponent is a reusable HTML element. Web components/custom elements are reusable behaviours/functions - which can contain custom js, all bundled as a reusable HTML element. Think of it a bit like an object in an object orientated programming language - the object has both data/state (DOM) and code/functions to manipulate that state.
- youngtaff 3y ago
  > A framework component is effectively a reusable block of code. So is a web component…
  - lelanthran 3y ago
    Do you think that there is a distinction between "reusable block of JavaScript" and "reusable HTML element"? To me there is a larg distinction but I do concede that to others there may be no difference.
    - LudwigNagasena 3y ago
      Both Web Components and Framework Components utilize JS and HTML.
      - lelanthran 3y ago
        > Both Web Components and Framework Components utilize JS and HTML. If you're writing them, certainly. For web designers, using Web Components means not having to know JS, not having to know React, not having to know hooks, not having to know usememo, etc. That's, to my mind, a large enough distinction: the requisite knowlege to reuse a framwork's components needs a full time developer. The knowledge required to reuse a web component is ... HTML (and maybe CSS?)
lelanthran 3y ago
> 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? 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.

lelanthran 3y ago

I've found much use out of custom elements. On nice use, that took me maybe 30m to code up, is a `<remote-fragment>` element. <remote-fragment src=/fragments/topbar.htmlf /> 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.

nesarkvechnep 3y ago
It seems like you reinvented Edge Site Includes (https://en.m.wikipedia.org/wiki/Edge_Side_Includes https://en.m.wikipedia.org/wiki/Edge_Side_Includes).
- lelanthran 3y ago
  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)
  - nesarkvechnep 3y ago
    Refined the concept into the simplest form that works… as long as you have JavaScript enabled.

DylanSp 3y ago

It's not directly related to the article, but there's a question I've had for a while, related to this line: > [Framework components] usually consist primarily of JavaScript, with only a very thin layer of HTML and CSS to provide their structure and are usually compiled away on the server side before they ever reach the DOM [...] Is there any decent data on how many sites built with SPA frameworks end up using SSR, or even just anecdotal reports? A decent amount of what I read online seems to assume devs are using SSR, but I'm not sure if that's an accurate representation or just hype/pushing newer technology.

vladsanchez 3y ago

"Their JavaScript API is clunky, esoteric, and hard to understand for devs" I loved her opinion, I've always shared that sentiment but I was afraid of saying it. I also wish there was a way to develop such abstractions (WebComponents) with/in HTMX.

KatrinaKitten 3y ago
I actually recently contributed Shadow DOM support to the HTMX cobebase for 2.0! Once that drops, linking Facet and HTMX will only take a simple mixin. <template mixin="htmx" global> <script on="connect">htmx.process(root)</script> </template>
- vladsanchez 3y ago
  Wow, just wow! 100x simplicity accomplished! THANKS a TON!!! <3

EricE 3y ago

A great example of their power is the US Web Design System (USWDS) https://designsystem.digital.gov https://designsystem.digital.gov

lakomen 3y ago

Author of such amazing discoveries like, the sun doesn't always shine and the sky isn't always blue. Are you new or something? Web components are so 2012

KatrinaKitten 3y ago
Thanks for filling my "only read the headline and made a snarky comment anyway" bingo square!