お好きなものでハイパーメディアを

Carson Gross

（MPAの）残された大きな利点の一つは、（サーバーサイドのプログラミング）言語の選択です。もしあなたがすでに反JavaScript抵抗勢力の一員であるならば、この講演の残りの部分で私が言うことはあまり重要ではないでしょう。

しかし、これについては後で詳しく説明しますが、その船はもう出航してしまったかもしれません…

Rich Harris - SPAはWebをダメにしたのか？

私たちがよく話題にするコンセプトは「HOWLスタック」です。HOWLはお好きなものでハイパーメディアをの頭文字です。

これはジョークのようですが、実際はそうではないソフトウェアスタックであり、LAMPスタックやMEANスタックのような、よりよく知られたスタックへの言及でもあります。

HOWLスタックの要点は次のとおりです。Webアプリケーションでハイパーメディア駆動型アプローチを使用すると、問題と自分の技術的な好みに最も適したサーバーサイドテクノロジーを自由に選択できます。

#JavaScriptのプレッシャーを感じる

WebアプリケーションにSPAフレームワークを使用することにした場合、当然のことながら、JavaScriptで記述された大規模なフロントエンドコードベースを持つことになります。

それを踏まえると、必然的に次の疑問が浮上します。

「では、なぜバックエンドもJavaScriptでやらないのか？」

これはもっともな疑問であり、ワイヤーの両側で同じプログラミング言語を採用することには多くの利点があります。

JavaScriptへの投資が増えるにつれて、JavaScriptを採用するこのプレッシャーは増大する一方でしょう。

さらに、JavaScriptは過去5年間で劇的に改善されており、現在ではそれを実行するための優れたサーバーサイドランタイムが複数存在します。言語の混乱に関する古い議論の多くは、リンティング、開発者の規律などによって回避できるものとして片付けることができます。

JavaScriptはWeb開発の思想的リーダーの間で支配的な言語であり、言語を強く強調するチュートリアル、コードキャンプなどが多数あります。成功したものは他に類を見ないほど成功し、JavaScript（およびReact）は成功を収めました。

この結果をJavaScriptのプレッシャーと呼び、Webに関わるほぼすべての開発者が多かれ少なかれそれを感じていることを認めましょう。

#ハイパーメディア：私たちの唯一の希望

Web開発において、非JavaScript開発者にはどのような希望があるのでしょうか。

そうですね、JavaScriptと並んでブラウザに存在する古いテクノロジーが1つあります。それがハイパーメディアです。

ブラウザは優れたHTMLサポート（および関連するドキュメントオブジェクトモデル、またはDOM）を提供します。実際、SPAフレームワークを使用している場合でも、ブラウザが理解できるUIを作成するためだけに（たとえばJSXテンプレートを介して）、何らかの形でそのハイパーメディアインフラストラクチャを操作することになります。

したがって、Webアプリケーションでは何らかの方法でHTMLまたは関連するDOM APIを使用することになります。

では、HTMLをもっと強力なハイパーメディアにしたらどうでしょうか。

それがhtmxのアイデアであり、ハイパーメディアアプローチを使用して一般的な最新Webアプリケーションパターンを実装することを可能にします。これにより、従来のMPAとSPAの間のUXギャップが解消され、より多くのWebアプリケーションでハイパーメディアルートを採用することが実現可能になります。

このハイパーメディアアプローチを採用すると（そして、ハイパーメディアインフラストラクチャはいずれにしても使用することになるため、できるだけ活用してみませんか？）、驚くべき副作用が発生します。

突然、HarrisがMPAに起因するとしたサーバーサイド言語の選択の利点が復活します。

アプリケーションのフロントエンドが主にHTMLで記述されており、クライアントサイドスクリプトが少しあるだけで、大規模なJavaScriptコードベースがない場合、バックエンドに対するJavaScriptのプレッシャーが劇的に軽減（または完全になくなった）ことになります。

これで、サーバーサイドの言語（およびフレームワーク）の選択を、技術的、美的、その他の考慮事項に基づいて行うことができます。

これらはすべて、技術的、哲学的、美的観点から見た、完全に合理的な考え方です。

そして、ハイパーメディアを主要なフロントエンドテクノロジーとして採用することで、2つのコードベースを持つことなく、これらの目標のいずれも追求できます。ハイパーメディアは、それを作成するために何を使用するかを気にしません。お好きなものでハイパーメディアを使用できます。

#すべての人にとってオープンなWeb

そして、「お好きなもので」と言うとき、私たちは本当にそれを意味しています。

これが最近のhtmx discordのHOWLサブセクションのスクリーンショットです。これらはアクティブなトラフィックがあるチャンネルにすぎないことに注意してください。他にもたくさんあります。

Java、Go、.NET、Rust、Clojure、PHP、Ruby、Python、Ocamlなど、さまざまなプログラミング言語とフレームワークで継続的に会話が行われています。BashとCobolでhtmxを使用することについて話している人もいます！

これがまさに私たちが望んでいる未来です。すべてのバックエンド言語とフレームワークが、対等で興味深い代替手段として機能できる、豊かで活気に満ちたWebです。各言語とフレームワークには独自の強みと文化があり、それぞれがWebという魔法のようなハイパーメディアシステムに貢献できます。

#しかし、それは反JavaScript抵抗勢力なのか？

このエッセイを終える前に、あらゆる場所でのJavaScriptへの抵抗が必ずしも反JavaScriptであるという考えに取り組みたいと思います。

確かに、私たちはJavaScriptに関するジョークを散々笑ってきました。そして、Web用の代替スクリプト言語であるhyperscriptを作成するところまで進みました。

したがって、私たちは反JavaScript支持者であるように見えるかもしれません。

しかし、それどころか、私たちはJavaScriptに深く感謝しています。

結局のところ、htmxとhyperscriptの両方ともJavaScriptで構築されています。JavaScriptがなければ、これらのライブラリを作成することはできませんでした。JavaScriptは、他に何と言われようと、そこにあるという大きな利点があります。

そして、私たちは、ハイパーメディア駆動型アプリケーションでフロントエンドスクリプトのニーズにJavaScriptを使用することさえ推奨しています。ただし、ハイパーメディアフレンドリーな方法でスクリプトを作成する場合に限ります。

さらに、チームにとって最適なオプションである場合、ハイパーメディア駆動型アプリケーションでサーバーサイドでJavaScript（またはTypeScript）を使用することから誰かを遠ざけたりはしません。前述のように、JavaScriptには現在、複数の優れたサーバーサイドランタイムと、多くの優れたサーバーサイドライブラリが利用可能です。

それがあなたとあなたのチームにとって最良の選択肢である可能性があり、その場合はそれを使用しない理由はありません。

お好きなものでハイパーメディアを、とはまさにその意味です。お好きなもので。

しかし、JavaScriptは、チームにとって唯一のサーバーサイドオプションであるべきではありません。

#船を方向転換する

ハイパーメディアへの関心の再燃（および改善）により、Webのオープンで多様な未来が現実になる可能性が出てきました。現実化しつつあると言えるかもしれません。

Webは、オープンで多言語対応、参加型のハイパーメディアシステムとして設計されました。

そして、その夢はまだ終わっていません。少なくともまだ！

Webの基礎テクノロジーであるハイパーメディアを再学習し、再採用することで、その夢を生き続けることができます。

htmxコミュニティが、いいねを気にせず、誇大広告を追いかけない人々を巻き込み、短いフレーズをニュアンスに変えていくのを手助けするような、開発者同士が助け合うコミュニティへと変化したことを私は嬉しく思っています。それは安易なソーシャルメディアポイントを獲得しないかもしれませんが、健全です。Webは以前よりも悪くなっていました。

@teej_dv

</>