ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development

Shameless plug; I'm the author. Criticism welcome.

I use this for client-side includes and web components.

No build process, no web-packer, no framework, no npm requirement. Just include the JS in your HTML and then you can create and include components.

>No build process, no web-packer, no framework, no npm requirement. Just include the JS in your HTML and then you can create and include components.

How does the rest of your codebase look?

This is the primary problem with web components. No frameworks sounds nice in theory, but it only solves about 30% of the problem. The rest ends up an ad-hoc mixture of libraries and custom code for state management, routing, styling, cross-component communication, etc, to the point that you end up building your own framework that is brittle and unmaintainable. Applications like this generally end up as a huge confusing web of global event buses or with multiple tightly coupled layers of prop drilling because of that.

There was a dream that was web components once upon a time. It felt like the future. But the APIs ended up half implemented (poorly), and the spec was more or less abandoned by everyone but Google. Browser vendors could have done things right, and focused on pulling in the good things from the framework world (i.e. what happened with jQuery), but they didn't.

This is cool. Remindes me of simplicity of https://tg.pl/drab which need phoenix/elixir.

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

I'm guess that since this is an academic paper and not say, a website or GitHub repo, that you're in school. But given the research paper nature of this, did you want to contrast and compare to other methods of authoring web components?

There are many existing and popular approaches out there. Is your take easier, faster, or more capable? That discussion would be interesting.

Two that I help maintain are Lit (https://lit.dev) and Heximal (https://heximal.dev/). Of those, Heximal might share the most with Zjs.