意見

Hotwireはもっと簡単にならないのか?

本質的な複雑性と向き合う

複雑さには偶有的な複雑性(accidental complexity)本質的な複雑性(essential complexity)があります。そして偶有的な複雑性は退治できますが、本質的な複雑性には正面から向き合う必要があります。

Hotwireは多くの偶有的な複雑性を取り除いてくれます。基本的なJavaScriptだけでUIが作成でき、複雑なステートを考える必要もなく、ReactやNext.jsなどのフレームワークを学ぶ必要もありません。しかしそれでもフロントエンド開発の本質的な複雑性は残ります。

モーダルダイアログの例のところでお伝えした通り、素人には簡単に見えるモーダルダイアログでも多くのステップがあり、かなり複雑です。これは全部本質的な複雑性です。

Hotwireで各ステップを簡素化はできますが、多数のステップを実装すること、そしてこれらを連携させる作業は必ず残ります。「Hotwireを使ったらJavaScriptを使わずにモーダルが簡単にできました!」って話を聞いても、眉唾で聞いてください。ライブラリを変更した程度では、本質的な複雑性を取り除くことは不可能です。

modal-dialog-show.png

ソフトウェア製品の大市場の利用

フレッド・ブルックスは1986年に論文「銀の弾丸」を発表し、「本質的な複雑性」と「偶有的な複雑性」を論じました。そして本質的な複雑さをも退治できる「銀の弾丸」の候補の一つとして「ソフトウェア製品の大市場の利用」をあげています。つまりソフトウェアを作るのではなく、買うという方法です。

オープンソースソフトウェアの普及により、ソフトウェア開発者にとっても「ソフトウェア製品の大市場」は想像できないほどに巨大になり、誰でも無料でアクセスできるものになりました。我々が普段使用しているライブラリはまさにこのことです。

しかし課題があります。ライブラリを使っても自分が直面している課題にうまくマッチしない可能性です。ライブラリの動作のカスタマイズ方法が複雑で、ゼロから作った方が早いというケースも珍しくありません。ライブラリがずっとメンテナンスされるかどうかという課題もあります。

Hotwireについていうと、「ソフトウェア製品の大市場」とはUIコンポーネントライブラリ等を指すと思います。これは多くの人にとって「銀の弾丸」になりうるものです。ただしこの分野で先行しているReactでも、UIコンポーネントライブラリを使わない人が多くいますまたUIコンポーネントライブラリの流行りが激しく、安定しません。潜在的な可能性はあるものの、まだまだ「銀の弾丸」になり切れていないように思います。

Hotwireはもっと簡単にならないか?

これもまたブルックス氏の「銀の弾丸」論文にありますが、複雑性をなくすのは技術ではなく、迅速なプロトタイプ作成と段階的なソフトウェア開発手法、さらに優秀な設計者の育成だと彼は予測しています。

そう考えるとHotwireを簡単にするのは技術そのものではなく、MPAからMVPを作る発想モーダルダイアログの要・不要の議論、さらにより簡単なモーダルの作り方の議論などで紹介した考え方かもしれません。これは私の経験によく合致しています。

私はTurbo Streamsで複雑になっているページを、Turbo Driveに変更してスッキリ・簡単にした経験があります。モーダルを使っているページを、ページ遷移するUIに変更してTurbo Driveで実装したこともあります。試しにMVPでやってみたら、却ってその方がUI/UXが良くなったりしました。管理画面の構成を大幅に見直して、内部オブジェクトに沿うもの(OOUI: オブジェクト指向UI)に変更しただけで、拡張性のある、わかりやすいUI/UXに変えたこともあります。

レオナルド・ダ・ヴィンチは「シンプルさは究極の洗練である」と言ったとされています。

私がHotwireでページを作るときは、この言葉を常に心に留めています。