HTMXの未来

27,488 文字

最初はHTMLだった。プリンター用のマークアップ言語が、今では完全にウェブを支配している。それ以来、多くのイノベーションがあった。良いものもあれば、悪いものもあり、醜いものも多かった。でも、その中の一つ、HTMXは実に良いものだ。
このブログ記事について、私は本当にワクワクしている。彼らのサイトで何か記事を読むたびに、いつも面白い方向に展開している。私がHTMXを嫌っていると思っている人がいるようだが、そういう人たちは明らかに私のHTMXに関する動画を十分見ていないか、皮肉が理解できていない。これは本当に重要なプロジェクトで、素晴らしいことをたくさんしていると思う。
もし、HTMXの未来について私の分析を見たいなら、何が素晴らしくて何がそうでないのか、そしてなぜあなたがテクノロジーとしてHTMXを少なくとも検討すべきなのかについて、最後まで見ていってほしい。
でも、まずは今日のスポンサーからの一言。今日のスポンサーはデータベースで、正直なところ私のお気に入りになりつつある。彼らはこれを「最後にして唯一必要なデータベース」と呼んでいて、その理由も理解できる。
私たちが話しているのは、選択、並び替え、グループ化、合計、そしてベクトルキー検索までも、すべて単一のSQLクエリで実行できるデータベースについてだ。私の言葉を信じるか、あるいはFathomの共同創設者であるJackの言葉を信じるかだ。「私たちは今、single store Heliosに完全に移行し、これによってRedis、DynamoDB、MySQLを削除でき、月額コストを大幅に削減しながら、パフォーマンスも劇的に向上させることができました。」
多くの人々がこう言っているのは、single storeが性能を犠牲にすることなく、そのすべての機能性を提供する強力な体験を与えてくれるからだ。私のお気に入りの例は、JSONサポートだ。MySQLと互換性のあるクライアントを使って、代わりにsingle storeにポイントすることができる。それは単にJSONブログに投げ込まれ、ほとんどの場合、MySQLベースであるにもかかわらず、あなたのものよりもかなり高速になる。本当に素晴らしい。
無料枠は永久に無料で、本当に必要ならDockerでセルフホストすることもできる。DrizzleからPHPまで、すべてをサポートしており、現代的なスタックのJavaScript開発者にとっても、古いスタックのPHP開発者にとっても素晴らしい体験となっている。
仕事に適したデータベースを選ぶのに疲れたなら、あらゆる仕事をサポートする一つを選んでみてはどうだろうか。soy.l/singlestoreでチェックしてみてほしい。
HTMXの未来について。始めに、HTMXはintercoolerとして生まれた。待って、私の偽の批判はどうなったんだ？私はHTMXがただのintercoolerの模倣だと装ったんだけど、彼らはそれを自分たちのブランドの一部にして、本当に面白かった。でも、もし誰かが最初のHTMXは糞だという動画の皮肉を見逃していたとしたら、HTMXは元々intercoolerだったけど、それをさらに発展させたんだ。
私はintercoolerが実際にjQueryを基盤に作られていたことを知らなかった。これは知っておくと面白い。開発者たちにとって、jQueryはクロスプラットフォームのJavaScriptを書くことを非常に簡単にした歴史のあるJSライブラリだ。ブラウザの実装が非常に不統一で、JavaScriptが今日持っているような便利なAPIや機能の多くを持っていなかった時代にね。
これは簡単に言えば、Internet Explorerが糞で、他のすべてのブラウザも別の方法で糞だったということだ。そう、今日多くのウェブ開発者はjQueryをレガシーソフトウェアと考えているが、すべての敬意を込めて言えば、jQueryは現在公開されているウェブサイトの75%で使用されており、この数字は他のすべてのJSツールを圧倒している。
この数字には異議を唱えたい。私は以前からこれについて話してきたが、ウェブサイトの使用率でツールの成功を測ることは好きではない。なぜなら、誰も訪れない古いウェブサイトがたくさんあって、それらは意味のある測定とは言えないからだ。
それはAtariのE.T.が最も成功したゲームの一つだと言うようなものだ。確かに彼らはE.T.のコピーをたくさん作ったけど、そのほとんどはアリゾナのどこかの溝に埋まっているんだ。それは数に入れるべきではない。
測定するのはほぼ不可能だけど、これらの指標について話すとき、私が見たいのは、例えばjQueryを使用しているウェブサイトでどれくらいの時間を過ごしているかとか、ウェブ上で過ごす時間の何パーセントがjQueryをインポートしているサイトなのか、ウェブ開発の世界で何パーセントの開発者がjQueryの仕事に雇われているのか、日々どれくらいの人々がそれを使用しているのかという比率だ。
この数字の現実は、75%以上のウェブサイトが古くてメンテナンスされていないということだ。この数字を使って、それ以外のことや、ある時点でのテクノロジーの普及度について語るのは適切ではないと思う。
チャットの人々は既に良いミームを投下している。「水を飲んだ人の100%が死ぬ」というような感じだ。そういう類の話に聞こえる。
はっきりさせておくと、私はjQuery嫌いではない。これは信じられないほど重要なテクノロジーで、私たちのどれ一人として、これなしには今ここにいなかっただろう。私は定期的にそれを称賛している。私のjQuery 4の動画を見てみてほしい、もし信じられないなら。
これを維持するのは感謝されない努力だが、ウェブにとって非常に重要だ。しかし、75%の人々が常にそれを使用しているわけではない。それは少し誤解を招く数字だ。でも、なぜそれがそれほど普及したのか、その技術的な理由について話すべきだろう。
jQueryの継続的な成功に貢献する3つの技術的な理由があると私たちは考えている：

プロジェクトに追加するのが簡単
一貫したAPIを維持し、その生涯を通じて大部分で後方互換性を保っている
ライブラリとして、必要な分だけ使用でき、アプリの構造を強制しない

これら3つのうち、Reactが行っているのはこれだけだ。10年前のReactコンポーネントを今日のサーバーサイドレンダリングされたNext.jsコンポーネントアプリに投げ込むことができる。これは本当にクールだ。
でも、私はこれに同意する。これは失われた芸術だ。スクリプトタグを追加するだけでより多くの機能を得られるという考え方は、しばらくの間なかった。
HTMXは新しいjQueryだ。これは大胆な発言で、彼らがどこに向かうのか楽しみだ。
おや、彼らも同じことを言っている。「もちろん、これは馬鹿げた傲慢な発言だ。しかし、これはHTMXチームである私たちが目指している理想だ」。
特に、私たちはウェブ開発者のツールキットにとって、低コストで高価値な追加となったjQueryのこれらの技術的特徴を模倣したいと考えている。
Alexは100年ウェブサービスの構築について議論してきた。私たちはHTMXがまさにそのユースケースにとって有用なツールになることを望んでいる。jQueryで構築されたウェブサイトは非常に長期間オンラインのままであり、HTMXで構築されたウェブサイトも同じかそれ以上の能力を持つべきだ。
以前の私の75%という数字についての発言を撤回するかもしれない。もし彼らが「忘れ去られても動き続けるものを作りたい」というピッチをしているなら、それは私も100%賛成できる。
今後、HTMXは既存のユーザーを念頭に置いて開発される。もしあなたがHTMXの既存ユーザーであるか、ユーザーになることを考えているなら、これが意味することは以下の通りだ。
面白い。これは非常に興味深いピッチだ。私は最近、アプリケーションの複雑さについてよく考えている。これは夜に悩まされる類のことの一つだ。夜眠れなくなるようなものについて、きっと皆も経験があるだろう。
明らかに、複雑さについて考えるとき、多くはReactについて考えることになる。私が気づいたのは、Reactについて私たちは必ずしもその責任ではない奇妙な認識を持っているということだ。
問題から始めよう。その問題とは、どうやってウェブアプリをよりダイナミックにするかということだった。そして私たちには興味深い解決策があった。Ajaxだ。
ちなみに、AjaxはAsynchronous JavaScript and XMLの略だ。これが重要な理由、これが存在する理由は、Ajaxがブラウザの標準の一部として導入されるまで、ページが読み込まれたら終わりだったということだ。
ネットワークタブで、更新時に異なる事柄が起こり、接続され、進行しているのを見せるという考え方は、本当には存在しなかった。画像タグを置いて、それが読み込まれるということはできた。しかし、ブラウザがJavaScriptを使って別のサーバーにアクセスし、何かを行い、そしてブラウザに戻ってきて、何かに使用するための更新されたデータを持ってくるという考え方は、常にそこにあったわけではない。
これはウェブ開発の歴史のある時点で、更新可能なページを作るという問題を解決するために導入された。それまでは、何かを行いたい場合はフォームを送信し、フォームが送信されると新しいHTMLコンテンツが返されるか、新しいHTMLページにリダイレクトされ、それによって見えるUIが変更されていた。
JavaScriptはアニメーションや要素の移動には使用されていたが、新しいデータの取得には使用されていなかった。Ajaxは、JavaScriptでサーバーから新しいHTMLを要求し、それを別の場所でレンダリングすることを可能にした。
これには本当にクールなことがいくつか付随していた。最大の初期のAjaxアプリ、すべてを変えたアプリ、今日でも使っているかもしれない、信じられないかもしれないが、最初のAjaxアプリは今でも非常に人気のあるGmailだ。
AjaxとGmailはすべてを変えた。この時点まで、もしメールのウェブアプリを使用していたなら、それは最悪だった。良いエディター体験を持つことができず、別のメールが届いた通知を受け取ることもできなかった。タブバーに行って戻ると、快適なUIを得ることができなかった。入力ボックスでの入力以外の何かを変更するたびに、ページ全体を更新しなければならなかった。ひどかった。
Gmailは、はるかに多くのことを可能にした。Outlookや他のデスクトップメールアプリを皆が使っていた時期があった。なぜなら、ウェブアプリがあまりにも悪かったからだ。Gmailは、このブラウザ内でページを変更せずに更新するという新しいテクノロジーを使用することで、私たちが何かを構築する方法を根本的に変えた。
これが革命だったと考えるのは狂っているかもしれない。今ではそれが当たり前になってしまったからだ。しかし、本当に革命だった。しかし、GoogleがGmailでこれを行うために、彼らは多くのことを発明しなければならなかった。その中には素晴らしいものもあれば、まずいものもあり、それ以来私たちが学んでいることもあれば、完全に捨て去ったものもある。しかし、これが起きたとき、私たちは多くのことを学んだ。
私たちが学んだことの一つは、より良いライブラリが必要だということだ。そしてそれは私たちが得たまさにそのものだ。そうして私たちが得たものが、誰もが知っていて愛しているMo toolsになった。今、smooshgateについて深く掘り下げたい誘惑に駆られているけど、本当に魅力的だが、やめておこう。
Mo toolsのようなツールは全てを変えた。そしてjQueryはさらに進んで、この素晴らしい魔法のような新しい構文「$.ajax」を持っていた。サーバーから何かを要求するのが突然本当に簡単になった。実は昨日、あるプロジェクトのために再現しようとしていたコードを読んでいたんだけど、そこにはたくさんの「$.ajax」呼び出しがあって、本当に面白かった。本当に、本当に面白かった。
しかし、ここにはもう一つの欠けているピースがあった。それはXML、XMLだ。私たちはまだサーバーから効果的にHTMLのチャンクを送信していたか、あるいは実際のデータを少し含んだXMLをフォーマットすることができたが、それは最悪だった。ひどかった。そしてそれが、最後の重要なピースが発明された理由だ。
Json、元々はJmal、Primeのお気に入りのもの、JavaScript Markup Languageが、JavaScript Object Notationになった。ここでの目標は、JSにおけるオブジェクトの見た目を取り、サーバーがブラウザにオブジェクトを送信できるようにすることだった。これは魔法のような変化だった。
なぜなら、それまでJavaScriptは単にHTMLとXMLを操作し、それらの異なるものの間で変換しようとしていただけだったからだ。Jsonがあれば、サーバーはJavaScriptが慣れている形のデータを、ブラウザが何かをするために使用できる形でブラウザに送信することができた。
これは全てを変えた。Jsonを使って、私たちはずっと複雑なウェブアプリを作り始めた。サーバーはHTMLがどのように見えるかを教えなくなり、サーバーは少しのHTMLを与え、そのHTMLが読み込まれた後、JavaScriptが引き継いで、サーバーからデータを取得し、クライアント上でユーザーに適したHTMLを作成しようとするようになった。
しかし、これら全ての変化、特にこの下の部分が表す変化を覚えておくことが重要だ。これはクライアントでのレンダリングを始めた時期だ。より良いライブラリを手に入れ、これらの部分でJsonを手に入れ始めたとき、サーバー上でのHTMLは減り、クライアント上でのHTMLが増えた。
それと共に、ユーザーの期待も変わり始めた。だから、Jsonの後、複雑さの爆発が起きた。はっきりさせておくと、Jsonが複雑だから、それ以降の全てが必然的に複雑になったと言っているわけではない。
私が言っているのは、これらのツールによって、GoogleがGmailに持っていたような魔法使いがいなくても、普通の人々がより動的なものを作り始めることができるようになったということだ。
投稿を書いて送信ボタンを押したときに、ページ全体を再読み込みする必要がないTwitterフィードを想像してみてほしい。代わりに、それが下にすぐ表示される。通知をスクロールしていって、底に到達したとき、新しいページに移動したり次のボタンを押したりすることなく、さらに通知が読み込まれるサイトを想像してほしい。
これらの種類のワークフローは、これらのテクノロジーが登場する前は本当に不可能だった。そしてGmailがウェブ上での高品質な体験の基準を設定し、これらのツールが他の人々も同じことを始めることを可能にしたため、ユーザーの期待は上がり始め、開発者はより複雑なものを作り始めた。
厳しい現実は、私たちが複雑さの軍拡競争に巻き込まれたということだ。なぜなら、誰もがウェブ上で最高のアプリを持ちたいと思い、誰もがこれらのテクノロジーを使用していたからだ。これらのテクノロジーがより複雑なものを作ることを簡単にしたとき、より多くの人々がより複雑なものを作り始め、より資格の少ない人々がより複雑なものを作り始め、ユーザーの期待は上がり始めた。
これを図示すると、時間軸でこのようになる。ここで私が図示したいのは、これらの事柄がどのように関連しているかだ。複雑なアプリを作ることの難しさは赤、平均的なアプリの複雑さは緑、ユーザーの期待は黄色だ。
Ajaxの前は、複雑なウェブアプリを作ることは基本的に不可能だった。そのため、ここにギャップを置くことにする。効果的にデッドゾーンやその領域だ。その時代は厳しい時代だった。その時代に何かをすることはできたが、最終的にはできるようになった。
突然、私たちはより複雑なことができるようになり、そしてツールは時間とともに良くなっていった。しかしReactが起こった。Reactは、そのような複雑なアプリを作ることの難しさを大幅に減らすことを可能にした。時々問題に遭遇することはあったが、かなり良かった。
そしてhooksが起こり、さらに簡単になった。そして私たちは、ブラウザでより複雑なユーザー体験を作ることをより簡単にするツールとテクノロジーをどんどん追加し続けている。これが物議を醸す意見でないことを願う。
つまり、ここでAngularが起こり、Reactが起こり、hooksが起こった。はっきりさせておくと、これは「これらが起こった唯一の影響を与えたもの」という意味ではない。これはより一般的に、複雑さがどのように変化してきたかということだ。
これと共に、平均的なアプリの複雑さは大きく変化した。ウェブアプリは昔はとても退屈だった。懐かしいPHPの掲示板の日々、phpbbの古典を覚えているだろうか。しかしGmailが登場したとき、私たちはすぐにわずかな上昇を見た。
突然、より複雑になり始め、そしてAngularが起こったとき、MEANスタックが起こったとき、即座にスパイクが起きた。突然、平均的なウェブアプリはずっと複雑になり始め、それ以来、着実に上昇を続けている。
人々がこの線を単独で見るとき、なぜそうするのか理解できるが、この線だけを見て、ウェブアプリがどれほど複雑になっているかを見ると、それを可能にしたテクノロジーを責めるのは簡単だ。「ああ、そうだね。テクノロジーがとても悪くて恐ろしく複雑だから、明らかにすべてのウェブが複雑になっている。もし彼らがjQueryを使っていれば、これは決して起こらなかっただろう」と。
しかし、ここでユーザーの期待について話す必要がある。なぜなら、これがここでの唯一の直線だからだ。ユーザーがソフトウェアに対して持つ期待は、時間とともにゆっくりと一貫して上がり続けている。
これは奇妙な時代をもたらした。誰もウェブアプリを使用していなかった時期があった。私たちは皆デスクトップソフトウェアを使用していた。Appleは、iPhoneではアプリをインストールする必要はなく、Safariに行って全てを行えばいいと私たちを説得しようとした。
それは失敗した。結局、彼らはアプリストアを導入した。そしてこれは確実にここに含まれるだろう。ユーザーの期待が、ほとんどのアプリが生存できる複雑さの範囲を超えていたこの時代に。
私がここで言おうとしているのは、複雑なアプリを作ることが簡単になるにつれて、平均的なアプリの複雑さは本質的に上がっていったということだ。なぜなら、私たちは自分たちが作るものについてより野心的になり、そしてユーザーの期待は私たちと共に一貫して上がり続けているからだ。
確かに、その過程で変化や衝撃はあった。Chromeが登場したとき、人々が期待するものは確実に比較的急速に変化したと思う。しかし重要なのは、これらの全てが互いに影響し合っているということであり、その一つだけを分析することは、私たちがここに至った全体像を見逃すことになる。
そして私たちはこの複雑さの軍拡競争に巻き込まれたが、同時にユーザーの期待は上がり続けた。私たちがしなかったのは、ここに戻って「そこまで複雑である必要のないアプリについてはどうだろうか」と考えることだ。この程度の複雑さしか必要としないアプリについてはどうだろうか。
ツールはここでは役に立たない。Angular、React、その他のフレームワークやテクノロジー、webpack、バンドラー、そしてそれらのすべてで起きたイノベーションの全て、それらのどれもシンプルなアプリをより良くすることには役立たなかった。実際、それらは逆に悪影響を与えたように感じる。
なぜなら、もし私がシンプルな静的ブログを持っていて、しかしページを更新せずにコメントを残すことができるコメントセクションを持ちたいと思った場合、私が今まで話してきたテクノロジーのどれも、本当にそれを助けることはなかったからだ。
jQueryでDIYすることはできたかもしれないが、Angular、Reactなどを採用した瞬間、それはアプリ全体を支配する。なぜなら、それらはアプリケーションフレームワークであり、完全なトップダウンのアプリケーションを作るのを助けようとしているからだ。
そして誰も、これらの新しいツールやテクノロジーの全ての採用なしに、ユーザーが持つようになった新しい期待に応えるのを助けることに本当に時間を取っていなかった。もしReactやAngularの複雑さを持ち込みたくない、アプリケーションにwebpackのビルドステップを追加したくないけれど、ブログにより良いコメントセクションを持ちたいと思った場合、それは過去10年間であまり良くなっていない。
そしてWeb Componentsのようなものを見ると、私たちがどれほど苦しんでいるかが分かる。ブラウザの標準もここでは助けにならない。結果として、多くの人々は良い感触のウェブアプリを持つためには、シングルページアプリのテクノロジーが必要だと感じてきた。
そしてそれは最悪だ。あなたの選択肢は、Reactのような複雑なフレームワークを採用するか、Web Componentsのようなツールを使って自分の複雑なフレームワークを構築するか、あるいはjQueryの暗黒時代に戻って全てを自分でDIYするかだ。
これらのどれも満足のいく答えではない。これらのどれも開発者体験に意味のある改善をもたらさない。そしてもし私が欲しいのが、HTMLをユーザーに送信するサーバーだけれど、何かをするたびにページを変更する必要がないようにしたいだけなら、それは本当に助けられていない。
それがHTMXをとても素晴らしいものにしている。私は以前に作った図を使ってこれを説明しようと思う。もし左側にバックエンド、右側にフロントエンドがあるとすると、私たちは各側に関連付けられた特定のテクノロジーを持っている。
私が注目したいのは、任意の品質だ。この図を最初に作ったとき、人々を怒らせるほどではなかった。それは正直驚きだった。何とラベル付けしたか覚えている。ここで任意の品質を与えることにしよう。
もし左にバックエンド、右にフロントエンドがあるとすると、一方に焦点を当てれば当てるほど、もう一方で提供できる潜在的な品質は下がる。そしてもしフロントエンドアプリを作っていて、Theoが推奨するようなことを全て行っているなら、例えばsoy、next.js、serverless、trpc、bongod DBのフルスタックマジックのようなもの、もしこれがあなたの構築方法だとしたら、あなたはバックエンドを正統的な伝統的な方法では構築していない。
バックエンドの世界で起きている最高のものを使っているわけではない。そしてもしバックエンド開発者と話をすれば、彼らはあなたを少し馬鹿にするだろう。それは理解できる。しかし、もしあなたの目標がその範囲内の体験を作ることなら、もしあなたの製品の優先順位がここにあるなら、つまり、できる限りフロントエンドを良くすることが、あなたが気にしている差別化要因なら、この範囲に住むツールとテクノロジーが、おそらくあなたを最も助けてくれるだろう。
しかし、もしあなたが動画をエンコードしたり、クレイジーなデータ処理や分析を行ったりするサービスを構築しているなら、これらのテクノロジーはあなたを傷つけるだろう。もしあなたのアプリの複雑さと、あなたが気にしていること、あなたの差別化要因がこの範囲にあるなら、あなたはkubernetes、terraform、rust rewrite、plus Tokyoの世界に深く入り込んでいる。
もしそれがあなたの住む世界なら素晴らしい。もしあなたが可能な限り安価に可能な限りスケールするバックエンドを作ろうとしているなら、私がここで推奨しているものは、あなたが即座に注目すべきテクノロジーやツールではない。あるいは、その側面に焦点を当てているPrimeのような人々により注意を払うべきだ。
この図を見る別の方法がある。品質の代わりに、これを許容度や目標として考えてみよう。ここでバックエンドを削除して、与えられたアプリに対してどれくらいの複雑さが必要かを描いてみよう。例えばupload thingを見てみよう。はい、これをもっと上手く描こう。
左側を基本的に静的なHTMLページとしよう。私は自分のフレームワークをcanvasで作った。ここで強調したいのは、ウェブアプリがどれほど複雑で対話的になりうるかという両極端を意味している。この側にはfigmaのようなものがあり、こちらの側には静的ブログがある。
バックエンドのテクノロジーは、これを行うときに全く邪魔にならない。もし主に静的なHTMLページを作っているなら、基本的に何を使っても問題ない。そして、私たちがpingで作ったようなものを見てみると、upload thingはおそらくここに快適に収まる。
upload thingを見たことがない人のために説明すると、これはフルスタック開発者、特にウェブ寄りの開発者がアプリにファイルアップロード機能を追加するための最良の方法だ。ユーザーが安全にファイルをアップロードできるようにする。私たちはpingでこれを作るのに多くの作業を費やした。私たちが作ったものを本当に誇りに思っている。
これを持ち出す理由は、ダッシュボードの管理、アプリの作成、そういったことを全て行うウェブアプリが、クールで、本当に良く動くということだ。私たちはnextjsのサーバーコンポーネントとapp routerの全ての機能を使っているが、それはかなりクールだ。
しかし、それは全てを必要としているわけではない。私は全体を標準的なPHPで書き直すことができる。Live Wireのようなものを使用せずに、単に静的なHTMLを出力するだけでも。それは素晴らしいものにはならないだろうが、問題はないだろう。
しかし、もし私たちが作った別のもの、例えばPingと比較すると、Pingはもう少し複雑だ。これはストリーマーがライブコラボレーションコンテンツを作成するためのZoomクローンだ。これは作るのが難しい製品だ。チームと一緒にこれを作るのに多くの時間を費やした。私たちが作ったものを本当に誇りに思っている。
もしprimeagenや私、あるいはAustin showのような番組で、多くの人々とライブコラボレーションをしているのを見たことがあれば、私たちの多くが使用しているのがpingだ。そしてそれが私がこれを作った理由だ。実は面白いことに、私はストリーマーになる前にこれを作った。
そしてここでクライアントの体験を素晴らしいものにするために私たちがしなければならなかったことの量は、HTMLファーストのフレームワークでは実現できなかっただろう。私たちはこれをnextで作ったが, nextjsをほとんど使用していない。
T3スタックはこのプロジェクトのために元々作られた。ユーザーに素晴らしいダイナミックな体験を提供するという目標で。そして私は本当にそれを達成できたと思う。しかし、私たちはそれを、バックエンドで狂ったようなイノベーションを起こすことではなく、フロントエンドで狂ったことをやり、State Managementとレンダリング、web RTCで狂ったことをやることで達成した。
良い体験を作るために。バックエンドは本当に考えなかった。JsonブロブとC認証、通話に参加するためのトークンを保存する場所以上のことは考えなかった。
しかし、これを見たとき、実際に私には目立つことがある。もしこれを反転させて、フロントエンドの複雑さの代わりにバックエンドの複雑さにすると、左側にはCRUD、つまり文字通りJsonブロブを書き込むために送信するか、読み取るためにJsonブロブを受信するだけのものがある。
もう一方の側には、グローバルに分散された、自動スケーリング、トランザクショナルに安全なデータ、gdpr 4コンプライアンス、つまり可能な限り最高のバックエンドを作ることに全力を注いでいるものがある。
もし私がこれら2つの線を正確に取るなら、ここで私がしなければならない変更は実際にかなりシンプルだ。うまくいけば、これが要点を強調するのに役立つ。Pingのようなサービスでは、バックエンドは比較的シンプルだ。
キーを特殊な方法で発行しなければならず、そんなに楽しくない同期をしなければならないが、バックエンドは本当にシンプルで、web RTCの側面を除けば、サーバーレスインフラストラクチャーで快適に永遠に動作するだろう。
一方、upload thingについては、インフラがどれほど複雑になっていたか、私たちがどのように単純化したか、しかし単純化を通じてどれほど多くの追加の複雑な作業をしなければならなかったかについての動画を見たことがあるだろう。
upload thingは、私たちが望むことを実現するために素晴らしいバックエンドを必要とする。そしてそれは、私たちがバックエンドの複雑さについてより多く考えなければならないことを意味し、単にサーバーレスとnextjsを通じて構築することはもはや正しい選択ではなかった。
ウェブアプリは依然としてNEXを使用しているが、必要ないかもしれない。なぜなら、それは複雑な部分でも製品の差別化要因でもないからだ。これは素晴らしいことだ。しかし、バックエンドはこれほど複雑である必要がある。
なぜこれら全てをHTMXについての動画で取り上げているのか？もしフロントエンドの複雑さをここに戻すなら、少し物議を醸す意見を言おうと思う。どこかにここに線がある。私は任意にここに引くことにする。
狂気に陥ることなくブラウザの標準でどこまで行けるか。ウェブアプリで達成できる品質と複雑さの一定のレベルがあり、それを超えると狂気に陥ったように感じ始める。
確かに、Web Componentsのようなものがここで役立つかもしれないが、それらを採用する意思があるかどうか、そしてそれらがあなたをどれほど狂気に追い込むかによって、この線はさらに低くなるかもしれない。そして、あなたが作っているものによって、これは問題ないかもしれないし、狂気に追い込まれるかもしれない。
もしあなたが静的ブログを作ろうとしているなら、あなたが住む複雑さのポイントは、ブラウザがあなたと戦う場所より下だ。しかし、少し複雑なものを追加したい瞬間、例えば先ほど言及した素敵なコメントセクションを追加したいと思った瞬間、それはウェブ標準とテクノロジーで良い時間を過ごせる場所を少し超えてしまうかもしれない。
では、どうすればいいのか？通常あなたが最終的にすることは、Reactを採用することだ。なぜならReactはこの全てのセクションを非常に快適に解決できるからだ。しかし、この複雑さの全てまでカバーできるテクノロジーを採用する唯一の理由が、この小さな、小さな範囲だけというのは本当に悪い感じがする。
あなたがReactのようなテクノロジーを採用する唯一の理由が、ビルドチェーン、ツール、パイプライン、そしてこれらすべてのものにそれほどの複雑さを追加することになるのに、ブログにコメントセクションを持ちたいからというのは、それはおかしい感じがする。
なぜなら、あなたはここにいて、ここに到達する方法を知っていて、次の線までほんの少し先を見ている。ほんの少し先に行けば、あなたが欲しい最後のピースを作ることができる。しかし今、あなたは気にもしていないこの全てのエコシステムを採用しなければならない。
現実的に言えば、たとえReactがこの全ての範囲をカバーできたとしても、おそらくそうする必要はないはずだ。理想的には、ある一定の複雑さのレベルに達したときにのみ採用され、それまでは他のツールとテクノロジーがこの部分を扱うのを助けるはずだ。
しかし、誰も自分のものが卒業されることを望まない。誰も、あなたのものが大きくなりすぎて離れなければならないようなツールを作りたいと思わない。多くの人はそれを試みなかった。しかし、これが私がHTMXが本当にクールだと思う理由だ。
それは複雑なテクノロジーを採用することなく、より複雑なものを作ることを可能にする。実際、それはバックエンドを離れることなく、より複雑なものを作ることを可能にする。HTMXで、私たちは効果的にここまで戻り、「はい、この点以降は本当にクールな実験で、本当に複雑なものを作ることを可能にした。しかし、どうすればここを離れる必要がないようにできるだろうか？」と言っている。
地獄、どうすればここを離れているように感じる必要すらないようにできるだろうか？あなたはただサーバーからHTMLを作っているだけだ。もしReactがもたらす追加の複雑さが必要ないなら、ただブログにより良いコメントセクションを持ちたいだけ、あるいはTwitterクローンでエンターを押したときにページ全体を再読み込みする必要のないフィードを持ちたいだけなら、HTMXは素晴らしい解決策だ。
そして、jQueryやこれらの他の解決策を見て、彼らが新しいjQueryになりたいと言うとき、私には分かる。私が思うに面白いのは、彼らは実際にもう少し先に進んでいるということだ。jQueryはまだクライアント上で自分で作業をする必要があり、XMLかより頻繁にはJsonをAjaxで送信する必要があった。
私の人生で見た「$.ajax」呼び出しのほとんどすべては、XMLではなくJsonをレスポンスとして取得している。では、もしそれら全てが必要なかったら？もしjQueryが表すものを、しかし反対の方向に行くことで、さらに単純化することで実現できたら？
開発者にHTMLでJavaScriptコードを書かせるのではなく、開発者がマークアップで何をしたいかを書くだけで、このエンドポイントが返すものでこの要素を更新すべきだと言えたらどうだろう？
このonclickの動作をするボタンを書く代わりに、このことをするというのではなく、HTMXが異なるのは、onclickや動作をそのように書かないということだ。代わりにこんな感じでHX-post（これはどのURLにポストしたいかのHTMXの略記）とHX-swap（レスポンスをどこに送るべきか）を書く。
なぜなら、/clickエンドポイントにポストするとき、レスポンスはJsonではない。レスポンスはHTMLだ。そのHTMLで何をするのか？ページ全体を置き換えたくはない。HTMXでは、置き換えたい部分のHTMLだけを送り、そしてマークアップで以前に、ボタンを押したときにどこに置くかをHX-swapで指示する。HX-swap outer HTMLは、直接上の層がたった今取得したHTMLで置き換えられることを意味する。そして他の場所に送ることもできる。たくさんのオプションがある。
これが意味することは、ペイロードが戻ってきたときに何が起こるべきかを記述するJavaScriptのロジックを書く必要がないということだ。代わりに、行きたいエンドポイントを書く必要がある。言わば、全ての作業をバックエンドに委ねたが、本当に作業なのだろうか？異なる要素をレンダリングするだけだ。
チャットで良い指摘があったので、取り上げたい。閉じタグを忘れたことについてではない。申し訳ない。このビットについて。onclickとAjaxをこのように追加することは、フロントエンドとバックエンドの間に大きな断絶も導入した。HTMXではタイプセーフティやそういったものはないが、フロントエンドはバックエンドにずっと近く、結果としてより安全だ。
全く同意だ。フロントエンドが、バックエンドが理解できないものをレンダリングしたり、期待したりする状態になる方法はもはやない。なぜなら、フロントエンドが何をしているかを推測してバックエンドが正しいデータを送ろうとする試みはHTMXではより難しいからだ。フロントエンドは自身の状態を制御しない。フロントエンドの状態は、バックエンドが何をすべきかを伝えることから来る。
これは、以前そうだったように、ブラウザから全ての状態を取り出してサーバーに入れる動きだ。この図の中でさらに下に行くにつれて、私たちは効果的にブラウザにより多くの状態を追加していっている。そして今や、indexdbのようなものがあり、ブラウザで直接ページごとにギガバイトのデータを保存できる。そしてそれらは信じられないほど強力で、素晴らしいことを可能にする。
しかし、それらはフロントエンドとバックエンドの関係も難しくする。私は経験から知っている。なぜなら、今取り組んでいるプロジェクトで、クライアントからサーバーに多くのデータを同期している。クライアントに期待があり、バックエンドがその期待に応えることを望むとき、それは簡単ではない。
厳しい現実は、私たちがより多くの状態をクライアントに移動させたとき、物事はより複雑になったということだ。その複雑さへの解決策を導入するほど複雑になり、あなたはこれらがどうなるか知っている。GraphQL。GraphQLは多くのことを試みた解決策だったが、最大のものは、フロントエンドとバックエンドの関係を標準化することだった。
そうすれば、この狂った同期層を構築することなく、フロントエンドのニーズを記述できる。グラフは、複雑さの軍拡競争の必然的な終着点だ。ウェブアプリがより対話的になり、より多くのことをするようになったため、これは効果的に必要な状態となった。
「ああ、私たちはReactを使ったからGraphQLが必要になった」というわけではない。私たちは以前ならデスクトップアプリとして作っていたものを、今はウェブアプリとして作っているんだ。これは多くの異なることを行い、それらを同期に保つ方法が必要で、それは簡単ではない。
HTMXはそれの否定だ。HTMXは言う。「なぜ私たちは、ほんの少しの複雑さのためにReactが必要なんだ？」。私は賭けてもいい。もしCarson、HTMXの人に「ねえ、私はWebRTCのビデオ通話アプリを作っているんだけど、HTMXを使うことについてどう思う？」と聞いたら、彼の応答はほぼ確実に「何だって？なぜそんなことをするんだ？」となるだろう。
そういったタイプのことをするための素晴らしいウェブアプリ、シングルページアプリのテクノロジーがあるのと同じように、もし誰かが私のところに来て「ねえ、AIの分析のために毎秒数百万のリクエストを処理できる本当に複雑なデータアーキテクチャを作っているんだけど、Nextを使えますか？」と言ったら、私は「えっ、何だって？ええ、ウェブアプリには使えるかもしれないけど、なぜそうするんだ？バックエンドに集中して、本物のサービスを作りなよ」と言うだろう。
それが問題だ。あなたが作ろうとしているものが、あなたが選ぶツールを決めるのを助けるべきだ。しかし、あなたが作ろうとしているのがブログにコメントセクションを追加することなら、それにReactは必要ないはずだ。
これをReactの人として言っているんだ。多くの人々がReactを嫌うようになったのは、もっと低い複雑さの範囲にいたのに、それを使わなければならないと感じたからだと思う。もしあなたがこのエリアにいるなら、Reactはひどく感じるだろう。なぜなら、このセクションをより地獄でなくするために作られたワークフローとマインドセットを導入しているからだ。
もしここに住んでいるなら、それはただ多すぎると感じ、本当にあなたの役に立っているとは感じないだろう。だから、特にバックエンド寄りの開発者たちが、Reactを試すことを強制されたと感じ、それを好まなかったことに完全に共感する。なぜなら、それは彼らが持っていた問題をすぐには解決せず、彼らが興味のない多くの複雑さを導入したからだ。
HTMXを使えば、Reactが必要になる前にずっと先まで行ける。これを考える別の方法は、これが赤で、Reactが必要になる前にどこまで行けるかということだ。黄色でHTMXを表すと、HTMXを使えば、Reactが必要になる前にずっと先まで行ける。
Reactは正直なところ、最後まで全て解決できる。静的ブログにReactを使うべきか？おそらくそうではない。しかし、もしvanilla JSを使おうとすれば、多くを自分で作らなければならない前に複雑さの限界に達してしまう。それは楽しくない。
HTMXを使えば、その壁にぶつかる前にずっと先まで行ける。そして繰り返すが、これはバックエンドでも全く同じことが言える。もしこれを下にコピーペーストして、これを「nextjsでどこまで行けるか」に変えれば、そう、nextjsプラスlambdaで、そういったスタックでは一定レベルの複雑さまで到達できる。
しかし、もしバックエンドの複雑さが十分に高くなれば、すぐに後悔することになるだろう。expressjsを使えば、もう少し先まで行けるが、それでも壁にぶつかるだろう。その時点で、バックエンドでJavaScriptを使用することは無責任になる。
代わりにGolangを使えば、その問題は起きない。そして現実的に言えば、CRUDアプリにGoを使うこともできる。おそらくすべきではないが、できる。ここでの要点は、nextとlambdaが導入する以上に複雑なバックエンドを持っているからといって、Golangを採用しなければならないと感じるべきではないということだ。
幸いなことに、ExpressやFastify、そしてそれらを展開し使用する素晴らしい方法があり、それは非常に優れているので、多くのことに対して本当に遠くまで行けると私は主張する。そしてこれは一つのカテゴリーや一つのバックエンドの複雑さの軸だけではない。複雑さには多くの異なる部分がある。
私たちのAPIと、実際にファイルを受け取って適切な場所に配置するアップロードエンドポイントについて言えば、その部分はそれほど複雑ではなく、ExpressやFastifyができることの範囲内に完全に収まる。しかし、もしそれらのファイルのクレイジーな分析を始め、そのサーバー上でクレイジーなデータ処理を始めるなら、それはもはや私たちを助けることはできず、より低レベルの何かに移行しなければならないだろう。
あるいは、単にコストを削減したいだけなら、そこで助けてくれる何かを選ぶ必要があるだろう。しかし、あなたが作っているものの現実と、必要とする複雑さの現実を認識することが重要だ。そしてもしデフォルトがあなたに与えるもの以上の複雑さが少し必要なら、他のものを採用することを恥じる必要はない。
しかし、そのギャップが以前のように大きい場合、それは本当に悪い感じがする。そしてHTMXはそのギャップを埋めるのを助ける。それはExpressやFastify、あるいは論争の余地はあるがnextとlambdaが向こう側でそれを埋めるのを助けるのと同じように。
もし私がフロントエンド開発者で、これらが私が慣れているツールなら、それらのテクノロジーを離れなければならない複雑さのレベルに達する瞬間を恐れる。できる限りそれを避けようとする。そしてもしあなたがバックエンド開発者なら、おそらく同じことをしている。Reactを使いたくないから、より複雑でないウェブアプリを作っているんだ。
HTMXを使えば、はるかに複雑なことができる。そして、ここでこの例で示したように、それらのより複雑なことは、より複雑なコードを必要としない。これは、それらがより保守可能で、より長く生き残り、理論的には錆びないことを意味する。
そして、それが私がrustという名前について好きなことだ。それは永遠にそこに座って大丈夫なコードを示すことを意図している。HTMXはあなたのフロントエンドのためにそれを構築しようとしている。なぜなら、ユーザーにとって十分に複雑だが、開発者にとって意味のある複雑さの導入をしないシンプルなものを作ろうとしているからだ。
そしてそのために、私はそれを愛している。そして本当に、彼らがそれをここに置いているところに収まると思う。彼らの目標は、Reactの開発者たちに、彼らが愛し使用しているツールを置き去りにしてHTMXを使うよう説得することではない。彼らの目標は、そのどれもやりたくない開発者たちを助けることだ。ただバックエンドで作業を続け、HTMLを生成し、良い体験を持ちたいだけの開発者たちを。
そう、私はrustが技術的にはある種の菌類にちなんで名付けられたことは知っている。とにかく、私はコードが錆びることができるという名前の意味が好きなんだ。
さて、この記事に戻ろう。ここに面白い指摘がある。
「安定性は機能だ。私たちは、APIと実装の両方において、HTMXが非常に安定していることを確実にするために作業を続ける。これは、現在の実装の特性を受け入れ、文書化することを意味する。1から2にアップグレードする人でも、以前と同じように動作することを期待すべきだ。適切な場合、より良い設定オプションを追加するかもしれないが、デフォルトは変更しない。」
面白い。全体として、バージョンを上げても大丈夫でファインだという考えに賛成だ。しかし、より良いデフォルトがある場合、メジャーチェンジの目的は、新しい人のために体験を良くするためにデフォルトを変更できることだ。
これを考えるには図が必要だと思う。それほど言わせてもらおう。ユーザーが時間とともに着実に増加しているアプリがあるとしよう。ここにユーザーと時間がある。これが私たちの1.0リリースだ。1.0でAPIを安定化させ、これを安定したサービスと呼んだ。素晴らしい。
さて、ここにいくつかの理想的でないものがあり、それが実際にユーザーの一部に生活をより困難にしていることに気づいたとしよう。ドキュメントを書いたり、他のことをしたりして、ユーザーにそのやり方を避けるよう伝えることはできる。しかし、この2.0リリースが起きるとき、私たちは決断をしなければならない。
デフォルトを修正するか、それともそのままにするか決めなければならない。この質問は、このラインの前と後でどれだけのユーザーが存在するかに帰結する。なぜなら、もしそのデフォルトがここのすべての人々、つまり2.0リリース以前の人々の生活をより困難にしたなら、デフォルトを変更することで2へのアップグレードが難しくなる可能性がある。
このグループに対して何かを壊す可能性があるため、これは辛い決断だ。これらの人々を愛しているからだ。これはあなたのユーザーの100%であり、1.0から2.0への変更でこのグループの人々に対して何かを壊るようなことをするのは恐ろしく感じる。なぜならこれはあなたのユーザーの100%だからだ。
しかし、これは時間の経過とともにあなたのユーザーの100%なのだろうか？時間が経つにつれて、さらに多くのユーザーが増えるだろう。ExcalIDrawでここで必要なことを上手くできないのを許してほしい。ここで必要なのは、これがこのように見えて、下の領域を塗りつぶすことだ。
この時点で、あなたのユーザーの100%がこのライン以下にいる。彼らは製品を使用している人々だ。2.0の変更は彼らに対して何かを壊すことになり、それは恐ろしい。すべてのユーザーに対して何かを壊す考えは、吐き気を催すはずだ。
しかし、未来のことを考えなければならない。あなたのものが成長し続ける未来を。そしてここの領域で、物事がどんどん大きくなるにつれて、デフォルトの変更をしないことは、この範囲の人々にとってより多くの作業を必要とすることになる。
新しいユーザーは苦労し、ここでの潜在的な変更から恩恵を受けることができない。そして変更が現時点でのユーザーの100%を傷つけることを意味するとしても、最終的にそれは100%を代表しなくなる。40%、あるいは20%のユーザーを代表するようになり、残りは全てその後に来る人々になるだろう。
これは恐ろしく感じる。なぜなら、その瞬間、あなたは最も忠実な、あなたのスタックに賭けた人々を傷つけることを非常に恐れているからだ。しかし、もしあなたが成長し続けているなら、これをもっと遊んでみよう。
成長率が上がるとしよう。20%の代わりに、ここから始めて、5年が経過し、2.0が落ちた後に95%のユーザーが採用することになるとしよう。その場合、絶対にデフォルトを変更すべきだった。なぜなら、このグループに対して物事をより痛みを伴うものにし、採用を難しくし、離脱する可能性を高くしたからだ。
これはこれらの人々を傷つけた可能性があったが、もしその変更をしなければ、この曲線は何か悪いことをする可能性がある。衰退し始める可能性がある。なぜなら、この側の人々はもはや新しいユーザーではないからだ。
新しい人々があまり入ってこない。なぜなら、もし彼らが来て試してみて、セットアップが難しすぎると感じたら、彼らは離れてしまい、それがどれほど良いかを友人に伝えることもなく、より多くの採用を得ることもないからだ。
そしてこれらのリリースは、しばしば転換点を示す。このような曲がり方ではなく、もし正しいことをして、新しいユーザーにとって物事を簡単にすれば、あなたのツールの採用を意味のある形で劇的に増やすことができる。
HTMXの歴史でこれを見てみよう。ここで厳密な数字を持っているかどうか確かではないので、その事実を無視してほしい。左側のこのセクションをintercoolerの時代と見ることができる。intercoolerの時代には、ユーザーを得て、人々はそれを好み、物事に使用した。
しかし、これがHTMXを示すとしよう。HTMXがドロップしたとき、それはintercoolerに対するSQLのようなものだ。採用が急激に上昇し始めた。
そこで決断しなければならない。将来のユーザーのために物事を簡単にする意図を持って、現在のユーザーを傷つける変更をするのか、それとも現在のユーザーベースを優先するのか。なぜなら、あなたの曲線はこのように見えると考えているからだ。
現在のユーザーベースをマイノリティに変えることを目指して構築しているのか、それとも彼らをサポートし、別の人が新しいツールやテクノロジーを使うことを気にせずに夕暮れまで乗り続けることを目指して構築しているのか。
これはフレームワークの作者として難しい決断だ。本当にそうだ。そして代替案として、完全に後方互換性と前方互換性のあるものを構築することができる。デフォルトを変更するが、新しいデフォルトを使用する必要はないようにする。人々が使いたい新しいものにあなたのフレームワークを魔法のように変換するコンパイラを持つ。
それらは素晴らしいが、何百人もの技術者が何千時間もの作業をする必要がある。HTMXは基本的に一人の人だ。それは根本的な違いだ。彼らの焦点がそこにある理由が分かる。なぜなら、彼らはある意味でこれを計画しているからだ。
HTMXを使用する人々の80%以上は、おそらく今それを使用している。だから私は理解するし、それは良い決断だと思う。しかし、デフォルトを変更することについて考えるとき、これについて考える必要がある。
なぜなら、デフォルトは現在のユーザーを傷つけるかもしれないが、もし5年後に現在のユーザーがマイノリティになるなら、そのクソデフォルトを変更しろ。
新しいユーザーのために構築しないことについて、これは別の例だ。「新機能がない機能として。私たちはライブラリのコアに新しい提案された機能を受け入れないことにますます傾くだろう。人々は特定のバグを修正して欲しい場合を除いて、時間とともにHTMXをアップグレードする圧力を感じるべきではない。
2025年に書くHTMXが2035年以降に書くHTMXとよく似ていると感じるべきだ。新しいブラウザの機能が利用可能になったとき、私たちは新しいコア機能を検討する。例えば、私たちは既にサポートされているブラウザで実験的なmove beforeのAPIを使用している。
しかし、ほとんどの新機能はHTMXの拡張APIを通じて探索され、提供されることを期待している。そして適切な場合は、拡張APIをより機能的にするように作業する。」
私は同様のことを行った別のプロジェクトの経験を即座に思い出している。Elixir言語は、言語が完成したと発表した。彼らはもはやElixir言語に新しい大きな機能を追加しないだろう。
目標は、拡張機能やプラグイン、ライブラリを通じて、あなたが望む方法で拡張できるようにすることだった。なぜなら、Joseによれば、ElixirをElixirたらしめる核心は完成したからだ。今では型システムで彼がやっている狂ったことは別だが、要点は、機能セットに満足し、拡張のパラダイムを構築して、安定したものを無期限に維持できるポイントを持つことは本当にクールだということだ。
これをする技術は十分にない。しかし、これにはコストがある。新しい人々が採用する可能性と同様に、ここに戻ると、将来HTMXのアップデートがあって、それをここまで押し上げることはないだろう。
私たちはHTMXのアップデートを得て、それをReactとより競争的にすることはないだろう。それはここに留まり、それは良いことだ。それは信頼し、頼りにできることを意味し、将来について心配する必要がないということだ。
そしてそれはHTMXの設計目標であり、多くの意味がある。ただ、このように直接呼び出されるのを見るのは変な感じだ。四半期ごとのリリースを行うことになったと述べている。それは理にかなっている。
「ハイパーメディアを推進する」について、何と言っているだろうか？
「HTMXは、ウェブアプリやサービスを構築するための完全な解決策を目指していない。それはハイパーメディアコントロールを一般化し、それがだいたいすべてだ。
これは、HTMXを改善する非常に重要な方法の一つが、人々がHTMXと共に使用するツールや技術を改善することを助けることであり、そこにはまだ多くの作業が残っているということを意味する。そうすることで、HTMXそのものには何の変更もなく、HTMXは劇的により有用になる。」
このマインドセットが大好きだ。HTMXは効果的に、あなたのバックエンドとフロントエンドの間の接着剤になることを意図している。そしてその接着剤が安定しているという考え、そうすることであなたは今、バックエンドとフロントエンドのインターフェースをより良くすることに集中できるという考えは、多くの意味がある。
jQueryだけを使うことができないのと同じように、HTMXだけを使うこともできない。何かをするバックエンドが必要だ。同じように、Reactだけを使うこともできない。HTMLを提供する必要があり、おそらくデータを取得するために何かを使う必要がある。
本物のバックエンドフレームワークか、誰に聞くかによってはバックエンドフレームワークであるnextjsのようなものだ。それらのテクノロジーは、そのピースを機能させるために必要だ。そして最終的に、イノベーションはもはやライブラリにはないポイントに達するだろう。
私はReactはそこに近いか、すでにそこにいると主張するだろう。将来、ReactのイノベーションはReactではなくなる。それはReactコンパイラとReactサーバーランタイムになるだろう。
私たちがブラウザで実行するReact、私たちがインポートするパッケージは、React 17以降、私たちが書く方法の人間工学やReactで行うことについて、そんなに変わっていない。しかし、直接その外側にあるピースは信じられないほどの速さでイノベーションを起こしていて、Reactそのものが常に変化しているように感じる。
そしてHTMXもそこに到達する可能性がある。これらの補助的なツールの未来がどのようになるか、そしてそれが私たちがHTMXについて話す方法をどのように変えるのか考えるのは面白い。
「補助的なツールをサポートする。HTMXはHTMLにいくつかの新しいツールを与えるが、ウェブサイトを構築する他の重要な側面については意見を持っていない。HTMXの主要な機能の一つは、どのバックエンドやデータベースを使用するかを指示しないことだ。HTMXは多くのバックエンドと互換性がある。私たちはすべてのバックエンドでハイパーメディア駆動の開発をより良く機能させることを助けたい。
HTMXが既に改善を助けたハイパーメディアエコシステムの一部は、テンプレートエンジンだ。私たちは最初に、テンプレートフラグメントがどのように部分的なページの置き換えをより簡単に定義できるようにするかについて書いた。それらはテンプレートエンジンではかなり珍しい機能だった。」
これが意味することを明確にしよう。伝統的なバックエンドフレームワークでは、example.com/user/Theoに行くと、これは巨大なHTMLの塊を返す。head タグ、title Theos info、bodyを持つHTMLの完全なドキュメントだ。
しかし、もし私がTheoで何かを編集したいなら？名前を変更したいけど、終わったときにページ全体を再読み込みしたくない。もし従来の古いスクールのテンプレートシステムや、Ruby on Railsのようなものを使っているなら、変更を行うとき、あなたは何をするだろうか。
変更したら、example.com/user/Theoにポストする。新しいデータをデータベースに書き込み、そして更新されたページで応答する。これは全ページの新しい更新されたHTMLで行う。なぜなら、SDKのテンプレートシステムとこれらすべての構築方法は、ブラウザがURLに行くとき、完全なHTML応答、つまり上部にHTMLタグ、その直下にheadタグ、body、メタデータ、これらすべてを期待するという前提で作られているからだ。
ここで変更されたのがタイトルだけなら？なぜページ全体を再読み込みし、サーバーレンダリングを待ち、そして最初から全く新しいHTMLページを生成しなければならないのか？
その代わりに、example.com/api/update-usernameにポストして、タイトルタグを入れ替えるだけでよければどうだろう？例えばCarsonの情報に。これが私たちが欲しいすべてだ。これはこれほど単純にはできない。何をすべきかを示すために、いくつかのことを追加する必要がある。
HTMLが少し異なっていたとしよう。ボタンがあり、クリックしたときにユーザー名を更新したいとする。今はTheoの情報と言っているが、これをCarsonの情報に変更したい。今、すべきことは、HX-swap outer HTMLを言うことだ。これはHTMXの略記で、どのURLにポストしたいか、そしてレスポンスをどこに送るべきかを示す。
なぜなら、/clickエンドポイントにポストするとき、レスポンスはJsonではない。レスポンスはHTMLだ。そのHTMLで何をする？ページ全体を置き換えたくない。HTMXでは、置き換えたい部分のHTMLだけを送り、そしてマークアップで以前に、ボタンを押したときにどこに置くかを指示する。
HX-swap outer HTMLは、直接上の層が今受け取ったHTMLで置き換えられることを意味する。そして他の場所に送ることもできる。多くのオプションがある。
これが意味することは、ペイロードが戻ってきたときに何が起こるべきかを記述するJavaScriptのロジックを書く必要がないということだ。代わりに、行きたいエンドポイントを書く必要がある。言わば、全ての作業をバックエンドに委ねた。しかし、本当に作業なのだろうか？異なる要素をレンダリングするだけだ。
「templatesフラグメントについて、ここに2022年に彼らが書いた記事がある。基本的に私が話していたことと全く同じことのようだ。このボタンを返すエンドポイントが欲しい代わりに、全てを返したくない。この問題は、今あなたがこのボタンを2回書いたということだ。最初のHTML応答で1回、そしてここで1回。もし再利用できたらどうだろう？それがフラグメントの目的だ。」
「既存の方法を呼び出して複数の場所で使用する方法だ。そして、意味のあるエンドポイントを持つこともできる。今、彼らが言うように、テンプレート全体をレンダリングするか、ページ全体をレンダリングするか、またはテンプレートのその部分だけをレンダリングすることができる。
そのため、実際にテンプレートを1か所だけで書く必要があり、フラグメントは効果的にテンプレートのこの部分に変数を割り当てているので、『ねえ、この部分だけが欲しい。ページ全体を再レンダリングせず、ページのこの部分だけを再レンダリングしてそれを返してください』と言うことができる。」
本当にクールだ。そして、より多くのフレームワークがそれを採用しているのを見るのは素晴らしい。なぜなら今、そのデータで何かをすることが可能だからだ。そして、私は完全にCarsonとHTMXチームに同意する。彼らはテンプレートフラグメントテクニックの復活に100%の功績がある。彼らの側の大きな勝利だ。これが起こる必要があった。
本当に面白いのは、Reactはサーバーコンポーネントでこれさえもしていないということだ。今のところ、ページ全体を再検証することを期待している。Reactの世界がこれからこれを学べることを願う。
Carsonが今後の焦点についてここで自身の計画を呼び出しているのも気に入っている。「HTMXは今後劇的に変化することはないが、私たちはハイパーメディアのアイデアを精力的に広めていく。素晴らしい。私たちは今やっているようにJsonを常に使うべきではない。Jsonは多くの問題に対して間違った解決策だ。そしてGraphQLはそれをさらに悪化させる。」
「特に、私たちはtriptickプロジェクトでHTMXのアイデアをHTML標準自体に押し込もうとしている。これは何だ？おお、これはHTMLの提案だ。興味深い。ページナビゲーションとフォームでより多くのことができるようにコアサポートを持つことが彼らの目標のようだ。
そう、今はHTMLで多くのHTTPメソッドを使用できない。そのため、何かをそれらの変換を行うものが必要だ。もしHTMLでより多くのものでHTTPエンドポイントを叩くことができれば...私は光が見え始めている。ブラウザはこれらのことをより多くすべきだ。」
そしてもっと知りたい場合は、この投稿へのリンクが説明の中にある。そして彼はBig Sky Defconで全てについての講演を行った。もし全てがうまくいけば、HTMXは死ぬべきだと。
自分が作り上げ、全てのブランドを築いたライブラリを不要にすることを目指すという目標が大好きだ。私はT3スタックについても同じような感じを持っている。T3スタックでの私の目標は、ウェブアプリのために誰もが使用するものに私の名前を付けることではない。
T3スタックの目標は、バックエンドとフロントエンドの関係がどれほどシンプルになりうるかを示すことだった。そして最終的にそれが無用になれば...そう、素晴らしい。私はエコシステムで大きな改善を見てきた。必ずしもT3スタックやcreate T3 appに直接クレジットが与えられているわけではないが、私たちは確実にこのフルスタックの型安全性の方向に業界を押し進めるのを助けた。
そしてHTMXはウェブ標準に対して同じことをしている。私はそれが大好きだ。そして最後に、intercoolerが正しかったようだ。これは彼らが当時intercoolerのドキュメントで言っていたことだ：
「多くのJavaScriptプロジェクトは目まぐるしいペースで更新される。intercoolerはそうではない。それは死んでいるからではなく、ほとんど正しいからだ。基本的なアイデアは正しく、実装は少なくとも十分に正しい。
これは、プロジェクトに絶え間ない活動と変更があるわけではなく、むしろ管理人のような関係があることを意味する。今や主な目標は、それを台無しにしないことだ。ドキュメントは改善され、テストが追加され、小さな新しい宣言的な機能が端に追加される。
大規模な書き直しや絶え間ない更新はない。これは、ソフトウェア産業全般、特にフロントエンドの世界とは対照的で、そこには笑えるレベルの変更がある。最も人気のあるRustパッケージをチェックすべきだ。」
3番目の段落の最後のスナークを別にすれば、この考え方は非常にHTMXにも当てはまる。実際、おそらくさらに当てはまる。なぜなら、HTMXはintercooler JSの経験と間違いから恩恵を受けた標準的なソフトウェアだからだ。
私たちは、HTMXが独自の小さな方法で、jQueryのような巨人に加わり、100年ウェブサービスを構築するための堅固で信頼できるツールになることを願っている。私もそう願う。
ウェブは、そこまで複雑でないものに対して安定したツールに値する。そしてHTMXは、疑問の余地なく、そこで最高のものになるポジションにいる。そしてもしあなたの目標が、jQueryのように10年後に考える必要がないことなら、私はHTMXが勝つことを願う。
ツールが進歩し続けるためには、進歩しないツールも必要だ。コードを数ヶ月ごとに書き直すことを望まない人々のために、安定して信頼できる何かが必要だ。
私が生きている生活を生き、私が楽しんでいるものを楽しむために、エコシステムの他の場所で安定性が必要だ。そして私は、多くの人々にそれを提供してくれるHTMXにとても感謝している。
これが、HTMXの「クソだ」という動画がそう見えたように皮肉だったことを理解するのに役立つことを願う。これは素晴らしい技術だと思う。私はCarsonと彼がやっていることが大好きで、HTMXがウェブアプリケーションを構築するための最も退屈な解決策であり続ける未来に期待している。
次回まで、平和を。オタク達よ。