Let me explain. Your large JS application is likely to be a huge graph that’s INCREDIBLY linked. It’s very typical for a JS app to have mostly atomic unload. In theory even with Turbolinks, as soon as we drop the page out and load the next one we are supposed to detach the application. Dereferenced application gets collected and our RAM is free again! But Turbolinks save DOM. And DOM has bindings. And bindings reference you application. So big parts of your application survive at page reload. Therefore in practice there’s a HUGE chance that Turbolinks will boost RAM usage up to 10 times.
Turbolinks 3 is currently in development but should be released within the next few months. One interesting aspect of Turbolinks 3 is that rather than strictly doing the full <body> replacement that Turbolinks 1 and 2 do, Turbolinks 3 has support for partial dom replacement . While this seems nice and is a bit closer to PJAX , the spiritual ancestor of Turbolinks introduced by Github, it nonetheless adds a good bit more complexity to the whole Turbolinks dance. With partial replacement, there is the possibility of involving the server and Rails controllers in deciding what content to replace, and overall things seem a bit more complex than with earlier Turbolinks versions.