Turbo Handbook を読んだ: https://turbo.hotwired.dev/handbook/introduction
もともと必要なところだけつまみ読みするやりかたでちらちらみることはあったのだけど、腰をすえて読むのははじめてだった。すごく充実したドキュメントを読んだ。ぐっと視界がひらけた。
まず Turbo とひとくくりにパッケージされているライブラリは、みっつのコンセプトの集合である。 JavaScript を使わずに現代的なウェブアプリケーションをつくることが、それぞれが違うことをしているこれらみっつを束ねるひとつの目的である。
“Turbo Drive” はおおきくいって便利なキャッシュを提供するライブラリで、開発者がほとんどなにも意識しなくてもウェブアプリケーションの体験を飛躍的に向上させる。つまりなにもわかっていなくても無料の性能向上という具合に使えるのがすごい。やっていることはすこし昔の Turbolinks と似ているし、そう割り切ってしまってもよさそう。もっとも、昔のことといえば、ある会社ではそれを使いこなすことをさっさとあきらめて、無効化して低速化するのをあたりまえとしていたことをおもいだしてもいる。
“Turbo Drive” のセクションでは、ごくあたりまえのウェブサーフィンが Visits という概念で抽象化される様子が読んで気持ちいい。リンクやフォームが引き起こすページの変化を Application Visits と呼び、ブラウザの「戻る」「進む」によるページの変化を Restoration Visits と呼ぶ。それぞれ異なるキャッシュやプレビューの戦略を実装している。履歴の管理も異なる。
“Turbo Frames” は、画面のコンポーネント化を提案する。ひとつの HTML 文書のなかでコンテクストごとにフレームをつくって、パーツごとに分割するやりかたでひとつの画面をつくることを可能にする。ちいさいフレームごとにキャッシュ戦略を最適化したり、ひとつのおおきなリクエストの代わりにいくつものちいさなリクエストを使うことで効果的に並列化する。フレームごとの単位で画面上のデータを書き換える様子は、ちょっぴり SPA 風な味付けも期待できる。
“Turbo Streams” は、ページの変更を HTML の断片として表現してサーバーサイドから配信する手法である。ユーザーはただ画面を開いてなにもしないでいるだけで WebSocket とかがいい感じにあたらしいデータを届けていってくれる。もっとも、これに頼り切ってあらゆるものを双方向通信に置き換えるという目的のものではなくて、別に “Turbo Streams” がなくても機能は作れるときに、ユーザー体験をアップグレードするために使うくらいのものにもみえる。
いったんこのハンドブックを読み終えたあとで、はじめて https://github.com/hotwired/turbo-rails の細部が読めるとおもった。みっつの概念がひとつのパッケージに収まっていて、しかもコンセプト自体はフレームワークに依存しないものだから、いったいどこからどこまでが Turbo のカバーする範囲なのかということを意識できていないと使いたい使いかたで使うことはむずかしそうだ。
むずかしそうとはいっても、いまあるなかでもっともつつましい道具のひとつだとおもう。これを使いこなすとかこれですべてを置き換えるとかを目指す必要はなくて、ちいさなところから適用していけるところがなによりいいとおもう。