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.

I always love seeing more done in the web component space. I think Lit has the no build process captured pretty well and they include things such as a router.

I do prefer the style of of your components more, where you separate out the script and styles with html tags. I don't know if one way or the other is superior for performance, I but just like the separation verse the templated strings in Lit.

With build tools being so straightforward now-a-days, I struggle to see the value in the build less approach. One use case I can think of is maybe a constrained environment where the application contains some kind of customizable user components fully in the browser like a reporting WYSIWIG of some kind.

Is there a particular reason you prefer this approach?

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/

>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 great! A few comments/questions if you have time to respond:

1) I thought that React already worked this way until I learned it, and was horrified. Similar disillusionment with Ruby on Rails, Objective-C on iOS and Java on Android. Why someone would want to mix code and markup, rather than define components via code to be used within markup, blows my mind. Said as someone who uses PHP daily and sees JSX as its frontend analog.

2) I appreciate that async/await and promises were deliberately left out of the spec. I view their use as an anti-pattern, since I've programmed both async/nonblocking and sync/blocking sockets logic, and view sync as far superior if deterministic behavior is the goal. I know this is a contentious subject, but IMHO async will someday be considered the goto of the web and be deprecated across most languages. Better approaches such as scatter/gather arrays, coroutines and channels (like in Go) exist to remove the temporal/imperative aspect of logic and make it declarative without requiring red/blue functions.

3) The main problem I've encountered with React is that it's nearly untraceable in web inspector. It's impossible to tell which component object instance is associated with an HTML element. It's hard to tell where attribute values came from, unlike function arguments: are they props that aren't declared in a function prototype? are they magically mapped from redux state? are they derived neither in the constructor nor componentDidMount() or affected by an affect they weren't supposed to be? etc etc etc. Component methods are buried in dozens of anonymous functions and boilerplate. Promise values can't be inspected until their then() method without using tricks like Promise.resolve(), which don't always match intuition. Redux state can't be conveniently inspected without adding debug lines to the source code and/or installing a browser extension. Code gets mutated by the build pipeline so it's hard to find code snippets to set breakpoints. I could go on. Have you found ZjsComponent easier to debug, and if so, how?

4) I applaud your use of caching for client-side includes. IMHO much of the complexity of React is around its deliberate rejection of HTTP idioms and metaphors. We already solved these problems declaratively in the mid 1990s, why are we manually managing initialization and state, even if through Redux? That was a rhetorical question, but really, React doesn't seem nearly as reactive as something like a spreadsheet that just re-renders cells that reference cells that changed. Basically all of its component methods could be replaced by the render() method containing a JSX template, with the state boilerplate handled by the framework internally via declarative and data-driven techniques like observing variables for changes. Instead, they put the onus on developers, which wastes all of our time and sanity.

5) Do advanced use cases such as components built with other components, subresource integrity (SRI) and observing variables similarly to Vue.js watchers "just work"? I'd be curious to hear your vision for the future.

6) (Special mention) after driving myself crazy manually managing recycler views in iOS, Android and React, I wanted to highlight https://github.com/splinesoft/SSDataSources and https://github.com/SDWebImage/SDWebImage (no affiliation with either). The idea is to populate callbacks to handle the lifecycle of table view cells. That way, an array or generator in memory can be mapped to a table and automagically handle all scrolling and resizing edge cases. Including dynamically loading images and other async data with caching via SDWebImage, without crashing when navigating between view controllers that get disposed, while running as fast as possible. With these metaphors, all other GUI elements can be derived. These are the only frameworks that I've ever used that do all of this correctly. Which let me do declarative web-style programming natively by treating tables as already fully populated, rather than building rows and columns programmatically. Perhaps something in this could inspire a ZjsComponent that "just works" like an ordinary web table, but fast, without the memory hogging of the browser DOM or React's virtual DOM.