インタビューNext.js 12 は、組み込みミドルウェアや ECMAScript (ES) モジュールのサポートなど、さまざまな新機能を備えてリリースされました。
「それは2つのレベルに分かれています」とラウチ氏はThe Registerに語った。「1つは開発者エクスペリエンス、もう1つはコンピューティングのためのグローバル実行モデルです。」
これらの主張の根拠は、第一に、新しい Rust コンパイラーを含む Next.js ツールの改良、第二にフレームワークへのミドルウェアの追加であり、Vercel は開発者が同社のコンテンツ配信ネットワークである Edge Functions (現在ベータ版) 上でこれを実行することを期待している。
Next.jsはReactをベースにしており、Node.jsによるサーバーサイドレンダリングと静的サイト生成のオプションが追加されています。バージョン12の新機能は以下のとおりです（ただし、多くの機能はまだプレビュー段階です）。
- ユーザーのリクエストとメインのアプリケーション コードの間で実行されるミドルウェア (現在はベータ版)。
- Vercel によれば、Next.js アプリケーションをコンパイルするための Babel に代わる Rust コンパイラーはビルド時間を 5 倍改善します。
- React 18（React 18はまだアルファ版ですが）のサポートを追加しました。これには、要求されたデータが解決されるまでコンポーネントの状態遷移を遅延させるサスペンス機能が含まれます。これは試験的フラグが付けられています。
- Reactサーバーコンポーネントのサポート（こちらもアルファ版）。「クライアントサイドのJavaScriptが不要なので、ページのレンダリングが高速化されます」とチームは述べています。
- WebP よりも 20 パーセント優れた圧縮率を持つ AVIF 画像のサポート。
- ESモジュールはデフォルトでネイティブサポートされますが、旧式のCommonJSモジュールも引き続きサポートされます。また、Node.js 12.22以降が必要です。
- ビルド プロセスではなく、URL 経由で ES モジュールを直接インポートするための実験的なサポート。
- webpack 4 を削除し、代わりに webpack 5 を導入しました (重大な変更)。
なぜ新しいコンパイラが登場したのか？「フロントエンドのコードベースの規模が急速に拡大していることが主な動機です」とラウチ氏は語る。「数百人のNext.js開発者を抱え、数万、場合によっては数十万のコンポーネントを含むコードベースを扱う企業も珍しくありません。」
VercelのCEO、Guillermo Rauch氏がNext.js 12を紹介
Next.jsが最初に開発された当時、「JavaScriptの構文は急速に変化しており、TypeScriptは現在のような事実上の標準ではありませんでした。そのため、多くのツールはJavaScript自体で書かれていました。今では状況は安定し、ReactのJSX構文も事実上の標準となっているため、ネイティブコードを活用することが理にかなっていると言えるでしょう。開発者が日々依存しているプロセスの一部は、ネイティブコードによって100倍も高速化されます。」
Nodeはこれまで私たちに良いサービスを提供してきましたが、今日のパフォーマンスのニーズに関しては、その時代遅れさを見せ始めています。
Next.jsミドルウェアはNode.js上で動作するのではなく、V8 JavaScriptエンジン自体（Node.jsでも使用されています）上で直接動作します。「クラウドのプリミティブとしてのNode.jsはサイズが大きすぎます。サーバーレスの文脈では、コールドスタートの問題を引き起こします。そこで、エッジ側と開発側の両方で開発者が使用できるコードを簡素化することで、APIサーフェスを制限し、パフォーマンスとセキュリティを大幅に向上させることができます。」
Rauch氏が言及しているのは、ミドルウェアが使用するEdgeランタイムですが、これはNode.js APIをサポートしていません。ドキュメントには、Nodeモジュールは「ESモジュールを実装し、ネイティブのNode.js APIを使用しない限り」使用できると記載されています。
ラウチ氏によると、開発者はこれらのサーバーレス機能にNode.jsを使用しないことで「様々な問題を完全に排除できる」という。「Node.jsはこれまで十分に機能してきましたが、今日のパフォーマンスニーズを満たすには時代遅れになりつつあります。」
- New Relic は CodeStream を大量に消費し、開発者がアプリのエラー テレメトリから問題のあるコードに直接ジャンプできるようにします。
- Node.js 17がリリースされましたが、開発チームによると本番環境では利用できないとのことです。
- Jamstack 調査: Typescript とサーバーレスが勝者
- JavaScriptフレームワークのChromeの「適合性」には、「ルールに従わないとプロジェクトはビルドされません」と書かれています。
ミドルウェアの潜在的な用途は多岐にわたります。認証、ボット対策、機能フラグとA/Bテスト、サーバーサイド分析、ログ記録、そしてリダイレクトやリライトが必要なあらゆるケースなどです。Next.js Confでは、リージョン固有のデータベースサーバーを使用することでレイテンシを改善できる例が示されました。
ラウチ氏は、マイクロサービスからの動的データを用いて静的ウェブサイトを利用するJAMStackには長所と短所があると指摘する。「良い点は、事前レンダリングに重点を置いていることです。短所は、あまりにも静的であるため、事前レンダリングが全くできないことがあったことです。」
「現在、特にベータ版として発表しているReactサーバーコンポーネントの導入により、コードの大部分をサーバーに戻すことが可能になりました。しかも、サーバーは世界の特定の場所にモノリシックに設置されるのではなく、コードをグローバルに分散させています。これによりパフォーマンスが向上し、単一障害点がなくなります。」
これは、従来のWebアプリケーションでCDNを使用するのとどう違うのでしょうか？「CDNが高速化を目指した時、彼らの武器はキャッシュでした」とRauch氏は語ります。「オリジンサーバーにアクセスし、ページを取得してキャッシュします。その時点で、特にメディアやeコマースといった分野では、既に静的になりすぎています。言語から通貨、コンポーネントのバリエーションまで、あらゆるものをパーソナライズしたいというニーズが高まっています。こうした状況では、従来のCDNベンダーのトップレベルキャッシュはもはや機能しません。」
ラウチ氏は、Next.jsのWeb中心の開発モデルもメリットだと考えている。「Next.jsには、Webブラウザにネイティブでないものは何もありません」と彼は言う。「今日のデザイナーの仕事ぶりを見てみると、彼らはWebブラウザを開いてFigmaを指定するだけです。私たちは、同じようにブラウザを開いてNext.jsプロジェクトを指定し、コンパイラとすべての仕組みをブラウザ内で実行できるのではないかと自問しました。」
このアイデアは、Webベースの開発プラットフォームであるNext.js Liveへと発展しました。「プライベートベータ版では、製品版レベルのアプリケーションをWebブラウザに直接読み込むことができました」とラウチ氏は言います。このコンセプトはGitHub CodespacesやGitpodに似ていますが、Next.js Liveではすべてがブラウザ内で行われ、コンテナバックエンドが存在しないという点が異なります。
「Next.jsは基本的にフロントエンドフレームワークです」とラウチ氏は言います。「Next.jsのランタイムは基本的にサーバーレスなので、プロジェクトの実行とレンダリングに追加の仕組みは必要ありません。Webは最初から読み取りと編集の両方ができるように設計されているのです。私たちは、より多くの人々にWebへの貢献の世界に足を踏み入れてもらいたいと思っています。」
Next.js Live のエディターは、Microsoft の Visual Studio Code プロジェクトと同様に、Monaco に基づいています。
Next.js Liveは、ブラウザのコンパイラとしてWebAssemblyを使用しています。「WebAssemblyは今や、アプリケーションを配布するための新しいユニバーサルな方法です」とラウチ氏は言います。「Rustで書かれたコードを完全にユニバーサルなものにすることができます。」しかし、ラウチ氏は「WebAssemblyを本番環境で使うのはまだ初期段階」だと考えているため、現在は開発用途のみに使用しています。ただし、チームは将来に向けて検討を進めています。
Next.js 12では、ホットモジュールリロード（HMR）のパフォーマンスと安定性も向上していると、ラウチ氏は説明する。「HMRとは、入力してファイルを保存し、Webブラウザを更新することなく変更が即座に反映される機能です。以前は、開発者は技術を完全に信頼できず、推測したり、記憶を頼りに更新ボタンを押したりする必要がありました。私たちはHMRを大幅に改良しました。入力中の画面の再描画速度が最大5倍速くなりました。」
高速更新を支えるテクノロジーは、ES モジュールの利点の 1 つです。「Web ブラウザに特定の変更のみを伝えることができるため、作業中のページ部分のみを読み込めます。」
なぜNext.jsではなくReactを使わないのでしょうか？「私はReactをエンジンとして考えています」とRauch氏は言います。「このエンジンは、一方でレンダリングを強化し、他方で開発者が使用する基本的な抽象化を提供します。コンポーネントモデルとレンダリングエンジンはReactによって提供されます。しかし、Next.jsでは、人々はWebサイトやアプリケーションを構築しており、その上にNext.jsが導入した抽象化レイヤーが存在します。私たちは、抽象化をコンポーネントからページへと引き上げました。」
TypeScriptはJavaScriptに取って代わるのでしょうか？「エコシステムは成熟しつつあります。開発者は、バグの削減、より高いレベルの正確性、より多く、より質の高いドキュメント、そしてコードだけでなく型を求めています。そのため、TypeScriptはNext.jsプロジェクト、特に企業のチームにとってデフォルトとなっています。」®
