Live data from Hacker News

Show HN: htmz – a low power tool for HTML

leanrada.com

191–200 of 256 posts

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

#191
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; }

You’re full of great hacks. That one I may actually use. Looking forward to that article.

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

#192

Earlier quoted context omitted.

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

I would caution against using HTMX in production, either, from personal experience.

I've been looking for someone to write a negative htmx experience analysis to host on the essays page:

https://htmx.org/essays

i don't want people to pick htmx if it's going to be a bad choice for their particular application, would be happy to work w/ you to get something put together

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

#193

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…

Regarding the size I would guess that if htmz would be extended to have the same features as htmx, it would also be similar in size? Would it make sense to modularize htmx in order to only pay for what you really use to support adding features without necessarily increasing the downloaded size?

I think you could do a smaller htmx by dropping a lot of the event and config stuff & adopting modern tools that produce smaller javascript. Clever use of JavaScript features could probably knock it down as well, but i'm anti-clever in most cases. As it stands, htmx is ~17ms to download over slow 4G and should be cached after the first download, so, while I wish I could make it smaller, every time I've tried to it ends up not moving the needle too much.

We are going to get a chance to remove all the IE-related syntax in 2.x which should help a bit.

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

#194

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…

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…

I wrote an essay on that topic here:

https://htmx.org/essays/when-to-use-hypermedia/

Things that involve a lot of events that need to be handled quickly are not a good fit for hypermedia. Sometimes you can have a rich island inside hypermedia though (e.g. a rich text editor w/ autocomplete, etc) so long at is triggers events and offers form participation. Two common examples I give are google maps and google sheets. Those would be difficult to do well in htmx. (But the settings pages for them might be a good use case for it)

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

#195

Earlier quoted context omitted.

same here, spent lots of time poking around, even tried svelte and react.js(heavily), and now firmly back to vue.js. vue.js does not mix SSR with SPA into one, make it much simpler compare to what React.js is doing today, and it provides way more than alpine.js and htmx etc, it's the best one in practice for me now.

I also started with Vue and switched to React for work but still miss the simplicity of Vue. Sadly, it didn't take off as React.

React has Meta behind it, Vue.js is a non profit project by individuals, very different, good news is that vue.js is good enough for serious projects nowadays and I especially like the fact that it does not mix SSR into SPA to make things complicated.

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

#196
post #164

Earlier quoted context omitted.

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.

It is JavaScript.

That's like saying Linux is C. True, but missing the point.

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

#197

Interesting. I wrote a similar plain HTML/WebComponent-based front end for my new no-code/low-code serverless platform https://saasufy.com/ It lets you build just about any data-driven application using only a handful of declarative generic HTML components: https://github.com/Saasufy/saasufy-components?tab=readme-ov-... I built a chat app with both group chat and private chat (with access control) using only plain HT…

>I built a chat app with both group chat and private chat (with access control) using only plain HTML; only ~250 lines of HTML markup for the entire thing: https://github.com/Saasufy/chat-app/blob/main/index.html I think I know what you mean, but we clearly have different definitions of "plain HTML." Mine wouldn't involve 9 javascript files. :-D Either way, I'm interested and will check out what you made!

Ah yes good point. By plain HTML, I meant apps which can be assembled without custom JavaScript logic needed.

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

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

One cool hack you can do is set the background of all widgets to a non transparent color, and then set the background image of the iframe to a loading gif. That way, between loads, you will not have any widget content in the iframe and will instead reveal the loader. :)
Post reply on HN