40 ms·

> you need to put the whole app state in the URL and that quickly becomes a nightmare. You should be doing this anyway ... it's so annoying when my wife sends

> you need to put the whole app state in the URL and that quickly becomes a nightmare. You should be doing this anyway ... it's so annoying when my wife sends me a link at work and it just goes to a generic page instead of the search results she wanted to share with me. She ends up mostly sending me screenshots these days because sharing links don't work.

Cthulhu_ 1y ago
Depends on what the commenter means by app state. Anything bookmarkable - like search results - should be in the URL, but "state" should not (I consider things like partially filled in forms, shopping carts, etc to be state).
- foobarbecue 1y ago
  Presumably you mean search query input, not search results, right?
  - LeFantome 1y ago
    I think you are saying the same thing. They mean that their wife is trying to send them search results. You are pointing out that the link would contain the search query.
    - foobarbecue 1y ago
      Not really same thing. If you share the search query, you'll be re-submitting the query at a later time, so the results are likely to be different when the receiver uses that URL. It would be possible (but pretty terrible) to embed the actual search results in the url. A more reasonable implementation of sharing search results would be to store results on the server and have a storedResults id key in the url.
- PaulHoule 1y ago
  You have choices, especially all the choices that 1999-style web applications have. The shopping cart can be kept on the back end and referenced by an id stored in a cookie. You can keep partially filled out forms in hidden form variables and can send them back in either GET or POST. Not all requests require all the form data, for instance my RSS reader YOShInOn is HTMX based -- you can see two forms from it here: https://mastodon.social/@UP8/114887102728039235 https://mastodon.social/@UP8/114887102728039235 in the one at the upper left there is a main form where you can view one item and evaluate it which involves POSTing a form with hidden input fields but above that I can change the judgements of the past five items by just flipping one of the <selects> which needs to only submit the id and the judgement selected in the select. I guess on clicking one of the buttons in the bottom section I could redraw the the bottom section, insert a <select> row at the bottom of the list and the delete the one at the top, but it just redraws the whole form which is OK because I don't have 200k worth of open graph and other meta data in the <head> and endless <script> tags and any CSS other than bootstrap and maybe 5k of my own, which all caches properly.
- naasking 1y ago
  > Depends on what the commenter means by app state. Anything bookmarkable - like search results - should be in the URL, but "state" should not (I consider things like partially filled in forms, shopping carts, etc to be state). Yes, shopping cart state should be in the URL in the form of a server-side token under which the cart state is stored. Ditto for partially filled in forms, if that's something your app needs. All page state should be transitively reachable from the URL used to access that page, just like all state in a function in your favourite programming language should be transitively reachable from the parameters passed into that function, eg. no global variables. The arguments for each are basically the same.
fvdessen 1y ago
That is just the location of a page, and indeed that should be put in the URL. But a modern js app has much more state than that: partially filled fields, drafted documents, scroll position of lists, multi-path navigation history, widget display toggles, etc. etc. In react/vue you have 'stores' to hold and manipulate those info. In HTMX you need to choose between the url, the session cookie and the dom. And what you can usually keep just keep in the dom with client vue/react can't be with HTMX since the backend needs to be aware of the state to correctly render the new widget.
- withinboredom 1y ago
  Are people really reimplementing browser history in JavaScript? Why are people implementing “navigation history”??!! All of this stuff needs to be stored on the server anyway… otherwise how will you get it back on the page when I switch computers or pull it up on my phone.
  - javcasas 1y ago
    Scroll positions of lists, toggleable widget status, partial form fills. You say all of that needs to be stored in the server? That is how you make a big server crawl with just 100 users, regardless of the programming language of the backend.
    - withinboredom 1y ago
      Those particular things are already handled by the browser. Even mobile browsers handle this just fine: https://share.icloud.com/photos/022RMgNZWot7w6AXurHPKC_Nw https://share.icloud.com/photos/022RMgNZWot7w6AXurHPKC_Nw
    - naasking 1y ago
      > That is how you make a big server crawl with just 100 users, regardless of the programming language of the backend. This is a myth, servers and round trips can be way faster than most people seem to believe: https://www.youtube.com/watch?v=0K71AyAF6E4#t=21m21s https://www.youtube.com/watch?v=0K71AyAF6E4#t=21m21s That's thousands of DOM updates per second being sent and rendered at 144fps.
threatofrain 1y ago
For easy apps, sure, like shopping carts and search results. What about all the other apps?

Cthulhu_ 1y ago

Depends on what the commenter means by app state. Anything bookmarkable - like search results - should be in the URL, but "state" should not (I consider things like partially filled in forms, shopping carts, etc to be state).

foobarbecue 1y ago
Presumably you mean search query input, not search results, right?
- LeFantome 1y ago
  I think you are saying the same thing. They mean that their wife is trying to send them search results. You are pointing out that the link would contain the search query.
  - foobarbecue 1y ago
    Not really same thing. If you share the search query, you'll be re-submitting the query at a later time, so the results are likely to be different when the receiver uses that URL. It would be possible (but pretty terrible) to embed the actual search results in the url. A more reasonable implementation of sharing search results would be to store results on the server and have a storedResults id key in the url.
PaulHoule 1y ago
You have choices, especially all the choices that 1999-style web applications have. The shopping cart can be kept on the back end and referenced by an id stored in a cookie. You can keep partially filled out forms in hidden form variables and can send them back in either GET or POST. Not all requests require all the form data, for instance my RSS reader YOShInOn is HTMX based -- you can see two forms from it here: https://mastodon.social/@UP8/114887102728039235 https://mastodon.social/@UP8/114887102728039235 in the one at the upper left there is a main form where you can view one item and evaluate it which involves POSTing a form with hidden input fields but above that I can change the judgements of the past five items by just flipping one of the <selects> which needs to only submit the id and the judgement selected in the select. I guess on clicking one of the buttons in the bottom section I could redraw the the bottom section, insert a <select> row at the bottom of the list and the delete the one at the top, but it just redraws the whole form which is OK because I don't have 200k worth of open graph and other meta data in the <head> and endless <script> tags and any CSS other than bootstrap and maybe 5k of my own, which all caches properly.
naasking 1y ago
> Depends on what the commenter means by app state. Anything bookmarkable - like search results - should be in the URL, but "state" should not (I consider things like partially filled in forms, shopping carts, etc to be state). Yes, shopping cart state should be in the URL in the form of a server-side token under which the cart state is stored. Ditto for partially filled in forms, if that's something your app needs. All page state should be transitively reachable from the URL used to access that page, just like all state in a function in your favourite programming language should be transitively reachable from the parameters passed into that function, eg. no global variables. The arguments for each are basically the same.

fvdessen 1y ago

That is just the location of a page, and indeed that should be put in the URL. But a modern js app has much more state than that: partially filled fields, drafted documents, scroll position of lists, multi-path navigation history, widget display toggles, etc. etc. In react/vue you have 'stores' to hold and manipulate those info. In HTMX you need to choose between the url, the session cookie and the dom. And what you can usually keep just keep in the dom with client vue/react can't be with HTMX since the backend needs to be aware of the state to correctly render the new widget.

withinboredom 1y ago
Are people really reimplementing browser history in JavaScript? Why are people implementing “navigation history”??!! All of this stuff needs to be stored on the server anyway… otherwise how will you get it back on the page when I switch computers or pull it up on my phone.
- javcasas 1y ago
  Scroll positions of lists, toggleable widget status, partial form fills. You say all of that needs to be stored in the server? That is how you make a big server crawl with just 100 users, regardless of the programming language of the backend.
  - withinboredom 1y ago
    Those particular things are already handled by the browser. Even mobile browsers handle this just fine: https://share.icloud.com/photos/022RMgNZWot7w6AXurHPKC_Nw https://share.icloud.com/photos/022RMgNZWot7w6AXurHPKC_Nw
  - naasking 1y ago
    > That is how you make a big server crawl with just 100 users, regardless of the programming language of the backend. This is a myth, servers and round trips can be way faster than most people seem to believe: https://www.youtube.com/watch?v=0K71AyAF6E4#t=21m21s https://www.youtube.com/watch?v=0K71AyAF6E4#t=21m21s That's thousands of DOM updates per second being sent and rendered at 144fps.

threatofrain 1y ago

For easy apps, sure, like shopping carts and search results. What about all the other apps?