Comment by dfabulich | Hacker News Reader

Comment by dfabulich | Hacker News Reader

Parent Full thread

Zjs 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/

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

Why use ZJS instead of HTMX?

> Why use ZJS instead of HTMX?

Because it does one thing and one thing only: instantiate an HTML element object. You literally cannot write a book about zjs-component the way it was done for HTMX: you'd be done on page one after demonstrating how zjs-component works!

To me there is value in lowering the cognitive burden this significantly; while HTMX is indeed a lower burden than almost everything else, zjs-component is even lower and gets you 80% (or more) of the way there.

You may disagree that the trade-off is worth it, but in many contexts the trade-off is certainly worth it.

In any case, with the way I use zjs-component, all I use are static files for the fragments (fragments are not generated by the server).

When I used HTMX the fragments returned in response to a request were almost never static files, they were all generated on the server (in Go, if you must know) so values could be interpolated. This, by its very nature, is not reusable.

When I create a component that is a zjs-component, the calls it makes to hydrate itself gets data in the responses (JSON, or similar), not HTML. It means that I write an object that has a snippet of HTML, has Javascript that is scoped to that object, and has DOM calls that can be scoped to that specific instance of the object.

HTMX has no scoping or containment of of the code in the HTML, nor can code in a fragment be written to only nagivate/search the DOM in that specific instance because HTMX does not have instances of objects.

The whole reason I use zjs-component over something like HTMX is because zjs-component has the concept of "Objects" (containing HTML and methods), "Instances" which are isolated from each other and a way to instantiate these objects in a page using nothing more than `<zjs-component remote-src='some/remote/path/SomeObject.zjsc'>`.

It is clear to me that having an object containing HTML and methods, with instances isolated from each other, is not of value to you. Even though you do not find value in the trade-off it offers, you must understand that HTMX is not a replacement for zjs-component, and zjs-component is not a replacement for HTMX.

Some of what zjs-component offers cannot be done easily in HTMX (like having nothing but static files for defining objects, scoping DOM nav to the instance of the object that is running that method, etc), and some of what HTMX does cannot be done in zjs-component (such as interpolating values into a template) because it makes no sense to do so in the context of zjs-component.

Seeing as how neither is able to replace the other, why the fixation on HTMX as a replacement for zjs-component?

Excellent comment; it's well-informed, accurate, and actionable feedback. Agreed 100%.

Just use lit, and build to vanilla

Reply on news.ycombinator.com