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 2 days ago | parent [-]

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.

▲

fvdessen 2 days ago | parent | next [-]

Because app navigation is not linear like the url history. Think of a popup with tabs within a page. There's the navigation within the popup, and the navigation within the page. When you close the popup, you don't want 'back' to bring the popup back, you want it to go to the page before the popup. This is hard to replicate with just urls and server side rendered html.

Also you don't want that store server side because there can be multiple parallel tabs and you don't get notified server side when the tab is closed to properly cleanup the associated resources.

	▲	withinboredom 2 days ago \| parent [-]
		This is why we are cooked. Just because you can, doesn’t mean you should. ?tab[0]=/some/url&tab[1]=/some/resource&activeTab=0 Bam, you have tabs in the url. I can duplicate the tab, share my view, or whatever. Assuming the other user/tab/window/profile has access to these resources, it’ll show exactly the same thing. I can even bookmark it! You can even add popups: ?popupModal=saveorleave This state probably won’t be applied on an entry, but what’s great is that pushing [back] in the browser is the same effect as cancel! If you click “leave” then you do a “replace state” instead of a “push state” navigation, so the user doesn’t go back to a modal… This was, at one point, decently standard logic. Then people who don’t know how browsers work started creating frameworks and reinventing things. I digress. I’m just so glad I left the front end 15 years ago, I’d lose my shit if I were dealing with this kind of stuff every day.

▲

javcasas 2 days ago | parent | prev | next [-]

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.

	▲	naasking 2 days ago \| parent \| next [-]
		> 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 That's thousands of DOM updates per second being sent and rendered at 144fps.
	▲	withinboredom 2 days ago \| parent \| prev [-]
		Those particular things are already handled by the browser. Even mobile browsers handle this just fine: https://share.icloud.com/photos/022RMgNZWot7w6AXurHPKC_Nw

▲

joseda-hg 2 days ago | parent | prev [-]

Depending of your flavor of SPA framework, Browser History might not work because there's no actual page change

Some will manually push a History entry, but not all