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

131–140 of 256 posts

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

#131

Post by smaudet »

superkuh wrote: post #113
MatthiasPortzel wrote: post #36

Earlier quoted context omitted.

> being an idealist Could you describe your ideals for why websites should gracefully degrade without JS enabled? It’s not an unpopular view on HN, but from my perspective as a web developer, JS is a part of browser application just like HTML, and there’s no reason for the website to work if you’ve disabled a part of the browser. I suspect “doesn’t have JavaScript” is being used as a proxy for a lot of other ideals t…

If you would've told anyone in the year 2000 that it'd become standard practice to blindly execute programs sent to you by anonymous people you don't know you'd get a lecture on why that's stupid. But in 2024 it's standard accepted practice. And that standard has made it so browser developers have to literally prevent the user themselves from having control over their browser because it's too dangerous to do otherwis…

Agreed. And treat all JS engine-requiring sites like viruses that need to be executed in protected VMs.

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

#132

Post by wild_egg »

lelandfe wrote: post #123

I'm somewhat frightened to ask if there's some special voodoo need for leaving off the quotes on htmz...

Quotes are completely optional on attribute values in HTML5 if the value doesn't have certain characters like spaces which will require quoting

I've found this article a handy reference on all the stuff it's safe to leave out

https://meiert.com/en/blog/optional-html/

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

#133

Post by TimTheTinker »

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

My name is John Galt and I wrote this library. When you learn who I really am, then you'll understand.

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

#134

Post by kevincox »

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.

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

#135

Post by sesm »

simpaticoder wrote: post #27
Kalabasa wrote: post #19

Earlier quoted context omitted.

Yeah it breaks without JS. You could add the iframe behind JS, so the target would default to a new tab. But the server would still be designed to return HTML fragments. I never found a way for a server to check if the originating request is for an iframe or a new tab. It's not quite a graceful degradation.

> I never found a way for a server to check if the originating request is for an iframe or a new tab. There is no such technique. One way to distinguish is to pick a URL convention and modify the URL (before the hash) of the iframe URL. For example, add ?iframe=true to the URL, and then have the server check for that. Perhaps more usefully you could include information about the parent URL, e.g. url += '?parent=${doc…

Can we add a cookie instead of modifying URLs?

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

#137

Post by _heimdall »

klabb3 wrote: post #125
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…

Yeah. I like the simplicity of htmx etc but network round trips are simply not suitable for a lot of interactions (at least if we’re talking about web apps ). For a barebones approach I’d prefer tabs etc to be low-JS on top of a functional plain html page.

Personally I've landed on the balance of leaving rendering wherever the state lives.

In the tabs example, my question is always how dynamic and complex the tabs are. For fairly simple tabs its pretty clean to server render the HTML for all tabs and use a basic client-side script to handle navigation (ideally its synced in the URL as well).

For more complex tabs, or tabs heavily dependent on dynamic state, I find that its much easier to maintain long term if the rendering happens server-side. I personally have enjoyed HTMX for this to swap out an island of HTML, but a full page reload has worked for decades now.

In my experience the worst solution is shipping the complex state and the complex rendering logic to the browser. From performance to bug reproducibility, it has always cause me more pain that the DX original dev time are worth.

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

#138

Post by recursivedoubts »

eproxus wrote: post #102
recursivedoubts wrote: post #66

Earlier quoted context omitted.

I'm the creator of htmx and think this is a great library/snippet. Much closer to what htmx-like functionality in HTML would/should look like in that it is following existing norms (iframes, the target attribute) much more closely than htmx. From a practical perspective, a lot of the bulk of htmx is bound up in things like history support, collecting inputs, a lot of callbacks/events to allow people to plug into thin…

Kind of makes me wish there was a htmx-lite of sorts. Like an 80/20 solution at 20% of the size, which could be extended to the full blown package with extensions. Have you thought about moving more features to extension, like was done with the web sockets feature?

I've looked at the codebase and there isn't much I feel would do well as an extension. As I said upthread, most of the code is AJAX, input gathering, history support and then book-keeping/event stuff around that.

There will be a bunch of htmx-like libraries coming out though and I expect many of them to take different design perspectives. Two that I'm aware of are https://data-star.dev/ and https://ajaxial.unmodernweb.com/, both were created by people on the htmx discord. I know of at least two other minimalist rewrites htmx discord users have done, but they haven't published their stuff yet.

If you'd like to create your own, I do an overview of how htmx works here:

https://www.youtube.com/watch?v=javGxN-h9VQ

I think a minimal, clean room, fetch() based implementation could be done in a weekend.

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

#139

Post by dormento »

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.

I had a dream yesterday, that scientists managed to create a new kind of EMP bomb. This bomb was unusual in that, by varying the level of EM discharge in the payload (dreamy-sciency explanation), it could target all hardware created after a certain point in time.

I had access to their facility (dreams being as dreams often are), and managed to set it for 1992, and right when I was about to press the button, I woke up.

It RUINED my day.

Post reply on HN