HN Distilled

Essential insights from Hacker News discussions

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

Original Article

Hacker News Discussion

Concerns about Performance and Client-Side Includes

Several commenters voiced concerns about the performance implications of using client-side includes, which is a core aspect of the Zjs-component's functionality. These concerns center around potential latency issues and layout shifts.

  • "Client-side includes are bad. The industry avoids them, for good reasons... If your components are nested at N layers, this means that the page won't finish loading until N serial non-parallelizable requests succeed. On cellular networks, where network latency can be measured in seconds, if you have four layers of components, you're looking at adding 10+ seconds to page load." (dfabulich)
  • "each client-side include will cause a layout shift, as the <zjs-component> element starts out at 0px tall, and then will change in height as the component loads. This is bad." (dfabulich)

Lelanthran responded that this is a known limitation and trade-off, particularly relevant for internal Line-of-Business applications.

  • "I agree. It's a trade-off that many sites currently make, SPAs included. While I find it incredibly annoying, this component is for when that trade-off decision is already made." (lelanthran)
  • "Even the most complex UI in these LoB applications have only a few different components, and at most two levels of nesting (these component objects are not like React components at all - they're meant to be instanced inline in HTML, which is both a drawback and an advantage)." (lelanthran)

The "No Build Process" Appeal and the Framework Debate.

A central theme is a discussion about the value and limitations of a "no build process" approach, and its place relative to frameworks. Some see value in the simplicity and reduced complexity, while others argue that it only solves a small part of the overall problem of modern web development.

  • ">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, styling, cross-component communication, etc, to the point that you end up building your own framework that is brittle and unmaintainable." (ramesh31)
  • "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." (cosmic_cheese)

The original author clarified the intention behind the "no framework" claim. * ""No framework" is not meant to be a prescription, it is an indication of the dependencies. IOW, I mean to say "No framework required", I did not mean to say "Don't use a framework with zjs-component"."(lelanthran)

Web Component Standards and Shadow DOM.

The implementation and adoption of web component standards, particularly the Shadow DOM, is a topic of discussion. Some argue that the standards have been poorly implemented or abandoned, while others assert that they are actively maintained and offer valuable features.

  • "There was a dream that was web components once upon a time. It felt like the future. But the APIs ended up half implemented (poorly), and the spec was more or less abandoned by everyone but Google." (ramesh31)
  • ">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." (spankalee)
  • "So much of the Web Components world is stuck with the quagmire of the Shadow DOM, and while there are some generalized use cases for the Shadow DOM, I have the harsh opinion that the Shadow DOM was mostly invented to be 'better IFRAMES for Ad Publishers' and not much else. I don't think enough web developers yet realize that the Shadow DOM is entirely optional and its complexity is so much easier to ignore and toss than to try to utilize." (WorldMaker)

One user suggests web components can be useful, if one ignores Shadow DOM.

  • "I was bullish on Web Components for a while, but most of my complaints have disappeared in recent months, and especially in realizing that I was very happy ignoring everything about the Shadow DOM. Sure, I'm not using Web Components without a "framework" but I'm using a far smaller "view engine" than a React or Angular, a lot more "Vanilla", and feeling a bit like it's a Revenge of Knockout sort of era." (WorldMaker)

Comparisons to Existing Libraries and Frameworks.

Several commenters suggest alternative libraries and frameworks that offer similar functionality or address the identified concerns. These suggestions include Lit, Heximal, HTMX, and others.

  • "Just use lit, and build to vanilla" (bythreads)
  • "HTMX is a lightweight framework that provides a reactivity framework around client-side includes." (dfabulich)
  • "Two that I help maintain are Lit (https://lit.dev) and Heximal (https://heximal.dev/). Of those, Heximal might share the most with Zjs." (spankalee)
  • "Also Facet.js! Almost declarative to a fault." (dleeftink)
  • "I came across Yoffee, also requires no specific build system or dependencies" (hirako2000)

Justification for Publication/Paper

Some commenters expressed confusion or bafflement as to why ZjsComponent was presented as a research paper. * "Neat, but not sure why its a paper." (mosdl) * "Yea, I feel like we are coming full circle with frontend JavaScript. To me this seems like a concept that has been around a while, but it’s being presented as a novel idea. I’m also baffled as to why it’s a paper." (coneonthefloor) * "Spankalee" guessed that the author was in school.

Lelanthran said there was a very good reason for the 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...[1] Not "done on a bet", but pretty similar." (lelanthran)

Vanilla JS

Several contributors commented that they prefer "vanilla" Javascript, and the original author aimed to promote this approach.

  • "> 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." (lelanthran, quoting WorldMaker)
  • "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." (hirako2000)
  • "I like vanilla components..." (sandreas)