1. kkeethのエンジニア雑談チャンネル
  2. No.98 朝活「Vue vs.React - W..
2022-10-04 20:00

No.98 朝活「Vue vs.React - Which One to Choose in 2022」をダラダラ読む回

はい.第98回はみんな大好き比較記事


Vue vs. React — Which One To Choose in 2022?
https://brocoders.com/blog/vue-vs-react/


の前半までを読んでいきました💁

いやー,今回は参加者が多く皆さん本当この手の記事好きなんだなーと改めて実感しましたw もちろん私もその一人ですがw

しかし,この筆者の方の考察は一歩深いところまで踏み込んでの考察でしたのでとても参考になりました.ぜひ読んでみてください❗


ではでは(=゚ω゚)ノ


See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

00:03
はい、9月30日金曜日ですね。 地獄朝9時を回りました。
はい、えー、今月もラストですね、締め身というところで、おはようございます。 締め身のkeethからの熊原です。
では、本日も朝活を始めていきたいなと思います。
えっとー、今日はですね、タイトルありますけど、
えーと、Vue vs. React 2022の海外の方の記事をちょっと読んでみたくなりました。
まあ、あとは、フォロワーさんの中に学生さんがいて、Vue vs. Reactの記事かな、なんかのスレッドで見て、すごい圧巻の回答があったっていうので、
なんかそんな、いい回答があるのかなーっていうのを思ったので、
僕なりにガッと調べて、なんか面白そうな記事を見つけたので、それをちょっと読んでいこうかなーと思っています。
はい、えーと、りんちゃんですね、おはようございます。ご参加いただきありがとうございます。
まあ、タイトルのある記事を本当にダラダラ読むだけの回になりますね。
はい。で、まあ2つほど記事を見つけて、片方から読んでいこうと思います。
もう1個、時間が余れば、えー、別の記事ですね。
Vue vs. React 2022 What to choose and whenっていう記事があるので、そちらも読んでみたくなったって感じですね。
はい、まあ多分、どちらもエンジニアの方が書かれてる記事っぽいので、えーと、そう、あんまなんか心配はしないんですけど、
なんか日本語の記事だと意外とこう、詩意的な文章が多いなーっていう印象があったので、
まあ海外の記事も今から読むんですけど、実は詩意的な感じはするかもしれないですけどね。
はい、まあいいや。一旦読んでいきたいかなと思います。
じゃあ行きましょう。
Vue.jsとReact.jsはJavaScriptベースのツールキットシステムでありますと。
動的なユーザーインターフェースの構築を支援するものです。
コンセプトとしてはUI全体がデータであり、変更される度に新しい機能が追加されます。
これらの関数は一般にUIコンポーネントと言われる特定のページブロックを更新するものです。
Vue.jsとReact.jsではコンポーネントはJavaScriptとHTMLコードの断片を1つのファイルに整備したものであると。
コンポーネントは親と子という類似の階層構造を持っており、互いにデータを渡すことができます。
ReactとVueの特徴を見つけるには、これらの基準を考慮する必要があります。
ReactとVueでどのようにコンポーネントを作成するか、コンポーネントがどのように互いに通信するか、
コンポーネントがブラウザのドームにどのような影響を与えるかという、
これらを理解した上で選択することができるでしょうと。
Reactはフレームワークと呼べないけど、常にそう考えられてきたことを述べておく必要もあります。
JavaScriptのライブラリーでありながら、
WebアプリケーションのVue部分全体を構築するのに適しているよというところが、まずサマリーでした。
では早速中に入っていきましょう。
コンポーネントビルドプリンシップルin React and Vueです。
ReactとVueの特徴を見つけるには、これらの基準を見直す必要があるところですね。
VueとReactではコンポーネントは、ReactとVueにおけるコンポーネント構築の原則ですね。
ReactのJSXとシングルファイルコンポーネント構造というところですね。
コンポーネントはWebブラウザー上でデータをレンダリングします。
ユーザーに見せる部分、HTMLとロジック部分、JavaScriptが含まれます。
03:00
ロジックにはブラウザ上でデータをやり取りするための関数やメソッドなどが記述されています。
Reactではブラウザのネイティブメソッドに対応した関数を記述するための構文言語であるJSXですね。
JavaScript Syntax Extensionの略です。
を採用しています。
で、Safari、Chrome、FirefoxはReactで書かれたロジック関数と直接対応できるJavaScriptエンジニアをベースにしています。
JavaScriptのコードはHTMLタグで強化されているため、Webブラウザーで認識することはできません。
そこでReactはBabel Transpilerというのを使ってプログラミングコードを純粋なJavaScriptに変換をしています。
JSXではJavaScriptでHTMLを返すことができますし、HTMLで実行することも可能です。
またJavaScriptの変数にはいかのようにHTMLタグを割り当てることができますと。
これは記事内にはソースコードがペッと貼られているんですけど、
ここはそういえば貼ってきますよねぐらいの参考に聞いていただければという感じですね。
なんだっけ、HTMLタグを割り当てることができる。
コンストメッセージみたいな変数を作っておいて、
イコールH1のホゲホゲのH1閉じ、みたいな感じでJSXのように割り当てることができると。
ダイナミック変数というのはJSXの途中の括弧分ですね。
項部に入れることもできますよと言っています。
まあまあこの辺はReact書き慣れている方だとそうだよねぐらいの感覚でしかないと思いますけど。
あとStack Shareというサイトがあるらしいですね。
Stack Shareというところの統計によるとReactの最も好きな機能というのはコンポーネントとシンプルさだそうですね。
そのアンケートを取っているサイトがあるらしくて、コンポーネントが747の結果になっていてシンプルさというのが484で第2位ですねと。
しかしJSXはユーザーからの評価がかなり低く、31しかいいねをもらえていないらしいですね。
いやこう面白いな。
意外とやっぱりエンジニアはJSX実は好きではないのかもしれないですね。
で、これに対して
考えを述べられていきますけど、JSXの最大の懸念っていうのは特定のコード構造を必要としないことだと私は考えています。
コンポーネントのロジックとUIが一つのファイルになっているため、コードが乱雑になる恐れがあります。
シングルファイルコンポーネントの考え方は
HTML、JavaScript、CSSを別々のファイルにすることを提案した、アンギュラーと対立するものですと。
まあまあそうね。でもアンギュラーも別に
切り出すこと全然できるしそういう構造にもなっているので
一概にアンギュラーと違うっていうのもちょっと想定かなって気はしますけどね。
で、AirbnbやNetflixがリアクトコミュニティに参加し、
MVPの構築にリアクトを使い始めない限り、コンポーネントを単一ファイルで関節されることは十分に普及しなかったと
この方は見ていると。で、今回のトピックに関連する資料を探したところ
DoBetterDevShowPodcastみたいなポッドキャストを見つけたらしいですね。そのエピソードの中で、兄さん
カルバン君っていう方がですね。彼の共同ホストである、また何て呼ぶんだ
ギャネッシュミーシャが共同ホストなんですけど、その方々が
06:02
Viewとリアクトの主な違いについて議論していました。
ポッドキャストの途中で、姉さんはリアクトにおけるコード調整のテクニックというのを披露してくれましたよと。
このポッドキャストも聞いてみたいですけどね。さすがに英語だと思うので
ついていけねえって感じはしますけど、まあ頑張って聞いてみたいかもあります。
はい、で、引用文ですね。JSXっていうのはロジックとプレゼンテーションを組み合わせたものです。
同じコンポーネントの中にHTMLとJavaScriptがあるわけですと。
現在は上部に全てのロジックを配置し、その下に全てのJSXを返すという方法で一応分離されてはいます。
十分に複雑なアプリケーションの場合は、そのロジックを全てコンテナに取り出すこともできます。
コンテナは全てのロジックを保持し、次のロジックを含むコンポーネントをロードしますみたいな。
とにかくJSXの恩恵を受け、開発側からの懸念事項の分流を得ることができるっていうのが
一つの強みだよというふうには言ってますと。
リアクトっていうのはブラウザードムの仮想コピーを通じてデータをレンダリングするというところからですね。
ユーザーがウェブページを開くと、インターネットブラウザーっていうのはそれをツリー上の構造に解析し、
上から下へ読み上げますと。
このツリー改造の構想のファイルをドキュメントオブジェクトモデル、ドムと呼びます。
ユーザーがページ上で何らかの操作を行った場合、ブラウザーはそのドムを再生するし、
サイン読み込みする必要があります。
これでは負荷がかかり、ブラウザーのリソースが減少してしまいますと。
リアクトは従来のドムレンダリングを回避し、ブラウザーのデータレンダリングの能力を活用したと。
リアクトチームの中心メンバーであるピート・ハント氏っていう方が、この間を
インフォワールド新にも一応寄稿したと。そういう雑誌があるんですね。
寄稿内容の引用ですけれども、
ブラウザーそのものがリテインモードですと。
画面上のHTML要素をクリックし、それを時間経過とともに変化させていくのです。
私たちがリアクトに求めたプログラミングモデルは、
基本的にすべてを捨てて再描画することでした。その方が分かりやすいと考えています。しかし、
ブラウザーはそのような仕組みにはなっていません。
そこで私たちは仮想ドムと呼ばれるものを構築して、それを抽象化しました。
基本的には仮想ドムにレンダリングし、データが変更されるために仮想ドムをすべて捨てて再生成し、それをリアクト内部で変換し、
古い仮想ドムと新しい仮想ドムっていうのを取得して、ブラウザのドムの操作に変換をしますと。
はい、というところですね。この仮想ドムが一大人気になったというか、新しい流れを作ったというのが歴史の話ですね。
はい。
ビートさんの説明をもとに、仮想ドムがどのように動作するかというのが一応理解できましたと。
別の記事のリンクも貼ってあるので、興味のある方は見てみてください。
ウェブページがウェブブラウザに読み込まれる前に、リアクトはドムのコピーを作成し、すべてのオブジェクトを新しいコンポーネントに配置します。
ユーザーがウェブページを開いたときに、リアクトは実際のドムにアクセスをせず、ドムのコピーをレンダリングします。
これは仮想ドムと呼ばれます。
ちなみに仮想ドム、自分で書いたことある方は分かると思うんですけど、単なるオブジェクトみたいな感じですね。
ユーザーがページ内を移動する間、リアクトは変更を計算しています。
ユーザーがボタンをクリックしたり、その他のアクションを実行したりすると、
リアクトはドムの新しいスナップショットというのを作成して、以前のバージョンと比較します。
09:00
さらに一つのノード要素が変更された場合、リアクトは実際のドムをレンダリングしていくページを更新します。
驚くべきことに、リアクトチームはこの仮想ドムを開発する際に、ゲームエンジンのアイディアを念頭に置いていたのであると。
ゲームエンジンのアイディアからスタートしていたんですね。
また別の引用が貼られていますね。
リアクトとの違いは、これらのアプローチとは対照的に、プログラムがデータバインディングによって、
よりゲームエンジンに近いものになることです。
あーなるほどね。
あんまりゲームエンジンの中身とか仕組みに対して詳しくないけど、そうなんやって感じですね。
さらに彼はこう説明します。
ゲームエンジンでは、マイフレームの最初に画面がクリアされ、その後シーンを再描画するのが効果的だよと言われているそうですね。
まだ考え方が結構近いですね。
仮想ドムというのは、ステートを変更してコンピューティとDiffを見つけてリレンダーをすると。
ブラウザードムというのはそうじゃなくて、ガツンと一発でリレンダーするというところがわかりやすくありますけどね。
一応今のがリアクトの話でした。
じゃあ続いてVueの話になりますね。
次のVueの話はやっぱり案の定、Evanyuの言葉が引用されていますね。
Vue.jsはバーチャルドムで動的な部分のみを追跡していると。
Vueはリアクトのバーチャルドムの考え方を踏襲はしていますが、処理方法は実は異なります。
Vueの創始者であるEvanyu氏は、リアクトのバーチャルドムを批判的に論評したと。
トロントで行われたそのプレゼンテーションでその知見を披露しましたというところで、その引用文です。
バーチャルドムによってVue構造の2つのスナップショットを比較し、実際にドムに適用すべき変更を把握できることをご存知の方もいらっしゃるかと思います。
多くの場合、比較的安価で高速に利用できます。
しかしたくさんのJavaScriptオブジェクトを再作成することになるため、やはりコストはかかりますよねと。
更新のためにツリー全体を操作して、実際に何が変更されたかを把握しなければなりません。
そしてそれはアプリケーションが大きくなるにつれてどんどん増えていくのです。
しかし仮想ドムの最悪の部分は、テンプレートにどれだけ小さな動的コンテンツがあっても、
常にツリー全体を歩き回って何が実際に変更されたかを見つけられないことですと。
いや、本当その通りだなという感じがしますね。
それに対して、VueはDOMツリーの各オブジェクト内の依存関係を追跡するようになりましたというのがこの発表の肝だったわけですね。
Vue 3.0.11の仮想ドムでは、例えばPタグにVFイコールOKみたいなものが入ったとしましょう。
こういうものを含む動的要素のみを追跡したりしています。
リアクトは16.0版リリース以降、レンダリングアルゴリズムを改良しています。
Evanは、DOMツリー内のノードをチェックするのは時間がかかるというのはその通りですねと言っています。
リアクトと比較してVueはこの技術を調整しました。
しかしこの違いを現在のリアクトに適用することはできるでしょうかと、
この問いに答えるにはいくつかの研究に挑む必要がありますよと言っています。
12:02
リアクトのバーチャルDOMというのは和解の原則に応用させます。
和解の原則ってなんだ?
わからないのでちょっと飛ばします。
はい。
既に説明したようにこのコンセプトというのは通常のDOMを変更する前に、
DOMの仮想コピーを作成して比較することを意味しています。
問題はWebブラウザを実行するJavaScriptエンジンにアプローチするときに現れます。
リアクトアプリの機能を反映させたり、DOMツリーを更新したりと、
いくつかの処理を並行して行なければならないので、
このときJavaScriptは全てのタスクをシングルスレッドで実行するということを忘れないでください。
プロップスとかステータの更新といったコンポーネントの機能を処理すると同様に、
DOM全体の変更も行わなければなりません。
ある処理に予想以上の時間がかかると、他の処理に影響を及ぼしアニメーションのクリアに繋がります。
まあまあ確かにって感じがします。
最近のWebアプリケーションは特にSaaS製品でグラフィックの繊維がある場合、
蒸気の問題は非常に重要な課題であると思われます。
一応いくつかの図がばーっと貼られているんですけど、
簡単に言うとインプットイベントがあって、タイマー図が動いて、ビギンフレームというのが動いて、
リクエストアニメーションフレームが動いて、レイアウトが動いて、ペイントして、
最後にアイドルピリオドという感じの、こういう流れですね。
Webブラウザーというのがということですね。
一応その中の、一つ一つの中にいくつかの細かい要素というのが書いてあったりします。
この辺もまあまあ見てもらえればわかりやすいなと思いますけど、
今日もまた続けて進んでいきたいと思いますね。
いやー今日多分朝勝一発で終わらない気がしますね。
これまだ今スクロール半分ぐらいしかいってないので。
はい、もしオーバーしたら明日は続けようといこうと思います。
はい、続けていきましょう。
ブラウザーは画面に表示された情報を一コマ一コマ徐々に描画していきます。
この仕事はかなりの量を処理する必要があるので、どのように進んでいくのかを見ていきましょう。
さっきの画像をちょっと言語化したものですね。
はい、一つ目がそのインプットイベント、入力イベントですね。
訪問者にできるだけ早くフィードバックを返します。
次にタイマーズですね。
パフォーマンスの時間というのを追跡してコールバック関数を実行します。
3つ目、ビギンフレームですね。
ウィンドウのサイズの変更だったり、スクロール、メディアクエリなどフレームごとのイベントをチェックします。
4つ目、リクエストアニメーションフレームですね。
こちらはその前にコールバックを実行した後、自己名関数か、ははははっていうのを実行します。
続いてレイアウトですね。
これは特定のレイアウトのスタイルと位置に応答するようになります。
6つ目、ペイントですね。
各ノード内の要素を塗りつぶして、そのサイズと位置を確保する。
最後、アイドルビリオードですね。
リクエストアイドルコールバックに登録されたタスクを実行します。
こんな感じの流れです。
このリストを見て様々な機能が含まれていることにお気づきでしょうか。
もし誰かが、例えば16マイクロ秒の時間をかけると、ページ画面上のグラフィックが中断されます。
そうするとページがシャットダウンしてしまい、ユーザーエクスペリエンスが悪くなりますよねってことです。
しかし、バージョン16かな。
以降のリアクトチームっていうのは、ツールキットのコアを完全に置き直しました。
15:01
現在はリアクトファイバーと呼ばれています。
リアクトのソースコードを見たことがある方は、確かにファイバーあるなっていうのがお気づきかもしれませんね。
これに対して、アブラモフ氏という方は、この原理をコンピューターゲームのアナロジーも使って説明しています。
あるオンラインレッスンで彼は、ゲームデザイナーがデバイス上で画面が正しく満たされない場合の問題に精通しているってことを認めました。
例えば下の部分が上の部分より早く更新されることがあります。
これはユーザーエクスペリエンスの品質に重大な影響を与えるものでした。
この問題を解決するのに役立ったのが、ダブルバッファリングと呼ばれるソリューションです。
ゲームデザイナーは同じバッファーに書き込むのではなく、別のバッファーに書き込みます。
そしてバッファーが完成したらそれを入れ替えるだけです。
というわけでリアクトは第16番からこのような仕組みになっています。
リアクトでは、機能をブラウザのDOMに影響を与えるものと、プロップスや状態の更新に関連するものに区別をしています。
コンポーネントの更新というのは一つのカテゴリー、関数にまとめられて、
ライフサイクルメソッドとDOMの変更というのは別のカテゴリー、いわゆる副作用ですね。
いわゆるサイドエフェクトにまとめられています。
この辺が最近のリアクトを考えますね。
このタスクによってプログラマーはレンダリング作業に優先順位をつけることができるようになりました。
ライフサイクルオペレーションのような最も所有される作業はアニメーションの移行作業のために延期することもできます。
一方優先順位の高いタスクは一つの給油にまとめ、より小さなタスク、つまりインクリメントで分割することができます。
このような解決策はワークユニット、いわゆるファイバーノードの実装によって可能になります。
各ファイバーはレンダリングフロー内の特定のステップに対応します。
ツリー状の構造ではなく、データの線形表現などを提案しています。
これによって処理が容易になり、エイバンが言及した時間のロスをなくすことができます。
ノードの線形構造というのはエフェクトリストとして形成されますよと。
ダン・アヴァルム氏はクリスマスツリーとイルミネーションに例えて説明するのが好きらしいですね。
ファイバーノードのツリーがあると想像してください。
ハイライズされた各ノードは特定の仕事を担当しますというふうに言っています。
一枚の画像がペッと貼られているんですけど、これを口頭で説明するのちょっと長い。
難しそうなんで、多分記事で言及している気がするんでそのまま続けますね。
画像についてはこの記事、後ほどツイートするので皆さんで読んでいただけるとありがたいです。
例に示すように最新の更新ではC2がホゲホゲって言っていたんですけど、いきなりわかりづらいな。
ざっくり言うと、A1、B1、C3みたいな各々それぞれの処理というところがグラフのツリー構造で一応表現されていて、
かつ、どちらかというとフローズに近い感じですかね。
それぞれに線が引かれていて、どのような関係性があるかみたいなことをやっています。
最近の更新ではC2が共に追加され、D2とC1が属性を変形してというふうに続けております。
説明があるんですけど、これは多分かなりわかりづらいんでちょっと割愛しますね。
新しい線形アプローチによって、リアクトアプリケーションというのは一つのスレッド内の機能に優先順位をつけて、
スケジューラーを使用してタイムラインを最適化してブラウザのリソースを節約することができます。
18:01
とはいえ、リアクトの仮想ドームのアルゴリズムというのは劇的に変化したという必要があります。
2019年にEvan Yuが説明した内容とは今は全然違いますよと。
リアクトが洗練されたのは多くのスタートアップがこのプラットフォームに移行することを促したファイバーのおかげであります。
例えばアリババは当初Vue.jsを使用していましたが現在はリアクトを使ったというぐらいドラスティックに変わったそうですね。
仮想ドームの処理の比較に対するまままとめです。
Vueのテンプレートというのはコンポーネントのミニドームを表現するのに役立ちます。
Vueは各オブジェクトを追跡する代わりに動的な部分をテンプレートで俯瞰していますと。
そのためVueのプロジェクトでは仮想ドームの操作が十分に最適化され、クライアントサイドレンダリングを活用することができます。
一方、リアクトは時間のかかる作業をスキップしたり先送りしたりすることで回避するためのファイバー技術を使っています。
開発者はレンダリングプロセスを制御しアニメーション遷移中のパフォーマンスを調節する能力を得ましたと。
それぞれアプローチが全然違う感じですね、Vueとリアクトでは。
どっちが好みかって悩ましいし、チームとかプロジェクトの状況にもよりけりなのでなんとも言えないですけど、
ここまで深い観点から技術選定したことはちょっとなかったので、かなり参考になるというか勉強になるなと思いながら読んでいます。
続いてコンポーネントデータバインディングってところですけど、
どうしようかな、時間が30分超えてしまったので、
かつ今から読むとすごい中途半端なところで終わってしまうので、一旦ここで平野で区切ろうと思います。
明日またこれを続けて読みたくなりましたので続けていこうと思います。
データバインディングオブ ザ コンポーネントから明日はちょっと入っていこうかなと思います。
一応後ほどこの記事のリンクツイートしますので興味ある方は見てみてください。
今日の朝々ここで一旦区切らせていただきたいと思います。
ずっと真剣に読んでいたらめちゃめちゃ多くの方が参加いただいてちょっとびっくりします。
ご参加いただきありがとうございました。
また明日も緩く読んでいこうと思いますのでご興味あれば聞いてみてください。
では今日ですね、金曜日、最終日、かつ今日は9月末ということで締め日ということで、
皆さん頑張っていけたらなと思います。
では終了します。お疲れ様でした。
20:00

コメント

スクロール