Turbo Links once was • It just works™ • Unless when it doesn’t (cough, cough, jQuery plugins) • Might be tricky to introduce into legacy apps • Replaces the contents of <body> with the contents of the response <body> • Merges the contents of their <head> • if <title> or <meta> tags change, they will be updated as expected • if links to assets are the same, they won’t be touched so browser won’t process them again
updated independently • Without reloading the entire page • Links and forms inside a frame are captured • Only that frame's contents are updated when navigating or submitting. • Can be lazy-loaded • Improve cache efficiency by separating page segments that change at different rates or for different people • Easy to introduce, it won’t break anything
fragments wrapped in <turbo-stream> elements • Partial page updates without full reloads* • CRUD-like actions: append, prepend, before, after, replace, update, remove, and refresh* • HTTP or over WebSockets or even Server-Sent Events (SSE) • Reuse existing server-side templates for both initial page loads and subsequent updates • Deep Rails integration with Action Cable and Active Job via turbo-rails gem
without custom JavaScript • They are completely independent of each other and have quite different use cases • Turbo Frames only manipulate themselves, and this manipulation is always an update • Turbo Streams can manipulate any DOM element anywhere on the page Frames vs Streams
out of the box - it does an actual reload of the page • idiomorph enters the stage • Add broadcasts_refreshes to the model • Hooks into existing turbo_stream_from • Add turbo-refresh-* meta tags to HTML