はじめに
本記事はアイレット株式会社Advent Calendar2023 8日目の記事になります！
UIを構築する際に活用されるフレームワーク・ライブラリは日々進化し、新たなツールが登場しています。
そこで、本記事では数多くある中から厳選して７つ紹介します！
Vanilla
Vanilla JSとは、純粋なJavaScriptのことを言います。ここでは、ライブラリを追加していない状態を指します。
バニラという表現はアイスクリームの標準的な味であるバニラ味からきており、エリック・レイモンドのジャーゴンファイルによると、バニラはdefaultよりはoriginaryの意味に近いとされています。
主なメリット
・軽量かつ高速
Vanilla JSは、他ツールよりも軽量であることからページの読込み時間が短縮されるのでパフォーマンスの向上に繋がるといえます。
・初心者向け
Vanilla JSは、純粋なJavaScriptであることから他ツールと違い、JavaScriptの基本的な概念から理解し、容易に始めることができます。
・ブラウザ互換性
Vanilla JSは、純粋なJavaScriptであることからほぼ全てのモダンなウェブブラウザで動作できます。追加の依存関係や互換性の問題を気にしなくて良いので、他ツールに比べて開発しやすいことがわかります。
・効率的なカスタマイズ
vanilla JSはライブラリやフレームワークを使用しないので、プロジェクトに必要な機能だけを選択して実装が可能です。この点でいえば、余分なコードやリソースを含めず、効率的でカスタマイズ可能なコードを作成できます。
・リソースの最適利用
vanilla JSはハンドルサイズやメモリ使用量が小さいため、ウェブページやアプリのリソースに最適な利用が可能です。
デメリット
・クロスブラウザの互換性
クロスブラウザとは、WebサイトやWebアプリケーションがどのWebブラウザでも同じ表示、動作を再現できる状態のことです。
vanilla JSでは、クラスブラウザの互換性に対して問題が発生することが現状でもあります。ブラウザ間での標準化は進んでいるようですが、特定の機能やメソッドが一部のブラウザでは異なる動作をする可能性があります。
・コードが長くなる
大規模なプロジェクトでは、Vanilla JSを活用すると、同じ機能や構造を再利用することが難しく、他ツールでは短縮できるところが、Vanilla JSでは出来ずにコードが長くなってしまいます。
・モジュール性の不足
Vanilla JSはモジュール性に限りがあり、大規模な構築の際にコードの保守性や再利用性に課題が生じることがあります。
・開発速度の低下
フレームワークやライブラリを使用しない場合、一から全てのコードを書く必要があるため、開発速度の低下につながります。
・状態管理が難しい
大規模なアプリケーションでは、状態管理が複雑になりやすく、Vanilla JSだけでは効率的に状態管理を行うことが難しいことがあります。
-近年では、ES6やES7などの新しいJavaScriptのバージョンを組み合わせることでいくつかのデメリットを軽減は可能となっています。
ユースケース
・適している場合
学習コストが低く、小規模なプロジェクトに適しています。
・適していない場合
大規模で複雑なプロジェクト
Vanilla JSのみでの構築は適しておらず、フレームワークやライブラリを利用するほうが効率的です。
Vanilla JSでの構築を希望の場合は、他のツールと組み合わせるという検討も可能です。
React
Reactとは、WebサイトやWebアプリのUI部分を開発する際に活用するJavaScriptライブラリです。
ライブラリとは、再利用可能なプログラムを特定のコンセプトに従って1つのファイルに集めたものです。ライブラリの中から適宜必要なプログラムを取り出して使うことができ、プログラムをする手間が省けます。
フレームワークは、新しいプログラムを開発する際の枠組みです。プログラムの枠組みが用意されるのでライブラリより効率的と言えます。その反面、決まった枠組みに従わないといけないので、ライブラリより自由度は低いといえます。
ReactはJavaScript用のフレームワークと勘違いされることがありますが、ライブラリです。
主なメリット
・仮想DOM
DOMとは、画面を表示するまでに解釈したHTML/CSS/JavaScriptによって構築されたDOM（ツリー）のことを言います。
Reactは、仮想DOM（情報を受け取ってもすぐにはブラウザの描写を行わず、バーチャルなDOMを構築する）使用して効率的にUIを更新します。このことで、全体のDOMツリーを再描写する必要がなくなるのでパフォーマンスが向上します。
・コンポーネントベース
Reactはコンポーネントベースのアーキテクチャを採用しており、再利用性が高まります。コンポーネントは独立して開発、保守ができるので大規模なアプリケーションの構築が容易になります。
・一方向データバインディング
Reactでは、データの流れが一方向であるため、データの変更が予測しやすく、デバックしやすくなります。
・豊富なコミュニティと資源
ReactはFacebookによって開発され、広くサポートされています。そのため貴重なドキュメント、トレーニングリソース 、サードパーティのライブラリが利用可能です。
・JSX
ReactはJSX(JavaScript XML)と呼ばれる独自の構文を導入しています。これにより、JavaScriptとHTML（またはHTMLに類似した構文）を組み合わせて記述でき、コンポーネントの見た目とロジックが一体化しやすくなります。
・生態系とライブラリ
Reactは豊富な生態系を持っています。多くのサードパーティライブラリやツールが利用可能であることから、開発者はより迅速にアプリケーションを構築できます。
デメリット
・学習向きではない
Reactを初めて使う人にとっては学習向けではなく難しいかもしれません。特にJSXや、コンポーネントベースのアーキテクチャを理解するのに時間がかかります。
・適応が難しい大規模なアプリケーション
Reactでは大規模なアプリケーションを構築する際に、状態管理やデータのフローを効果的に管理することが難しい場合があります。これに対処する場合は、別途状態管理ライブラリやパターンを挿入することが必要となることがあります。
・仮想DOMのオーバーヘッド
Reactは仮想DOMを使用してパフォーマンスを向上させています。しかし、一部の場合では仮想DOMのオーバーヘッドが問題になることがあり、特に単純な変更に対しても完全な再描画を行うためです。
・エコシステムの変更が頻繁
Reactのエコシステム（Reactを中心に構築された広範な開発環境やツールの集まり）は非常に活発であり、新しいライブラリやアプローチが頻繁に登場します。
これにより、プロジェクトが進行する中で技術の変更に追随する必要が生じることがあります。
・初期ロードのオーバーヘッド
Reactの初期ロードには相対的に大きなサイズのライブラリが含まれています。これが初期ページロードのオーバーヘッドにつながることがあります。
ユースケース
・適している場合
Webアプリケーション開発においてはコンポーネントベースのアーキテクチャを使用して、UIを構築し、状態管理を容易にしてくれるので適しているといえます。
React Nativeを使用したモバイルアプリケーション開発、
管理画面などの複雑なユーザーインターフェースが必要なアプリケーション開発、
Reactを使用してPWAを構築することで、オフラインで動作するなどのプログレッシブウェブアプリケーション（PWA)、
Reactのコンポーネントベースのアーキテクチャによってコードの再利用を促進し、保守性を向上されることからコンポーネントの再利用
などが適しているといえます。
・適していない場合
小規模なプロジェクトがまず挙げられます。小規模で単純なプロジェクトの場合、Reactの導入はオーバーキルとなる可能性があるからです。
他にも、SEO（検索エンジン最適化）が不要で、クライアントサイドのレンダリングが主に行われる場合は、Reactを使用する必要がないかもしれません。Reactはクライアントサイドでの動作に焦点を当てていますが、サーバーサイドでのレンダリングを必要としない場合は、他の選択肢も考慮することができます。
軽量なページの場合はReactは、状態管理やコンポーネントベースのアーキテクチャを提供してるので、Reactの使用は過剰となる可能性があります。
また、初心者や他のツールを熟知している場合は学習コストも高くなるのが見込まれるためおすすめはできません。
Preact
Preact（プリアクト）は、JavaScriptのライブラリであり、Reactに似た機能を提供するものです。
特徴として、PreactはReactと同様の機能を提供しつつも、サイズが小さく、高速に動作することが挙げられます。
主なメリット
・軽量かつ高速
PreactはReactよりも軽量で、サイズが小さく、高速に動作します。これにより、ページの読み込み時間が短縮され、ユーザーエクスペリエンスが向上します。
・小規模プロジェクトに適している
小さなプロジェクトや単一のページアプリケーション（SPA）の構築に適しています。Reactよりもコードがシンプルなため、学習コストが低いと考えられます。
・Reactとの互換性
PreactはReactと互換性があります。ほとんどのReactコンポーネントをそのまま使用でき、既存のReactプロジェクトからの移行が比較的容易です。
デメリット
・機能の制約
PreactはReactよりも機能が制約されており、一部の高度な機能やモジュールがサポートされていないことがあります。そのため、大規模で複雑なプロジェクトではReactの方が適している場合があります
・コミュニティの規模
Reactに比べてPreactのコミュニティは小さく、情報やサポートが限られていることがあります。問題が発生した場合、解決策を見つけるのに若干の制約が生じる可能性があります。
・将来の不確実性
PreactはReactと同じくらい人気があるわけではなく、将来のサポートやアップデートの不確実性があります。プロジェクトの長期的な安定性を考える際には注意が必要であるといえます。
ユースケース
・適している場合
パフォーマンスが重要な場合は、PreactはReactよりも軽量であり、ページの読み込みやUIの反応速度が重要な場合に優れています。
小規模なプロジェクトにおいても、PreactはReactよりも小さなバンドルサイズを持ち、小規模なプロジェクトや単一のコンポーネントに適しています。
PreactはReactと互換性があるため、既存のReactプロジェクトに簡単に統合できることから、Reactの代替として適しているといえます。
アプリケーションにおいてはモバイルアプリのほうが適しているかもしれません。 PreactはReactよりも軽量であるため、モバイルアプリケーションやリソース制約のある環境での開発に適しているといえます。
・適していない場合
最初に大規模なプロジェクトが挙げられます。
大規模で複雑なプロジェクトでは、Reactの方が適している場合があります。Reactはより多くの機能やエコシステムを提供しており、大規模なアプリケーションの開発に向いています。
他にも、React生態系の特定の機能が必要な場合はPreactではサポートされていない可能性があることや、開発者が既にReactを慣れ親しんでいる場合は、Preactに切り替える必要がない場合があります。
Lit
Litは、Googleが提供するライブラリです。Webコンポーネントを構築するための軽量で効率的なツールセットを提供しており、このWebコンポーネントは、再利用可能で独立したUI部品を作成するための標準化された手法です。
主なメリット
・軽量かつ高速
Litには高速なレンダリングエンジンが備えられており、非常に軽量なのでパフォーマンスの向上が期待できます。
・シンプルな構文
Litの構文はシンプルで直感的なので、開発者は迅速にコンポーネントを構築できるようになっています。
・Webコンポーネントのサポート
LitはWebコンポーネントの標準を採用しているので、再利用可能なコンポーネントの作成と仕様が簡単にできます。
・データバインディング
Litではデータバインディングの協力なサポートを提供しているので、データとUIの同期を効果的に行うことができます。
・アクティブなコミュニティ
LitはGoogleによって開発されているので、アクティブなコミュニティが存在しています。質問に対するサポートや新しいリリースが定期的に行われます。
デメリット
・生態系の規模
Litは比較的新しいライブラリなので、他の大規模で有名なツールと比較すると、プラグインや拡張機能の生態系がまだ大きくありません。
・ドキュメンテーションの限定性
他の一部のツールと比較すると、Litのドキュメンテーションが限定的な場合があります。これは開発者が詳細な情報を見つける際に一定の課題ができてしまう可能性があります。
ユースケース
・適している場合
Webコンポーネントの構築
LitはWebコンポーネントの作成に適しており、デザインシステムや再利用可能なUI要素を作成する場合に便利です。
パフォーマンス要件が高いプロジェクト
litは高性能で効率的なライブラリであり、パフォーマンスが重要なプロジェクトに適しています
軽量なサイズが求められる場合
litは小さなサイズのライブラリであるため、軽量なWebページやプロジェクトに適しています。
モダンなブラウザサポート
litはモダンなブラウザでのサポートが強力で、これにより最新のWeb技術を活用できます。
・適していない場合
既存の大規模なAngularやReactプロジェクト
litは独自のアプローチを取っています。
既存の大規模なAngularやReactプロジェクトに統合するのが難しい場合があります。
生態系が必要な場合
Litは比較的新しいツールです。
他の大規模で成熟したツールと比較して生態系がまだ豊富でないことがあります。
開発者の経験がAngularやReactに偏っている場合
litは独自の構文やアプローチを採用しています。AngularやReactに慣れている開発者には学習コストがかかることが予想されます。
Svelte
svelteとは、JavaScriptフレームワークの一種であり、クライアントサイドのWebアプリケーションを構築するためのツールキットです。最大の特徴として大体のフレームワークでは標準で備わっている「仮想DOM」の仕組みを備えていないことが挙げられます。
主なメリット
・パフォーマンス
Svelteはビルド時にコンパイルされ、ランタイムではフレームワークのコードが必要ないため、軽量で高速なアプリケーションを構築できます。
・コードの書きやすさ
Svelteでは、他のフレームワークに比べてコンポーネントの定義がシンプルであり、冗長なコードが少ないです。
・学習コストの低さ
Svelteは他のツールに比べて学習コストが低く、新しい開発者や初心者が迅速にプロジェクトに参加できる可能性が高まります。
・効率的なリアクティブプログラミング
Svelteはリアクティブな変数をサポートしており、データの変更に応じて自動的にビューが更新されるため、開発者が手動で状態管理を行う必要がありません。
デメリット
・生態系の拡充
Svelteは他ツールと比べて新しいフレームワークであり、それに伴うライブラリやツールの生態系が他のツールに比べて少ないです。
・柔軟性の低さ
Svelteはコンパイル時に最適化が行われるため、動的な処理や柔軟な構造が必要な場合には他のフレームワークに比べて制約があることがあります。
・導入のハードル
既存のプロジェクトにSvelteを導入する場合、既存のコードベースやライブラリとの統合が難しく課題になる可能性があります。
ユースケース
・適している場合
シンプルでパフォーマンス重視のアプリケーション
Svelteはビルド時に最適化されたコードを生成されます。そのため、軽量で高速なアプリケーションを構築するのに適しています。
リアクティブなUIの開発
Svelteは状態の変更に応じて自動的にUIを更新するリアクティブなプログラミングモデルを提供しています。これがUI開発においては非常に便利です。
小規模なプロジェクト
Svelteは新しい開発者や初心者でも学習しやすく、小規模なプロジェクトやプロトタイプの開発に適しています。
フレームワークのオーバーヘッドを避けたい場合
Svelteはランタイムが非常に小さく、コンパイル時に必要なコードだけを生成します。そのため他のフレームワークよりも軽量です。
・適していない場合
大規模なアプリケーション開発
Svelteは小規模なプロジェクト向けです。大規模かつ複雑なアプリケーションには他のツールがより適している場合があります。
既存のプロジェクトのリファクタリング
既存の大規模なコードベースをSvelteに切り替えることは、手間がかかる可能性があります。
大規模なコミュニティとエコシステムが求められる場合
Svelteは他のツールに比べて、コミュニティとエコシステムはまだ小規模です。
・ちなみに
SvelteKitというツールを紹介しておきます。
SvelteKitとは
Svelte Kitは、Svelteフレームワークを基にして、ウェブアプリケーションやサイトを構築するための包括的なツールセットを提供しています。
特徴としては、ルーティング、サーバーサイドレンダリング、コード分割、プラグインシステムなどが含まれていることが挙げられます。
これにより、より大規模でパフォーマンスの高いウェブアプリケーションを効果的に開発できます。
Solid
Solidは、Webアプリケーションにおけるフロントエンド（画面）部分を構築するためのJavaScriptフレームワークです。シンプルさと高いパフォーマンスが特徴です。
主なメリット
・リアクティブなアーキテクチャ
Solidは、仮想DOMを使用せずにリアクティブなUIを実現するためのユニークなアーキテクチャを採用しています。これにより、高いパフォーマンスとスムーズなユーザーエクスペリエンスが得られます。
・軽量でシンプル
Solidは小規模であり、学習曲線が比較的緩やかです。これにより、新しい開発者が素早く始められることが可能になっています。
・SSRのサポート
SSRとはサーバーサイドレンダリング(サーバーサイドでHTMLを生成して描画する技術)のことであり、Soildではこれをサポートしているため、SEO向上や初期読み込みの最適化などの利点があります。
デメリット
・コミュニティとドキュメンテーション
Solidは比較的新しいフレームワークです。他の主要なツールと比較してコミュニティやドキュメンテーションが少ないことがあります。
・エコシステムの拡充
他の人気のあるフレームワークに比べて、Solidのエコシステムはまだ発展途上のようです。サードパーティのライブラリやプラグインの選択肢が制限されている可能性があります。
・普及度の低さ
他の主要なツールに比べて、Solidの普及度は低いため、求人市場での需要が制限される可能性があります。
ユースケース
・適している場合
リアクティブなUI
Solidは、リアクティブなUIを構築するために設計されています。データの変更に対して自動的に再レンダリングされるため、動的で即座なUIを作りたい場合に適しています。
単一ファイルコンポーネント
Solidは単一ファイルコンポーネントのアプローチを採用しており、コンポーネントベースのアーキテクチャが得意な場面で優れています。
軽量で高性能
Solidは軽量でありながら高性能なツールであり、小規模から大規模までのプロジェクトに適しています。
・適していない場合
既存のコードベースとの統合
他のフレームワークやライブラリとの既存のコードベースとの統合が必要な場合、切り替えることが難しい場合があります。
生態系の拡充不足
比較的新しいツールであり、まだ他の主要なツールと比べて生態系が十分に充実していません。
学習コスト
既存のチームや開発者が既存のフレームワークやライブラリに精通している場合、Solidへの移行には学習コストがかかる可能性があります。
Qwik
Builder.io社が作成したWebアプリケーションを構築するためのWebフレームワークです。
QwikはDelay Executionという考えのもと、JavaScriptの実行をできるだけ遅らせることを前提としています。最初にはHTMLと約1kb程度のJSを配信し、必要なときだけJSを段階的にロードすることで、高いパフォーマンスを実現しています。
主なメリット
・軽量なフレームワーク
Qwikは軽量かつパフォーマンスが優れているため、ページの読み込み時間を短縮し、ユーザーエクスペリエンスを向上させることができます。
・Angularとの互換性
QwikはAngularと同じ開発者が使いやすく、既存のAngularアプリケーションからの移行が比較的容易です。
・効率的なレンダリング
Qwik.jsは仮想DOMを使用しています。必要な部分のみを更新することができるため、効率的なレンダリングが可能です。
デメリット
・コミュニティの規模
他のツールと比較すると、Qwikのコミュニティはまだ小規模です。そのため、サポートや情報の利用可能性が制限される可能性があります。
・学習コスト
Angularとの互換性がある一方で、Qwikは新しいフレームワークであるため、学習コストが可能性があります。既存のAngular開発者には理解が容易かもしれませんが、初めての開発者にとっては理解が難しいかもしれません。
ユースケース
・適している場合
Angular アプリケーションのパフォーマンス向上
Qwikは、Angularアプリケーションの初期読み込み時間を短縮するために設計されています。これは、サーバーサイドレンダリング（SSR）を使用してアプリケーションの初期レンダリングを高速化してくれます。
コードの分割
Qwikは、アプリケーションのコードを効果的に分割し、必要なコードのみをクライアントに送信することができます。これにより、初期ページロードの時間を短縮し、ユーザーエクスペリエンスを向上させます。
データのフェッチとプリフェッチ
Qwikは、サーバーサイドでデータをフェッチすることができます。クライアントには事前に取得したデータを提供し、クライアントがデータを取得するための待ち時間を減少させます。
オフライン対応
Qwikを使用することで、アプリケーションはオフラインで動作するためのサポートを容易に実装でき、サービスワーカーと組み合わせて利用されることがあります。
・適していない場合
コミュニティやドキュメンテーションの不足
比較的新しいツールのQwikは、コミュニティやドキュメントも少なく、情報も少ないため開発時に解決不可能な問題が出てくる場合があります。
最後に
以上！フレームワーク・ライブラリの紹介でした。
本記事では、有名なツールから比較的新しいツールまで紹介させていただきました。
UI構築を始める際に迷っている方は是非、こちらの記事も参考にしてプロジェクトや開発者の状況に合ったツールを検討していただければと思います！