Stimulus 1.0：既にお持ちのHTML用の謙虚なJavaScriptフレームワーク

翻訳者から： David Heinemeyer Hanssonは、彼と彼のRuby on Railsチームが独自のJavascriptフレームワークを開発した理由について短いテキストを書きました。 元のテキストは 、新しいプロジェクトのリポジトリに配置されます

2月4日更新 ：元の記事はBasecampブログで公式に公開されました。 オリジナルとタイトルへのリンクを更新

Basecampで多くのJavascriptを作成しますが、現代的な意味での「JavaScriptアプリケーション」の作成には使用しません。 すべてのアプリケーションはサーバー側のHTMLをレンダリングし、javascriptスプラッシュを追加してそれらに命を吹き込みます。

これが雄大な一枚岩の道です。 Basecampは、ネイティブモバイルアプリケーションを含む多くのプラットフォームで実行され、Ruby on Railsで作成された単一のコントローラー、ビュー、モデルのセットを備えています。 単一の場所から更新される共通のインターフェースを持つことは、サポートされている多くのプラットフォームにもかかわらず、小さなチームがうまく機能することを保証するための鍵です。

これにより、古き良き時代のように、生産性を高めることができます。 分散システムの抽象化の層にとらわれることなく、一人のプログラマーがかなりの進歩を遂げることができた時代に戻ります。 誰もが聖杯がサーバー側をクライアント上のJavascriptアプリケーション用のJSONを生成するだけに制限していると考えるようになる前の時代。

これは、ある場所の一部の人々にとって、そのようなアプローチに意味がないという意味ではありません。 しかし、Basecampなどの多くのタイプのアプリケーションへの主なアプローチとして、これは一般に単純さと生産性の観点からは後退です。

また、これは、1ページのJavaScriptアプリケーションの配布が利益をもたらさなかったことを意味するものではありません。 それらは、速度、より動的なインターフェース、およびページ全体のリロードの自由をもたらしました。

また、Basecampにそのような感覚を求めていました。 まるで群れの感覚に従っているかのように見せるために、クライアントレンダリングですべてを書き直すか、モバイルで完全にネイティブなアプリケーションに切り替えました。

この欲求が、 TurbolinksとStimulusという二重のソリューションにつながりました。

ターボリンクアップ、刺激ダウン

謙虚なJavaScriptフレームワークであるStimulusに進む前に、Turbolinksの目的について簡単に説明します。

Turbolinksは、GitHubで開発されたいわゆるpjaxから来ています。 基本的な考え方は変わりません。 ページ全体のリロードが遅いように見えるのは、ブラウザがサーバーから送信されたHTMLを処理するのが難しいからではありません。 ブラウザは本当に優れており、高速です。 通常、HTMLコンテンツが類似のJSONよりも大きいという事実も重要ではありません（特にgzipを考慮）。 いいえ、主な理由は、CSSとJavascriptを再初期化し、ページに再適用する必要があることです。 ファイルがキャッシュされているかどうかに関係なく。 適切なCSSとJavaScriptサイズがある場合、これは遅くなる可能性があります。

この再初期化を回避するために、Turbolinksは、単一ページアプリケーションがこれを行うように、プロセスを一定に保ちます。 しかし、基本的に、これは目に見えないプロセスです。 リンクをキャッチし、Ajax経由で新しいページを読み込みます。 サーバーはまだ完全なHTMLドキュメントを返します。

この戦略だけで、アプリケーションのほとんどのアクションを非常に高速にすることができます（サーバーが100〜200ミリ秒で応答できる場合、これはキャッシングで可能です）。 Basecampの場合、これによりページナビゲーションが3倍に加速されました。 これにより、アプリケーションは、単一ページアプリケーションのほとんどの長所であった応答性とダイナミズムを非常に感じます。

しかし、Turbolinksはストーリーの半分にすぎません。 全ページの変更レベルの下には、単一ページ内のマイナーアップデートがあります。 要素の表示と非表示、クリップボードへのコピー、todoリストへの新しいエントリの追加、および最新のWebアプリケーションで行うその他の操作。

Stimulusの前、Basecampはさまざまなスタイルとパターンを組み合わせてこれらの機能を追加しました。 コードの一部はjQueryにあり、同様のサイズの部分はバニラJavaScriptとやや大きなオブジェクト指向システムにありました。 それらはすべて、データ動作属性に依存して、明示的なイベント処理を通じて連携しました。

このような新しいコードを追加するのは簡単でしたが、完全なソリューションではなく、いくつかの既存の自家製スタイルとパターンが並行してありました。 これにより、コードを再利用し、新しい開発者に何らかの統一的なアプローチを教えることが難しくなりました。

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

Stimulusは、これらのパターンのベストを、コントローラー、アクション、ターゲットという3つの基本概念を中心とするささやかな小さなフレームワークにラップします。

意図するHTMLを徐々に改善するように設計されています。 そのため、単純なテンプレートを使用して、どの動作がそれに影響するかを確認できます。 以下に例を示します。

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これを読んで、何が起こっているかについてかなり良いアイデアを得ることができます。 刺激について何も知らず、コントローラー自体のコードを見なくても。 それはほとんど擬似コードに似ています。 これは、ここにイベントハンドラーをぶら下げる外部JavaScriptファイルがあるHTMLの一部を読み取ることとは大きく異なります。 また、多くの最新のJavaScriptフレームワークで失われたエンティティの分離も提供します。

ご覧のとおり、StimulusはHTMLの作成について心配していません。 むしろ、現在のHTMLドキュメントにフックします。 また、ほとんどの場合、HTMLは、ページをロードする（最初の呼び出し）か、DOMを変更するAjaxリクエストを介してサーバーにレンダリングされます。

刺激は、既存のHTMLドキュメントの操作に焦点を当てています。 これは、要素を非表示、アニメーション化、または強調表示するCSSクラスを追加することを意味する場合があります。 これは、グループ内の要素を再配置することを意味する場合があります。 場合によっては、要素のコンテンツを操作することを意味します。たとえば、コンテンツと共にキャッシュされているUTC時間をローカルに変換してユーザーに表示することです。

このような場合、Stimulusで新しいDOM要素を作成する必要がありますが、作成は自由です。 将来的には、さらに簡単にするために砂糖を追加することもあります。 しかし、これらは二次的なシナリオです。 主な焦点は、要素の作成ではなく操作です。

StimulusとメインストリームJavaScriptフレームワークの違い

これにより、Stimulusはほとんどの最新のJavaScriptフレームワークとは大きく異なります。 それらのほとんどすべてが、何らかのテンプレート言語を介してJSONをDOM要素に変換することに焦点を当てています。 ほとんどの場合、これらのフレームワークを使用して、JSONからテンプレートへのレンダリングによって作成された要素のみで満たされた空白ページを作成します。

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

これは大きく異なるパラダイムです。 最新のフレームワークを使用した経験豊富なJavaScript開発者の多くがモックを作成すると確信しています。 しかし、いや、私を放っておいてください。 アプリの渦を維持するために必要な複雑さと労力、たとえばReact + Reduxに満足している場合、Turbolinks + Stimulusは魅力的ではありません。

しかし一方で、作業しているものが現代のテクノロジーに含まれている複雑さやアプリケーションの分離のレベルを必要としないと感じているなら、私たちのアプローチに救いを見いだすでしょう。

現実世界からの刺激と関連するアイデア

Basecampでは、このアーキテクチャをBasecampのいくつかのバージョンや他のアプリケーションで数年間使用しています。 GitHubは同様のアプローチを使用し、素晴らしい効果をもたらしました。 これは、最新のWebアプリケーションがどのように見えるかについての主流の理解に代わるものであるだけでなく、驚くほど競争力があります。

実際、Ruby on Railsを行ったときにBasecampにあった秘密の材料のように見えます。 現代の一般的なアプローチは非常に単純であるため、少ない労力でより多くのことができると感じています。

さらに、選択する必要さえありません。 刺激とターボリンクは、他のより重いアプローチと連携して非常に効果的です。 アプリケーションの80％が複雑なインストールに収まらない場合は、2コンポーネントビルドを試してください。 次に、アプリケーションの実際の恩恵を受ける部分に重機を配備します。

Basecampでは、必要に応じて、より複雑なアプローチをいくつか使用します。 カレンダー機能はクライアント側のレンダリングを使用します。 私たちのテキストエディター、Trixは、完全に組み立てられたワードプロセッサであり、Stimulusコントローラーの束のようには意味がありません。

代替の減量フレームワークのこのセットは可能な限りです。 この単純なモデルでうまく機能するほとんどの相互作用について、要求と応答のパラダイム内にとどまること。 次に、最大の効果を達成することが理にかなっている高価なツールを使用します。

まず第一に、これは、より労働集約的な主流のアプローチを使用して、より大きなチームとカバレッジを競いたい小さなチームのためのツールのセットです。

彼にチャンスを与えてください！

GiHubプロジェクトへのリンク