Seems to be taking how old frameworks used to work in the old days (download some html/js and run in an closure) and wraps it into webcomponents. Neat, but not sure why its a paper.
[deleted]
ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
41–50 of 65 posts
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#42Earlier quoted context omitted.
>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, styl…
I think Google has done a great job of making Web Components seem both poorly implemented and way too complex. If Angular is the "Google blessed" way of writing Web Components and Angular makes a terrible hash of it, who can build good Web Components? Angular and a couple other well known frameworks were targeting for far too long pre-spec Google-specific versions of Web Components and Web Components moved quickly pa…
I haven't had too much trouble with Shadow DOM so far, and I was especially surprised to learn about `` recently. It makes SSR rendering of web components with shadow DOMs viable and appears to be well supported in browsers.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#43It’s remarkable that you can write a paper about a 100 lines of code (literally). Maybe I should try that some time.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#44It’s remarkable that you can write a paper about a 100 lines of code (literally). Maybe I should try that some time.
One of John Nash's most famous paper's is 1 page: https://www.pnas.org/doi/abs/10.1073/pnas.36.1.48
Large systems is not a requirement for novelty.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#45Earlier quoted context omitted.
> Neat, but not sure why its a paper. I have a very good reason for that[1]. I will, however, concede that this approach might have been used somewhere public in the past, even though I have no knowledge of seeing this approach previously. A poster downthread mentioned a link that I am going to read up when I have time, that seems like it is the same approach as zjs-component. ----------------------------------- [1]…
Okay, but what is the reason? I didn't understand it from your comment.
As I said elsewhere:
> Posting on Arxiv is a great way to signal that you don't intend to monetise something, aren't pretending to be an influencer and not posing as some thought leader.
In short, I'm not trying to build a community, I'm not trying to get followers, I'm not trying to build an email list.
I want to publish something to the world, but I'm not going to run the gauntlet of peer review publishing.
Arxiv aligns with my goal for this.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#46Earlier quoted context omitted.
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 d…
That's a lot you wrote, thank you for all that effort and time. I will do my best to address them: > Client-side includes are bad. The industry avoids them, for good reasons. The industry we are talking about does lots of things that has caused many to consider "the industry" to be something of a running joke. You may not like client-side includes, but it really is something useful to have. Wanting to have client-sid…
Why use ZJS instead of HTMX?
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#47Earlier quoted context omitted.
That's a lot you wrote, thank you for all that effort and time. I will do my best to address them: > Client-side includes are bad. The industry avoids them, for good reasons. The industry we are talking about does lots of things that has caused many to consider "the industry" to be something of a running joke. You may not like client-side includes, but it really is something useful to have. Wanting to have client-sid…
Why use ZJS instead of HTMX?
> Why use ZJS instead of HTMX?
Because it does one thing and one thing only: instantiate an HTML element object. You literally cannot write a book about zjs-component the way it was done for HTMX: you'd be done on page one after demonstrating how zjs-component works!
To me there is value in lowering the cognitive burden this significantly; while HTMX is indeed a lower burden than almost everything else, zjs-component is even lower and gets you 80% (or more) of the way there.
You may disagree that the trade-off is worth it, but in many contexts the trade-off is certainly worth it.
In any case, with the way I use zjs-component, all I use are static files for the fragments (fragments are not generated by the server).
When I used HTMX the fragments returned in response to a request were almost never static files, they were all generated on the server (in Go, if you must know) so values could be interpolated. This, by its very nature, is not reusable.
When I create a component that is a zjs-component, the calls it makes to hydrate itself gets data in the responses (JSON, or similar), not HTML. It means that I write an object that has a snippet of HTML, has Javascript that is scoped to that object, and has DOM calls that can be scoped to that specific instance of the object.
HTMX has no scoping or containment of of the code in the HTML, nor can code in a fragment be written to only nagivate/search the DOM in that specific instance because HTMX does not have instances of objects.
The whole reason I use zjs-component over something like HTMX is because zjs-component has the concept of "Objects" (containing HTML and methods), "Instances" which are isolated from each other and a way to instantiate these objects in a page using nothing more than ``.
It is clear to me that having an object containing HTML and methods, with instances isolated from each other, is not of value to you. Even though you do not find value in the trade-off it offers, you must understand that HTMX is not a replacement for zjs-component, and zjs-component is not a replacement for HTMX.
Some of what zjs-component offers cannot be done easily in HTMX (like having nothing but static files for defining objects, scoping DOM nav to the instance of the object that is running that method, etc), and some of what HTMX does cannot be done in zjs-component (such as interpolating values into a template) because it makes no sense to do so in the context of zjs-component.
Seeing as how neither is able to replace the other, why the fixation on HTMX as a replacement for zjs-component?
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#48It’s remarkable that you can write a paper about a 100 lines of code (literally). Maybe I should try that some time.
One of John Nash's most famous paper's is 1 page: https://www.pnas.org/doi/abs/10.1073/pnas.36.1.48 Large systems is not a requirement for novelty.
OP doesn’t feel that novel. I read the code and it all has been done before.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#49Earlier quoted context omitted.
One of John Nash's most famous paper's is 1 page: https://www.pnas.org/doi/abs/10.1073/pnas.36.1.48 Large systems is not a requirement for novelty.
OP doesn’t feel that novel. I read the code and it all has been done before.
> 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.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#50Earlier quoted context omitted.
>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, styl…
I think Google has done a great job of making Web Components seem both poorly implemented and way too complex. If Angular is the "Google blessed" way of writing Web Components and Angular makes a terrible hash of it, who can build good Web Components? Angular and a couple other well known frameworks were targeting for far too long pre-spec Google-specific versions of Web Components and Web Components moved quickly pa…
TLDR: Browser vendors made Shadow DOM for themselves.
Browser implementors use Shadow DOM extensively under the hood for built-in HTML elements with internal structure like range inputs, audio and video controls, etc. These elements absolutely need to work everywhere and be consistent, so extreme encapsulation and fixed api for styling them is an absolute must.
The Shadow DOM API is the browsers exposing, to developers, a foundational piece of functionality.
If you’re thinking about whether Shadow DOM is appropriate for your use case, consider how/why the vendors use it —- when an element’s API needs to be totally locked down to guarantee it works in contexts they have no control over. Conversely, if your potential use case is scoped to a single project, the encapsulation imposed (necessarily!) by Shadow DOM is probably overkill.
Web components are a decent way to make reusable UI, but if they don’t have strong encapsulation needs, you might avoid Shadow DOM.