Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Components Aren't Framework Components

kgscialdone.substack.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Web Components Aren't Framework Components

#21

Post by lelanthran »

Quekid5 wrote: post #19
lelanthran wrote: post #16

Earlier quoted context omitted.

What's the alternative other than simply doing without this feature?

E.g. Apache's Server Side Includes[0] allows for Tbf, you did specify 'server language' in a post further up the comment chain, but the the thing is that it doesn't have to be much more complicated that SSI -- assuming it's available for your deployment target, of course. (SSI obviously does not require JavaScript.) [0] https://httpd.apache.org/docs/current/howto/ssi.html

I've used those before, but I feel that having something that works within the spec, independent of any particular implementation's extensions is much more valuable for longevity.

Sure, you can use $A if using $B server, or use $C when using $D language, or use $E when using $F framework, or use $G when using $H reverse-proxy, or use $I when using $J CDN, or use $K when using $L hosted cloud service ...

Or you can just use what's in the specification which works on all of the above, but won't work on clients with Javascript disabled.

It's a "choose your poison" scenario.

Re: Web Components Aren't Framework Components

#22

Post by DylanSp »

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.

Re: Web Components Aren't Framework Components

#23

Post by DylanSp »

lelanthran wrote: post #4

I'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…

Can you elaborate a bit more on the example in your footnote about propagating client-side state? Does that provide functionality similar to Alpine.js's data objects/stores?

Re: Web Components Aren't Framework Components

#25

Post by mewpmewp2 »

lelanthran wrote: post #8
nesarkvechnep wrote: post #7

Earlier quoted context omitted.

It seems like you reinvented Edge Site Includes ( https://en.m.wikipedia.org/wiki/Edge_Side_Includes ).

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. Comple…

Technically you could also just write a bit of JS within the HTML to do without needing any of the first 3.

You could querySelectorAll and check the src attribute etc, then fetch the content put it in the innerHTML.

    

    

      document.querySelectorAll("remote-fragment").forEach(async (el) => {

        const src = el.getAttribute("src");

        const result = await fetch(src).then((res) => res.text());

        el.innerHTML = result;

      });
Or if you want to react to any such component inserted at times down the line or src attribute changes, you could use MutationObserver.

Re: Web Components Aren't Framework Components

#27

Post by KatrinaKitten »

vladsanchez wrote: post #24

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

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.

    
      htmx.process(root)

Re: Web Components Aren't Framework Components

#28

Post by mst »

lelanthran wrote: post #12
SkiFire13 wrote: post #11

Earlier quoted context omitted.

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

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.

I rather like https://lit.dev/ for web components so far.

For the reactivity stuff, you might want to read 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.

Re: Web Components Aren't Framework Components

#29

Post by jbergens »

lelanthran wrote: post #4

I'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…

Sounds like htmx.

https://htmx.org/essays/right-click-view-source/

Re: Web Components Aren't Framework Components

#30

Post by jbergens »

jbergens wrote: post #29
lelanthran wrote: post #4

I'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…

Sounds like htmx. https://htmx.org/essays/right-click-view-source/

Meant to link to the root but can't change now.

https://htmx.org/

Post reply on HN