221–230 of 256 posts
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…
Earlier quoted context omitted.
> Moving the data to the edge is much harder. Which means its gonna be the same thing if you try to render on the client, since you still need a round trip for data...
With some JS you might not need to do multiple roundtrips though. For example to open a tab or a dialog.
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…
Reimplementing browser functionality in JS also often breaks excpectations as things don't work quite the same for all browsers. It also means browser extensiosn are less likely to be able to deal with the content.
Essentially it's like wanting your documents in PDF format even though a executables are also part of the PC platform and you could just ship a custom exectuable that renders your document instead. To me JS is just as absurd.
Earlier 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="..." ?
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…
If you are concerned about the delay when switching a tab, nothing prevents you to load both tabs during the first page load, and then just display the content without a new network requests. Whether you should do this or not is completely unrelated to whether you should use htmx, htmz or react.
I think there's a pretty strong argument at this point for this kind of replacing DOM with a response behavior being part of the platform. I think the first step would be an element that lets you load external content into the page declaratively. There's a spec issue open for this: https://github.com/whatwg/html/issues/2791 And my custom element implementation of the idea: https://www.npmjs.com/package/html-include-e…
I think some of the proposals I see in that thread are kind of interesting, but to do it properly requires a new MIME type for html fragments, eg. text/html-fragment. This is arguably what htmx should also be using for fragments.
I do kind of like the idea of adding this as an attribute to some existing elements, and they show the inner content by default until the target is loaded. Basically like adding an iframe-like rendering mode to existing elements. Then you could implement htmx's hx-boost behaviour just by setting this mode on the body element and using the htmz trick of links naming the body as a target.
Why not htmy ?
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…
Earlier quoted context omitted.
Agreed. And treat all JS engine-requiring sites like viruses that need to be executed in protected VMs.
Of course! Actually, for any website that runs JS, in my opinion, we should just automatically forward the JS execution into a virtual machine, it is horrible to allow any random website to just run code directly on our machine. What if we built this virtual sandbox directly into the browser, that way no code could run on our machine, but all websites still work fine? That's revolutionary! Hang on...