alt Hacker NewsZjs is a web component for doing client-side includes. The Zjs code itself is itself a web component that extends HTMLElement and registers itself as <zjs-component>. It's only 100 lines long. In its connectedCallback, it fetches the URL of the "remote-src" attribute, and injects its content in innerHTML.
Client-side includes are bad. The industry avoids them, for good reasons.
First, they hurt performance. The client can't start downloading a zjs-component content until its connectedCallback runs. If a zjs-component includes another zjs-component, the client can't start downloading the nested component until its parent component downloads and executes. If your components are nested at N layers, this means that the page won't finish loading until N serial non-parallelizable requests succeed. On cellular networks, where network latency can be measured in seconds, if you have four layers of components, you're looking at adding 10+ seconds to page load.
Second, each client-side include will cause a layout shift, as the <zjs-component> element starts out at 0px tall, and then will change in height as the component loads. This is bad. https://web.dev/articles/cls
Finally, in your article, you claim that reactivity is "out of scope for a component creation mechanism," but there is no universally recognized "scope" for component creation. You'd need to justify the claim that reactivity is out of scope.
If you think reactivity matters at all, then you'd need to demonstrate how to use client-side includes in the context of a framework that does provide reactivity.
HTMX is a lightweight framework that provides a reactivity framework around client-side includes. https://htmx.org/ You might especially appreciate the academic theoretical framework the HTMX team provides in their book, Hypermedia Systems. https://hypermedia.systems/
HTMX is pretty good for what it does; it's not clear that anyone should prefer ZJS over HTMX for anything. But it's also not clear that HTMX is better than more frameworky alternatives, especially React Server Components.
Dan Abramov has written a series of articles explaining the theoretical framework behind RSC. Here's one that's relevant to you. https://overreacted.io/one-roundtrip-per-navigation/
Replies
Excellent comment; it's well-informed, accurate, and actionable feedback. Agreed 100%.
That's a lot you wrote, thank you for all that effort and time. I will do my best to address them:
> Client-side includes are bad. The industry avoids them, for good reasons.
The industry we are talking about does lots of things that has caused many to consider "the industry" to be something of a running joke.
You may not like client-side includes, but it really is something useful to have. Wanting to have client-side includes and not wanting to spin up an entire tech stack of 5 or so different technologies is not unreasonable.
> First, they hurt performance. [...] On cellular networks, where network latency can be measured in seconds, if you have four layers of components, you're looking at adding 10+ seconds to page load.
1. The first time, sure. It's 10s the first time those 4 components are downloaded. Any other component using any of those 4 components on the rest of that page, or if that page is reloaded, will have a 0s download.
2. On cellular networks I currently get longer wait times than that for SPAs used by the mainstream frameworks anyway today. I'm not losing any sleep over the pathological cases which affect mainstream frameworks and libraries as well.
3. I call it pathological because I feel that it would be an extreme case to have lots of components being downloaded, of which only a few get reused. The whole point to reusing is so that the component only gets downloaded once, even if used in multiple places.
> Second, each client-side include will cause a layout shift, as the <zjs-component> element starts out at 0px tall, and then will change in height as the component loads. This is bad. https://web.dev/articles/cls
I agree. It's a trade-off that many sites currently make, SPAs included. While I find it incredibly annoying, this component is for when that trade-off decision is already made.
> Finally, in your article, you claim that reactivity is "out of scope for a component creation mechanism," but there is no universally recognized "scope" for component creation. You'd need to justify the claim that reactivity is out of scope.
I'm a bit confused about this; if there is no universally recognised "scope" for creation of an object in an OO environment, why would I have to first define what scope is and then defend that decision? Most (all?) mainstream OO approaches don't have reactivity within scope for the definition of an object, so I feel that any claim that reactivity is within scope for this specific OO approach needs to provide some sort of reason why that an exception must be made for zjs-component so that it is measured against a higher bar than other OO approaches.
> HTMX is a lightweight framework that provides a reactivity framework around client-side includes. https://htmx.org/ You might especially appreciate the academic theoretical framework the HTMX team provides in their book, Hypermedia Systems. https://hypermedia.systems/
I've read those.
Regardless, if you are building an SPA with Facebook level number of components, then this is not for you. IOW, this may not suit your use-case, or even most of your use-cases. I find it suitable to an embarrassingly large number of use-cases, though.
I build Line-of-Business applications for internal use at companies. Even the most complex UI in these LoB applications have only a few different components, and at most two levels of nesting (these component objects are not like React components at all - they're meant to be instanced inline in HTML, which is both a drawback and an advantage).