>URLs up to ~2000 characters
Exactly, this approach doesn't scale well without trickery involved. You have to have some sort of weird encoding in place to compact it down.
URL-Driven State in HTMX
81–90 of 188 posts
Re: URL-Driven State in HTMX
#82Earlier quoted context omitted.
> 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?
> The same thing should happen that happens with Rails/Django and friends: nothing
So you can never make any breaking change to your api whatsoever? Or, in practice, you don't care and let users deal with app crashes and invalid state? Yep, welcome to the frontend-world.
Re: URL-Driven State in HTMX
#83I 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…
> modern internet connection
Have you heard of these things called smartphones? I hear they're getting quite popular.
Re: URL-Driven State in HTMX
#84I find it deeply ironic that we have come full circle, and Javascripters have reinvented what we had 20 years ago.
I'm not sure that it really counts as ironic when HTMX was conceived specifically to try and get people to stop writing megabytes of JS and to go back to the old ways.
Re: URL-Driven State in HTMX
#85I think people are now ready for php. I bet it will be reinvented on top of nodejs.
Glad I skipped the whole "JavaScript only" webdev phase. My mad PostNuke skills are relevant again.
Re: URL-Driven State in HTMX
#86It's just how web works – storing data in URL params to restore the same state later. With React or whatever library you do the exactly same thing. In this case HTMX doesn't particularly stand out or enable anything new here.
Re: URL-Driven State in HTMX
#87Earlier quoted context omitted.
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?
html native datalist?
Re: URL-Driven State in HTMX
#88It's just how web works – storing data in URL params to restore the same state later. With React or whatever library you do the exactly same thing. In this case HTMX doesn't particularly stand out or enable anything new here.
> With React or whatever library you do the exactly same thing.
There are many React SPAs where the address bar URL rarely changes, and I have to find some "share" button on the page itself to get the page's URL.
Re: URL-Driven State in HTMX
#89Re: URL-Driven State in HTMX
#90The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added. To get truly bookmarkable list URLs, the best approach I've seen is ‘page starting from item X’, where X is an effectively-unique ID for the item (e.g. a primary key, or a timestamp to avoid exposing IDs).
> The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added.
Why is the content changing between refreshes not "(helpfully) bookmarkable"?
The HN front page (ie. "page 1") does that but it's a very useful bookmark.