Blog

JAMstackは、過去数年間で開発者の間でますます人気があり、2015年頃から静的サイトが一般的になりました。Webデザインが開発者のエクスペリエンスをより重要視するようになると、JAMstackという用語が形成され、業界で注目を集めています。以来。その傾向の背後にあるものは何ですか、そしてそれは継続するように設定されていますか？

JAMstackとは何ですか、またどのように機能しますか？

JAMstackにおけるJAMはJ avaScript、A PI、およびM ARKUPの略です。これは本質的にウェブサイトとアプリケーションを構築する新しい方法ですが、主な違いは、フロントエンドでほぼ完全に実行され、従来のウェブサーバーなしでサイトとアプリを提供できることです。

従来のCMSワークフローでは、フロントエンドとバックエンドが結合されています。つまり、ユーザーに提示するデータを生成するには、Webリクエストの処理、データベースやその他のサービスとのやり取り、レンダリングなど、さまざまなプロセスを実行する必要があります。出力、およびサーバーとブラウザー間の通信。

ただし、JAMstackは、コンテンツ配信と、コンテンツをレンダリングするために前に行う必要のあるすべてのこととの間に強い線を引きます。静的サイトジェネレーター（SSG）を使用すると、 M arkupを事前に生成でき、静的ファイルはコンテンツ配信ネットワーク（CDN）からユーザーに直接提供されます。任意の動的な機能強化は、J avaScriptとA PIを介して利用可能なサービスへのクライアント・サイドのおかげで行われます。

なぜJAMstackはそのような上昇を経験したのですか？

すべての素晴らしいアイデアと同様に、天才はそのシンプルさにあります。特にJAMstackと静的サイトジェネレーターは、最新のJavaScriptフレームワークのおかげです。すべてのSSGがJavaScriptに基づいているわけではなく、ReactとVueが登場するずっと前から存在していたものもありますが、それらの大部分は、既存のものと幅広い開発者コミュニティであるReactのJSXとVueによって大いに採用されたものを利用していました。 jsテンプレート。

静的サイトジェネレーターは、これらのテンプレートエンジンの上に構築されたフレームワークであり、パフォーマンスという非常に価値のあるものを提供する派生物です。そしてパフォーマンスは、ウェブサイトがグーグルでどれだけランク付けされるかに違いをもたらすものです。

Googleがウェブサイト（Lighthouse、PageSpeed Insights、AMP（Accelerated Mobile Pages））の高速化を推進し、API主導のコンテンツ管理に対する需要が高まっていることを考えると、JAMstackは当面の間ここにとどまるようです。しかし、それは誰にとっても正しい解決策ですか？

JAMstackを使用することの長所と短所は何ですか？

静的に生成されたサイトは、文字通りどこからでもデータを取得できます。ローカルに保存されたマークダウンファイル、Googleスプレッドシート、または理論的には従来のCMSです。コンテンツの管理と配信を主な責務とするヘッドレスCMSを使用する方がはるかに理にかなっています。

ヘッドレスCMSは当初、オムニチャネルギャップを克服するために作成されましたが、静的サイトジェネレーターと完全に一致するようです。

懸念事項を分離しておくと、（マイクロ）サービスをほぼ無期限に拡張できるようにしながら、問題ごとに最善のソリューションを使用できます。スケーラビリティについて言えば、静的ファイルを提供するために必要なインフラストラクチャはほとんどなく、データベースとWebサーバーのパフォーマンスを向上させる必要がありません。静的ファイルを提供することは、それらをネットワーク経由で転送するだけの問題であるため、パフォーマンスとスケーラビリティを向上させる方法は事実上ありません。ページの読み込み時間は、接続の速度とファイルを提供するハードドライブ/メモリによって制限されます。

インフラストラクチャを縮小することは、メンテナンスコストを削減し、攻撃対象領域を減らすのにも役立ちます。ご覧のとおり、静的ファイルでは、ハッキングするものはほとんど残っていません。実際、一般的に問題が発生する可能性があるのはごくわずかであるため、アプリは非常に安定しています。

したがって、パフォーマンスの向上、セキュリティ、スケーラビリティ、費用対効果の向上、および最新のJSフレームワークと同じかそれ以上の開発者エクスペリエンスの提供が利点です。欠点は何ですか？

コンテンツに取り組んでいる人など、あまり技術的な説得力がない人にとっては、習得するのが複雑なシステムになる可能性があります。同時に、動的な機能には、サードパーティのソリューションの支援が必要になる可能性があります。さらに、プレゼンテーション層を大幅に変更するには、開発者の支援が必要になります。最後に、JAMstackは、リアルタイムの更新やほとんど動的なアプリは言うまでもなく、頻繁な必要性を要求するサイトやアプリに常に適しているとは限りません。

JAMstackを使用してサイトを構築するのに適したフレームワークはどれですか？

JAMstackの優れている点は、Webサイトやアプリを構築するためのテクノロジーやフレームワークを規定していないことです。 JAMstackのサイトのケーススタディを一目見れば、これを十分に証明できます。 Gatsby、Vue、React、Hugo、Jekyllはすべて目立つように機能していますが、材料の最終的なカクテルはあなた次第です。ヘッドレスCMSと静的サイトジェネレーターの間に統一されたインターフェイスを作成することを目指すStackBitやSourcebitフレームワークなどのイニシアチブを使用すると、サービスを簡単に組み合わせることができます。

それで、JAMstackの上昇は2020年も続くように見えますが、次は何ですか？

ランドスケープを混乱させる可能性のあるテクノロジーが1つあります。それは、WebAssemblyです。 WASMとしても知られるWebAssemblyは、バイナリ形式の効率的なバイトコードであり、ネイティブのようなパフォーマンス（JavaScriptの1.5倍から最大20倍）のおかげでJavaScriptの後継と見なされる人もいます。

WebAssemblyだけでも、JAMstackによって設定された高いパフォーマンス標準の注目すべき挑戦者になる可能性があります。

まだ比較的初期段階にありますが、WASMがどのように景観を再形成するかはまだわかりません。最初のWebAssemblyフロントエンドフレームワークの誕生により、このテクノロジーが深刻な牽引力を獲得していることは否定できません。ただし、JavaSciptを置き換えるのではなく、JavaSciptを補完する可能性が高くなります。 WebAssemblyをJAMstackと組み合わせると、静的に生成されたマークアップと超高速バイトコードを利用した動的なパーツの両方の世界で最高のパフォーマンスを提供する致命的なコンボに命を吹き込むことができます。我々はすぐにW AMstackサイトを見始めるのだろうか？