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

Show HN: htmz – a low power tool for HTML

leanrada.com

Post reply on HN
Print view View original

211–220 of 256 posts

Re: Show HN: htmz – a low power tool for HTML

#211

Post by yawaramin »

simplify wrote: post #72
azornathogron wrote: post #20

This is a glorious demonstration of someone really understanding the platform. I don't expect I would ever use it, but I think it's excellent.

Understanding or not, certain decisions like overriding the semantic meaning of a hash in a url doesn't seem to be working with the platform. A better version would be adding a target to a `data-` attribute. It's a fun project overall, though.

But the hash doesn't have a semantic meaning when it is in an href or action attribute, because it is stripped out before the request is sent to the server. The hash only has a meaning when it's in the URL bar. That's kinda the point of this hack.

Re: Show HN: htmz – a low power tool for HTML

#212

Post by yawaramin »

kevincox wrote: post #134
Arch-TK wrote: post #9

Given that this uses `target`, doesn't it mean that unlike htmx you can't easily make this gracefully degrade when JS isn't enabled? And, yes, I know, saying "when JS isn't enabled" in 2024 is a bit like saying "when the user is on Mars and has a 10 minute RTT" but forgive me for being an idealist.

Not even just without JS. If you middle-click to open a link in a new tab you get just get content that was expected to be swapped in. I think that abusing links is a far bigger sin than adding a custom attribute.

This is why htmx sends requests by default with an HX-Request header so that the server can distinguish between them and serve different content if need be.

Re: Show HN: htmz – a low power tool for HTML

#214

Post by withinboredom »

pier25 wrote: post #206
withinboredom wrote: post #146

Earlier quoted context omitted.

Totally disagree as a regular user of 2g internet on a phone. If you are downloading a 1mb bundle to show me your home page, I'm going to give up within 30s or go elsewhere. I'm more than happy to put up with laggy feedback. That being said, usually people writing downloads using fetch will implement a promise-based timeout on top of the network timeout, which causes all kinds of issues on 2g internet. One of my favo…

1MB bundle of JS is definitely terrible. I'm not advocating that by any means :)

It happens more than anyone wants to admit, but even at 2g speeds, 256kb takes almost 20 seconds to download (I get about 120-180 kbps). When sites provide the HTML and CSS, I can usually stop the page from loading and at least read the content within a few minutes. When there's a js bundle, there is usually a fairly large initial bundle, then that loads a couple of other bundles ... and I'm still looking at a white screen, and not even a loading animation (from the browser or the developer) because as far as the browser is concerned, it has loaded the HTML and most developers don't even realize they can edit the base-line HTML sent to browsers because they never even see it.

Re: Show HN: htmz – a low power tool for HTML

#215

Post by RamblingCTO »

safety1st wrote: post #118
keepamovin wrote: post #41

This is great. I had an idea to use named iframes and targeted forms for simple, server-rendered pages with built-in style-scoped widgets, without leaning into complex JS client-side. But, I never simplified it well nor expressed a polished and elegant realization of that idea, as this htmz looks to me to be. A reminder to never give up good ideas, focus on excellence, and focus on refinement to a completion of an id…

I am a little bit confused because your comments seem to imply initially that htmz is written by someone other than you, and then later that you wrote htmz. Who are you and what is your relationship with htmz and its creators? Please be honest and refrain from violating federal law and FTC guidelines in your response.

Who the f are you then?

Re: Show HN: htmz – a low power tool for HTML

#218

Post by jdthedisciple »

pier25 wrote: post #115

This seems snappy from the US but I doubt someone in say NZ will have a good experience. Going back and forth between the client and the server on every interaction can result in terrible UX. Users will be happy waiting 1-2 seconds after submitting a form but waiting that much to switch a tab is not gonna fly. Plus there's internet weather etc which might result in unpredictable latencies over long distances. Yes, yo…

This is my biggest gripe with this approach as well as HTMX.

Avoiding delays for what should be purely client-side actions is a non-negotiable to me.

Re: Show HN: htmz – a low power tool for HTML

#219

Post by larodi »

tambourine_man wrote: post #15

That's a great hack and it shows how close the browser is to offering SPA natively. Just a few attributes and we could avoid the iframe. It's probably more useful to prove a point than an actual day to day tool. And the point seems to be: htmx is too much trouble for what it offers. We just need HTML native ajax.

You know... we've been doing something very similar 20 years ago for a stats dashboard web app - reloading only DIVs that need with new content server-generated. We didn't even bother to recreate the DOM, but directly innerHTML = content loaded.

Perl on the back-end and some very tiny JS on the front-end. Do I need to tell U that this worked as absolute charm and was blazing fast. The only considerable downside was that indeed lots of traffic was going back and forth. But then 20 years later latency is much lower, traffic much cheaper, CPUs also, and I am very happy to see more and more people realize this bare-bones approach was actually a good thing to consider (the author lists the downsides).

To me such approach is much more web-native in comparison to abomination UI frameworks, that try to reinvent presentation marginalizing the browser to be nothing more than a drawing surface. But guess what - their primary goal is to save on this network latency, that is anyway going down down down down with every year.

The htmlz/htmlx approach is indeed much simpler and easy to live with in a large project, it is really sad that we put so much logic in the front-end in recent years...

Post reply on HN