期待していたものではないけど、必要なものかもしれない

MMaximilian Schwarzmüller
Computing/SoftwareInternet Technology

Transcript

00:00:00新しいJavaScriptフレームワーク、
00:00:03フルスタックフレームワークが登場しましたが、
00:00:06諦める前に聞いてください。これはかなり興味深いものです。というのも、
00:00:10Remixの開発者たち、
00:00:12つまりRemix JSを構築したRyan FlorenceとMichael Jackson、
00:00:19いや、
00:00:19あのMichael Jacksonじゃないですよ、
00:00:23そしてReact Routerのオリジナル作者でもある彼らによるものだからです。彼らは新しいJavaScriptフレームワーク、
00:00:32Remixバージョン3のビジョンと、
00:00:34実際に最初のプロトタイプ、
00:00:36いわば最初のデモを共有しました。つまり、
00:00:39これは完全に新しい名前ではなく、
00:00:41既存の名前ですが、
00:00:43まったく新しいフレームワークなのです。このビデオでは、
00:00:46そのすべてを理解しようと試みます。それが何であるか、
00:00:50そしてもちろん、
00:00:51本当に別のJavaScriptフレームワークが必要なのか、
00:00:55その成功または採用の可能性についての私の意見を説明します。今や大規模言語モデルがデフォルトでReactアプリを吐き出す時代ですからね。しかし、
00:01:05段階を追って説明しましょう。Remixとは正確に何で、
00:01:09なぜ重要なのでしょうか?
00:01:11もしご存じなければ、
00:01:12RemixはReactメタフレームワークであり、
00:01:16最終的にはNext.jsの代替となるものです。Remixは数年前にすでにリリースされており、
00:01:22Remixバージョン2は、
00:01:24私の記憶が完全に間違っていなければ、
00:01:262022年にリリースされたと思います。そして2024年に、
00:01:30Remixバージョン2は本質的にReact Routerと統合されました。だからこそ、
00:01:36今React Routerを使用する際、
00:01:38従来通りReactアプリのルーティングライブラリとして使用することもできますし、
00:01:44それは今でも機能し、
00:01:45そのための素晴らしいライブラリです。しかし、
00:01:48フレームワークモードで使用して、
00:01:50本質的にフルスタックReactアプリケーションを立ち上げることもできます。この場合、
00:01:56React Routerは単なるルーターではなく、
00:02:00データフェッチ、
00:02:01データロード、
00:02:02データ変更も支援します。まさにRemixがそうであったように、
00:02:06なぜならRemixがReact Routerに統合されたからです。しかし、
00:02:11もちろん、
00:02:11これはRemixというブランドに何が起こるのかという疑問を生み出しました。
00:02:17そしてRemixは、
00:02:18バージョン3で新しいフレームワークになることが判明しました。重要なのは、
00:02:23Reactから独立した新しいフレームワークになるということです。これはReactメタフレームワークではありません。いわばNext.jsの別の代替でもありません。代わりに、
00:02:35まったく新しいフルスタックJavaScriptフレームワークであり、
00:02:40ゼロから一から書かれたもので、
00:02:42Ryan FlorenceとMichael Jacksonが新しいJavaScriptフレームワークに持たせたいすべての機能とAPIを備えています。つまり基本的に、
00:02:53彼らがJavaScriptエコシステムで見てきた問題、
00:02:57既存のライブラリとフレームワークのランドスケープで見てきた問題を解決するものです。特にもちろん、
00:03:04Reactに関してです。なぜなら、
00:03:06それが外にある主要なライブラリでありフレームワークだからです、
00:03:10どう呼びたいかによりますが。では、
00:03:13この新しいRemixは何についてのものなのでしょうか?先週金曜日に...
00:03:18私たちは最初のデモ、
00:03:19APIの最初の垣間見ることができました。もちろん、
00:03:23すべてを見たい場合に備えて、
00:03:25完全なライブストリーム、
00:03:27アナウンスメントイベント全体を視聴できる場所をこのビデオの下にリンクしておきます。ただし、
00:03:35約4時間のノンストップデモと説明になることに注意してください。私はあなたが見たくない場合のために視聴しましたが、
00:03:44もっと学びたい場合は絶対に見てください。そして、
00:03:48ここにこの新しい...
00:03:49フレームワークの主な内容、
00:03:51あるいはXで波紋を呼んだ主なもの、
00:03:54this.updateが見られます。あまり目立たないように見えますか?実は、
00:04:00これは2つのことを暗示しており、
00:04:03それは...
00:04:04JavaScript開発者がもはやあまり慣れていないものです。1つ目は、
00:04:09thisキーワードの使用です。つまり、
00:04:11私のような古い人間は、
00:04:13JavaScriptを始めたときにthisのすべての癖と機能を学びました。今日では、
00:04:19Reactではあまり使用しません。おそらくthisを書くことはないでしょう。しかし、
00:04:24これはJavaScriptに組み込まれたキーワードです。彼らはこのthisキーワードを活用して、
00:04:31いくつかのAPIをあなたに公開します。これらのAPIにはどこでアクセスできるのでしょうか?それでも関数を書きます。
00:04:39つまり、
00:04:39このキーワードを使っていても、
00:04:41クラスを書くわけではありません。しかし、
00:04:44Remixで作業する際には、
00:04:46まだコンポーネントを構築しており、
00:04:48そのために関数を使用します。Reactで知っているのと同じように。ただし、
00:04:53それらのコンポーネント関数は少し異なって見えます。しかし、
00:04:57this.updateに戻りましょう。それについて2つの重要なことがあると述べました。thisはその1つです。updateはもう1つです。なぜなら、
00:05:07Remixバージョン3では、
00:05:09いつ画面を更新すべきか、
00:05:10いつ再レンダリングすべきかをフレームワークに伝える必要があるからです。そしてそれはもちろん、
00:05:16私たちがもはや慣れていないものです。なぜなら、
00:05:19ReactだけでなくVueやAngularでも、
00:05:23いつ更新するかをフレームワークが決定することに依存しているからです。Reactでは、
00:05:28setStateを呼び出すと、
00:05:30管理している状態に新しい値を割り当てており、
00:05:33それがUI更新もトリガーします。ただし必ずしも即座にではありません。代わりに、
00:05:38Reactはバッチ処理を行い、
00:05:40複数の状態更新を収集する可能性などがありますが、
00:05:43最終的にはUIを更新します。つまり、
00:05:46setStateを使用すると、
00:05:48ReactにUIを更新すべきだと伝える形になりますが、
00:05:51主に何らかの値が変更されたことを伝え、
00:05:54その効果としてUIが更新され、
00:05:56再レンダリングされることになります。Remixでは異なります。Remixのバージョン3では、
00:06:02状態を標準変数で管理し、
00:06:04特別なものはありません。useStateフックのようなものはなく、
00:06:08実際にはフックは全くありません。そして、
00:06:11UIを更新すべきだと分かったときにthis.updateを呼び出すだけです。つまり、
00:06:16複数の変数を変更してthis.updateを呼び出さなければ、
00:06:20UIは更新されません。または、
00:06:22複数の変数を変更してthis.updateを呼び出せば、
00:06:26UIは更新されます。そのように機能します。そして、
00:06:29インターネットをご存知でしょう、
00:06:32インターネットの人々はひどいですから、
00:06:34何人かの人々がそれに問題を抱えているようです。私は、
00:06:38それがどう機能するか見てみようと言いたいです。つまり、
00:06:41これは新しいアプローチであり、
00:06:43古いアプローチは確実にうまく機能しています。すべてのライブラリとフレームワークで使用されている理由があると思いますが、
00:06:51古いアプローチには確実に自爆する可能性があり、
00:06:54何かが更新される理由または更新されない理由が明確でない状況につながる可能性があります。そして、
00:07:00より複雑なアプリ、
00:07:02特に多くのフックなどで非常に複雑になった新しいバージョンのReactでは、
00:07:07何が起こっているのかを真に理解するのは圧倒的になる可能性があります。それが、
00:07:12完全な制御ができるよりシンプルなAPIに戻っている理由の1つです。
00:07:16また、
00:07:16thisキーワードを使用して他にもいくつかのAPIを公開していますが、
00:07:21実際にはそれほど多くはありません。なぜなら、
00:07:24明らかにフレームワークをシンプルで焦点を絞ったものに保ち、
00:07:28優れた開発者体験を提供し、
00:07:30このフレームワークを使いやすくするという考えがあるからです。また、
00:07:34今年初めに彼らが共有したブログ記事で述べられている明確な目標として、
00:07:39このフレームワークは大規模言語モデルが使いやすいものであるべきだという点があります。つまり、
00:07:45ドキュメント記事や例を大規模言語モデルとのチャット履歴に入力し、
00:07:49コンテキストとして情報を提供することで、
00:07:52LLMやコードアシスタントにコード生成を手伝ってもらえるようにするという考えです。当然、
00:07:58彼らはそうする必要があります。なぜなら、
00:08:01これは全く新しいフレームワークだからです。明らかに、
00:08:04既存の大規模言語モデルはこのコードベースでトレーニングされていませんし、
00:08:09当面の間、
00:08:10トレーニングされることもないでしょう。なぜなら、
00:08:13すべてのフロントエンドコード例の80%はReactのようで、
00:08:17特にshadCNを使ったReactだからです。そのため、
00:08:21当然ながら、
00:08:22開発者が大規模言語モデルにRemix We Freeコードの書き方を認識させる別の方法を見つける必要があります。これが、
00:08:30彼らがAIをシンプルに保とうとしているもう一つの理由だと思いますし、
00:08:34表現力豊かで理解しやすく、
00:08:36使いやすいものに保ちたい理由でもあります。なぜなら、
00:08:40人間だけでなく、
00:08:41大規模言語モデルも使用できるべきだからです。これが彼らが持っていた明確な目標の一つであり、
00:08:47その基調講演やプレゼンテーションで共有された例からもわかります。さらに、
00:08:52彼らが持っている別の目標として、
00:08:54そのプレゼンテーションで何度も述べられていたのは、
00:08:57Web標準を使用しているということです。モダンブラウザで利用可能な機能を使用しており、
00:09:03ブラウザだけでなく、
00:09:05バックエンドでも使用可能です。バックエンドについては後ほど説明しますが、
00:09:10ブラウザに組み込まれているものを使用しています。ネイティブイベントやカスタムイベントをディスパッチする組み込み機能に大きく依存しています。ブラウザでカスタムイベントを作成してディスパッチすることができ、
00:09:23彼らはそれに大きく依存しています。また、
00:09:26コンポーネントがアンマウントされたことを伝えるためにabortシグナルに依存しており、
00:09:32イベントリスナーを自動的に停止できるようにしています。つまり、
00:09:36ブラウザに組み込まれているものを使用しているのです。なぜなら、
00:09:40私たちWeb開発者は、
00:09:42モダンブラウザができることに追いついていないと強く感じているからです。モダンブラウザだけでなく、
00:09:48何年も前から存在している特定の機能があり、
00:09:51私たちはそれらを使用していません。それらについて知らないかもしれません。DOMが提供するもの、
00:09:57ブラウザが提供するもの、
00:09:59どのようなAPIが利用可能かを本当に深く掘り下げれば、
00:10:03そこでできることはたくさんあり、
00:10:05追加のサードパーティライブラリが必要ないかもしれない多くのことがあります。そして、
00:10:10それが最終的に彼らが活用しようとしているものです。シンプルに保ち、
00:10:15それらの組み込み機能を使用する。それが最終的な彼らのアプローチです。ただし、
00:10:20前述したように、
00:10:21これは依然としてフレームワークです。createElementやすべてのDOM APIでDOMノードを作成することはありません。前述のように、
00:10:31関数を作成し、
00:10:32その中でJSXコードを使用してコンポーネントを作成します。彼らはそれをすべて示しました。ただ、
00:10:38状態管理の仕組みが全く異なり、
00:10:40一般的により軽量で、
00:10:41フックなどはありません。また、
00:10:43Reactの場合のように、
00:10:45それらのコンポーネント関数が何度も呼び出されることはありません。代わりに、
00:10:502種類の関数があり、
00:10:52書き方に応じて、
00:10:53一度だけ呼び出されるか、
00:10:54その一部が複数回呼び出される可能性があります。ここで、
00:10:582017年頃にReactを使っていた人たちのために何かあります。当時、
00:11:032種類のコンポーネントがあったことを思い出すかもしれません。状態を管理でき、
00:11:08その状態が変更されたときに更新できるクラスベースのステートフルコンポーネントと、
00:11:13ステートレスコンポーネントがあり、
00:11:15それが当時のコンポーネント関数でした。そして、
00:11:19React Hooksが登場し、
00:11:21すべてのコンポーネントが最終的にコンポーネント関数になり、
00:11:25ステートフルまたはステートレスのいずれかになりました。Remixバージョン3は、
00:11:30その昔ながらのReactアプローチを採用していますが、
00:11:34クラスや関数ではなく、
00:11:35常に関数ですが、
00:11:36異なるタイプの関数です。JSXを返す関数がある場合、
00:11:40それは最終的にステートレスコンポーネントです。その中でこのupdateを呼び出して、
00:11:46コンポーネント関数が再度実行されることを期待することはできません。そのようには機能しません。propsを受け入れることができ、
00:11:54親コンポーネントが再レンダリングされると、
00:11:57コンポーネント関数が再度実行されますが、
00:12:00その中で状態を管理することはできません。コンポーネント関数をステートフルコンポーネント関数に変えるには、
00:12:07JSXコードを返すのではなく、
00:12:09JSXコードを返す関数を返すことで実現します。つまり、
00:12:12JSXコードを返す関数を含んで返すコンポーネント関数は、
00:12:16ステートフルコンポーネントになることができます。そして、
00:12:20this.updateを呼び出すと、
00:12:22返した関数が再度実行されます。少なくとも、
00:12:25私はそのように理解しました。つまり、
00:12:27異なるコンポーネントタイプがありますが、
00:12:30やはり最終的には非常にシンプルなAPIであり、
00:12:33ステートフルまたはステートレスコンポーネント関数を区別する非常にシンプルな方法です。そして、
00:12:39バックエンドがあります。なぜなら、
00:12:42Remixバージョン3は単なるフロントエンドフレームワークではないからです。代わりに、
00:12:48フルスタックフレームワークです。フルスタックフレームワークであることを意図しています。ちなみに、
00:12:54複雑なフォームコンポーネントなどを構築しやすくするコンポーネントライブラリも提供される予定です。これも言及しておくべきですが、
00:13:03バックエンドに戻りましょう。バックエンド部分も付属します。フロントエンドとバックエンドを組み合わせたフルスタックフレームワークを目指しています。繰り返しますが、
00:13:13Reactを完全に排除し、
00:13:15すべてをゼロから再構築しているわけです。しかし、
00:13:18バックエンドでは、
00:13:20ルーターを取得します。非常に有能で強力なルーターです。なぜなら、
00:13:24明らかに彼らは過去10年間React Routerを構築してきたので、
00:13:29ルーティングについて多くのことを知っているからです。つまり、
00:13:33強力なルーターを取得し、
00:13:34ルートでJSXコードとRemixコンポーネントを返す機能を取得し、
00:13:39サーバー上でそれらのコンポーネントをハイドレートします。彼らはReact Server Componentsに対する独自の代替案、
00:13:48よりシンプルな代替案を考え出しました。これにより、
00:13:51クライアントで提供された後に更新できるコンポーネントを返すことができます。DOMの一部を再取得することで更新できます。例えば、
00:13:59何かを削除する場合、
00:14:01クライアントからそのサーバーにリクエストを送信し、
00:14:04再度ハイドレートできるHTMLコードを取得して、
00:14:07DOMの一部を更新できます。つまり、
00:14:10彼らは、
00:14:10Next.JSやReact Routerフレームワークモード、
00:14:15またはTanStack Startなどの他のフレームワークで構築できるように、
00:14:20スナップで現代的なシングルページのようなフルスタックアプリケーションを構築するためのこれらすべての機能を提供していますが、
00:14:28よりシンプルです。それが明確な目標です。それらのアプリを構築するシンプルな方法を持つこと。それが彼らがやりたいことです。このプレゼンテーションにはもっと多くのことがあります。長いですが、
00:14:41これが最も重要な部分だと思います。それが私の主な要点です。彼らは強力でシンプルなフルスタックフレームワークを提供したいと考えています。ゼロから書いています。手動更新などがあります。つまり、
00:14:53私が説明したすべてです。それが必要でしょうか?
00:14:56それが大きな問題であり、もう一つの大きな問題は、成功するのかということです。
00:15:02明らかに、両方の質問に答えるのはかなり難しいですが、最善を尽くします。それが必要でしょうか?
00:15:08まあ、
00:15:08世の中には多くのJavaScriptフレームワークがあり、
00:15:13明らかに多すぎるという人もたくさんいるでしょう。そうすると答えはノーということになります。私は、
00:15:192018年当時、
00:15:20毎週新しいフレームワークが出ていた時でさえ、
00:15:23常にイノベーションがあり、
00:15:25新しいアイデアを試すことは良いことだと思っていました。わずかな違いがあるだけのReactのような新しいフレームワークが必要だとは思いません。それは必要ないと思います。しかし、
00:15:37手動でトリガーされる更新や、
00:15:39彼らが持っている他のすべての小さなことを含む全く新しいアプローチは、
00:15:44素晴らしいアイデアだと思います。間違いなく試す価値があります。興味深く聞こえます。Reactに対するよりシンプルな代替案を提供してくれるかもしれません。Reactは素晴らしいですが、
00:15:57長年にわたってかなり複雑になってきました。だから、
00:16:00そう、
00:16:01必要かもしれません。成功するでしょうか?
00:16:04それはもちろん別の問題です。特に今、
00:16:06AIや大規模言語モデルの時代においては、
00:16:09明らかにそれらのモデルは通常デフォルトでReactを推奨するでしょう。一方で、
00:16:14コードの書き方を知らない人々は、
00:16:17もちろん必ずしも直接的なターゲット層ではありません。それについては後で触れます。だから、
00:16:23そこでは問題ないのです。しかし経験豊富な開発者は、
00:16:26Remixの使用に興味を持つかもしれません。公式のサンプルなどを使って大規模言語モデルを導き、
00:16:33Remixコードを生成させることで、
00:16:35よりシンプルなコードベースを持ちたいと考えるからです。結局のところ、
00:16:40開発者として私たちはまだコードに触れます。その大部分を生成するかもしれませんが、
00:16:45それでも大規模言語モデルをコントロールし、
00:16:48コードの一部を微調整します。AIがどうしてもうまくできない非常に特定の機能を念頭に置いている場合は、
00:16:55コードのより大きな部分を書くこともあるでしょう。ですから明らかに、
00:17:00開発者として私たちはまだ技術スタックを気にかけています。少なくとも私は気にかけていますし、
00:17:06皆さんの中にもそうした方がいると確信しています。だからそこでは、
00:17:10何か別のものを試してみるのは興味深いかもしれません。そしてそのフレームワークが大規模言語モデルと一緒に使いやすく、
00:17:18大規模言語モデルにその使い方を教えるのに十分なリソースがある限り、
00:17:23これはもちろん彼らが重点を置き、
00:17:25優先事項として持っているように見えることですが、
00:17:28それは私にとって良いことです。だからそれは間違いなく、
00:17:32彼らに成功の正当なチャンスを与えるかもしれません。もちろん難しいでしょう。しかし、
00:17:38まあ、
00:17:38それは常にそうだったはずですからね。だから私はチャンスを見ています。しかしもちろん、
00:17:44こう言えば、
00:17:45混雑した市場です。さて、
00:17:47重要なのは、
00:17:47Remixは2022年にShopifyに所属したということです。
00:17:52Shopifyが言わばRemixを買収したのです。つまりRemixチームはShopifyの一部になりました。さて、
00:18:00Shopifyは明らかにもちろん、
00:18:02積極的にメンテナンスされ、
00:18:04少なくともShopify内部で使用されているフレームワークを持つことに興味があります。そしてそれは、
00:18:11Shopifyのマーケティングやブランディングページのために社内で使うという意味だけではありません。Shopifyのショップのためという意味です。Shopifyのベンダーが、
00:18:23Shopifyの上に独自のショップを構築したいと考え、
00:18:26それらのショップを調整したり、
00:18:29ショップ全体を構成するカスタムのストアフロントやページを構築する簡単な方法を求めている場合、
00:18:35Remixをオプションとして持つことが目標である可能性は十分にあります。そしてもちろん、
00:18:41使いやすく、
00:18:42大規模言語モデルと一緒に使いやすいフレームワークを持つことは、
00:18:46非常に大きな意味を持つ可能性があります。もちろん、
00:18:50それでも保証ではありませんが、
00:18:52RemixにShopifyがついているということは、
00:18:55おそらく大きな価値があると思います。したがって、
00:18:59私はRemixの将来についてかなり前向きです。もちろん、
00:19:03彼らは小さいかもしれませんが、
00:19:05非常に熱心なコミュニティを持っているからです。私が知る限りでは。彼らは明らかに、
00:19:10React Routerなどを開発してきた素晴らしい実績を持っています。だから、
00:19:16ええ、
00:19:16私たちが何を得られるかとても楽しみです。今は実際にはそれが不可能なので、
00:19:21自分自身でついに使えることにワクワクしています。これらが私の考えです。いつものように、
00:19:27皆さんの考えを教えてください。私たちにそれが必要だと思うか、
00:19:31彼らが勝つと思うか、
00:19:33そして興味があってもっと学びたい場合は、
00:19:36カンファレンスの4時間全体の部分を見てください。

Key Takeaway

Remix v3は、Reactの複雑さを解消するためにゼロから構築された新しいフルスタックJavaScriptフレームワークで、手動更新とWeb標準の活用により、よりシンプルで大規模言語モデルとも相性の良い開発体験を目指している。

Highlights

Remix v3は完全に新しいフルスタックJavaScriptフレームワークで、Reactから独立し、ゼロから書き直されている

this.update()を使用した手動UI更新により、開発者が再レンダリングのタイミングを完全にコントロールできる

Web標準とブラウザ組み込み機能(カスタムイベント、abortシグナル等)を積極的に活用している

大規模言語モデル(LLM)が使いやすいように設計されており、AIコード生成との相性を重視している

ステートフルとステートレスの2種類のコンポーネント関数があり、関数の返り値によって区別される

ShopifyがRemixチームを所有しており、特にShopifyのストアフロント構築での活用が期待される

Timeline

Remix v3の登場と背景

RemixのオリジナルクリエイターであるRyan FlorenceとMichael Jacksonによる新しいフルスタックJavaScriptフレームワークRemix v3が発表された。彼らはReact RouterとRemix JSの開発者として知られており、2024年にはRemix v2がReact Routerと統合されていた。Remix v3は従来のReactメタフレームワークから脱却し、完全に新しい独立したフルスタックフレームワークとして再構築される。このフレームワークは、JavaScriptエコシステムとReactにおける既存の問題を解決することを目的としており、約4時間におよぶライブストリームで最初のデモとAPIが公開された。

this.update()による手動UI更新の仕組み

Remix v3の最も特徴的な機能は「this.update()」による手動UI更新メカニズムである。ReactやVueでは状態変更が自動的に再レンダリングをトリガーするが、Remix v3では開発者が明示的にthis.update()を呼び出す必要がある。thisキーワードを使用してAPIを公開し、状態は標準的な変数で管理され、useStateのようなフックは存在しない。このアプローチは古いと感じるかもしれないが、完全な制御を提供し、複雑なアプリケーションで何が更新されるのかが明確になるという利点がある。ReactのフックやuseEffectなどが複雑化している現状に対して、よりシンプルで理解しやすいAPIを提供することを目指している。

Web標準の活用とシンプルさの追求

Remix v3のもう一つの重要な設計思想は、モダンブラウザに組み込まれているWeb標準機能を積極的に活用することである。ネイティブイベント、カスタムイベントのディスパッチ機能、abortシグナルなどを使用し、コンポーネントのアンマウント時にイベントリスナーを自動停止できるようにしている。開発チームは、Web開発者がモダンブラウザの機能に追いついていないと考えており、DOMやブラウザAPIが提供する機能を深く掘り下げれば、多くのサードパーティライブラリが不要になる可能性があると主張している。フレームワークをシンプルで焦点を絞ったものに保ち、優れた開発者体験を提供することが明確な目標として設定されている。

大規模言語モデル(LLM)との統合戦略

Remix v3は大規模言語モデルが使いやすいフレームワークであることを明確な設計目標としている。ドキュメント記事や例をLLMのチャット履歴に入力することで、AIコードアシスタントにコード生成を手伝ってもらえるようにする考えである。既存のLLMはこの新しいフレームワークでトレーニングされていないため(現在のフロントエンドコード例の80%がReact、特にshadCNを使ったReact)、シンプルで表現力豊かな設計が重要となる。フレームワークはJSXを使用し、コンポーネントを関数で作成するが、状態管理の仕組みは全く異なり、フックは存在せず、より軽量な設計となっている。コンポーネント関数は、JSXを直接返すステートレスタイプと、JSXを返す関数を返すステートフルタイプの2種類に分かれる。

フルスタック機能とバックエンドの統合

Remix v3は単なるフロントエンドフレームワークではなく、完全なフルスタックフレームワークとして設計されている。バックエンド部分には非常に有能で強力なルーターが含まれており、これは開発チームが過去10年間React Routerを構築してきた経験に基づいている。サーバー上でRemixコンポーネントをハイドレートする機能があり、React Server Componentsに対する独自のよりシンプルな代替案を提供している。クライアントで提供された後に更新できるコンポーネントを返すことができ、例えば何かを削除する場合、クライアントからサーバーにリクエストを送信して再度ハイドレートできるHTMLコードを取得し、DOMの一部を更新できる。Next.JSやReact Router、TanStack Startなどで構築できるようなモダンなシングルページアプリケーションを、よりシンプルな方法で構築することが明確な目標である。

必要性と成功の可能性についての考察

新しいJavaScriptフレームワークの必要性については賛否両論があるが、手動更新などの全く新しいアプローチは素晴らしいアイデアであり、試す価値がある。Reactは長年にわたってかなり複雑になってきたため、よりシンプルな代替案が必要かもしれない。成功の可能性については、AI時代において大規模言語モデルがデフォルトでReactを推奨する課題がある一方、経験豊富な開発者はよりシンプルなコードベースを求めてRemixに興味を持つ可能性がある。重要な点として、2022年にShopifyがRemixチームを買収しており、Shopifyのストアフロント構築での活用が期待される。Shopifyのベンダーがカスタムストアフロントやページを構築する簡単な方法として、使いやすく大規模言語モデルと相性の良いRemixが選択肢となる可能性は高い。小さいながらも熱心なコミュニティとReact Routerなどの開発実績を持つチームであることから、将来性は前向きに評価できる。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video