>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.
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.
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.
> 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.
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.
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.
There are patterns that can get you the same benefits without having to use GraphQL.
Even on a REST API, you can achieve the same pros
> - It makes working with describing the data you want easy
> - It can save you bandwidth. Get what you ask for and no more
You can describe the fields you need (and I assume that is what reduces the bandwidth)
GET /users?fields=name,addresses.street,addresses.zip
> - It makes documentation for data consumers easy
I don't think so in practice. You can see Shopify's GraphQL documentation [1]. If anything it is more complex than their REST API docs
> - It can make subscription easier for you to use
Not too different from using something like SSE or even websockets and every decent web framework seems to have a decent implementation
> - Can let you federate API calls
So many ways to achieve this at the application layer (which is what GraphQL federation does with a Router). In the python world this could be separate WSGI apps or racks in ruby? And makes no difference if done at the load balancer level.
Speaking of which -- how does one go about buying an QWERTY layout XPS 13 dev edition with ubuntu in Germany? Navigating teh dell website is impossible to find it -- I just find the windows based units.
https://hypermedia.systems/hypermedia-components/
And to avoid entire page rewrites, there is alway the option to inject a server response (html) into the top (or end) of comments for example.