I cannot believe how simple and elegant this is. Using an iframe as a request/response proxy to enable targeted replacement is just
You accidentally the
Show HN: htmz – a low power tool for HTML
181–190 of 256 posts
Re: Show HN: htmz – a low power tool for HTML
#182I 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…
...You realize this "framework" is 181 characters long, right?
elements add to the history, it's what they're supposed to do. If you don't want them to do that, don't use elements for UI. Use a button and change the iframe src with javascript. That's not really the library's problem, and it's not really hypertext's problem what the browser is putting into history.
> For something that claims to "just be html", it seems to be breaking some fundamental rules of the web/UX.
Yes, obviously. HTML+CSS are meant to put boxes and words and images on a screen. If you want to show a spreadsheet with cell formulas, use javascript. Fundamental rules of web/UX are not the same as fundamental rules of hypermedia.
> Whether it's a simple mistake or not and easy to fix, it does not inspire confidence in the framework.
There's a section on the page titled "Is this a joke?" (not to mention, "Is htmz a library or a framework?"- its a snippet). Confidence is not the point. The point is to demonstrate how little it takes to turn HTML into a stateful UI. As the author says:
> If you need something more interactive than the request-response model, you may try the htmz companion scripting language: javazcript. Sorry, I meant JavaScript, a scripting language designed to make HTML interactive.
> htmz does not preclude you writing JS or using UI libraries to enhance interaction. You could, say, enhance a single form control with vanillaJS, but the form values could still be submitted as a regular HTTP form with htmz.
Re: Show HN: htmz – a low power tool for HTML
#183Earlier quoted context omitted.
OP addresses this at “We can do a hack that enables you to write the target ID selector in the target attribute itself!”
I'm only addressing the comment on "a glorious demonstration" of understanding the platform, where hacks like this go against such a take (IMO)
I'd say hacking the platform in a way that's elegant like this would require a certain level of understanding of it,
Re: Show HN: htmz – a low power tool for HTML
#184Very neat use of existing HTML. One thing this highlighted for me is that the MDN docs on the target attribute are incomplete, because I was recently reading them and while they mention that you can target iframes, they didn't actually describe how to do so.
I was reading the docs because I had some thoughts on my own htmx-like take. You've used some of the same attributes I was going to use but slightly differently than how I was going to approach it. Some good food for thought!
Re: Show HN: htmz – a low power tool for HTML
#185Earlier quoted context omitted.
This. I think Vue.js "scales down" excellently. You can just load it via the cdn and write some widgets and go about your day. In the past I've tried to make use of "microframeworks" like alpine.js and such but often found myself returning to Vue.js.
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.
Re: Show HN: htmz – a low power tool for HTML
#186Earlier quoted context omitted.
As a fun hack / code golf it's great. I was being tonedeaf I guess, woosh as they say. The marketing pitch on the landing page is written so well that I took it too seriously probably. I know htmx but wasn't able to see this as a parody, so my fun capabilities were failing :)
I have changed it to explicitly state within the first paragraphs that "htmz is an experiment" now. I started this as a joke but turned into a fun working solution - I myself am not sure if this is just a joke or a thing. Maybe I'll use it in some smaller projects, or maybe not!
All power to you! No need to decide if it is a joke or not! ;)
In fact I clicked on it just because the name was so hilarious and already indicated pretty well what might be to expect (I didn't expect your particular solution though, kudos)
Re: Show HN: htmz – a low power tool for HTML
#187This 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'm in Australia and it's quite nice to use.
The big killer here isn't just round trip time, it's the RTT compounded with the 14KB limit from TCP before it stops blindly sending data and compounded with extra resources that have to be fetched in a chain. If you keep the size of the response under 14KB and don't have render-blocking links to CSS and JS a page will be pretty fast; the moment it's any bigger the time before page load will double. I'm happy waiting about 300ms for a page served from the east coast of the US to load, but 600ms becomes noticeable and anything more - JS which loads more JS which loads JSON and blocks rendering until it's done, for example - starts to be excruciating.
Re: Show HN: htmz – a low power tool for HTML
#188Earlier quoted context omitted.
Love it! I think this idea has some legs in that a programmer can build their own f****k. Bundling only the pieces that they actually use. I don't see why it should not be used in a production environment...other than someone in the internet disapproves...a fear many of us suffer from. It's a simple idea & can be easily managed in a codebase. In he spirit of breaking apart HTMX piece by piece, I created hyop (Hyperme…
What does single__hyop actually do? I read the whole README and couldn't find a definition of it. Is it essentially the same as onload="..." ?
I released it a few days ago & I appreciate the feedback. A single__hyop is a strategy to run a hyop mapped to a key...opposed to a multi__hyop which runs multiple hyops on keys delimited by whitespace. Other strategies are possible, like implementing an HTMX-like api with tree-shaking...but I havn't yet run into a use case for such sophisticated behavior. TBH, I only use single__hyop but wanted to leave the api space open for more sophistication. I mainly use this pattern instead of the overly-bloated hydration feature that come with the large UI frameworks.
It is like onload for all elements, it works with tree-shaking, & the hyops can keep local scope (do not need to be assigned to globalThis/window). I didn't use the onload attribute because hyop has different semantics than onload. eval would need to be used & the functions would need to in global scope to preserve onload semantics.
There is a DEBUG preprocessor which ensures that all of the hyops are loaded in the browser build & there are no unused hyops as well.
It's only 61 bytes, so it's basically snippet-ware at this point. There may be more built on this foundation as I mentioned earlier. I wanted to express this pattern b/c it's been useful for me.
Re: Show HN: htmz – a low power tool for HTML
#189Earlier 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…
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.
Re: Show HN: htmz – a low power tool for HTML
#190Earlier 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?
I would caution against using HTMX in production, either, from personal experience.