For anyone curious, the source code: https://github.com/lelanthran/ZjsComponent/
ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
11–20 of 65 posts
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#12I came across Yoffee, also requires no specific build system or dependencies. Proposes to either code native web components, or not. No web components means instances are used to get fragments, and still support a state store. Not only one state store can be passed over to instance, as many as we want.
Can you compare with ZjsComponent?
Pure html and JavaScript from my experience is a relief, I still stuff the trauma of seeing jsx error cluttering the console with barely anything useful to troubleshoot.
How doé ZjsComponent compare, any advantage with your paradigm?
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#13Shameless plug; I'm the author. Criticism welcome. I use this for client-side includes and web components. 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.
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…
With the caveat that I’m generally outside of the web dev sphere aside from casual tinkering: no build process means no setup and one fewer thing that can break. That’s valuable in itself.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#14I like vanilla components... Personally I think that instead of providing either frameworks or vanilla compnents, frameworks should provide a way to compile components to independant vanilla JS (similar to svelte not needing a "runtime").
This way it would not matter this much how you deploy components and this compiling step could probably have its own API with hooks and callbacks.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#15Shameless plug; I'm the author. Criticism welcome. I use this for client-side includes and web components. 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.
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…
Excellent comment; it's well-informed, accurate, and actionable feedback. Agreed 100%.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#16Seems 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.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#17Shameless plug; I'm the author. Criticism welcome. I use this for client-side includes and web components. 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.
>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…
> the spec was more or less abandoned by everyone but Google
This is very, very much not true.
All browsers are very up-to-date with web components APIs, and Safari is leading in some areas like scoped custom element registries, which they're about to ship first.
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#18Shameless plug; I'm the author. Criticism welcome. I use this for client-side includes and web components. 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.
>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…
Disagree, done several custom frameworks for highly regulated areas and high load userbases - and as long as you keep to seperation of concerns it is a lot more nimble and long term viable - easy to wield that 200000 dependencies just to set a history state
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#19Earlier 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…
Excellent comment; it's well-informed, accurate, and actionable feedback. Agreed 100%.
Just use lit, and build to vanilla
Re: ZjsComponent: A Pragmatic Approach to Reusable UI Fragments for Web Development
#20[deleted]