00:04
6月2日、地獄朝9時を回りました。今日の東京は結構いい天気になってますね。はい、おはようございます。
かぶし返しゆめみのキースことくわはらです。では本日の朝活を始めていきたいと思います。
えーとですね、本日の朝活ですけども、今日は、昨日まででRFC周りですね、React Server ComponentsのRFCと、あと
エクストJSのレイアウツのRFCですね、を読み切ったので、今日何を行って、ちょっといろいろ
あのウェブで記事を探しまくったんですけど、えーとちょっと気になったことというか、相方からも疑問があったものとして、
えーとまぁ、Svelteって早いって言うけど、仮想ドームを使ってないからと、あとReactiveで早いって言うけど、それなんで?っていうところの疑問を受けて、僕も確かにちゃんと理解しなかったなんていうところで
えーといろいろ記事を探したんだけど、今日はそのタイトルにある通りですね、フルの記事のタイトルでいくとReact VS Svelte
The War Between Virtual and Real DOMっていうタイトルですね、の記事を読んでいきたいと思います。
こちらですけど、ちょっと2年前の記事なんで古いんですけども、まぁ一応2つのメリットあると思ってて、一応まず最初に歴史を学ぶことをですね、どういう経緯があって今の
進化になっていたかって、その昔の仮想ドームとリアルドームの比較ってどういう視点だったのかなっていうのも知った上で今の話に
持っていきたいなと思いました。2つ目としては、仮想ドームとリアルドームの話ってそんな大きなパラダイマは起きないだろうなっていうのが1つもあると思っているので
ここで読んだ事件っていうのは意外と現代でも通じることもあるんじゃないかなっていう2つのメリットがあると僕は見込んで今日はちょっと読んでいこうかなと思っております。
はいまぁ興味あるかどうかは別としてですけども、はいちょっと気になったので読んでいきたくなりました。
おそらくこれの続きとして、そのスベルトのスピードのところにお話が行ってくれたら嬉しいなとはちょっと思ったりはしていますね。
はいという感じでじゃあ最初からまた翻訳つつですけどちょっと読んでいきたいかなと思っております。
2年前の記事というところまた全部とネットに置いておいて聞いていただければと思います。
最近スベルトで遊ぶ機会があって簡単なショッピングカートアプリケーションの構築方法というのをちょっと学んでみました。
さらにリアクトと多くの類似点があることに気づかすにはいられなかった。
ユーザーインターフェースを構築するための最も人気のある JavaScript スクリプトライブラリーの一つであるリアクトとこれほどまでに競合することができるのは驚くべきことです。
今回はそのリアクトとスベルトを比較しその舞台裏をちょっと紹介してみたいかなと思っております。
話でした。はい最初ですね、スベルトはコンパイラー、リアクトはバーチャルドームを使うというところですね。
まず大前提のところからですね。リアクトとスベルトはどちらもコンポーネントベースのアーキテクチャを提供しています。
つまりどちらもcdd のボトムアップ開発を可能にし、ビット各GitHubのようなツールやプラットフォームを介してアプリ間でコンポーネントを共有することができるのです。
そうですね。
03:00
続いて、両者の大きな違いですね。というのは実行時に仮想ドームを使ってアプリケーションコードを解釈するリアクトに対して、スベルトはビルド時にアプリケーションを理想的なジャバスクリプトに変換するコンパイラーであることです。
はい、ちょっと専門的な用語が多かったのでちょっと噛み砕いて説明します。という感じですね。
今一つの図がどんどん目の前にあってですね。この図を多分見てもらうとほうがわかりやすいかもしれないんですけど、ちょっと口頭にはなりますけども説明させていただきますね。
スベルトはですね、コンパイラーの時に何をしているかというと、まずコンポーネントというものを作って、そこでコンパイラーが走ってコンパイラーしますと。
で最後に、これ翻訳できないな、ideal javascript the surgically updates DOMというところですね。
はい、というので、DOMをアップデートして最後ブラウザーDOMに反映されるという感じです。
はい、タグハさんですね、ご参加いただきありがとうございます。
タイトルにある通り、the war between virtual and real DOMということで、リアクトとスベルトを比較した記事というのにはちょっと読んでます。
ただ2年前の記事なので少し古いですけど、歴史と今でも通用するものがあるかもしれないというのを期待して読んでる感じですね。
はい、今はスベルトのコンパイラーの流れのところを読んでました。
でリアクトはというとちょっとステップ数が多くて、もちろんコンポーネントがあってそれをトランスファイルにするときに、まずはブラウザーのJSエンジンが走ってくれて、そこでバーチャルDOMのノードを解釈します。
で、diff between previous DOM and update virtual DOMなので、既存のDOMと仮想DOMのところを比較して差分検知して、さらにその仮想DOMをアップデートするという処理が走ります。
で続いてupdate DOM with the help of reconciliation diffing algorithmというところで、要は仮想DOMの差分を変更した後にリアルDOMを反映して、それを最終的にブラウザーで表示するという感じで、
5ステップを踏んでます。なのでブラウザーでやることがちょっとリアクトのほうが仮想DOMを使う方が多いということですね。
というような図でした。ではちょっとここら辺の説明がずらずらとまた解説が続いていくので、そこら辺読んでいこうと思います。
リアクトはまず仮想DOMですね。リアクトっていうのは仮想DOM、VDOMとはしおったりしますけど、と呼ばれる概念を使用しています。
UIの仮想的な表現をメモリ内に保持し、リコンシレーションですね、と呼ばれる処理によって実際のDOMと同期させます。
このリコンシレーション処理では、バーチャルDOM、メモリ上のオブジェクトでUIの最新更新をプッシュするといったものと、リアルDOMですね、以前に連伝されたUIを保持するDOMの差分を見つけます。
特定のヒューリスティックアルゴリズムを使用して、UIをどのように更新するかを決定します。このプロセスはほとんどの場合、高速で信頼性が高く、絶大な反応性を持っています。ダジャレです。
06:00
なるほどですね。英語では確かにインを踏んでますのよりダジャレですね。
これを実現するためにリアクトは一定量のオーバーヘッドコードをバンドルして、ブラウザのJSエンジンで実行して、様々なユーザーインタラクションに基づいてDOMを監視および更新をしているというのがリアクトの中身です。
ではそれの対比して、Svelteのコンパイラーの話ですね。
Svelteコンパイラーですけども、Svelteは純粋にコンパイラーであって、実運用に向けてアプリケーションをビルドする際にアプリケーションを理想的なJavaScriptコードに変換します。
つまりアプリケーションの実行中にブラウザで実行するオーバーヘッドコードを注入してDOMを更新するということはまずありません。
このアプローチというのは一般に仮想DOMを利用するリアクトと比較すると比較的新しいものになりますよというふうに言ってますね。
続いてのお話ですね。ここからSvelteの強みの話がバーッと繋がりますね。
合計6個あるらしいです。
では行っていきましょう。Svelteを使うことで得られる主なメリットは何なのかを見ていきましょう。
1つ目ですけども、リアクトや他のフレームワークと比較してビルド時間が圧倒的に早い。
バンドルにロールアッププラグインを使用しているのがその秘密かもしれません。
Webpackとロールアップの比較の話も続いてくるので、これに話すとまた長いので今回は割愛します。
リアクトに比べてGzip圧縮したときのバンドルサイズが小さく、これは大きなプラスポイントです。
私が作ったショッピングカートアプリケーションでも初期ロード時間やUIのレンダリングにかかる時間は非常に短く、
追加した分厚い画像に少し時間かかる程度でございます。
サイズが小さいというのは本当そのまま数字にはっきり出てくるものですので、これは大きいメリットだと思いますね。
3つ目。クラスと変数のバインディングが比較的簡単で、クラスをバインディングさえにカスタムロジックは必要ありません。
CSSスタイルというのをコンポーネント自体にスコープすることで柔軟なスタイリングが可能になります。
スコープすることと柔軟なスタイリングというのは別にリアクトでもできると思いますけど、
Svelteも結構できますし、もうちょっとクラスバインディングするというカスタムロジックが必要ないというのがもうちょっと強みになる感じですかね。
今のスタイリングは4点目でしたね。
5点目はSvelteの大部分はプレーンなJavaScriptやHTMLやCSSであるため、他のフレームワークと比較して理解がしやすく使い始めやすいですよねという話をしていました。
リアクトは確かに特殊なAPIであったりとか書き方、記号というのがあったりするので、それを覚えなきゃいけないので、そこの読み替えコストはかかるって確かにありますよね。
ラスト6点目ですけども、リアクトのコンテキストAPIと比較すると、ストアの実装はより簡単ではあります。
コンテキストAPIってより多くの機能を提供したりして、Svelteは一般的なシナリオでは十分シンプルから教えません。
09:02
今のリアクトはだいぶ変わったので、2年前の記事だと確かにそういう比較記事になってしまうのは仕方ないかもしれないですね。
ただ今リアクトフックスが入ったので、全部概念的とか開発の手法、書き方とかも全然変わりましたし、今関数コンポーネントが主流になっているので、
ちょっとここに関しては昔の利点と欠点の話ですね。
では続いてSvelteの欠点の話をしていこうかなというところでした。
続いて欠点はどこにあるか見てみましょう。こちらも5点あります。
1点目ですけど、Svelteっていうのは参照の更新とか配列の変異をリスニングすることはない。
これは残念なことで開発者は積極的にこれをチェックしてUIが更新されるように配列の割り当てを確認する必要があります。
これに関してはSvelteは更新されていて、今は変異をリスニングしてくれる気がしますけどね。
リアクティブに受け取ることができて、ダラーをつければいけるはずなので。
配列も確かいけた気がするんですけど、ちょっと僕が確認してないだけで変数だけかもしれないです。
ここは何か改修されているんじゃないかなと思ってますが、すみません僕が不勉強です。
では続いて2つ目ですね。
ドムイベントの仕様も定義済みのJS構文ではなく、Svelte特有の構文に従わなければならないため、ちょっとわずらしく感じることがあります。
Reactのようにオンクリックを直接使うことはできず、オンコロンクリックのような特殊な構文を使わなければなりません。
ここはもう仕方ないですね。
フレームワーク固有の書き方、APIになってくるので、このように従わなければならないので、新しい書き方を覚えなきゃいけないというのがちょっと欠点になるかもしれないと言ってました。
そこに関しては確かにReactはオンクリックというブラウザの標準仕様のままでいけるというのは確かに強いかもしれないですね。
では続いて3点目ですね。
Svelteというのは新しくかつ若いフレームワークであり、コミュニティのサポートも少ないため、重いプロダクションアプリケーションで必要とされるような幅広いプラグインや統合をサポートしていません。
ここではReactが強力な競合となります。
ここに関してもちょっと改善されてきたとは思っていますね。
もう2年も経ちましたし、Svelteキットというようなラッパーフレームワークですね。
いわゆるReactでいうNext.jsみたいなものも生まれてきていますし、TSの対応もされていますので。
そこまで重いプロダクションアプリケーションで使えないかというと、結構使えるようになったという話も聞いたり、大規模で作っているという実例もちょこちょこっと耳にしたことがあります。
数件ですけどね、僕としては。
ここも改善されてきたんじゃないかなという気はしてますね。
4つ目です。
追加的な改良というのは特にないです。
Reactサスペンスはあなたのコードとその実行方法を積極的に制御し、DOMが更新されたときに最適化しようとし、
時にはデータを持っているときに自動ロードスピナーを提供することさえあります。
12:00
これらの追加機能や継続的な改良というのはSvelteでは比較的少ないですと言ってますね。
はい、なるほどですね。
僕もまだ最新のSvelteがどういう機能になっているかわからないですけど、
確かにReactのような追加的な機能であったり、
開発者に沿ったような素晴らしい機能というのがあるかというとちょっと疑問というのはありますね。
そもそもReact18のサスペンス機能というのがかなり大きく、
かなり我々にとって嬉しいものであるので、
そういうような動きとかありがたいものがSvelteには別にないよというふうに言ってますね。
視聴優先さんですね。
今日もご参加いただきありがとうございます。
タイトルはThe War Between Virtual and Real DOMということで、
こちらは仮想DOMとリアルDOMの比較の記事っぽいですけど、
厳密に言うとReactとSvelteの比較記事を読んでます。
ちょっと2年前の記事なのでだいぶ情報は古いんですけど、
仮想DOMとリアルDOMの比較というところの歴史を学びたいというのと、
あとはそこまで抜本的に変わるものがあるかというと、
そこに関しても僕はちょっと疑問なので、
現代でも通じる知識とか記述があるんじゃないかなというのを期待して読んでます。
今はSvelteの欠点をずっと読んでて、ラスト5点目ですね。
開発者の中にはテンプレート内でSharp IfやSharp Eachといった特殊な構文を使うことを好まず、
代わりにReactが許容するプレーンなJavaScriptを使いたいと思う人もいるかもしれません。
これは個人の好みの問題かもしれませんと言ってます。
ここもそうですね。
Reactは純粋なJavaScriptの方でマップを使ったりとか、
JSXで扱うので最後はJSXでガンって入れるだけですので、
実態としてはJavaScriptなんですけど、
Svelteの場合はHTMLの方にSvelteの特殊な構文を埋め込んでいく形になるので、
ここに関しては気嫌いをする人も全然いらっしゃると思いますし、
ここは本当に好みだと思います。
結局、HTMLとロジックっていうのが依存関係にあるじゃんっていうことになってしまうし、
見た目的にそうですので、そこをどう思うかって感じですね。
ではですね、いろいろばーっと読んでいきましたけども、
コンクリューション、もう結論の話になるらしいですね。
まとめとしては、Svelteの高速なビルドタイムと小さなバンドルサイズっていうのは
リアクトと比較すると非常に魅力的で、特に日常の小さなアプリケーションには最適です。
しかし、拡張機能、コンテキストAPIとかサスペンスなどですね、
コミュニティサポート、また幅広いプラグインや統合、そして特定の構文の簡略化によって
リアクトも魅力的になっていますと。
リアクトの強みはそこですよね。
サポートチームも充実しているのと、やっぱりエコシステムがものすごく充実しているっていうのがかなり大きいと思いますね。
ここからいくつかのFAQが来ますね。
FAQでも少ないのでこれを読んでしまうと、今日の朝から一瞬で終わってしまいそうになっちゃうんですけど、
時間が余ったら別のものを読んでみようかなと思います。
15:03
Svelteはリアクトより優れているんですか?それはその逆ですか?という質問に対してですけど、
この触った人、この人は別に中の開発者ではないと思いますが、
答えを言うと、2年前ですけど、
Svelteはリアクトを比較すると特定の機能で顕著な改善を提供しています。
しかしリアクトを完全に置き換えるほどの重要性や規模はまだないかもしれません。
リアクトはまだまだ堅牢で広く採用されています。
Svelteはかなり追いつかなければならないところがあります。
しかしコンセプト的には、Svelteが取ったコンパイラーアプローチというのは、
仮想ドームの差分が高速なリアクティブアプリケーションを構築する唯一のアプローチではなく、
非常に優れたコンパイラーが同じ仕事を行わせることを証明していますと言っています。
可能性は全然あるし、今は2020年なので、
2022年現代のSvelteと比較したらどうなんだろうという気がするので、
今日は時間がありそうなので、軽くググってみて、
良さそうな記事があったらそれを見てみようかと思います。
続いての質問です。
次のアプリケーションはどのフレームワークを使うべきでしょうか?
結局我々は楽して答えが欲しいし、楽な選択肢を提供してほしいという質問ですが、
これは世界でも一緒なんですね。
長所と短所を比較した場合、私の意見では、
もしあなたがスタートアップのためのシンプルなeコマスアプリケーションのような
小さなアプリケーションを構築するのであれば、Svelteをおすすめします。
JS、HTML、CSSの知識があれば、Svelteを使いこなすのは結構簡単ですよ。
また、Svelteを使えば、強力で高速かつ軽量なアプリケーションを構築することもできます。
しかし、いくつかの統合とか特定のプラグインが必要とするような巨大なプロダクションアプリケーションには、
もちろんリアクトが適しているかもしれません。
リアクトがNext.jsを提供するように、
SvelteもSapperというシングルページアプリケーションフレームワークを提供して、
こちらの検討の価値があります。
現代だとSvelte SapperというのはSvelte Kitというものに統合されていますね。
こっちを検討する価値はありますよねって言ってました。
どちらのフレームワークも優れたユーザーインターフェースを構築するための実用的かつ効率的なツールでもあります。
この2つのどちらを選ぶかは、もちろんあなたのシナリオと好みによるところが大きいでしょう。
先に述べたように、どちらも主要な目標を達成するために見事に機能しているので、
1人に絞るのは結構難しいよと言っています。
この記事でリアクトとSvelteの簡単な比較をしていただけたらと思います。
そして、あなたの次のアプリケーションにどちらのライブラリを選択するかを決定するために役立つといいと思います。
それでは、ということで、この記事は今回終了ということでした。
記事が古かったというのもあって、あくまで参考値というのと、
あまり仮想ドームとバーチャルドームの比較というところがあまり詳しく書かれていなかったのが僕としては残念でしたけど、仕方ないですね。
続いて、ちょっと時間が余ってしまったので、Svelteとリアクトの比較というところの記事を今軽く作ったんですけど、
1本見つかったので、これをちょっと読んでみようかなと思いますね。
18:01
時間いっぱい読み切れることはないと思いますし、この記事かなり長いので、ザラザラと読んでいこうと思いますね。
タイトルはSvelte vs. React in 2022. Choosing the best match for you というところですね。
2つの記事のリンクがあって、Here for quick answers といって、Jump to the overview というところがあります。
オーバービューがあるので、そこを読んでくれてもいいんじゃないかというところですね。
じゃあ、先にオーバービューだけザッと読んでいっちゃいましょうかね。
では、オーバービューに行きます。
Which do we choose ということで、我々は結局どれを選べばいいのかということですけど、
リアクトとSvelteの対比をいくつか見てきましたが、こちらはモード的なレストではありませんが、
チームがどちらのツールを好むかもしれないかは一応理由を列挙してみましょうというところで。
まず一つ目の観点としては、When React is a good fit という、リアクトが適している場合というところですね。
あなたのチームはより強力なプログラミングのバックグラウンドを持っています。
バックエンド技術に精通したフルスタックエンジニア、もしくは関数型プログラミングのマニアとか、
JavaScriptの達人などがいるかもしれません。
プロジェクトが非常にダイナミックでデータドリブンである場合とか、
リアクトが大規模な状態管理を解決するために構築されているので、
ファーストパーティーとかサードパーティーの両方のレベルではどこにも引きを取ることはないよと。
またプラットフォームを超えて自分の仕事を再現する予定がありますとかですね。
リアクトはもともとフレームワークに依存しないので、
ボンバイルデスクトップアプリケーションのリアクトネイティブとか、
WebのリアクトJSというのは良い組み合わせになりますよという話もしています。
これらのときにはリアクトにヒットするんじゃないのという観点でしたね。
続いて、When Svelte is a Good Hitということで、
Svelteが適していればいいという観点ですね。
こちらは3つあるんですけど、
1つはフロントエンドに強いチームであることということでした。
テンプレート言語の経験があって、
CSSやページアニメーションに自信のあるフロントエンド開発者がいる場合とかはいいんじゃないのということでした。
2つ目はプロジェクトがUI中心でウェブ用に構築されていると。
SvelteというのはCSSとかアニメーションとか3Dソリューションまでも組み込まれたバッテリー内蔵のフレームワークであります。
リアクトはこれらのそれぞれについてサードパーティーのソリューションを必要としますというところですね。
3つ目、あなたのチームは機能までに出荷する必要があります。
要は早くデリバリーする必要があります。
Svelteというのは徹底したシンプルさと引き換えに日々書くコードを減らしています。
それでも人間が読めるレベルです。
コードの記述量をどんどん減らしたというのがSvelteなので、デリバリーを早くしたいというところには適しているのではないかという話をしています。
この記事の中で図があってComparing Core Features Setというところで比較が書いています。
21:02
こちらは記事のリンクを後ほどツイートしますので見てもらえれば。
最後にIf you are undecidedというところで、もしあなたが迷っているならというところですけど、
一旦両方試してくださいと。
プロジェクトごとにReact Svelteを切り替えると特に便利だよねという話をしています。
できればの話ですけどね。
またこの記事をシェアして、開発者にコードデモを分解してもらうとかもいいんじゃないかと言っていました。
なるほど。
ウェブ開発とはコンピューターにコードを打ち込むことではなく、人々が自分の考えを考えるための言語です。
だから仕事に適した言語を見つけるために議論を巻き越すことを絶対にお勧めしますよということでした。
というところで、一旦ザッとオーバービューだけ見たので、実際の本記事のところですね。
ガーッと中身を読んでいこうかなと思っています。
時間がそんなにないのでどこまで読めるかわからないですけど、
せっかくなんでこれこのまま読み切れないと思うので、
明日以降も引き続きReactとSvelteの比較記事をどんどん読んでいこうかなと思いますね。
では入ります。
まず最初にある逸話を紹介しましょう。
先日ある11TYの開発者と話をしました。
11TYってなんだ?僕が知らねえな。
なんだろう?11Tかな?11Tのディベロッパーですね。
11Tっていうのはなんだっけ?
お製的なページを作るフレームワークだったという記憶をしています。
なんか結構便利そうで素晴らしいものだったので結構お勧めしますね。
11Tかなりいいと思いました。
その開発者と話をしました。
彼らは純粋なフロントオブフロントエンドの技術、
プレーンなHTMLとCSSからJavaScriptのコンポーネントフレームワークの世界へ移行することを計画していたのです。
彼らはReactからVue、Svelteまで人気のあるオプションのどれにもオープンでございました。
その人気の高さから彼らはまずReactを試しました。
そしてそれを嫌いました。
私ではなくて彼らの言葉です。
11Tの人たちはReactを試して実は嫌ったんですね。
意外です。
React嫌いという人も全然いらっしゃるんですけど、結構数は少ないので意外でしたね。
なぜかというとマークアップを第一に考え、
よくできたウェブサイトを構築するウェブ開発者としての彼らのアプローチや考え方とどうしても相容れなかったのです。
マークアップ第一って考えるとそもそもJSXなのでJavaScriptで物事を全部制御するっていう考え方って確かにそもそもが違いますもんね。
それでも彼らはエコシステムの中でいくつかの異なるツールを試しました。
もちろんVueとSvelte.jsです。
しかしそれぞれのツールに対する反応は全く異なるのでした。
インタラクティブなウェブサイトの構築がこれまでになく簡単になり、彼らの開発者としての哲学に合致し、
制作物もReactが達成できるものとほぼ同じだったのです。
彼らにとってベストマッチだったのは実はSvelteだったということでした。
今の逸話の一つでした。
24:01
もう一つの例を紹介しましょう。
私は大学時代、コンピューターサイエンスの学生を対象としたウェブ開発ブートキャンプを主催していました。
最初の数十間はプレーンなHTML、CSS、JavaScriptを学ぶという控えめに言ってもかなりハードなものでした。
カスケードスタイルやアクセシブルなHTMLを理解することは毎日Javaの宿題をこなしている学生にとってピンとこないのです。
技術はシンプルですけど簡単ではありません。
Javaの学生にカスケーディングスタイルを理解させるのはかなりハードで高いと思います。
しかしReactを導入した途端、人々の意識が変わり始めた。
ある学生は当時Reactのドキュメントで唱えられていたクラスベースの公文取り上げ、これは私がJavaで書いたクラスに似ている気がすると言っていました。
UIをJavaScript Firstで作ることはCS領域の人たちにはとても有効でした。
Reactは彼らにとってベストだったと。
このようにさまざまな開発者背景の逸話を2つ紹介しました。
では、あなたのチームがReactスペルと比較する場合、どちらがよりマッチするのでしょうかというのを比較してみましょう。
レッツコンペアということですね。
3つの視点で比較していこうという話をしています。
1つ目ですけど、それぞれのコンポーネントフレームワークで使われている公文ですね。
あとはその基本方針とかですね。
方針というともうちょっとあれですけど、原文ではプリンスプルと言っているので、もうちょっと上のレイヤーというか高い視点で見ている話かなと思います。
最後、API設計に影響を与えた原点ですね。
これはオリジンと書いてあるので、原点でいいんじゃないかということですね。
この3点を挙げていますね。
仕事に適したツールを選択するのに役立つような比較をしていこうかなという話でしたね。
ではでは、その比較の方に入っていくんですけど、
まずとりあえず翻訳をするので、ちょっと時間かかりますね。長いので。
まず面積事項ですね。
なるほど。
これは人気投票ではないですと。
はい、わかりました。
では入ってきますね。
他のリアクトvsスベルトの作品というのはダウンロードするから始まるかもしれません。
作品と言っているけど記事と言った方がいいかもしれないですね。
というわけで、この記事を書いている時点のNPMの統計ですと。
リンクをクリックして事実確認してくださいというところで、
これは多分NPMトレンズですか?
違う、NPMJSの単純にダウンロードのところですね。
このリンクがあって、
だいたいスベルトというのは週間ダウンロード数が10万以上ぐらいですと。
リアクトは600万以上なので、
ぶっちゃけ60倍の差がありますと。
それはそうですよね。
仕方ない。リアクトはまだまだめちゃくちゃデカいと言ってました。
27:00
もうちょっと解説を続けますけど、
チームがどちらを選んでも現存するものを使いたいのであれば、
私は完全にそれを理解するとか納得しますよというところですね。
しかし私の意見としてはダウンロード数が多いからといって、
品質が高いとは言えないということです。
どのライブラリーも開発者のニーズを満たすために設計上のトレードオフを行っています。
ですから全ての開発者、全てのチームが同じツールを使って
同じように生産的になるとは限りません。
また、劣等性という言葉になってますけど、
これはどういう意味なのか難しいですね。
コンテキストからも読みづらいけど。
劣等性に対する不信感にも触れたいと思います。
まず、スベルトのコミュニティは企業レベルのサイトや
複雑なウェブアプリケーションを扱うには
十分大きくなっていますということですね。
スベルトコミュニティは十分大きくなったんですね。
デザインシステム、CMSインテグレーション、エンベデットなど
サードパーティーライブラリーの多さを見てくださいと。
スコット・トリンスキーのコースというのがあって、
そのプラットフォーム全体をスベルトに移行した経営スターディというのも一見の価値がありますよと。
これはそういう記事が別途あります。
記事というかYouTubeですね。YouTube動画がありました。
ケース・スタディで正しいタイトルは
ケース・スタディ・オン・マイグレイティ・ザ・ヒズ・エンタイア・コース・プラットフォーム・トゥ・スベルトって書いてますね。
これは全然価値があるよって言ってますね。
またさらに、スベルトは趣味のプロジェクトではないですと。
現在スベルトは作者によってフルタイムでメンテナンスされていて
バーセルによってバックアップもされていますと。
本格的にちゃんと運用されてるんですね。
それはかなり良い情報でしたね。
なるほど。
以上コミュニティとエコシステムを比較するつもりはありませんと。
それぞれのツールはこの点では十二分に有能ですと。どちらも。
我々はこれらのツールがどのように機能し
どのような問題を解決するために設計されたのかを探求するために
今ここにいますよっていう話をしてました。
なるほどですね。はい。
というところで、続きいきたいんですけども
ちょっと時間が来たので今日はこちらに終了して
次回またコンペアスベルトvsリアクト2020の記事ですね。
この記事の続きを読んでいこうかなと思います。
次回からはレッツトライリアクトとかレッツトライスベルトという感じで
本当に両者を触ってみた比較の記事がどんどん書いてくる感じですね。
ちょっとソースコードも増えてくるんで
音読でソースコードを読んでしまうことにもなってしまうので
大変申し訳なくて理解しづらい感じになってしまうかもしれないですけど
ご了承いただけると嬉しいなと思います。
はい。じゃあ今日はこちらで朝かつですね。
は以上にしたいと思います。
はい。木曜日ですよ。今日も一日頑張っていきましょう。
ではお疲れ様でした。
