4 ms·
I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so
by wg0 3y ago
I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so.
And if you step into that realm of keeping the window URL in sync with where exactly the user is in the app, then you're almost already into realm of SPAs but without having the full set of tools that go with SPA.
Any open source project done in HTMX that has gone beyond TODO/LLM front ends etc could be interesting to look at
- naasking 3y ago> then you're almost already into realm of SPAs but without having the full set of tools that go with SPA. You don't need all of the tools you think you need. HTMX is reimagining SPAs by extending hypermedia. It doesn't yet extend as far as existing SPA frameworks, but it covers a much broader range than you think.
- thomassharoon 3y agonot everything needs the window url to be updated. * Add a comment on the timeline and you don't need the url to be updated. * Open a new record and the url needs to be pushed to history
- wg0 3y ago>not everything needs the window url to be updated. The user needs it to be. It is the single most important handle of information for a layman. Of copying and pasting URL to someone else so that's kinda should be non negotiable for any pro user developer/engineer. I find React to be too convoluted through its evolution multiple times over (plus the virtual DOM and horrendous ergonomics of hooks) but at the time, I'm pretty content with SvelteKit's way of doing things. Even in SPA mode, it keeps the whole thing in sync and the state management is awesome, comes built in, damn simple, just works. But honestly, torn towards htmx but undecided.
- tecleandor 3y agoThe thing is... not everything needs the window url to be updated. Either because the URL is the same, or because you're pulling content that shouldn't/can't/won't be accessible with a direct URL. For example: - Blog: You add a comment to a blog post. The comment appears without reloading, and you don't need a new URL (because it's the same blog post) - Menu navigation: You load menu items and/or children via htmx. That probably doesn't need a new URL. - Ecommerce: You add/remove/modify products to/from your cart. The URL for the cart is still the same.
- graftak 3y agoFor all your examples I can think of a reason to update the url in some or most scenarios. It depends. New blog comment can be part of the url target with the comment id. Makes it easy to share and puts the scroll bar at the right position. Menu navigation can be quite complex with nested modals, you might want to be able to deeplink for documentation/training purposes and highlight a selection. With a cart you might want to add a ‘cart state/session’ id so you can share it with your spouse to quickly get to an agreement about stuff to order.
- yawaramin 3y ago> With a cart you might want to add a ‘cart state/session’ id so you can share it That might not work for carts that work by temporarily 'booking' an item, like a seat for a cinema ticket. By definition, the cart is unique to a user.
- graftak 3y agoMy local cinema actually allows this but the cart-session is tied to the user session so when you share it the page goes to readonly mode where only the time and chosen seats are visible.
- thomassharoon 3y ago> But honestly, torn towards htmx but undecided. We are in the middle of migrating from our monster react application into server rendered pages (with jinja2). The velocity at which we are able to ship and the reduction of complexity has been great so far. Managing client side state for simple things like (is the dropdown open/closed), listening to keyboard events and such can be done with something like alpine-js [1] without all the baggage that something like react brings. It appears this is already the trend with JS frameworks too - with server side rendering being the new norm. [1] https://alpinejs.dev/ https://alpinejs.dev/
- zaphod420 3y agoI've only just started getting into HTMX, but I think the point of it is more about hypermedia as the engine of application state. The response is a self contained declarative UI. The browser just has to stick the response in the right place. There is no need to interpret the response and create the UI based on it.
- thomassharoon 3y agoYep. https://hypermedia.systems/hypermedia-components/ https://hypermedia.systems/hypermedia-components/ And to avoid entire page rewrites, there is alway the option to inject a server response (html) into the top (or end) of comments for example.
- Ralfp 3y agoNot every app is so complex that keeping address in sync with the UI requires complex logic. A lot of apps just want to update whats between the navbar and the footer without changing any of those. And URL needs to change from "/" to "/categories/". Sometimes you want to reload part of page as user clicks on tabs or side menu. Or load a content into a modal.
- r00ks 3y agoKeeping the url in sync can be done by tracking whether the request has the `HX-Request` header in it and then returning either a partial template or the full the template, example of the helper - https://github.com/Austionian/bl0g/blob/46182cf762e9acefc35ef4517da63a377b60024c/src/helpers.rs#L26 https://github.com/Austionian/bl0g/blob/46182cf762e9acefc35e... The great part of this, too, is caching these responses is still simple with the a `Vary: HX-Request`
- yawaramin 3y agoAnd, of course, with a 'Cache-Control: ...' header.
- Fire-Dragon-DoL 3y agoDoesn't this go against the philosophy though? I'd expect navigation to happen mostly with plain old html navigation
- marcosdumay 3y agoIf you want the URL to be updated, just go and do a full request.
- graftak 3y agoThat doesn’t make sense because there’s millions of reasons to update the url even when navigating sub sections of the page or to reflect some sort of state that needs to be persistent when refreshed/shared.
- infamia 3y ago> I am confused about htmx because if it is about AJAX, they don't replace the window URL as user clicks about and around unless you explicitly tell HTMX to do so. When you use `hx-boost` (one of the most common uses), it does an ajax request, updates all the child elements, and updates the URL in the browser automatically.
- hipadev23 3y agoThis needs to be higher. Works normally without JS enabled and doesn't require any header fiddling. By far the easiest way to integrate htmx while keeping a consistent user experience.
- thunderbong 3y agoHow the heck does HTMX work without JS? And in this specific example, they're making an Ajax call! Also, the 'j' in Ajax stands for 'javasxript'
- hipadev23 3y agoIt doesn’t? Your site still does is the entire point.