Amal Hussein: JSパーティーのリスナーの皆さん、こんにちは。今日はとてもとても特別なショーにようこそ... 毎週言っていることですが、本当に、この番組にとても興奮しています。本当に特別なゲストをお招きしていますが、ゲストをご紹介する前に、本日の共同パネリスト、副操縦士のアメリア・ワッテンバーガーをご紹介します。こんにちは、ようこそ、アメリアさん。
Amelia Wattenberger: ヘイヘイヘイ。
Amal Hussein: アメリア、あなたの名前はドイツ語ですか？ちょっと聞きたいんだけど・・・。だってワッテンベルガーって言う度に、完全なドイツ語にしたい衝動に駆られるんだもの。"問題なし、ヤー "みたいな感じで。
Rich Harris: ワッテンバーガー
Amal Hussein: ああ、ワッテンベルガーか...。それでドイツ語なの？
Amelia Wattenberger: 実は、数日前に調べたんです...。父が家系図に凝っていて、私たちの家系を1200年代まで遡らせたんです。
Amal Hussein: わあ。
Amelia Wattenberger: でも、由来はドイツのヴァッテンベルク州だったような...。
Amal Hussein: それはすごいですね。ああ、僕の両親はソマリア人で、僕の家系をたどると27人の祖先がいるとか、そんな感じなんだ...。クレイジーだよ。とにかく、血統の話はさておき、ウェブの血統、ウェブの歴史、ウェブの歴史にとって本当に重要な人物の話をしましょう... リッチ・ハリス ようこそ リッチ こんにちは
Rich Harris: どうも、お招きいただきありがとうございます。
Amal Hussein: あなたのことをどう紹介したらいいかわからないんだけど、あなたはすべてをより良くするJavaScriptのエンジニアで、ジャーナリストでもあるんだ...。オープンソーサーであり、教師であり、教育者であり、クリエイターであり......。そして今はフルタイムでオープンソースに取り組んでいるようです。そうそう、知らない人のために、あなたについて少し教えてください... そして、ようこそ。
Rich Harris: [04:22] そうですね。私はリッチです。3週間前からVercelで働いています。入社したのは、Svelteをフルタイムで担当するためです。Svelteは、私が過去5年間開発してきたプロジェクトです。今月で5回目の誕生日を迎えます -- 実は、違うんです。先月です。今、12月です。時が経つのは早いものです。
そして、Vercelに入社する前は、ずっと報道の現場でキャリアを積んできました。ジャーナリストとしての訓練を受け、The GuardianとNew York Timesのインタラクティブ・グラフィックス部門で働きました。
その過程で、オープンソースを少しばかり手がけました。モジュール・バンドラーであるRollupを開発した人物として私を知っている人もいます。Rollupプロジェクトを設定しなければならないたびに、私の名前を呪うのです。
Amal Hussein: いいんです、リッチ、あなたは先人のおかげで成り立っているのですから......。そして、Rollupは確かに針を押してきたと言えるでしょう。[笑う]だからすごいんだ リッチ 少なくとも私は、あなたがクラス最高のものを作る人だという評判を得たような気がします。例えばWebPackのようなバンドルは、クラス最高のものと考えられていて、ユースケースによっては今でもそうかもしれません。でも、そういうツールを使って、別の制約にうまく対応できるようなものを作っているんです...。特に、オープンウェブにとって良い制約だと思うんですが...。どうすればオープンスタンダードをうまく使えるか、どうすればより少ないJavaScriptしか使わないか、どうすればよりパフォーマンスの高いWebエクスペリエンスを作れるか、といったようなことです。Svelteは、それと同じような流れにあると思います。オープンウェブにとって良いことです。
では、Svelteの着想や原点について、少しお話しいただけますか？3年前にChangelogに掲載されましたね。1月30日です。そのエピソードにリンクしておきます。素晴らしいエピソードです... しかし、私はあなたが私たちのために起源物語を要約することができれば興味があります。
Rich Harris: 確かに試せますね。Svelteは、私がJavaScriptを書き始めた10年前から考えていたことの集大成のようなもので、インタラクティブな記事を作ろうとしていたんです。New York Timesなどで見られるような、インタラクティブな記事を書こうとしていました。私は超初心者プログラマーでしたから......。それでわかったのは、これは難しいということです。今でいうところのステートドリブン、コンポーネントドリブンのユーザーインターフェイスを実現するためのツールが、あまりなかったんです。
それで、どんなツールがあれば生活が楽になるか、空想するようになったんです......。そして、空想するのをやめて、作り始めたんです。数年間、私はRactiveというプロジェクトを管理していましたが、これは私自身の痒いところに手が届くようなものでした。
その後、プログラマーとしてもう少し経験を積み、これらの問題のいくつかを解決するさまざまな方法を意識し始めた後、2016年にSvelteになったアイデアが根付きました。Svelteはそのアイデアの延長線上にあるもので、「ウェブ上でインタラクティブなコンテンツをできるだけ簡単に作成するにはどうすればいいか」というものですが、前身のプロジェクトよりも少し洗練された考え方で、非常に小さなJavaScriptバンドルで、非常にパフォーマンスの高いユーザー体験を実現する方法を組み合わせています。
そうして始まったのが......。その後、ウェブ開発に関するより包括的なアイデアに発展していきました。数年前、私たちはフレームワークをデザインしているのではなく、ひとつの言語をデザインしているのだと気づきました。ユーザーインターフェイスを表現するための言語...。SvelteKitはメタフレームワークで、コンポーネントフレームワークの部分だけでなく、ウェブアプリケーションを隅から隅まで構築する方法について私たちが考えているものです。その周辺にあるライブラリはすべて、「私たちはウェブ開発の問題についてこう考えています」というものです。
Amelia Wattenberger: [07:56] 特にNew York Timesのような派手なグラフィックを扱うニュースルームからは、良いツールがたくさん出てくるような気がします。何か秘密のソースがあるのでしょうか。それとも、これらの素晴らしいツールを生み出す条件とは何でしょうか？
Rich Harris: 条件はとても重要だと思います。いくつか例を挙げると...。New York Timesのグラフィック部門、私はしばらくそこに所属していました。その前は、Jeremy Ashkenasがグラフィック部にいて、Timesで他の仕事もしていました...。そして、彼がBackboneを作り、Underscoreを作り、CoffeeScriptを作った...。これらは、JavaScriptのエコシステムに大きな影響を与えました。特にデータビズの分野では、Mike BostockがThe New York Timesのグラフィック部門にいたときに、非常に大きくD3を作りました。ほかにもいろいろな例があります。Gregor Aischは、本当にクールなオープンソースをたくさん作っていて、彼はその部門のメンバーでした...。
私の考えでは、このようなことが起こるのは、ニュースルームで物を作るときは、さまざまな理由から、より主流のエンジニアリングよりも制約が少しばかり厳しくなるからです。その1つは、ニュースサイクルの中で仕事をしていることです。ニュースのスピードに合わせ、Babelコンフィグなどをいじくりまわしている暇はないのです。とにかく出荷しなければならないのです。そのため、できるだけ分かりやすいツールに強いバイアスがかかっているのです...。
Amal Hussein: 障壁が低いような…
Rich Harris: そうですね。そしてそれは、裏を返せば......。ニュースルームでこうしたツールを使っている人の多くは、JavaScriptのロックスターであるニンジャではなく、自分の仕事をよりよくするためにJavaScriptを学んだ人たちなのですから。ですから、不必要に学習曲線が急なツールや、付随する複雑さが多いツールは、成功しない傾向にあります。
その結果、小さくても高速でリッチなアプリケーションを短時間で開発するための問題を解決できれば、ウェブ開発者がより広い範囲で直面する問題の多くを解決できたようなものだとわかりました。
そのため、D3はニュースルームの外でも確実に成功し、UnderscoreとBackboneが引き継ぎました...。今となっては不思議な話ですが、その昔、UnderscoreとBackboneは、CoffeeScriptと同様にウェブ開発のあり方を完全に変えました。ES6に道を譲ったのです。
Svelteは、ニュースルームの外でも多くの人に利用されています。Svelteは、もともとそのために作られたものとはかけ離れた、あらゆる種類の異なる文脈で使用されています。これは、ニュースルームのケースを解決することで、ウェブ開発をより広い範囲で解決できたからだと思います。
Amal Hussein: そうですね。ニュースはオープンウェブファーストですからね。それが健全なイノベーションの原動力になっていると思いますが、同時に、eコマースもニュースサイトも、多くのAPIやウェブのリッチさを本当によく活用しているように感じます。SEOを考え、画像を考え、コンテンツ管理を考え、スタイリングを考え、パフォーマンスを考え、サードパーティーのコンテンツを埋め込む......。このように、たくさんのことがあり、そのすべてが、まるで印刷したてのように、あなたに届けられるのです。このようなスペースから、どれだけのクリエイティビティが生み出されたかを聞くのは、本当に興味深いことです。
そして、それを少しずらすと......。それで、あなたはNew York Timesから移って、フルタイムの仕事をするようになり、より純粋にオープンソースプロジェクトに集中するようになったんでしょう。私にとってVercelは......すごく魅力的な人が部屋に入ってきたとき、Svelteは同じ部屋に入ってきたもうひとりのすごく魅力的な人のような気がして、その2人がお互いを見つけて誘い合う、そんな感じです......そんな感じです。VercelとSvelteは理にかなった結婚だと思います。なぜなら、Vercelの核心は、パフォーマンスの高いウェブ体験やターンキー開発者体験を本当に推進していることであり、Svelteは同じことを別の角度から取り組んでいるように感じるのです。
[12:01] では、Vercelのストーリーと、プロジェクトに対する彼らのサポートについて教えてください。
Rich Harris: Vercelは、ウェブをより高性能にし、またターンキーにしようとしている場所であるというお話は、まさに正鵠を射ていると思います。私がVercelに本拠地を置いているのは、そのためだと思います。
Amal Hussein: Vercelの電話番号を知っているようなものではないのですか？あなたは魅力的な人だから他の人と知り合おうとしてるんでしょう、冗談よ [笑う]
Rich Harris: 魅力的な人の話をするならば、Guillermoが僕のDMに紛れ込んできた数ヶ月後に起こったことなんだ、だから......。
Amal Hussein: おやおや、これはこれは...。 [笑う] 陰謀は深まるばかり...。
Rich Harris: そうですね。VercelとSvelteは、ウェブ開発をいかに民主化するか、しかしユーザーエクスペリエンスを損なわないようにするかということに非常に関心を寄せています。明らかにVercelは、より広範な意味でこの問題に取り組んでいます。Svelteは、純粋にフロントエンドのオーサリングにフォーカスしています......。しかし、このような哲学的な整合性があるのです。VercelがSvelteのようなフレームワークに投資するのは、理にかなっていると思います。Svelteを使用している顧客もいますし、SvelteKitとNextの間には常に相互作用がありますから。
少なくとも私が理解しているVercel側の希望は、Svelteがより良いフレームワークになるよう投資することで、Vercelの顧客にとっても、Web全体にとっても良いことです。ここ数年、私にとってSvelteの開発を阻んできた最大の要因は、時間を割くことができないことだったのですが、それが解決されたのですから、私としてもまったく納得がいきます。
だから、この1年で何ができるか、とても楽観的に考えているんだ...。そして、それはすでに配当として実を結び始めています。SvelteKitについては、1.0に向けて着実に前進していますが、フルタイムでこのようなことに取り組む人がいないと、本当に大変なんです。
Amelia Wattenberger: SvelteKit 1.0以外で、ロードマップの中で最も楽しみにしていることは何ですか？
Rich Harris: 長いリストがあるのですが......。ロードマップという言葉を使うのはためらわれるのですが、それは、何が優先されるべきかを実際に見極めて、それにリソースを割くことを決めたという意味だからです。今のところ、どちらかというとウィッシュリストのようなもので、私たちが話していることのいくつかは -- 文脈的には、Svelteの一部、つまりSvelteの主要部分は、コンパイラだと思います......。宣言的なコンポーネントコードを、基本的には命令的なJavaScriptと同等なものに変換してくれます。これは非常にうまく機能していて、ほとんどの場合、小さなバンドルが得られます。でも、数が多くてコード分割をしない場合、何らかの理由で、生成されるJavaScriptはコンポーネントのソースコードのサイズより早く大きくなってしまいます。そして場合によっては、例えばReactバンドルよりもSvelteバンドルの方が大きくなるという変曲点にぶつかることがあります。頻繁に起こることではありませんが、起こり得ることです。ちなみに、エラー境界のようなものを実装する能力も得られるかもしれません。
Amal Hussein: ビルド時とか？実行時のエラーバウンド？
Rich Harris: そうです。
Amal Hussein: なるほど、興味深いですね。
Rich Harris: というのが、今のところ浮かんでいるアイデアです。あと、Vercelは今、Rustに超熱心で...。だから、「Rustを学ぶべきか？SvelteのコンパイラをRustで書き直すべきか? もしかしたら、それはとんでもない考えかもしれませんが、少なくとも調査する価値はあると思うのです。
他には......？モーションとトランジションがもう少し統一されていれば、フレームワークでどのように見えるかについて、たくさんの大きなアイデアを持っています...。これは、Svelteの得意とするところです。エレメントがステージに入り、ステージを去るときのトランジションは宣言的に行われますが、それをさらに推し進めて、異なるページレイアウト間の補間など、本当に楽しいことができると思うのですが......。
Amelia Wattenberger: Svelteで一番気に入っているのは、トランジションです。ReactとSvelteのプロジェクトを行ったり来たりしていますが、アニメートインと言えばアニメートしてくれるし、ライブラリを引っ張ってきたり、コードを書き足したりする必要がないんです...。とてもいいことだと思います。
Rich Harris: [16:06] そうですね。そしてReactチームは時折、Reactでそのようなことをより簡単にすることについて話しています... 例えば、要素のアンマウントを延期できるようなAPIを追加するとか...。でもそれはすごく大変なことで、積極的に優先順位をつけなければならないことです... というのも、このトランジションを構築する過程で学んだことのひとつに、フレームワークを構築する際に最優先で考慮すべきことであり、そこに深く結びついている、ということがあります。ですから、どうなるかはわかりませんが......。でも、このアイデアをさらに発展させることは可能だと思います。いろいろなことがありますが、どれもまだ確約はできませんが、2022年にはすべて検討するつもりです。
Amal Hussein: Vercelの人たちは、「私たちはこの製品の価値を理解し、パフォーマンスを重視しています」という意味で、公式スポンサーになってくれているようなもので、いろいろな意味で、本当にお金をかけてくれていると感じます。これは素晴らしいことです。改めて、この機会におめでとうございます。私たちは皆、彼らのスポンサーシップから恩恵を受けることを望んでいます。これこそがオープンソースの美点であり、私たちのコードのスタジアム効果なのです。
SvelteKitの話を少ししましたが......ちょっと興味があります。それは、よりフルフィーチャリングであるという、非常に意図的な決定です。Reactのようなライブラリは、「私たちはUIライブラリであり、フレームワークであるとは考えていません」と明言しています。一方、AngularやEmberのようなツールは、どのように使うべきかについて、より明確な意見を持ち、あらゆるベルやホイッスルが付属しています。Angularは、個人的には、いろいろな意味で企業チームに最適だと思います。この種の規約が組み込まれていると、大人数をコントロールするのが容易になります。Svelteは、その中間のような気がします。Angularほど厳密ではありませんが、Reactのような、曲げようと思えばいくらでも曲げられるツールを使うよりは、潜在的な落とし穴は少ないと思います。
では、その決定について少しお話しいただけますか。どんな制約があったのか、また、どのようにして、人々に...と思わせるような幸せなバランスを見つけたのか。MITのScratchチームには、「高い天井、広い壁、低い床」という素晴らしい例えがあります。低い床とは、新しい人が入ってきて使いやすいという意味で、広い壁とは、いろいろなことができるという意味で、高い天井とは、エキスパートユーザーを止めないという意味で、クレイジーでハムになりたい人、複雑なものを作りたい人、そういう人ができるようにするということなんです。
ですから、初心者にも使いやすく、ガードレールにもなり、専門家にも使えるという、これらすべての条件を満たすようなインターフェースやAPIを設計するのは非常に難しいことなのです。では、そのような制約や判断のいくつかをお話しいただけますか？
Rich Harris: 私たちの指針は、「これは、フレームワークに入れる意味があるほど多くの人が必要とするものなのか」ということです。たとえば、これまでウェブ上で作られてきたすべてのアプリは、ごくわずかな例外を除いて、CSSを必要とします。ですから、もしフレームワークが、プロジェクトにスタイルを含めるための祝福された方法を含んでいなければ、そのツールのユーザーに、膨大な仕事の塊を残していることになります。
これは、より多くのフレームワークが採用しないことに少し驚いていることです。Vueは、CSSをアプリに取り込む方法について明らかに意見を持っているフレームワークですが、Reactや、Reactに似たフレームワークはすべて、それを開発者に任せているようなものです。私には、それが責任放棄のように感じられるのです。Reactが主張するのは、この問題について意図的に骨抜きにし、コミュニティに独自の規約を作らせることで、問題に取り組む人を増やし、最高のアイデアが表面に出てきて、それを徐々に採用することができる、というものです。
[20:07] でもその間、ユーザーには多くの混乱と負担を強いている。特にSvelteが作られた環境では、そんなことをやっている暇はないんです。フレームワークの中で、スタイリングが第一級の関心事であることは、まったく理にかなっています。先ほどお話したトランジションについても同様です。あらゆる種類の動き、たとえばユーザーインターフェイスにスプリングフィジックスを導入したい場合、Svelteパッケージの内部から来るインポートで、Svelteでそれを行うことができます。これは、フレームワークを使ったときに得られるものの一部として考えてもらいたいからで、私たちが解決すべき問題として提供するのではありません。
しかし、歴史的に見ると、SvelteはReactやVueのようなコンポーネントフレームワークであり、AngularやEmberはアプリフレームワークのようなものだと考えています。特にNew York Timesでは、SvelteはGoogle Docsを中心としたワークフローと統合しなければならないという、非常に難解な要件がありました。そのため、さまざまなユースケースに対応できるような、独自のアプリケーションフレームワークを用意することができませんでした。ですから、Svelteは、独自のサーバーサイドレンダリングソリューションや、独自のビルドツール、プラグインなど、好きなように使えるコンパイラであることが、常に重要なポイントでした。完全にフリーフォームなんです。
しかし、これには明らかにギャップがあります。初めてSvelteに来た人は、「これを使って一体どうやってアプリを作ればいいんだ？これに対する私たちの回答は、歴史的に見ると少し精彩を欠いたものでした。一方、AngularやEmberでは、最初から「こうやってアプリを作るんだよ」と教えてくれます。もちろん問題は、非Angularアプリの中でAngularコンポーネントを使うことはできませんし、非Emberアプリの中でEmberコンポーネントを使うことはできませんが...。つまり、もしかしたらできるかもしれません。ドキュメントの奥底に、その方法があるのかもしれませんが、そうすることは非常に嫌がられます。これは本当にマイナス面だと思います。SvelteKitは、エキスパート・ユーザーが必要とする柔軟性を排除することなく、「じゃあ、いったいどうやってアプリを書き始めればいいのか」という問題を解決するものなのです。
SvelteKitは低床で、Svelteは（おそらく）高天井......というわけです。どっちが高い天井でどっちが広い壁だったか思い出せないけど...。
Amal Hussein: そうですね、広い壁はいろいろなことができる、高い天井は無限の複雑さ、夢中になれる、垂直方向に複雑なことができる、という感じです。これって、意味があるんでしょうか？
Rich Harris: そうですね、ええ。
Amal Hussein: そしてこの帰属は、MITスクラッチチームによるものです。番組ノートに、彼らがそのことについて語った記事へのリンクを貼っておきますね。Scratchは子ども向けのプログラミング言語で、皮肉にも現在はJavaScriptで書かれています...。私はBocoupという会社で働いていて、MITのScratchチームがFlashから完全に書き直すのを手伝ったんです。Flashベースのアプリケーションだったのですが、それをJavaScriptに変換し、彼らがJavaScriptに変換するのを手伝ったのです。そして、実際にReactを使っています。オープン ウェブで最も複雑なReactアプリケーションの1つですが、美しく、パフォーマンスも高く、Bocoupの素敵なエンジニアのおかげで、高速化する方法について多くの考察がなされています...。間違いなくチェックする価値があります。
さて、リッチ、ちょっと休憩しましょうか。比較の話もしたいし コミュニティの話も... たくさんあるんだ 短いメッセージの後、すぐに戻ってきます。
Break: [23:40]
Amal Hussein: なるほど...。Rich、SvelteとSvelteKitに関する素晴らしい背景と文脈をありがとうございました。このインタフェースと制約の背後にある意思決定のいくつかを知ることができ、本当によかったです。
先ほど、Svelteは主要なフレームワークの1つと考えられているというお話がありましたが、それについて少しお聞きしたいのです。本当にSvelteですか？"本当にSvelte "ではなく、"本当にRich? "と言いたいです。[笑う]これからはスベルテと呼ぶよ で、本当にリッチ？スベルテは本当にメジャーなフレームワークと言えるのか？なぜなら... いつも時間がかかるとは限らないが、JavaScriptのUIフレームワークが、生産可能で安定し、よくサポートされているとみなされる転換点に達するには、しばらく時間がかかるからだ。このプロジェクトはVercelから資金提供を受けているんですね、すごいですね。でも、他に誰が使っているのでしょう？5年前からあるのですが、「主流」になるまでに5年かかっているようなので、採用の指標をいくつか教えていただけないでしょうか。
Rich Harris: 今、主流と言えるかどうかわかりませんが......。でも、現時点ではかなりのマインドシェアを持っていると思います。ReactやVueほど広く使われてはいませんが、多くの開発者がその名前を聞いたことがあり、多くの開発者が試してみたいと思っています。npmのダウンロード数が伸びないのは、長い間、専任のメンテナがサポートしていないものを使おうとすることに、企業が非常に抵抗があったからでしょう。私や同僚がSvelteを使ってプロジェクトを構築したいのに、プロジェクトマネージャーやCTOが「これは誰かの週末プロジェクトだからダメだ」と言う、というようなことをよく耳にします。それは長い間、事実ではありませんでした。私たちのコアチームはとてもアクティブです。
Amal Hussein: みんな夜や週末に働いているのですか？そうか、違うのか... [笑い声]
Rich Harris: フルタイムのメンテナはまだ私一人ですが、かなり定期的にプロジェクトに携わっている人がたくさんいます。
Amal Hussein: そうか。すごいですね。
Rich Harris: しかし、Vercelという後ろ盾ができたことで、"実は、その判断は再考できる "という声が聞こえ始めています。具体的にはnpmの数字ですが、1週間に20万ダウンロードと、決して大きな数字ではありませんが、今年に入ってから倍増していて......。この間計算したら、このまま毎年倍増し続けたら、2037年には地球上のすべての人がSvelteをダウンロードしていることになる...。 [笑い声] だから、世界制覇までそんなに遠くない。
Svelteがメジャーなフレームワークのひとつであるというのは、Svelteの決定に他のフレームワークが影響を受けているケースが少なからずあるということです......。新しいクラウドのようなものが発表されると、「その上でSvelteのアプリを構築する方法はこちらです」と言うことがよくあります。これは、導入時のドキュメントに最初に記載されることの一つです。Cloudflare Pagesがリリースされたばかりですが、彼らはSvelteKitをCloudflare Pagesサイトの構築方法の例として使用しました。このような認知度に達したら、たとえ規模が小さくても、主要なフレームワークの1つとみなすのが妥当だと思います。
[27:48] そして、これからも成長し続けるという確信があります。私たちは、かなり高い満足度を得ています。最新の「State of JavaScript」調査では「Most satisfied」という結果が出ていますし、「Stack Overflow」の今年の開発者調査でも、最も愛されているフレームワークでした...。ですから、今後も採用が進むのは当然のことです。しかし、同時に、採用は私たちがこれを行う理由ではありません。採用は、最適化を図るための指標ではありません。あくまでも、正しい最適化を行っているかどうかを判断するための指標です。
Amelia Wattenberger: JavaScriptのフレームワークを見ると、人々がどれだけそれを好み、どれだけそれを使っているかを図にすると、ハイプ・サイクルのようなものがあります。どれだけ好きかをX軸に、どれだけ使っているかをY軸に。普通は、右肩上がりになっていくんですが...。だから、本当に好きな人がいるときは、間違いなく使用率が上がってくるし、逆に下がっていくのが目に見えている。結局、多くの開発者が仕事で使わざるを得なくなり、それが嫌になって使わなくなるんです。 [笑い声]
Rich Harris: 100％そうなりますね。おそらく、Svelteではもう始まっていることだと思います。最も満足した」「最も気に入った」という評価は、現在Svelteを使っている人たちが、Svelteを選んだという事実によってもたらされたものなのです。テンプレート駆動型のフレームワークであることや、他のフレームワークとは異なるSvelteの決定事項について、すでに理解されているのです。しかし、いつかはそうでなくなる時が来るでしょう。
だから、来年も同じ評価を得られるとは思っていませんが、Svelteを使いたい人がSvelteを使い続け、Svelteを使わざるを得ない人がSvelteに耐えられるのであれば、大丈夫だと思うんです。
Amal Hussein: 私がSvelteに興奮した理由のひとつが、今になって思い出されるのですが...。これはFacebookやMicrosoft、Googleといった10億ドル、20億ドルの企業がスポンサーになっていないプロジェクトなんだ」と思ったからです。今、JavaScriptのオープンソースコミュニティの状況を見ると、最も早く採用され、広く普及したプロジェクトは何かというと、企業は「これに取り組むためにお金をもらっている人はいるのか」というような指標を使っているように感じます。というような指標を使っています。
RushのようなプロジェクトやLernaのようなプロジェクトを見て、Lernaがどれだけ苦労して数字を上げたかを見てみると......。Lernaはモノレポの管理ツールでしょ...。Rushもそうですが、Rushはマイクロソフトから出てきたもので、ショーノートにリンクを貼っておきます。でも、Rushが登場したことで、人々は「おお、素晴らしい！」と思ったような気がします。会社が支援するLernaの代替品だ」と。企業の支援を受けているソフトウェアが悪いわけではありませんから、まったく問題ありません。すべて良しです。Vercelも同じようなことをやっています。でも、オープンソースやコミュニティ、オープンなガバナンスの精神は、このようなプロジェクトでは失われつつあるように思います。Vercelの場合、あなたとの関係は少し違うように思います。あなたのプロジェクトであることに変わりはありませんが、ガバナンスやその他諸々のことが、非常に草の根的で、ライブラリを利用する人々の影響を受けるように開かれており、その点がReactとは大きく異なっていると思います。数週間前、ReactチームのリーダーであるSophie Alpertと素晴らしい会話をしました。彼女は、Reactにおけるオープンなガバナンスをめぐる課題について話していて、「これは絶対にチームのコアショーになる。特に、多くの賢い人たちがいて、悪いことばかりではない意見を持っている場合、コミュニティ内に摩擦が生じることがあります。
Rich Harris: そうですね、難しいですね...。Reactのようなプロジェクトは、実にさまざまなプロジェクトに使われます。すべてのフロントエンド・フレームワークに言えることですが、さまざまな決定がなされることになります。私たちは常に、可能な限り、物事を絶対的なカオスに陥らせることなく、この合意とコミュニティ主導のプロジェクトであることを誇りとしてきました。また、コアチームは非常に多様性に富んでいます。さまざまな経歴を持つ人が集まっていますし...。
Amal Hussein: おそらく世界中にあるんでしょうね？地理的に離れている人たちもいるはずです。
Rich Harris: とても国際的なプロジェクトです。
Amal Hussein: [31:56] ええ。ウェブにとって素晴らしいことです。私にとっての使命は、ウェブ用に文章を書く人の数を増やし、割合を変えて、ウェブを使う人たちをより反映できるようにすることです、わかりますか？つまり、ウェブを利用する人たちをより反映した文章を書くようにすることです。ですから、そのようなお話が聞けて本当にうれしいです。
Rich Harris: うん。そして、それは実際のところ、どのような形で現れるのでしょうか。SvelteやSvelteKitの機能について議論するとき、多くの場合、まったく異なる経験をしてきた人たちが行き来し、異なる方法で決定事項について話すことができます。そうすることで、同じような経験をしてきた人たちだけのチームよりも、プロジェクトはずっと強くなります。
Amal Hussein: はい。それ自体もホットな話題ですが、それはまた別の番組で......。でも、ありがとうございました。そう言ってもらえると本当に嬉しいです。これからも、多様で多彩な貢献のレベルを育んでいってください。それはウェブにとって重要なことです...
そこで、なぜSvelteなのか、具体的な話を少ししてみたいのですが......。この話を聞いている皆さん、APIは廃止されますが、人間は廃止されません。このツールとあのツールの比較について話しているとき、私たちは客観的な視点から話をしているのであって、個人的な話でもなければ、恨み節でも炎上でも何でもありません。私たちは、エンジニアとして客観的な会話をしているだけです。ですから、このコーナーの残りの部分には、そのような警告や文脈を前置きしておきたいと思うのです。
というわけで、リッチ教えてください -- たとえば、Reactだけを取り上げるとしたら......。Reactを選ぶとしたら......やっぱりReactでしょう？なぜReactではなくSvelteなのでしょうか？新しいプロジェクトを始めるなら、ReactではなくSvelteで始めるべき理由は何でしょうか？
Rich Harris: 簡単に言えば、より速く出荷できるようになるということです。それが私たちの考えです。もちろん、これには注意点もあります。すでにReactの経験がある人がSvelteの使い方を学ぶには、少し時間がかかるでしょう。しかし、全体として、Svelteの主張は、私たちが取っている設計上の決定、そして基礎的な設計上の決定、つまり、私たちは本質的にコンポーネント言語を設計しているのであって、ユーザーインターフェースのセマンティクスを根本的に不向きな言語（つまりJavaScript）で表現しようとするのとは対照的な、コンパイラ中心の考え方を持っているということです。
この点については、多くの人が猛反対するでしょうが、私の観測では、たとえばReactコンポーネントをSvelteコンポーネントに変換すると、書かなければならないコードのバイト数が約40％小さくなります。物理的に書く量が減るので、コンポーネントを書くスピードが上がるのはもちろんですが、読みやすさも向上します。少ないコードは、多いコードよりも読みやすいのです。
Amal Hussein: また、メンテナンス性にも優れている。
Rich Harris: より保守しやすいです。
Amal Hussein: 変更も簡単ですよね？
Rich Harris: より簡単に変更できる...
Amal Hussein: よくお聞きする言葉ですが、私自身は「変化に最適化する」という言葉を新しい信条としています。そうですね、少ないコードの方が圧倒的に変更しやすいですね。
Rich Harris: ええ、その通りです。膨大な量ではありませんが、あるコード量に対してどれだけのバグを書くかについての研究も行われていて、書いたコード量とアプリのバグ数の関係は、どの言語でも基本的に同じであることが判明しました...。しかし、その関係はコード量に対して超直線的です。10,000行のアプリがあれば、1,000行のアプリの10倍以上のバグが発生することになるのです。
ですから、Perlのようなちんぷんかんぷんなコードにならずに、できるだけ簡潔にコードを書くことができれば、一般に、アプリケーションはより堅牢になるはずです。これが大きな主張です。Svelteについては、以前はまったく別の観点から考えていたので、少し変わりました。というのも、当時はデスクトップのフレームワークが主流だった時代から、モバイルがウェブで物を書く上でより重要な場所になりつつあった時期でした。今でもそうですが、JavaScriptを大量に出荷することは、最も緊急な問題でした。
[36:19] Svelteが最初に目指したのは、バンドルサイズを小さくすることだったのです。また、重い仮想DOMの機械を使わずにバニラJavaScriptにコンパイルするので、更新も速くなります。
Svelteから連想されるのは、小さくて速いということで、それがSvelteと呼ばれる所以です。しかし、最近では、書いているコードについてどのように考えるかという点で、より重要視されています。
Amelia Wattenberger: さて、これを解決してくれるかな...。同僚は皆、私ができることならSvelteで新しいプロジェクトを始めたいと思っていることを知っています。私たちは本当に素早くプロトタイプを作ることに集中しているので、それは素晴らしいことです。でも問題は、Reactを使う場合、アクセシブルなコンポーネントに使えるライブラリが100万個くらいあって、それを本当に簡単に放り込めることです... その豊富なコンポーネントを構築するには、長い時間と大きなコミュニティが必要なので、Svelteではどうすることもできませんが...。でも、それが私の最大の悩みの種でもあります。
Rich Harris: 個人的にはあまり使いませんが、私が作っているアプリは通常必要ないからです。しかし、世の中にはコンポーネントライブラリがあります。特にどれがいいとは言えませんが、実際に存在するのです。
SvelteKitのリリースによって、本当に高品質のコンポーネント・ライブラリが簡単に構築できるようになることを期待しています。SvelteKitは、アプリケーションを作るためのフレームワークであることに加えて、コンポーネント・ライブラリを作るためのフレームワークでもあるからです。これまでいくつかのライブラリに使ってきましたが、これまで使ってきたどのライブラリよりも、ライブラリを構築するためのワークフローがずっとずっと素晴らしいのです。SvelteKitのリリースによって、コンポーネントライブラリが爆発的に増えることを期待しています。数カ月後に、それが実現されているかどうかを確認したいと思いますが......。この種の問題は、時間が経てば解決するものだと思います。
ですから、すぐに何かを作りたいと思っていて、すぐに使えるコンポーネント・ライブラリのセットが欲しいのであれば、Reactはおそらく最適な方法でしょう。しかし、これは基礎的な技術の選択ではありません。これは、たまたま今そうなっていて、将来的にはそうでなくなる可能性があるものです。つまり、タイムスケールにもよりますし、自分で何かを作りたいという意欲にもよりますし、技術をどう評価するかにもよります。
Amal Hussein: アメリアが指摘するエコシステムの問題は、まさに現実的なものです...。テーブルライブラリやマテリアルUIライブラリが必要で、少なくとも他のエコシステムと同じペースで作業を続けるためには、それらすべてのベルやホイッスルが必要なのです。だから、妥協したくないんですね。しかし、コミュニティとして、どの時点で、HTML、CSS、JavaScriptなどのウェブプリミティブを本当に活用し、すべてのライブラリが使用できるアコーディオンウィジェットを一度に作成し始めるのか、気になるところではあります。なぜなら、React、Angular、Ember、Backbone、これらすべてのライブラリは、結局のところ、ウェブ・プリミティブに出力しているだけだからです。これを一度書いてしまえば、あとは好きな言語やフレームワークにインポートできるようになりませんか？もしあなたがこのような方法でこの製品を使いたいのなら、それは素晴らしいことです。
結局のところ、まったく新しいエコシステムを作り、解決した問題をまた別のインターフェースで解決するというのは、馬鹿げていると思うのです。つまり、私たちがこれをやり直すというのは、あなたにとって奇妙なことではないでしょうか？
Rich Harris: まるで、私にWeb Componentsの辛口な感想を言わせようとしているようですね。
Amal Hussein: [40:11] Web Componentsの話をしたかったのですが、「目くじらを立てるのはやめよう」ということになり、だってみんな目くじらを立てるだけですから...。でも「これはCustom Elementでいいのでは？」と思っています。本当に、気になるんです。なぜなら、これはWeb APIであり、大多数のブラウザがプラットフォーム上でネイティブにサポートしており、かなり良好だからです。だから、ちょっと興味があるんですが、それについてどうお考えですか？
Rich Harris: フレームワークごとに書き直さなければいけないという問題は、大げさに言われがちですが......。なぜなら、フレームワークの数はそれほど多くないからです。3つのフレームワークで何かを書き直さなければならないのは、扱いやすい問題ですが、1000のフレームワークで書き直さなければならないのは、そうではありません。しかし、私たちが置かれている状況は、そうではありません。
ですから、私はまず、「すべてのフレームワークでこれを書き直さなければならない」という考え方が根本的な問題であることを、強く主張したいと思います。しかし、ウェブには非常にユニークな制約があり、残念ながら、この分野に長く携わってきた私の意見では、ウェブコンポーネントはそれを解決するものではありません。
Amal Hussein: 確かにAPIはDXを満たせませんでしたし -- そう、Webコンポーネントのユーザビリティには、開発者と相容れない部分があるんです。開発者が置かれている状況や、人々が最新のWebアプリケーションをどのように書いているか、Web Componentsを大規模に動作させるために必要なこととは、確かに食い違いがありますね。そこには隔たりがあります。
でも、私は......もしかしたら、あなたの言うとおり、それほど大きな問題ではないかもしれない、と感じています。ある週をSvelteのエコシステムウィークにして、みんながこれとこれとを書き換える必要があるコンポーネントを選んで、それがSvelteでドーンと出てくる、というようなハッカソンが必要な気がするんです。
解決済みの問題にいくら頭を使っても無駄だというのは、ちょっとおかしいと思います。解決済みの問題を、別の色で......。ウェブ開発者は地球上で最も賢い人たちだと思うのですが、それは脳みその時間の使い方として間違っているような気がします。新しいボタンの種類を作ることは、とにかく私にとっては良い脳内時間の使い方ではありません。というのが、私の率直な感想ですが......。
Rich Harris: つまり、あなたは間違ってはいませんが、最終的には、もしこれらのことが複数のフレームワークで書き換えているほど重要なことであれば、それはそもそもプラットフォームに属することなのかもしれません。
Amal Hussein: そうです。
Rich Harris: 当時、私がWeb Componentsに期待していたのは、後に舗装されることになる牛の道を作ることができるようになることでした。しかし、さまざまな理由から、私たちはそのような牛の道を敷き詰めることはしませんでした。そのため、JavaScriptで動作しないコンポーネントの記述方法が残ってしまい、プログレッシブ・エンハンスメントや他のすべてのものにとって致命的なものとなっています。
Web Componentsのことを考えるのはもううんざりで、自分が作りたいアプリを作るのがどれだけ大変か...。もう考えるのをやめたんだ。Svelteを使い、Custom Elements じゃないものをターゲットにして、楽しくやっていこうと思います。他の人がWeb Componentsで多くの問題を解決しようとするならば、それは素晴らしいことです。
Amal Hussein: [笑う] 問題点が違うんでしょう？
Rich Harris: まさに。
Amal Hussein: そうですね、別の問題で、ますます縮小している開発者グループも気にしているようですが......。ええ、ですから、その点を考慮して、私のユーモアに付き合ってくださって、本当にありがとうございます。あなたはその落とし穴を避けるために本当に良い仕事をした。リッチ、よくやった。
Break: [43:38]
Amal Hussein: リッチ、オープンソースコミュニティのホットな話題の第1弾を紹介していただき、ありがとうございました。まるで終わりのない物語のようです。実は、アメリア、今日この番組の準備をしていたのを覚えているかい？あなたがとても面白いことを言ったと思うのですが、それを共有したいですか？彼は、まるでホットテイクのような... [笑う]
Amelia Wattenberger: あ、実はSvelteのドキュメンタリーを撮っているんですよ、その話もできると思うんですけど...。
Rich Harris: ええ、できますよ。
Amelia Wattenberger: フィルムの機材を持って家に来てくれたんですが、これがなかなか威圧的で......。そして、準備万端整えて、「リッチ・ハリスについて説明できるか？」 [笑う] そして、「やれやれ...」という感じでした。知らないよ" 最初に出てきた言葉は「ホットテイクだけど ホットテイクじゃない」「理にかなってる」「もう一回やろう」っていう話になったんです。でも、それが僕の本音なんです。 [笑い声]
Rich Harris: ああ、確かにカメラを突きつけられて質問されるような感じは共感できますね。
Amelia Wattenberger: ああ、ひどい...。
Amal Hussein: そうですね まあ、あなたは確かにホットテイクが得意ですね。あと、フロアにガソリンが散乱しているときに、Twitterで試合を告知して、その試合を落とすというのもすごくうまい。そして、ブーン！という感じです。 [笑い声] 今日のTwitterはこれで終わり、か...？文字通り、3週間経った今でも、RichがJavaScriptについて非常に合理的な意見を述べたスレッドに「いいね」と言及されることがある。正直なところ、私は99% -- 100%の確率であなたに同意しています。でも、ええ、本当に、あなたは素晴らしいです。
というわけで、ホットトピックの続きです。Reactは、私がJavaScriptをもっと上手に使えるようになるために、ずっと使っているライブラリです。コミュニティとして長い間避けて通ってきたコンポーネントモデルを、民主化する手助けをしてくれました。だから、このライブラリがある種の前進を後押ししてくれたことに、とても感謝しています。しかし、パフォーマンスやその他の点で、Reactが停滞しているように感じられることもあります。私としては、Reactはさまざまなアプリケーションやプラットフォームに対応できる製品であり、それが成功の要因だと考えています。和解のアルゴリズムや仮想DOM、合成イベントなど、ウェブ上の他のプロジェクトには必ずしも見られない、余計なものが入っているんですが......。PreactやSvelteを見ればわかるように、仮想DOMも合成イベントも必要ないんです。極めて高いパフォーマンス、はるかに小さなバンドルサイズ......。しかし、Reactの制約として、多くのDOMツリーを出力してしまうことがあります。そのため、若干の肥大化が見られます。
[47:48] 数週間前に友人と交わした友好的な議論では「よし、その時点で、Webだけのために書いているなら、Reactはベストな選択ではないのかもしれない」と言っていいのでしょうか？私たちは同意したのですが、彼は「そうだ、もしあなたがWebのためだけに書いているなら、Reactはベストな選択ではない」というようなことを言いました。というのも、私が言いたかったのは、Reactは...例えば、私が2021年（あるいは2022年現在ほぼ）にウェブ向けのプロジェクトを始めるとしたら、Reactは選ばないだろう、ということなんです。選びませんね。かさばるという理由だけでです。私なら、できるだけJavaScriptを使わないで済むようなものを選びます。Reactは、ウェブ用に書くだけなら、必要以上にエンジンがかかるんです。Svelteはこの問題にどのように取り組んでいるのでしょうか？というのも、私にとっては、Svelteは今、非常にウェブファースト、ウェブオンリーであるように感じられるからです。モバイルの話はあるのでしょうか? マルチプラットフォームに関する制約に取り組んだことがありますか? なぜなら、もし私が会社で働いていて、上司にSvelteを採用させようとしたら、上司は「じゃあ、ネイティブのライブラリはないのか」と言うでしょう。それはどのように機能するのですか？SwiftやKotlinを書くために人を雇うのは嫌だ」と言うでしょう。
Rich Harris: ええ、この件に関してはいろいろと思うところがあります。前置きが長くなりましたが、私はメタル系の開発者ではありません。
Amal Hussein: そうですね。私もです。
Rich Harris: 気にするようなことではないのです。私はウェブ派なんです。ネイティブアプリが存在せず、モバイルデバイスのウェブが十分な能力を持ち、そのようなものから解放されるのであれば、私はとてもうれしいです。とはいえ、すでにReactのコードベースを持っていたり、ウェブ開発に慣れていたりすれば、iOSやAndroidで何かを作るのにReact-nativeが最も緊密に統合された方法であることは事実でしょう。
Svelteでネイティブアプリを構築できるようになるものがいくつかあります。Svelte Nativeというプロジェクトがあります。これは基本的にNativeScriptのラッパーで、モバイルプラットフォームをDOMのように見せるためのインターフェースのようなものです。これには、VueバージョンとSvelteバージョン、そしてバニラバージョンがあります。個人的には使ったことがないのですが、私が知る限りでは、かなり素晴らしい結果が出ています。
この分野では、他にもいくつかの試みが進行中です。最近知ったのですが、まだ公開されていないもので、Node GUIか何かの上に構築されているものだと思います。こういうのもいくつかあるんですよ。可能性はあります。プログレッシブWebアプリ（PWA）を提供すれば、それをネイティブアプリとしてバンドルして、デバイスのAPIにアクセスできるようにしてくれます。繰り返しになりますが、私はそれらを使ったことがないので、保証はできませんが、少なくとも表面上は、KotlinやSwiftの開発者を雇用せずにモバイルデバイスにデプロイするという問題を解決できるように思われます。
そして最後に、Svelteが将来的にこのようなことをネイティブにできるようになるのかどうかという問題があります。また、Svelteはウェブ専用であるという誤解があるようです。もちろん、ウェブが最優先です。私たちは、HTML、CSS、JavaScriptを基盤として構築されています。Svelteのコンポーネントは、HTMLのスーパーセットなのです。しかし、コンパイラは、コンポーネントをJavaScriptに変換するとき、2つの方法のいずれかを取ることができます。DOMをターゲットにしたコードを出力するか、サーバーサイドレンダリングをターゲットにしたコードを出力するか、です。これらは非常に異なるものです。コンパイラは、それぞれのケースで非常に異なる仕事をしています。
私たちが行っていないのは、この処理をプラグイン化し、APIで公開することです。しかし、それは可能です。コンパイラのための独自の出力装置を作ることができるようにすることはできます。これは私たちが時々話してきたことです。でも、優先順位や積極的に追求したいことというレベルには達していません。でも、できるかもしれません。そうすれば、Svelteでコマンドライン・インターフェイスを構築したり、Reactでできるような他のものを構築したりできるようになります。
Amal Hussein: プラットフォームにおけるメディアを開放するのです。アウトプットの間にパイプのようなものがあると、非常に興味深い方法で開放されます。でも、面白いのは......。
Rich Harris: Svelteがいつかもっとネイティブに対応する可能性はあります。今のところ、できます。もしかしたら注意点は......また、私はそんなに経験があるわけではないので、なんとも言えないのですが......。でも、ネイティブアプリを作るための実戦的なソリューションが欲しいなら、React Nativeが今のところベストかもしれませんね。
Amal Hussein: [52:09] それは面白いですね。そう言ってもらえるとうれしいです。1年後、あなたの答えがどうなっているのか、とても気になります...。なぜなら、私はJavaScriptのエコシステムが指数関数的な複利の性質を持つことを知っているので、誰かが明日にでも解決策を用意してくれるかもしれないからです。だから、それがどうなるのか興味があるんです。でも、その点については、ご意見をありがとうございました。
アメリアと私は、Svelteのコミュニティの話を聞いて、とても興奮しましたね。コミュニティについて語らずには、この番組を終えることはできません。オープンソースの通貨のようなもので、私たちが行うことすべての通貨なのです。Svelteのコミュニティは非常に活発で、先ほどおっしゃったように、仕事ではなく趣味でSvelteを選んだ人たちや、APIを本当に評価している人たちがいます。では、Svelteのコミュニティについて少しお聞かせください。最近、最初のカンファレンスがあったようですが...。
Rich Harris: Svelteには素晴らしいコミュニティがあります。Discordは...この数字を確認するために、招待ページを開いたところです。Discordには35,000人がいて、そのうち4,000人が今オンライン中...。かなりの人数です。Discordは、コミュニティの人たちが集まって、お互いに質問したり、取り組んでいることを共有したり、仕事を宣伝したりする場所なんですね。そして、Svelte.dev/chat は、それを見つける方法です。
そうそう、最近カンファレンスがあってね...。Svelteにはコアチームとメインメンテナ、それに従事する人たちがいて、さらにSvelte societyという姉妹組織もあります。これは何人かで運営しているんですが、今すぐ呼びたいのはSwyxで、彼は......。
Amal Hussein: Shawn...
Rich Harris: Shawn Wang, Swyxとして誰もが知っている...
Amal Hussein: ええ。
Rich Harris: ロンドンで開催される予定だったミートアップを、「Svelteが生まれた街であるニューヨークで開催するわけにはいかない」と、彼が最初のきっかけを作ったんです。それで、すぐに同じ日にミートアップを開催することにしたんです。それで、彼はこのロンドンとニューヨークの同時ミートアップを開催したのです。これは2019年、パンデミックの直前のことでした。
Amal Hussein: それはとても古典的でShawnという感じがします。彼は、可能な限り最高の方法で、最も意欲的で、過当競争的な人間です。彼は本当にすごいんです。
Rich Harris: 彼は絶対的なマシーンだ。
Amal Hussein: #goals、これはどういうものです？
Rich Harris: そう、彼は驚くべき人物なのです。
Amal Hussein: ああ、確かに。
Rich Harris: それがSvelte Societyの誕生です。Svelte Schoolもあります。これはSvelte Radio Podcastのホストでもあるケビンが立ち上げたものです。彼が最初のカンファレンスを実現させました。2020年4月に最初のバーチャルカンファレンスが開催され、その後2回開催されました...。そして先週末、2週間前に4回目のバーチャル・カンファレンスが開催されましたが、初めてここブルックリンで対面式の要素も取り入れました。これは素晴らしいことでした。ブルックリンのイベントスペースに大勢の人が集まりました。パンデミックによってバーが閉鎖される前は、ブルックリンのJSミートアップが行われていた場所のすぐ近くです。
Amal Hussein: そうですね。あ、ちょっと待って、ブルックリンJSと全く同じスペースにあったんですか？
Rich Harris: いいえ、違います。
Amal Hussein: なるほど、かなりカッコいい空間でしたからね。
Rich Harris: そう、だから地元では61ブルゴンストリートだったんだ。ブルゴンストリート51番地の「透明犬」という店にいたんです。そのすぐ近くね。
Amal Hussein: ああ、そうなんだ。ヒップスタービルのすぐ近くなんだけどね。ニューヨークで一番クールな街だよ、本当に。ブルックリンは全米で一番クールな街だと思う。正直言って、これ以上クールな街はない...。だからすごいんだ。
Rich Harris: つまり、このイベントはかなりクールだと思ったんだ。
Amal Hussein: そうでしょうね。
Rich Harris: 素晴らしい参加者が集まり、人が集まり...。そうだ、また実際に技術者の集まりをやろう」という気持ちになりました。人々はボードゲームをしたり、おしゃべりをしたりと、本当にいい雰囲気でした。その後、みんなでシャッフルボードで遊びました。よかったよ。
GuillermoとVercelのスタッフが飛んできて、集まった人たちに即興で話をしたんですが、その模様はインターネットでも生中継されていました。ちょうどSvelteの5歳の誕生日と重なったこともあり、コミュニティがこれまで成し遂げてきたこと、そしてこれから進むべき道について考える、とてもいい機会でした。
Amal Hussein: [56:14] それはすごいですね。あと、「Svelte Sirens」という新しいコミュニティグループもありますね。彼らはーー
Rich Harris: あ、そうそう、そうなんです。Svelte Sirensの話をしたかったんです。
Amal Hussein: ええ、女性とノンバイナリーは、確か...。
Rich Harris: はい。
Amal Hussein: 素晴らしいことです。存在感の薄い人たちのためのスペースがあるのは、とてもうれしいです。素晴らしいことです。
Rich Harris: コアチームでは、オープンソースは一般的にかなり均質なシーンであり、特にアーリーアダプターのオープンソースはさらに均質である傾向があるという事実を少しばかり気にしてきました。それは確かに実感しています。でも、コアチームもある次元ではかなり均質で、それを修正するためにできることは限られています。ですから、コミュニティから有機的に生まれる必要があるのです。Svelte Sirensはコミュニティから生まれたもので、Brittney Postmaが中心になって進めています。
Amal Hussein: すごい。
Rich Harris: 彼女は2週間前にサミットに参加していて...。素晴らしい人です。本当に素晴らしい方で、他の女性やノンバイナリーの人たちと一緒にこのイベントを立ち上げたんです... そして、このようなことが起こったことに、私は胸を熱くしました。
Amal Hussein: コミュニティ、ホットテイク...。次は何をするのか、ぜひ聞いてみたいものです。Svelteの最先端、次世代、ネクストネクストって何ですか？
Rich Harris: ということで、次はSvelteKit 1.0です。今はすべてがSvelteKit 1.0に向けて動いています。これが最優先事項です。そして、Svelte 4のウィッシュリストのいくつかを紹介しました。その合間に、いくつかのサイドプロジェクトに取り組んでいます。最近リリースしたsvelte-kubedというライブラリは、Three.jsをSvelteで包んだものです。これはThree.jsのSvelteラッパーで、Three.jsでインタラクティブな3Dシーンを作ることができるのですが、宣言的なコンポーネントシーンとして使えます。
Amal Hussein: すごい。WebGLを開発者向けに簡単に作っているんですか？あの手のものは参入障壁が高いですからね。最悪です。
Rich Harris: それが希望です。私たちはThree.jsをラッピングしています。そしてThree.jsはすでに多くのヘビーリフトを行っています。生のWebGLのコードを書いたことがあるなら、それは不愉快なことです。本当に、先に進むのが難しいんです。私はその世界で少しばかり時間を費やしましたが......。本当の専門知識を身につけるほどではありませんが、Three.jsのようなライブラリがあなたの代わりにどれだけの仕事をしてくれているかを理解するには十分です。
つまり、95％はThreeがやってくれて、最後の5％をSvelte Kubedが目指す...ということですね。なぜならThreeを扱うのは、DOMを扱うのと同じようなものだからです。バニラDOMのAPIに対して書くだけで、アプリケーションを作ることができるんです。でも、そうやってコードを書いていると、最終的には保守性の問題にぶち当たることになるんです、私の経験では...。というのも、本質的に階層的なものを作っているのに、それを階層として表現していないという事実があるからです。線形的な命令型コードとして表現しているわけですから。
同時に、命令的にものを作っていると、状態管理が非常に難しくなる......。コンポーネント フレームワークがあれば、アプリの他の場所で使用しているのと同じイディオムを使用して WebGL を構築できるので、管理が非常に簡単になります。また、ライフサイクル管理のようなこともできます。たとえば、Three.jsのクラス内でモジュールのホットリロードを行うことができます。つまり、単に慣用句を増やして使いやすくしただけでなく、目に見える形で、しかし明白ではない方法で、実際にものを作るときの経験を向上させているのです。
[59:48] だから、ちょっと楽しみなんです...。これは夏のNew York Timesのプロジェクトから生まれたものですが、オープンソースになったことで、実際に何をやっているのかを知っている人たちからの貢献が得られ始めています...。それがどのような形になるのか、とても楽しみです。
Amelia Wattenberger: react-three-fiberを使ったことがある方にお聞きしたいのですが、実装の違いやAPIの違いなどはありましたか？それともほとんど同じようなものですか？
Rich Harris: つまり、Three.jsの上に宣言的なインターフェイスを与えるという意味で、両者は似ているのです。しかし、実装の面では、両者は大きく異なっています。ここで注意しなければならないのは... react-three-fiberを書いたPaulは、多くの点で僕に反対するでしょうから、彼の反応を見ながらこの話をしなければなりません。でもreact-three-fiberはコンポーネント・ライブラリではなく、レンダラーなんだ。つまり、React DOMが与えてくれるものを、Three.jsのために、基本的に実装しています。そのため、react-three-fiberの実装は非常に複雑です。実際にコードを見てみると、それを可能にするために非常に巧妙なことをたくさんやっているんです。コンポーネント ライブラリではなく、レンダラーとして実装することには、ある種の理論的な利点があります。コンポーネントでグラフを作成するのではなく、基本的には自分で直接スリーグラフを作成することになります。理論的には、Three.jsのバージョンアップに伴う変更に対する防御策になりますが、実装そのものと比較検討する必要があります。
ユーザーの立場からすると、一般的にアプリの中でThree.jsのクラスを使っているだけというのが、一番大きな違いだと思います。Svelteでは、フレームごとにアプリを再レンダリングする必要がないため、それが可能です。Reactアプリでは、頻繁に再レンダリングすることはできません。そのため、クラスを作成し、それを後で更新する中間レイヤーのようなものが存在します。コンポーネントの内部で新しい3ドットのボックスのジオメトリを作成することはできません。できるかもしれませんが、更新のたびにそれを再作成することになり、パフォーマンスが低下します。Svelteでは、そのような問題はありません。
ですから、私の考えでは、Svelte Kubedの使い方は、react-three-fiberの使い方よりも少しイディオム的だと思うのです。しかし、react-three-fiberを使ったことがあり、それに精通している人がいたら、どのように違うのか、どの点が優れていて、どの点が劣っているのか、ぜひ意見を聞かせてください。
Amelia Wattenberger: 掘り下げるのが楽しみで仕方ありません。
Amal Hussein: そうですね、特にビジュアルなものに関しては、すべてにおいてアメリアの考えが欲しいですね......。あなたはAPIのインターフェイスについて、本当に素晴らしい直感を持っていると思います。情報をいかにうまく表現するかを理解している...。RichとAmelia、もしまだコラボレーションしていないなら、ぜひやるべきだよ。間違いなく。でも、とにかく......。
この話をまとめるために、HTMLについてのご意見をお聞かせください。この番組ではあまり触れてこなかったので...。というのも、この番組ではあまり触れていないんですが、Webの世界では、HTMLをレンダリングするだけの時代に戻りつつあるような気がします。Astroは大胆にもデフォルトでHTMLのみを提供し、JavaScriptをうまく使うことを難しくしています...。SvelteKitがHTMLだけを出力するオプションを持っているのも同じことです。では、これからはHMTLなのでしょうか？90年代のウェブに戻るのか？先週の番組には、Salma Alam-Naylorという素晴らしいゲストがいました。彼女は素晴らしい開発者の支持者で、実は最近Netlifyで仕事をすることになったばかりなんです。でもSalmaは、「私たちはJavaScriptを飲みすぎて二日酔いになってしまった。そして今、私たちはJavaScriptをあまり飲まない方がいいことを学んだ。だから、私たちは一周回っているような気がするんです。あなたは明らかにその動きの一部なので、それについて何か思うところがあれば教えてください。
Rich Harris: [01:03:45.28] いろいろと思うところはあるんですけどね。振り子のようなもの......私たちは間違いなく、サーバーのほうに振れているのです。しかし、私たちはそれを別の方法で行っています。というのも、この比喩は、全体として静止した状態であり、トレードオフの関係にあるものから別のものに移行していくような印象を与えるからです。しかし、実際には、1周するごとに物事を拾い上げ、より賢くなり、進歩するのですから、1周するというのはよりよい考え方かもしれません。
私は最近、このことについて「Transitional Apps」という講演を行いました...。というのも、私たちはマルチページアプリ（MPA）やシングルページアプリ（SPA）を、ウェブを構築するためのまったく異なるアプローチだと考えてしまうという、言語上の罠にはまってしまったような気がするからです...。しかし実際には、今日、人々が使っているすべてのアプリケーションフレームワークは、マルチページアプリとシングルページアプリの世界の間にある、もう少しニュアンスの異なるものに収束しています。
私たちはHTMLを生成していますが、多くの場合、アプリケーション内でナビゲーションを行う場合、アプリケーション内でリンクをクリックし、別の場所に移動する場合、そのナビゲーションはクライアントサイドで行われます。
だから、検索エンジン最適化、プログレッシブ・エンハンスメント、その他もろもろについて、より配慮する方向に戻りつつあるんです。開発者が以前より配慮するようになったからというわけではありませんが、ツールがデフォルトとしてそれを提示するだけで、最新のフレームワークで正しいことを行うことを積極的に選択しなければならなくなったからです。しかし、シングルページ・アプリのパラダイムが持つ可能性を、私たちは守り続けています。ですから、これは逆行するものではありません。90年代のアプリの構築方法に戻るわけではありません。バックエンドのレンダリングロジックはすべてサーバーに移行します。
Amal Hussein: エッジ...
Rich Harris: ...サーバーレスへの関心が高いのは明らかですが、エッジへの関心も高いです。Cloudflareのワーカー、Vercelのエッジファンクション、Netlifyのエッジハンドラ（まだベータ版だと思いますが）などがあります。ここが動いているんです。まだすべてに使えるわけではありませんが、非常に多くのことに使えるようになり、これまで人々が取ってきた意思決定に影響を与えてきたトレードオフが変わってきています。
Amal Hussein: そうですね。さて、番組を終えるのにこれ以上の方法はないと思います、本当に......。今日はありがとうございました。ウェブへの貢献に感謝します。現状に満足せず、疑問を持ち、"本当はもっとうまくやれるはずだ "と言ってくれることに感謝します。あなたのような思想家がいることは、私たちにとってとても幸運なことだと思います。あるアイディアに固執して、「いや、実は違うんだ」と言うような、本当に頭のいい人たちの意見に反対するのは難しいことだと思うんです。 [笑う] だから、ありがとう...。そして、この来年はSvelteについてもっと学びたいと思っています。それは、私のますます限られた時間を使って新しいことを学びたいと考えているリストに入っています...。だから、私は何を学ぶかについて非常に慎重で、スベルテはそこに入っているので、それは大きなことです。とても大きなお墨付きです、リッチ。
Rich Harris: 本当にありがとう。ありがとうございました。
Amal Hussein: そうだね。そしてアメリア、私の副操縦士として、いつも素晴らしい洞察力を発揮してくれて本当にありがとう... さて、今週はこれでおしまい。みんなが素敵なホリデーシーズンを過ごすことを心から願っています。今年を締めくくる本当に楽しい番組がいくつかありますし、来年もさらにいろいろなことを計画しています。皆さん、お元気で。バイバイ！
Outro: [01:07:38.12] to [01:08:40.09]
Rich Harris: ...そして、簡単に言うと、より速くリリースすることができます。
Amal Hussein: 「クソ早くなる」と言ったと思ったら、「待てよ、違う...！」でしたね。 [笑う]
Rich Harris: それもあるかもしれませんが、マーケティングには含めないつもりです......。
Amal Hussein: ええ、編集しますよ。とにかく... [笑う] じゃあ、やり直します？リリースも早くなるし... [笑い声]
Rich Harris: なるほど、要するにリリースが早くなるということですね。