次のウェブベースのサイドプロジェクトにはHTMXを選ぶべき理由 - 古臭いMPAと複雑なSPAは捨て去るべき

私は多くのサイドプロジェクトを構築しているので、常にそれらをより速く、より安く、同様の品質で構築できる技術やパラダイムを探しています。ここ数ヶ月、HTMXやAlpineのような低JSツールを使ってウェブアプリを構築する実験をしています。

この記事では、HTMXがウェブアプリをより速く、より安く構築するための優れた選択肢である理由と、それが私の技術スタック - HAMスタックの中核部分となった理由を共有します。

MPAとSPA
MPAとSPA

マルチページアプリ (MPA)
最初はマルチページアプリがありました(MPA)。

各URLはウェブページに移動します
このウェブページはサーバーサイドでレンダリングされ、ユーザーに送信されます
もしユーザーが何かを変更したり、リフレッシュする必要がある場合、ページ ( の何かを更新する必要があるなら、ページ全体を再読み込みする必要があります。
これはうまく機能しますが、ページ上の何かが変更されるたびにすべてを再読み込みする必要があるため、非常に遅く、動作がぎこちない感じを与えます。これの例として、州政府のウェブサイトを考えてみてください。それらのほとんどは依然として古いスタイルのMPAであり、ほとんどの現代的なアプリと比較して古くてぎこちないと感じます。

MPAの長所と短所

利点: 簡単に構築できる
欠点：リフレッシュのため、遅くてもたついている感じがする
シングルページアプリ)SPA(
これを解決するために、シングルページアプリ)SPA(が作成されました。

URLは、大量のJSペイロードをロードし、アプリロジックの一部を含んでいます。
このJSはページレンダリングを引き継ぎます
内部状態を使用してページの見た目を決定し、裏でデータ転送を行うため、変更が必要なページの部分のみを更新する必要があります。
これによりユーザーはより快適に感じます。変更が速く感じられるからです。ページは必要な部分だけを更新し、データを変更するためにフルページリフレッシュを必要としません。今日のほとんどのアプリやウェブサイトはこのように感じられます。なぜなら、一般的により良いユーザー体験を提供するからです。

プロ: 豊富な"現代的"なユーザー体験
欠点: スケール時の複雑さ - データ転送)graphQLはこれのために構築されました(、抽象化、およびアプリロジックのペイロードサイズ
一般的には:

マルチページアプリ )MPA( - 簡単に構築できますが、リッチな「モダン」ユーザー体験を得るのは難しいです
シングルページアプリ )SPA( - 構築は複雑ですが、豊かな「現代的」ユーザー体験を実現できます
MPA対HTMX対SPA
MPA対HTMX対SPA

画像のインスピレーションは、r/htmxのu/Abhilash26から。

HTMXは数年前から存在していますが、ここ1年ほどで大きな注目を集めるようになりました。この注目は根拠のないものではなく、HTMXはしばしばSPAよりも速く、安価にモダンなウェブアプリを構築することを可能にします。

HTMXは本質的にHTMLを拡張し、部分的なページ再読み込みを行えるようにします。

任意の要素は、最新のデータをどのように取得できるか、およびそのタイミングを指定できます。
その要素は、新しいデータで自分自身またはページ上の他の要素を置き換えるかどうかを指定できます。
MPAとSPAの比較を振り返ると、部分的なページリロードの欠如が、MPAを制約している主な要因であることがわかります。したがって、この機能をMPAに追加することで、主にMPAの複雑さレベルを維持しながら、SPAの豊かな「モダン」ユーザー体験のほとんどを得ることができます。

HTMXのサイドプロジェクト
サイドプロジェクトの目的は、しばしばそのものを作ることです。おそらく、エンジニアのチームやVC資金の戦争資金はありません - あなたとあなたのコンピュータだけです。

したがって、時間とお金の両方で建設コストを下げることは、サイドプロジェクトを成功させるために重要です。

私の視点から見ると、HTMXは非常に低い複雑さで現代的なアプリを構築することを可能にし、)したがって時間とコスト(の面で素晴らしいバランスを提供します。したがって、それは私の技術スタックのコア部分となっています - HAMスタック。

次に
Md サイドゥール・ラーマン