· 5 min read

Hotwire and Turbolinks

# Frontend
This article was auto-translated from Chinese. Some nuances may be lost in translation.

Introduction

DHH (the creator of Ruby on Rails) tweeted about his new project Hotwire. DHH is known to be somewhat skeptical of SPAs (as hinted in his tweet), which is why he aims to minimize the use of JavaScript in development. This tweet sparked lively discussions on Twitter, and I’d like to summarize some key points here.

The introduction to Hotwire is directly quoted from the official description:

Hotwire is an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire.

This description has two main points:

  • No need to use JavaScript
  • Directly sending HTML instead of JSON

This concept isn’t entirely new; Ruby on Rails has employed a similar technique for years, known as Turbolinks.

Turbolinks is a JavaScript library typically used in conjunction with Ruby on Rails (though it can also be used independently). It primarily fetches HTML to avoid the overhead of re-sending requests and reloading CSS when navigating between pages. Saying “no need to use JavaScript” isn’t entirely accurate—JavaScript is still involved, but the library handles it for you, so you don’t have to write it yourself.

For example, when there’s a tag like this on a page:

<a href="/articles/1" data-remote="true">link</a>

If Ruby on Rails has Turbolinks enabled, when a user clicks the link, it doesn’t send a new request. Instead, Turbolinks performs something like this:

fetch('/index.html').then(res => res.html())
	.then((html) => $page.html(html))

This way, when a user clicks a button, it doesn’t re-render the HTML. Instead, it first fetches the HTML file for that page (via AJAX) and then directly renders it using JavaScript. Ruby on Rails is highly integrated with Turbolinks, which means sometimes you hardly notice Turbolinks at all, only feeling that “wow, page transitions seem faster.”

As the HTML grows larger, the effect may become less noticeable, but if the HTML is relatively small, it can lead to a better user experience.

Why is this approach useful?

  • No need to reload CSS and JavaScript, resulting in a better user experience.
  • Turbolinks manages the <head> section for you.
  • Minimal need to write additional JavaScript.
  • Back-end developers can achieve a better experience with minimal effort.

Things to watch out for

  • Events like load will only trigger on the initial load since Turbolinks doesn’t reload the entire page. Remember to switch to turbolinks:load or similar to listen for events.
  • With increasing JavaScript interactions, event bindings can easily conflict with each other.
  • State does not get cleared when changing pages, so poorly written JavaScript can lead to memory leaks.

As JavaScript interactions increase, using Turbolinks may sometimes result in strange behaviors, such as errors due to repeated executions.

Some thoughts

As developers, many have experience writing SPAs, and we all know creating a functional and user-friendly SPA is no easy task. Poor state management can lead to excessive memory usage, state synchronization issues, inadequate error handling, and the frequent loading of large JavaScript bundles. Sometimes, sticking to pure SSR (Server-Side Rendering) for rendering might actually be a better approach, using Turbolinks to enhance the experience could be a good strategy.

Conclusion

Some believe JSON is smaller than HTML, thus making it more efficient to transmit. However, once gzipped, both are often similar in size, and sometimes HTML can even be smaller. So, rendering HTML directly doesn’t seem like such a terrible idea after all.

Currently, the best integration of Turbolinks is likely with Ruby on Rails, while Hotwire is still relatively new, and some developers may be observing before diving in.

Related Posts

Explore Other Topics

Random Talk公司階段的重要性Software EngineeringDancing with AIDev NoteStop Using Access Keys Already