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:
<x-counter start-at="100"></x-counter>
<x-counter start-at="200"></x-counter>
<x-whatever></x-whatever>
With zjs you have to use the same tag for everything:
<zjs-component remote-src='counter-obj.zjsc' start-at='100'></zjs-component>
<zjs-component remote-src='counter-obj.zjsc' start-at='200'></zjs-component>
<zjs-component remote-src='whatever-obj.zjsc'></zjs-component>
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.
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.