[wg0]

>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]

The 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]

For 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]

> 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]

My 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]

> 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/

[wg0]

I have not prototyped anything but I think that alpine-js + htmx can go long way for such apps. Especially, this is pretty interesting idea [0]

React... might be good but I am too weak to handle all that comes with it.

[0]. https://devdojo.com/pines