最近話題のRemixに入門したので、Next.jsと比較しながら布教します|東京のWEB制作会社・ホームページ制作会社|株式会社GIG

最近話題のRemixに入門したので、Next.jsと比較しながら布教します

2024-09-30 制作・開発

こんにちは!GIGのサービス開発事業部でアプリケーションエンジニアとして働くちいかた(片田)です!

モダンフロントエンドが好きな皆さん、Remixってご存知ですか?

新しい技術なので聞き馴染みがない方もいらっしゃるかもしれませんが、じつは著名なサービスで実際に採用されているような技術なんです。

しかし、モダンフロントエンドは技術の移り変わりが激しいため、トレンドの技術を追いかけ続けるのは大変で、ましてやプロダクトに活用するのは勇気がいりますよね。

ただ、それでもおすすめしたいのがRemix。RemixはWeb標準APIをフレームワークがほぼ隠蔽していないため、学習する必要のあるRemix独自の知識は他のフレームワークに比べ少なくすみます。そのため、フレームワークのアップデートも追従しやすく、Remix自体のキャッチアップもしやすいと言えます。

今回の記事では、ここ数週間でRemix製のプロダクトを3つ開発した私が「Remixとはどんな技術で、何ができるのか、Next.jsと比較してどう違うのか」を解説します。

Remixとは

公式ドキュメントによると、RemixとはフルスタックなWebアプリケーションフレームワークです。

Remix 公式サイト

前項で述べたとおり、Web標準APIを尊重する思想のフレームワークです。

Remixの実態は、React Routerをベースとしつつ、SSR(サーバーサイドレンダリング)する機能を搭載したもの、とも言えそうです。

Web標準のAPIを積極的に使えるところが個人的に気に入っているポイントです。技術のキャッチアップをしていても、フレームワーク特有の知識ではなく、Web開発として普遍的な知識をインプットできている感覚があります。

2023年の9月にはRemix v2が発表されました。Viteによるコンパイルが可能になったことで、開発体験がとにかく良くなりました。

2021年にOSSとしてリリースされたばかりのRemixですが、すでにWeb開発のフレームワークとしてNext.jsと肩を並べる存在になっており、これからの進化にも期待できるような技術だと感じています!

Remixを使ってみて感じたメリット

ここからはRemixを使ってみて感じたメリットやデメリットを、Next.jsを比較しつつ解説します。

まずは、なんといってもWeb標準APIを重視しているところです。たとえば、データのフェッチにはFetch APIを使用しています。これにより、ブラウザとサーバー間で一貫したAPIを使用できます。

Next.jsの場合、サーバーコンポーネントではFetch APIを使いますが、クライアントコンポーネントではSWRを使用します。

// Remix example
export const loader = async ({ request }) => {
  const response = await fetch('https://api.example.com/data');
  const data = await response.json();
  return json(data);
};

// Next.js App Router example
async function getData() {
  const res = await fetch('https://api.example.com/data');
  if (!res.ok) {    throw new Error('Failed to fetch data'); }
   return res.json();
}

export default async function Page() {
  const data = await getData(); 
  // ...
}


また、キャッシュ周りの扱いもRemixの方がハンドリングしやすく使いやすいと感じています。Next.jsは良くも悪くもフレームワークがパフォーマンスを最適化してくれるため、キャッシュの設定をするのにも手間がかかったり、そもそも制御できなかったり部分もあります。その点、Remixは柔軟に設定できます。

さらに、公式がアダプターをいくつも用意していて、ホスティング先が違っても実装に困らない点もRemixのいいところです。

Next.jsの場合、基本的には同じ組織が開発しているVercelというプラットフォームにデプロイすることを想定されているため、たとえばCloudflare Workersにデプロイしようとすると開発体験もかなり落ちてしまいます。

一方で、Remixは公式がアダプターと呼ばれる、Remixアプリケーションと実行環境のクッションとなるような機能を用意しており、実行環境がNode.jsだろうがCloudflare Workersだろうが、さらにはDenoでも問題なく動作します。

さらにはHonoといったモダンなバックエンドフレームワークをアダプターとして採用できるため、開発体験やパフォーマンス面でより多くの恩恵を受けられます。

RemixのアダプターにHonoを採用する素晴らしさを語ると長くなるので、詳細は私の個人ブログにまとめました。もし興味がある方はこちらもご覧ください!

RemixのAdapterにHonoを選択した理由

Remixを使ってみて感じたデメリット

慣れるまでの辛抱かもしれませんが、ルーティングの方式に関してはRemixは分かりづらいなと感じます。

# Remix Routing
app/
├── routes/
│   ├── _index.tsx
│   ├── about.tsx
│   ├── blog.tsx
│   ├── blog.$slug.tsx
│   └── products.$.tsx


# Next.js App Router
app/
├── page.tsx
├── about/
│   └── page.tsx
├── blog/
│   ├── page.tsx
│   └── [slug]/
│       └── page.tsx
└── products/
    └── [...slug]/
        └── page.tsx


ご覧の通り、Next.jsはディレクトリベースのルーティングをしているのに対し、Remixは.(ドット)区切りのようなファイルベースのルーティングしています。

たとえば、トップページはroutesディレクトリ直下の_index.tsxにルーティングされます。

/blogというパスにアクセスするためには、blog.tsxを用意し、ブログの詳細画面を/blog/1や/blog/2など、slugをパスパラメータに設定する場合にはblog.$slug.tsxというファイルを作成します。

私も元々Next.jsをがっつり使っていたので、最初はこのルーティングに違和感しかありませんでした。

ただし、Remixのアプローチにも利点があります。たとえば、ファイル名ベースのルーティングは深くネストされたルートを単一のファイルで表現できるため、ファイル構造がフラットになり、管理しやすくなる場合があります。

もう一点のデメリットは、Next.jsと比較してコミュニティの規模が小さいため、先人たちが残してくれた情報の量に差があること。

基本的には公式ドキュメントと睨めっこしながら実装していくことになるため、初学者の方は注意が必要です。

そういった意味での学習コストはかかるかもしれませんが、Remixを使っていて学べることはWeb開発において普遍的であることが多いため、長い目で見るとコストパフォーマンスは良いと考えています。

おわりに

Remixを使った開発がとにかく楽しすぎるので、本当はメリットをもっと書きたかったんですが、収集がつかなくなりそうなので自制しました。

Web標準のAPIを使えるRemixであれば、フレームワーク自体のアップデートにより大幅にソースコードを改修することが少なくなると考えられるため、もっと気軽にモダンなフロントエンド技術を取り入れていけると思います。

プロダクトや組織の要件次第ですが、選択肢の一つとして検討してみるのはいかがでしょうか。

株式会社GIGは、ナショナルクライアントからスタートアップまで、Webコンサルティング、UI/UXデザイン、システム開発など、DX支援をおこなうデジタルコンサルティング企業です。また、50,000人以上が登録するフリーランス・副業向けマッチングサービス『Workship』や、7,000人以上が登録するデザイナー特化エージェントサービス『クロスデザイナー』、リード獲得に必要な機能を備えたCMS『LeadGrid』、UXコンサルティングサービス『UX Design Lab』などを展開しています。

WebやDX支援のご相談はいつでもご連絡ください。

Web制作/Webマーケティングに関するご相談・ご依頼はこちら
会社紹介資料のダウンロードはこちら

また、株式会社GIGでは一緒に働くメンバーも募集中です!技術が好きなエンジニアも多く、モダンな技術に関しても常に情報交換しながら切磋琢磨しています。挑戦したいことにはどんどん挑戦できる環境なので、LeadGridの開発に少しでもご興味を持っていただいた方は、ぜひカジュアル面談でお話しましょう。

採用応募はこちら(GIG採用サイト)
採用応募はこちら(Wantedly)

WebやDXの課題、お気軽にご相談ください。

片田 凌太

1997年10月生まれ。自動車のコネクティッドサービス開発や日本最大のコーヒーサブスクリプションサービス開発などの経験を経て2023年10月に株式会社GIGに入社。現在は、Webサイト制作からコンテンツSEO、問い合わせ管理、LP制作などWebマーケティングに必要な機能をもったCMS『LeadGrid』の開発チームに所属。