Comment by lelanthran
2 months ago
> OP doesn’t feel that novel. I read the code and it all has been done before.
Thank you for reading the code. Where was this done before?
A few projects were mentioned in this page (Yoffee, Lit, etc) but after closer examination none of them appear to be "define an object in simple terms, then use HTML to inline it", where object is "HTML fragment with methods in a script element that are scoped only to that specific instance of the fragment".
I'm curious to see prior usage.
There are quite a few HTML include components out there. A quick GH search return a lot of results.
From very simple (https://github.com/include-html/include-html.github.io/blob/..., from 3 years ago), to more sophisticated, including script execution (https://github.com/SirPepe/html-import/blob/master/src/html-..., from 4 years ago; or even https://github.com/webcomponents/html-imports/blob/master/sr..., dating back 9 years). I haven't checked all of them but there's a decent chance there's something that covers each feature of OP, maybe even at once.
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.
5 replies →