Can it trigger JS returned from the proxy? Something like alert(123);
Show HN: htmz – a low power tool for HTML
141–150 of 256 posts
Re: Show HN: htmz – a low power tool for HTML
#142Here a version that works for cross origin requests.
document.querySelector(x.data.target).innerHTML=x.data.content">
just some other text
parent.postMessage({
target:location.hash,
content:b.outerHTML
},'*')
dog
Re: Show HN: htmz – a low power tool for HTML
#143Here a version that works for cross origin requests. document.querySelector(x.data.target).innerHTML=x.data.content"> but website you are requesting has to embed the below script tag. just some other text parent.postMessage({ target:location.hash, content:b.outerHTML },'*') You would still set the DOM destination on the main page. dog
Careful with that snippet, targetOrigin of * is dangerous. I could embed your iframed content on my own site and then you'd happily send me the entire HTML inside the iframe.
Re: Show HN: htmz – a low power tool for HTML
#144I 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/UX. Whether it's a simple mistake or not and easy to fix, it does not inspire confidence in the framework.
Re: Show HN: htmz – a low power tool for HTML
#145Earlier 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…
Sorry if I came across as dismissive, htmx is a much needed counterpoint to React's dominance and a great contribution to the industry. And I hope its core idea (Ajax from HTML with results loading inside a target element) will be adopted as a Web standard.
not at all, i understand there are going to be different takes on what the right balance of functionality & configuration are and htmx has been hamstrung to an extent by being IE compatible, which, coupled w/ my commitment to backwards compatibility, means some obvious things are off the table (e.g. using fetch())
i don't begrudge other people having differing opinions on this stuff and agree w/the spirit of your original comment: HTML should have a native mechanism for doing what htmx does. hopefully htmx (and other takes on the idea) contribute to that future.
Re: Show HN: htmz – a low power tool for HTML
#146This 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…
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 favorite side-effects are implementations that "retry after 2s" that don't actually cancel the in-flight request, causing my entire bandwidth to be hogged up with dozens of these requests "retrying" when the initial request eventually returned successfully. Javascript developers are unintentionally evil to non-5g internet.
Re: Show HN: htmz – a low power tool for HTML
#147Why the "||:not(*)" in the iframe onload handler of htmz and not just "null"?
Re: Show HN: htmz – a low power tool for HTML
#148Earlier 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…
I'm not the creator of htmx and you are wrong. I am now officially emotionally invested in htmx so I have to justify investing my time/energy in htmx instead of something else, so all alternatives to htmx are stupid and their existence make me very angry.
how sweet it is
Re: Show HN: htmz – a low power tool for HTML
#149I'm somewhat frightened to ask if there's some special voodoo need for leaving off the quotes on htmz...
Nah it's a stylistic thing. It's so that you can see the `=htmz>` logo in code if you order the target attribute last :D
Re: Show HN: htmz – a low power tool for HTML
#150That'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…
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?