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

One major benefit of not having a build process is that you can make changes and instantly see the result without delay.

Thanks to the availability of ChatGPT and Claude, I have actually checked all those links prior to creating my own.

The ZjsComponent thing I use is unlike those things; while the goal of those (and other similar projects) is primarily to perform client-side includes, the goal of zjs-component is to provide client-side object instantiation using a remote object definition.

The paper itself may be a bit arcane and obscure, but as a quick example of what zjs-component was intended to do, see the GH page: https://github.com/lelanthran/ZjsComponent/tree/master?tab=r...

As you'll see from the above link, the goal was not to simply include remote fragments (with some execution behaviour), but to instantiate a local instance of an object defined in a remote file fragment and support instance-scoped code and HTML.

IOW, it's the scoping to a specific instance that is different from the existing `include` or `import` libraries.

It means when you do this (assuming you wrote a counter-obj.zjsc object):

You will get two independent instances of the counter object, each with their counter variables scoped to their own instance, and each with their HTML scoped to their own instance.

How is this different to the standard WebComponents then?

I mean, web components are JS with HTML in them and you have all the power of JS to manage state and functionality. In case of zjs you have HTML with JS in it and you get an entry point callback to set up your instance (and another to clean it up).

BTW, the API is a little awkward (`exports.onConnect = function () { /.../ }`) and easy to mix up with the standard syntax (`export function onConnect() { /.../ }`) which you can't actually use here.

In either case you have to include a script into your page to make the component work. But also when you have many different components in case of regular webcomponents you use a somewhat readable markup:

With zjs you have to use the same tag for everything:

To me this looks not unlike the primordial div soup. And on top of it it's 1 more request as compared to regular webcomponents.

The point is if HTML inclusion is not the main feature, but rather the per-instance state then regular WebComponents seem like a better solution if only for being a standard. When a reader sees a WebComponent they immediately know what they're dealing with. zjs appears to solve the same problem but differently, yet uses WebComponint API itself.

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.

Lit has always supported plain JS ways of authoring components. Just because it also supported TypeScript and Babel decorators doesn't make it "pre-spec".

Lots of developers like decorators, we gave them the option. _shrug_