I find it deeply ironic that we have come full circle, and Javascripters have reinvented what we had 20 years ago.
URL-Driven State in HTMX
71–80 of 188 posts
Re: URL-Driven State in HTMX
#72[deleted]
Re: URL-Driven State in HTMX
#73This is a classic pattern of web applications from the 1990s. Works amazingly well even w/o HTMX
Coming up next: moving JS outside of markup with selectors.
Re: URL-Driven State in HTMX
#74I think people are now ready for php. I bet it will be reinvented on top of nodejs.
Given you can run Doom on your fridge these days, it should be absolutely no surprise that you can already run PHP both in the browser and in Node [0].
Re: URL-Driven State in HTMX
#75We were experimenting with saving states in URLs with https://libmap.org. Sharing these URLs on mastodon.social would add the post to the map.
Re: URL-Driven State in HTMX
#76The JS world leaves me more and more perplexed.There's a similar rant about forms, but why is this so hard? Huge amount of dev time spent being able to execute asynchronous functions to the backend seamlessly yet pretty much every major framework is just rawdog the url string and deal with URLSearchParams object yourself. Tanstack router[1] provides first class support for not only parsing params but giving you a typ…
> Tanstack router[1] provides first class support for not only parsing params but giving you a typed URL helper, this should be the goal for the big meta frameworks Let's not pretend that the Tanstack solution would be good . For example, What if my form changes and a new field is added but someone still runs the old html/js and sends their form from the old code? Does Tanstack have any support to 1.) detect that sit…
The same thing should happen that happens with Rails/Django and friends: nothing. Most frameworks only parse URL params, they don't check to see if the params are valid given your app logic.
That's your job. Frankly, anything more would be over kill. Why should my url param manager handle new or removed form fields?
Re: URL-Driven State in HTMX
#77Finally we are getting out of Hipster tech territory and back to something that makes sense. Thank you HTMX.
Putting JavaScript directly in your markup with bespoke attributes is extremely hipster.
Re: URL-Driven State in HTMX
#78Re: URL-Driven State in HTMX
#79I think people are now ready for php. I bet it will be reinvented on top of nodejs.
At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. We used this exact same technology over dialup modems and it worked well enough to get us to this point.
Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. It also doesn't help much in the more meaningful domains of business since you can't cheat god (information theory). If the data is so frequently out of sync that every interaction results in JSON payloads being exchanged, then why not just render the whole thing on the server in one go? This is where I can easily throw the latency arguments back in the complexity merchant's face - you've simply swept the synchronization problem under a rug to be dealt with later.
Re: URL-Driven State in HTMX
#80I think people are now ready for php. I bet it will be reinvented on top of nodejs.
At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. We used this exact same technology over dialup modems and it worked well enough to get us to this point. Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. It also doesn't help much i…
What about a feature like query completion?