この記事はGoogle翻訳の結果を編集したものです。

Basecampでは多くのJavaScriptを作成していますが、現代的な意味での"JavaScriptアプリケーション"を作成するために使用することはありません。私たちのすべてのアプリケーションはサーバー側でレンダリングされたHTMLをコアに持ちJavaScriptを散りばめることでそれらを輝かせます。

これが雄大なモノリスの道です。BasecampはRuby on Railsを使用して作成された単一のコントローラー、ビュー、およびモデルのセットを使用して、ネイティブモバイルアプリを含む6つのプラットフォームで実行されます。単一の場所で更新できる単一の共有インターフェイスを持つことは、多くのプラットフォームがあるにもかかわらず、小規模なチームで実行できるようにするための鍵です.

昔のように生産性を上げてパーティーをすることができます。1人のプログラマーが間接的な層や分散システムに行き詰まることなく、猛烈な進歩を遂げることができた時代への逆戻り。JavaScriptベースのクライアントアプリケーション用にJSONを生成することだけをサーバー側アプリケーションに限定することが誰もが究極の目標だと考える以前のことです。

だからと言ってそのようなアプローチに価値がないと言っているわけではありません。多くのアプリケーション、そして確かにBasecampのようなものへの一般的なアプローチとして、それは全体的なシンプルさと生産性の後退です.

また、単一ページのJavaScriptアプリケーションの急増が真のメリットをもたらしていないと言っているわけではありません。その中で最も重要なのはページ全体の更新から解放された、より高速でより流動的なインターフェイスです。

Basecampもそのように感じられるようにしたかったのです。群れに従ってクライアント側のレンダリングですべてを書き直したか、モバイルで完全にネイティブになったかのように。

この欲求からTurboとStimulusという2つのパンチの解決策にたどり着きました。

Turboは高く、Stimulusは低く

新しい適度なJavaScriptフレームワークであるStimulusに入る前にTurboの提案を要約させてください。

TurboはGitHubで開発されたpjaxと呼ばれるアプローチから派生しています。基本的なコンセプトは変わりません。ページ全体の更新が遅く感じることが多い理由は、ブラウザーがサーバーから送信された大量のHTMLを処理する必要があるためではありません。ブラウザーは非常に優れており、その点で非常に高速です。また、ほとんどの場合でHTMLペイロードがJSONペイロードよりも大きくなる傾向があるという事実も重要ではありません（特にgzipの場合）。いいえ、CSSとJavaScriptを再初期化してページに再度適用する必要があるためです。ファイル自体がキャッシュされているかどうかに関係なく。かなりの量のCSSとJavaScriptがある場合、これはかなり遅くなる可能性があります。

この再初期化を回避するために、Turboは単一ページアプリケーションと同様に永続的なプロセスを維持します。しかし、ほとんど目に見えないものです。リンクをインターセプトし、Ajaxを介して新しいページをロードします。サーバーは完全な形式のHTMLドキュメントを返します。

この戦略だけでほとんどのアプリケーションのほとんどのアクションが非常に高速に感じられます（サーバーの応答を100～200ミリ秒で返すことができれば、これはキャッシュで非常に可能です）。Basecampの場合、ページからページへの移行が最大3倍高速化されました。これにより、単一ページアプリケーションの魅力の大部分を占めていた応答性と流動性をアプリケーションに与えることができます。

しかし、Turboだけでは話の半分に過ぎません。ざらざらしたもの。ページ全体の変更のグレードの下には1つのページ内のすべてのきめ細かい忠実度があります。要素の表示と非表示、クリップボードへのコンテンツのコピー、リストへの新しいToDoの追加、および最新のWebアプリケーションに関連するその他すべての操作を行う動作。

Stimulusの前にBasecampはこれらのスプリンクルを適用するために、さまざまなスタイルとパターンを散らばっていました。一部のコードはjQueryのピンチにすぎず、一部のコードは同様のサイズのバニラJavaScriptのピンチであり、一部はさらに大規模なオブジェクト指向サブシステムでした。それらは通常data-behavior属性にぶら下がっている明示的なイベント処理に基づいて機能しました。

このような新しいコードを追加するのは簡単でしたが、包括的なソリューションではありませんでした。また、社内のスタイルとパターンが共存しすぎていました。そのため、コードの再利用が難しくなり、新しい開発者が一貫したアプローチを習得するのが難しくなりました。

Stimulusの3つのコアコンセプト

Stimulusはこれらのパターンの最良のものをコントローラー、アクション、およびターゲットという3つの主要な概念だけを中心に展開する控えめで小さなフレームワークにまとめます。

アドレス指定しているHTMLを見るとプログレッシブエンハンスメントとして読み取れるように設計されています。単一のテンプレートを見て、それに基づいてどの動作が実行されているかを知ることができます。以下に例を示します。

<div data-controller="clipboard">
  PIN: <input data-clipboard-target="source" type="text" value="1234" readonly>
  <button data-action="clipboard#copy">Copy to Clipboard</button>
</div>

あなたはそれを読んで何が起こっているのかについてかなり良い考えを持つことができます。Stimulusについて何も知らなくても、コントローラーのコード自体を見なくても。それはほとんど疑似コードのようなものです。これはイベントハンドラーを適用する外部JavaScriptファイルを含むHTMLのスライスを読み取ることとは大きく異なります。また、現在の多くのJavaScriptフレームワークで失われている懸念事項の分離も維持されます。

ご覧のとおり、StimulusはHTMLの作成を気にしません。むしろ、それ自体を既存のHTMLドキュメントに添付します。ほとんどの場合、HTMLはページの読み込み時（最初のヒットまたはTurbo経由）、またはDOMを変更するAjax要求を介してサーバーにレンダリングされます。

Stimulusはこの既存のHTMLドキュメントの操作に関係しています。場合によっては要素を非表示にしたり、アニメーション化したり、強調表示したりするCSSクラスを追加することを意味します。グループ内の要素を再配置することを意味する場合もあります。要素のコンテンツを操作することを意味する場合もあります。たとえば、キャッシュ可能なUTC時刻を表示可能なローカル時刻に変換する場合などです。

Stimulusに新しいDOM要素を作成させたい場合がありますが、それは間違いなく自由です。将来的には簡単にするために砂糖を追加することさえあるかもしれません。しかし、それは少数派のユースケースです。要素の作成ではなく、操作に重点が置かれています。

Stimulusと主流のJavaScriptフレームワークとの違い

これにより、Stimulusは現在のJavaScriptフレームワークの大部分とは大きく異なります。ほとんどすべてが何らかのテンプレート言語を介してJSONをDOM要素に変換することに重点を置いています。多くの場合、これらのフレームワークを使用して空のページを作成し、このJSONからテンプレートへのレンダリングによって作成された要素だけで埋められます。

Stimulusは状態の問題でも異なります。ほとんどのフレームワークにはJavaScriptオブジェクト内の状態を維持する方法があり、その状態に基づいてHTMLをレンダリングします。Stimulusは正反対です。状態はHTMLに保存されるため、ページが変更されるたびにコントローラーを破棄できますが、キャッシュされたHTMLが再び表示されたときに元のように再初期化されます。

それは本当に著しく異なるパラダイムです。現代のフレームワークでの作業に慣れている多くのベテランJavaScript開発者が嘲笑するものだと確信しています。そして、ちょっと、嘲笑してください。たとえば、React + Reduxの大混乱の中でアプリケーションを維持するために必要な複雑さと労力に満足している場合、Turbo + Stimulusは魅力的ではありません。

一方、自分が取り組んでいることは、現代の技術が意味するような非常に複雑でアプリケーションの分離を保証しないというしつこい感覚を持っている場合は、私たちのアプローチに逃げ場を見つける可能性があります。

Stimulusと関連するアイデアは野生から抽出されました

Basecampでは何年にもわたってBasecampやその他のアプリケーションのいくつかの異なるバージョンでこのアーキテクチャを使用してきました。GitHubは同様のアプローチを使用して大きな効果を上げています。これは"モダン"Webアプリケーションがどのように見えるかについての主流の理解に対する有効な代替手段であるだけでなく、信じられないほど説得力のあるものです。

実際、BasecampでRuby on Railsを開発したときと同じ種類の秘密のソースのように感じます。現代の主流のアプローチは不必要に複雑であり、はるかに少ないリソースでより多くのことをより迅速に行うことができるという感覚。

さらに、選択する必要さえありません。StimulusとTurboは他のより重いアプローチと組み合わせると効果的です。アプリケーションの80%で大きなリグが必要ない場合は、2パックパンチの使用を検討してください。次に、実際に恩恵を受けることができるアプリケーションの部分に重機を展開します。

Basecampでは必要に応じてより負荷の高いアプローチをいくつか使用しています。私たちのカレンダーはクライアント側のレンダリングを使用する傾向があります。私たちのテキストエディターはTrixです。完全に形成されたテキストプロセッサであり、Stimulusコントローラーのセットとしては意味がありません。

この一連の代替フレームワークは重労働を可能な限り回避することを目的としています。その単純なモデルでうまく機能する、非常に多くのインタラクションすべてに対して、要求と応答のパラダイム内にとどまるために。次に最高の忠実度が要求されると高価なツールに手を伸ばします。

何よりも忠実度で競争し、より面倒な主流のアプローチを使用してはるかに大規模なチームとリーチしたい小規模なチーム向けのツールキットです。

試してみて。