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

161–170 of 256 posts

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

#161

Post by Kalabasa »

bachmeier wrote: post #69
Kalabasa wrote: post #24

Earlier quoted context omitted.

Yes this was a response to htmx. It was a half-parody half-I wanna make it work project. Like https://github.com/vilgacx/aki I would fear if anyone wants to use this in production BUT I would love someone to get inspired and use the concepts rather than the actual code. Hmm maybe i should write a disclaimer...

> I would fear if anyone wants to use this in production Why? How would it be different from using htmx?

It's just a weird feeling for someone to use a hack / experiment as a foundation or something. I know 'the software is provided "as is ", without warranty'.

The difference with htmx is that they are more polished.

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

#162

Post by Kalabasa »

nashashmi wrote: post #103
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…

I browse the web without JS. It is a fast easy way to load websites. And some sites with heavy app interaction features need JS. And that is fine. It is the other sites that use JS to figure out if their users have read more than 2 articles that are the problem. Degrade gracefully is a required development skill. Sites need to allow for their pages to work in limited fashion without JS. JS should only be a layer adde…

`?id=thing` is a great idea!

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

#163

Post by Kalabasa »

atum47 wrote: post #58

I'll take a deeper look in the code later, but it seems useful. If been using the window location hash to do some simple navigation on my SPA, but i use JS. (Just hide all sections and shows the one that matches the hash i.e.: #main

> hide all sections and shows the one that matches the hash

Oh there is a good hack you can do here! I've been meaning to write a blog post about this exact thing!

See CSS `:target` selector

  section {
    display: none;
  }
  section:target {
    display: block;
  }

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

#164

Post by bb88 »

recursivedoubts wrote: post #66
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.

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…

Thanks for HTMX, I think it's showing the world what the web browser could be.

I'm going to be doing a lot of web pages in HTMX in the next couple of years, and it will be much easier to develop/debug than javascript.

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

#165

Post by liendolucas »

recursivedoubts wrote: post #66
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.

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…

Hi Carson! I've been using htmx sprinkled with hyperscript and I find using your tools very enjoyable (though I found myself fighting a bit with hyperscript at the beginning but past that and once you get the mindset and the hs way, things are easier).

Thanks for these tools! I wanted to also take the opportunity to ask you something you either mentioned, commented or heard in a podcast.

You said that htmx might not be the tool to solve all problems (or certain kind of apps). Just asking because I think is also great to hear when not to use something to solve a problem. So, in your opinion what kind of webapps do you consider that maybe htmx is not a good fit? And in that case what alternate tools/approaches do you suggest? Once again thanks a lot for htmx & hyperscript!

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

#166

Post by MikeTheGreat »

TimTheTinker wrote: post #133
safety1st wrote: post #118

Earlier quoted context omitted.

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.

You're a convenient fiction?

ba-dump-ching!

No, no don't bother, I'll show myself out :)

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

#168

Post by jamespo »

MatthiasPortzel wrote: post #36
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.

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

Part of this is backend devs and admins like telling frontend devs what to do

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

#169

Post by phinnaeus »

cmgriffing wrote: post #144

I think the demo section needs work. Clicking a "tab" to change the example code to Greeting, or anything else adds a history event but doesn't update the url. I probably would have done the exact opposite in both aspects. Use replace to prevent extra navigation entries, but still update the url for bookmarking etc. For something that claims to "just be html", it seems to be breaking some fundamental rules of the web…

So that's why my back button didn't work the first time when I tried to return to HN...

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

#170

Post by mhd »

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…

I don't think every solution in the webdev space is supposed to be a one size fits all panacea. Especially this, which seems more like an incentive to think about structuring webapps.

Sometimes it's interesting to see how far you can go without going the "let's download the web in a JS blob" way.

One of these days, I'm going to see whether I can still build something reasonably modern with Seaside, the continuation-based framework from the olden days, where basically the whole UI state is stored in the server-side session and everything is a request. Worked quite alright, way back when not everything had a local CDN and the internet tubes were a bit narrower.

Post reply on HN