Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arxiv.org

Post reply on HN
Print view View original

31–40 of 65 posts

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

#31

Post by lelanthran »

mosdl wrote: post #16

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.

> 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] Not "done on a bet", but pretty similar.

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

#32

Post by lelanthran »

spankalee wrote: post #10
lelanthran wrote: post #2

Shameless 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'm guess that since this is an academic paper and not say, a website or GitHub repo, that you're in school. But given the research paper nature of this, did you want to contrast and compare to other methods of authoring web components? There are many existing and popular approaches out there. Is your take easier, faster, or more capable? That discussion would be interesting. Two that I help maintain are Lit ( https:…

> I'm guess that since this is an academic paper and not say, a website or GitHub repo,

It is a github repo. And a website too, IIRC. And now, finally, it is a paper as well.

I haven't been evangelising this as I have no burning desire for popularity. I posted the link here for discussion and criticism.

> that you're in school.

I wish. I've been professionally developing (i.e. getting paid for it) for close on to 30 years now (I am almost 50).

I like Lit, but was not aware of heximal. Will check it out.

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

#33

Post by WorldMaker »

lelanthran wrote: post #29
WorldMaker wrote: post #24

Earlier quoted context omitted.

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…

> Sure, a lot of cross-component communication and some of state management goes back to DOM APIs and DOM event management, but there used to be a lot of knowledge in those areas and maybe it past time to return to Vanilla JS ideas about some of that. My approach is, actually, an attempt to inject some Vanilla into front-end component development.

I think many of us, as this linked article that kicked off this discussion included, are thinking of various ways of using more Vanilla approaches. I appreciate the above poster's complaints that we aren't in some promised land of being able to do things 100% Vanilla without some form of reactivity management. That's still all in progress, no matter where you are in the Observables versus Signals "debate", Browsers are back to showing interest in native specs for one or both. (I personally think Signals are just "worse, poorly encapsulated Observables", but either proposal is a good building block for whatever the next steps are and thinner libraries to build on top of them will be.) But Web Components are mostly some steps in the right direction, I think, while that other work remains ongoing.

I also like gradual typing too much to expect to be 100% Vanilla any time soon. Typescript is too handy a verification/testing tool and while I'm still watching the native type stripping proposal with TC-39 with a lot of interest, it's certainly not on a fast track.

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

#34

Post by lelanthran »

fayten wrote: post #7
lelanthran wrote: post #2

Shameless 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…

> Is there a particular reason you prefer this approach?

Compared to Lit? Firstly, I like Lit. My approach is better for me because there are far fewer things to know in order to create a reusable object and there are far fewer things to know in order to use an existing object.

IOW, my approach trades off functionality in favour of a lower cognitive burden for me. I just wanted something that had the minimum functionality I need - create an object and then reuse it. For me, anything outside of that goal is peripheral burden that I'd rather not get bogged down in.

I agree with many here that this is not an approach for them, maybe even for most, but I am certain that if I find something useful that increases my velocity of feature delivery, then maybe someone else will as well.

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

#36

Post by SoKamil »

lelanthran wrote: post #31
mosdl wrote: post #16

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.

> 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.

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

#37

Post by croemer »

SoKamil wrote: post #36
lelanthran wrote: post #31

Earlier 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.

He has maybe mentioned to someone that he'll write a paper on this topic

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

#38

Post by notnullorvoid »

sandreas wrote: post #14

I 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.

Older Svelte versions may not have needed a runtime, but Svelte 5 definitely does.

Runtimes are good, the abilities of web components suck compared to most framework runtimes.

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

#39

Post by spankalee »

WorldMaker wrote: post #24
ramesh31 wrote: post #4

Earlier 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…

Angular has nothing to do with web components. It isn't even a way to write web components.

If anything is the "Google blessed" way of writing web components (Google doesn't really work that way), it's Lit: https://lit.dev/

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

#40

Post by WorldMaker »

spankalee wrote: post #39
WorldMaker wrote: post #24

Earlier quoted context omitted.

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…

Angular has nothing to do with web components. It isn't even a way to write web components. If anything is the "Google blessed" way of writing web components (Google doesn't really work that way), it's Lit: https://lit.dev/

I'm aware of Lit and thought about mentioning some of its past versions too from the pre-spec era, but I think those are even more forgotten.

Around Angular 8-14 era Angular had a lot of "Angular is Web Components" marketing and assured devs at the time that the Angular way including CSS Modules support and its HTML Template language (and its super complex compiler) were "browser standards and the future of Web Components". Obviously none of that played out, CSS Modules are still in spec debate, the TEMPLATE tag was much simplified and no "template language" has been knighted as "the template language". But it was all so heavily marketed and it left scars in what people think of when they think of Web Components. People still expect CSS Modules. People still expect some sort of "blessed" template language out of the box for "Vanilla templating". Among other curious decisions by people marketing Angular to developers as a way to prepare for Web Components. (We can talk for hours about everything wrong with Zone.js and why it has taken Angular to version 20 to start to undo a lot of that [brain]damage.)

Lit was never quite so extreme in its worst pre-spec days, and it is useful for its templating language looked different enough from Angular's to, even at the time, prove that Angular's template language was neither HTML nor necessarily the template language to be knighted by Web Components. But it still had some versions with questionable Google-only decisions that are best forgotten today, and apparently easily forgotten today.

Of course, you don't have to take my anecdata on it, the sources still exist. If only Google made a search engine that works in 2025 maybe you could even find them.

Post reply on HN