When Turbolinks makes sense

Engineering Programming

They are employing Turbolinks in their work. They generate everything on the server side, and then Turbolinks calculates the difference between the currently loaded template in the client and the incoming template generated on the server, and then it only injects the changes that have been calculated.
You don’t have to worry about the state on the client side, and you’re always in sync with the real estate on the backend. These are just two of the many benefits that come along with using this method. However, there is a significant drawback to it. If you want to make snappy interfaces, you will still need to create some client visual state and then modify that visual state before you receive the response from the server. This is required in order to make the interfaces. In that case, the performance will suffer because it will have to wait for the response before it can re-render. If you don’t do it in this manner, it will definitely have a slower feel to it.

To reiterate, the most significant benefit of this is that the client does not require any complicated state logic. The rendering done on the server is the most accurate representation of your state.

If you’re looking for that quick SPA snappiness, you’ll need to write JS to create user interface states because those states are expected to come from the server. This requires a different mentality than traditional programming.

I believe this to be an intriguing strategy, but to be honest, I’m not entirely certain that I like it. When I use this method to build apps, I always get the impression that I’m not producing something that has a speedy feel to it.