They are using Turbolinks. They generate everything server-side and then Turbolinks calculates the delta between the existing loaded template in the client and the incoming template generated in the server and injects only the changes.
This has a lot of advantages, mainly that you don't need to care about state on the client side and you're always synced with the real estate on the backend. It has one major drawback though. If you want to create snappy interfaces, you still have to create some client visual state and modify the visual state before you receive the response from the server. Otherwise it becomes laggy because it's waiting for the response to re-render. If you don't do it this way it's going to feel slow for sure.
But again, the main advantage of this is that there's no complex state logic in the client. The server-rendering is the source of truth for your state.
It's definitely a different mindset because now you have to write JS to create UI states as they are expected to come fro the server (if you're looking for that quick SPA snappiness).
I think it's an interesting approach, but I'm not sure if I like it, though. I have build apps this way and always get the sense that I'm not creating something that feels fast.
Where is the "existing loaded template" kept server-side, sticky session cache? Seems maybe better for scale to send the whole small html and let client diff-apply.
In theory the server doesn’t care about this because the idea is that you’re requesting something that is generating a complete new template.
What turbolinks does is looking at the difference between whatever you have loaded in the browser and whatever was sent by the server.
So if you have 10 images loaded and one changed, turbolinks it’s only going to swap the one that changed.
Have in mind that we are talking about plain HTML likely gzipped blobs. So although this is not efficient it’s still fast enough for simple app layouts.
This has a lot of advantages, mainly that you don't need to care about state on the client side and you're always synced with the real estate on the backend. It has one major drawback though. If you want to create snappy interfaces, you still have to create some client visual state and modify the visual state before you receive the response from the server. Otherwise it becomes laggy because it's waiting for the response to re-render. If you don't do it this way it's going to feel slow for sure.
But again, the main advantage of this is that there's no complex state logic in the client. The server-rendering is the source of truth for your state.
It's definitely a different mindset because now you have to write JS to create UI states as they are expected to come fro the server (if you're looking for that quick SPA snappiness).
I think it's an interesting approach, but I'm not sure if I like it, though. I have build apps this way and always get the sense that I'm not creating something that feels fast.