1 名前:デフォルトの名無しさん mailto:sage [2022/03/08(火) 22:57:16.85 ID:D77bZcWT0.net] !extend:on:vvvvv:1000:512 Vue https://jp.vuejs.org/ React https://reactjs.org/ Angular https://angular.io/ Svelte https://svelte.dev/ ※前スレ Vue vs React vs Svelte Part.7 https://mevius.5ch.net/test/read.cgi/tech/1610901677/ Vue vs React vs Angular vs Svelte Part.8 https://mevius.5ch.net/test/read.cgi/tech/1621744952/ Vue vs React vs Angular vs Svelte Part.9 https://mevius.5ch.net/test/read.cgi/tech/1642316774/ ★ここではjQuery, Ruby, C#, Blazorの話題は禁止です ★jQuery, Ruby, C#, Blazorキチガイが書き込んでも無視してください Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおk。 VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured
100 名前:デフォルトの名無しさん mailto:sage [2022/03/29(火) 22:38:01.87 ID:a2KK+TKpM.net] >>95 this 使うのvue3ちがうよ。
101 名前:デフォルトの名無しさん mailto:sage [2022/03/29(火) 23:48:30.54 ID:xxVtcj7qa.net] blazor
102 名前:デフォルトの名無しさん mailto:sage [2022/03/30(水) 07:39:00.66 ID:ojoAdHT2M.net] BlazorはC♯で全部やりたいって人以外にはメリット無くね……
103 名前:デフォルトの名無しさん mailto:sage [2022/03/30(水) 09:43:48.12 ID:zC4eLKs90.net] ×ゲームでしかない
104 名前:デフォルトの名無しさん mailto:sage [2022/03/30(水) 10:47:39.46 ID:iu76Nwkv0.net] Reactを使うのかVueを使うのかについて個人的なモチベーションを整理したかった https://zenn.dev/marokanatani/articles/compare_vue_and_react > VueはEasy、ReactはSimple わかる
105 名前:デフォルトの名無しさん mailto:sage [2022/03/30(水) 12:16:39.31 ID:OOkK5m9Na.net] まぁvueは個人開発の延長よね
106 名前:デフォルトの名無しさん mailto:sage [2022/03/30(水) 23:06:07.37 ID:ZV6rQOSL0.net] vueはフレームワーク独自のルールが多かったり業務でちゃんと使うにはVSCode等のエディタの拡張機能が無かったら辛かったりで、慣れすぎてしまうと悪い意味でvue以外が使えなくなってしまう感じがする
107 名前:デフォルトの名無しさん mailto:sage [2022/03/31(木) 01:46:33.94 ID:86aTlM7E0.net] たしかにいまvue(nuxt)で開発してるけど わりとめんどくさいとこあるね typescriptを使わなければそうでもないのかもだけど
108 名前:デフォルトの名無しさん mailto:sage [2022/03/31(木) 10:50:34.39 ID:oSy/YhOk0.net] vueは確かに使ってると楽なんだよね ただ、何でもフレームワークがやってくれるから根本のプログラミングに対する考え方が深まらずにvueをどんだけ長く使っても「ただvueに慣れた」で終わってしまうことになると思う reactはちゃんと使おうと思ったら ・javascriptの文法 ・関数型プログラミングとは何か ・副作用とは何か みたいに、深いとこまで突き詰める必要があるからreactを使いたくない人はこういうのを嫌がる その代わりreactに習熟すると他のjavascriptフレームワークや他の言語にも活かせるような考え方が身につくと個人的には思ってる
109 名前:デフォルトの名無しさん mailto:sage [2022/03/31(木) 11:20:24.39 ID:aHZxCmZf0.net] よくReactは関数型プログラミングって言われてるけどあんまり分かってないわ そもそも関数型言語に対する理解が足りないんだろうけど今まで書いてた手続き型言語(C++/Python)とそこまで書き方に違いがあるかって言われると謎だし 移行して違和感あったのは if (is_hoge === true && do_hoge()){} みたいなのだけどこれは関数型関係ないだろうしなぁ
110 名前:デフォルトの名無しさん mailto:sage [2022/03/31(木) 15:19:18.41 ID:F2XPsESOa.net] >>106 ぶっちゃけ関数型言語的なのはクロージャくらいだよ 型があると話が変わってくるけど素のJSならそれくらい
111 名前:デフォルトの名無しさん mailto:sage [2022/03/31(木) 15:58:23.58 ID:iKma4XC/r.net] useEffect地獄
112 名前:デフォルトの名無しさん mailto:sage [2022/03/31(木) 18:21:07.43 ID:k0INsa2ta.net] useEffectめっちゃシンプルだと思うけど
113 名前:デフォルトの名無しさん mailto:sage [2022/04/02(土) 21:07:33.40 ID:NF+PiVrF0.net] hooksで良いなと思った部分は副作用とマークアップ部分が綺麗に分離できるようになったことだな それによってコンポーネント内の副作用の影響等が把握しやすくなったり、カスタムフックで自分好みに複数のフックをまとめて抽象化出来たりするからコードの可読性も上がったように思う
114 名前:デフォルトの名無しさん [2022/04/02(土) 22:03:18.78 ID:phShoyKu0.net] createRootとrender分けろって警告で出したね。 シンプルじゃないなぁ
115 名前:デフォルトの名無しさん mailto:sage [2022/04/02(土) 22:39:16.37 ID:WPblCx5D0.net] その警告をしてシンプルでないとする理由がわからん
116 名前:デフォルトの名無しさん mailto:sage [2022/04/02(土) 22:48:49.10 ID:B/N6Fa/fa.net] ごちゃごちゃに書きたがる人っているよね
117 名前:デフォルトの名無しさん mailto:sage [2022/04/02(土) 23:53:46.13 ID:GrEAMzhIa.net] >>97 いや、抜本的に変わったのは3.2とかだったろ
118 名前:デフォルトの名無しさん mailto:sage [2022/04/04(月) 18:57:54.46 ID:TKeyZlO5M.net] スマホアプリのデータをWebでも編集できるようにしたくて 色々調べてく中でここにたどり着いたんだけど なんかWebフレームワークは乱立した感じになってるのね… 調べてもどれを使うべきなのかよく分からない githubの星くらいしか参考データもなく でも>>101 さんのリンク先記事が参考になった 別にそんなにライブラリは使わないし、規模の小さい個人開発はVue.jsで良さげなのかなと
119 名前:デフォルトの名無しさん mailto:sage [2022/04/04(月) 23:40:42.03 ID:EAh2hm0B0.net] webアプリ初心者が両方ちょこちょこ触ってみてvue使ってるよ なんかpinia好きだわ コード打ち込みはreactが楽しいね 正直たいしたものつくらないから優位性はよくわからん
120 名前:デフォルトの名無しさん [2022/04/05(火) 00:02:53.38 ID:4sgd/Hm90.net] reactはカスタムレンダラーがすごいらしい
121 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 02:34:36.17 ID:NrUXKx3F0.net] > 次世代のReact? Solid.jsについて https://zenn.dev/nicky/articles/754f0ca74c887a もうReactの天下も終わりかぁ早かったなぁ
122 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 06:54:29.03 ID:bH2gxj8m0.net] 100歩譲ってReactの終わりの始まりだとして、それ、React系の流れを汲んだ技術じゃん。今はとりあえずReact使っといて(本当に流行ってから移行しても)問題ないように見える
123 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 07:17:54.78 ID:HsXfDOwGM.net] Solidは仮想DOMを使わないため高速 さらにReactでの無駄なレンダリングも抑えている Reactを採用するモチベーションがない
124 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 07:54:01.75 ID:bH2gxj8m0.net] 仮想DOM使ってないから速いってのは木を見て森を見ずでは?
125 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 08:10:00.23 ID:VqqpMSri0.net] reactやvuejsでアプリケーションを構築しててパフォーマンスが問題だと感じる場面に遭遇したことはあるが、大量のデータをフェッチしていたり自分のコードの書き方が悪かったりで、reactやvuejs自体が問題に感じるようなことは無かったなあ
126 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 09:09:02.03 ID:+EK3ySaMM.net] 比較した?
127 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 10:11:51.52 ID:ZReMvbtfM.net] >>118 これいいね 週末に試してみる
128 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 13:26:52.69 ID:ETld5ZoPr.net] なんでReactは仮想DOMつかってるの? メリットはなんですかい?
129 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 14:59:22.43 ID:6a13xz8Z0.net] jQuery みたいに実DOM を扱わない。 仮想DOM変更時には、自動的にDOM木の差分を計算し、差分部分だけを実DOMに反映させる ただし、メモリは実DOM・仮想DOMの2つを持つので、2倍使う
130 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 15:19:17.06 ID:0YlujQsY0.net] 実際普及して移行ツールが出たら起こして
131 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 15:48:51.29 ID:raev6Saea.net] >>125 それ言われてハッとしたわ 今や差分検出と書き換えをやるメリットってほぼない気がする 本当に必要なのはJSXとHooksであって仮想DOM入らんかも
132 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 15:54:41.73 ID:raev6Saea.net] Reactの"次"が見えてきたな
133 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 16:30:16.36 ID:aekYSBQXM.net] Webフロント門外漢は知らないかもしれないけど実DOMの変更はレンダリング処理とか入ってそこそこコスト重いんだよ。 最近はtemplateのslotとかあって必要なとこだけ更新しやすくなったけど、それでも。
134 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 16:48:05.27 ID:SCn4t5fAM.net] 仕事中なのでこっそりドキュメント読んだだけだけどかなりよくできてそう Solid.js普及するといいね👍 個人的にRNよく使うからそっち方面もサポートしてくれれば最高です(仮想DOMないと流石に厳しいか?)
135 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 17:20:25.99 ID:u+FS9OX10.net] その重いっていうのを数字で見せてくれる人がいないのよね 正直10年前の比べてマシンスペックも上がったし 大した差はないんじゃないの? むしろ差分検出なんてことをやることのほうが重い可能性
136 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 17:54:05.17 ID:ETld5ZoPr.net] Solid.jsって名前がダサい
137 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 17:56:06.60 ID:u+FS9OX10.net] >>133 確かに 今の時代これはないわ
138 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 18:15:07.55 ID:3u8+O//Xa.net] これreactじゃなくてsvelteが死ぬんだろな
139 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 18:39:10.39 ID:zCnZtIiB0.net] 新しいのでてくるの
140 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 18:41:37.46 ID:6a13xz8Z0.net] 差分検出は軽いでしょ? 各ノードに、変更の有無のフラグを持つだけじゃないの?
141 名前:デフォルトの名無しさん [2022/04/05(火) 19:45:00.74 ID:wCKcIEh+0.net] もう速度くらいでシェアは変わらんよ 重要なのは開発体験の方だ
142 名前:デフォルトの名無しさん [2022/04/05(火) 20:26:33.63 ID:G2ThUmqoa.net] パフォーマンスばっかり言及されてるけどこれのスゴイ所はhooksのトップレベル制約、明示的なキャッシュ処理、依存関係の記述から開放されることだろう reactを踏襲しつつ弱点を見事に解消してる完全な進化系だからもうreactを選ぶ理由がない(レガシーのメンテ以外では)
143 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 20:35:42.86 ID:ETld5ZoPr.net] Solid.jsは誰がつくったの?
144 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 20:38:38.09 ID:3tK/podq0.net] これが流行るかは別だけどreactが文句のつけようのないものってわけではないよね 競合相手のvueがそれ以上に迷走してるだけで
145 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 20:41:35.88 ID:bH2gxj8m0.net] >>139 そこから開放されても、(広い意味での)状態の取り扱いは残るし、あんまり魅力的とは思わないな。 どうしてもReactを過去のものにしたいようだけど。どっちも使えば良いだけなわけで。
146 名前:デフォルトの名無しさん mailto:sage [2022/04/05(火) 23:59:41.42 ID:Pmd2Ul1s0.net] reactとnextjsってどっちがいいの?
147 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 01:39:52.94 ID:xqee3k0P0.net] たまには Angular のことも思い出してあげてください
148 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 12:57:39.21 ID:DIJBOrU7r.net] 誰も答えられないの? なんでReactは仮想DOMつかってるんすか
149 名前:デフォルトの名無しさん [2022/04/06(水) 13:07:19.26 ID:K22cA7Fi0.net] 仮想DOMを使うのは現状一番速度とコードの少なさでバランスが取れてるから あとReactは自由にレンダラーをすげ替えられるから、もっといい方法があるなら 仮想DOMを使わないReactレンダラーを作って実装してそれを使えばいい だからReactを離れる必要はない
150 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 13:14:26.43 ID:S/lTt5hhM.net] マルチプラットフォーム対応とかかな? Solid.jsは仮想DOMを捨てたからモバイル移植が難しいと予想
151 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:00:54.13 ID:7agkb2pSM.net] >>146 仮想DOMは使えば有利というものではないからそれは難しいところですね >>147 仮想DOMとマルチプラットフォーム対応は無関係ですね
152 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:02:45.11 ID:S/lTt5hhM.net] 仮想DOMという抽象化レイヤでプラットフォーム間の差分を大部分吸収できるのでマルチプラットフォーム対応しやすくなるのでは?
153 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:03:19.50 ID:6A9Aeuema.net] >>145 上で書いてるだろw DOM全体を書き換えるとブラウザの描画パフォーマンスが落ちるのよ jQueryおじさんがinnerHTMLに丸ごとぶち込むようなコードだよ 一方JSXはユーザーからはinnerHTMLに全部突っ込むコードを毎回生成しているように書いてるけど 中では差分だけ見てるというトリック これこそが仮想DOMのメリット
154 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:09:22.87 ID:CIB91XNYM.net] >>150 そのメリットは仮想DOMを使わずとも可能なので仮想DOMのメリットではなく差分書き換えのメリットですね そして差分書き換えのみと比較すると仮想DOMを用いる分だけデメリットですね
155 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:14:46.50 ID:6A9Aeuema.net] >>151 1番大きいのはユーザー体験だよ 該当箇所のDOMを丸ごと毎回生成する処理を書くだけでいいのだから 以前はDOMの状態をみて書き換える箇所を自分で判断してた それこそがjQueryなコードをスパゲッティにした原因なのよ
156 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:18:36.04 ID:6A9Aeuema.net] パフォーマンス速くしたいからDOMの差分を自分で見る→コードがスパゲッティ 差分見るとスパゲッティになるからDOMを毎回丸ごと生成したい→innerHTMLに突っ込むしかなくてパフォーマンス劣化 この悪循環の無限ループ これを両方同時に解決したのが仮想DOMでありReact 俺が信者になったのはこれを意識した時だな マジで神だと思ったね
157 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:19:52.73 ID:6A9Aeuema.net] ここにいるのに仮想DOMメリットを言語化できるやついなかったのな 上のような事実というか歴史的経緯があるんだよ しっかりと理解してくれ
158 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:22:06.41 ID:so8tWsAwa.net] 別に仮想dom使わなくても良いんだよ あくまでレンダリング高速化の手段の一つ reactが差分管理として仮想domを採用しただけの話であって他に良いのが出て来ればそれに変わられていくだけ ただdomと密接に結合するようなレンダラーと差分管理を分離しないアプローチは流行らない webにしか使えなくなる
159 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:40:06.43 ID:DIJBOrU7r.net] >>150 Solid.jsとsvelt.jsはDOM全体を書き換えてるの?
160 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 14:46:33.31 ID:6A9Aeuema.net] >>156 流石にそれはない ソース読まないとわからんが別な方法で管理してるのだと思う
161 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 15:13:32.10 ID:6A9Aeuema.net] >>155 まあ仮想DOMはメモリをバカ食いするデメリットはありからね 他の方法で差分管理できなら問題ない Reactの次が見えてきた
162 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 15:28:45.86 ID:34Ai9MwnM.net] >>156 コンポーネント(DOM)を生成するのは最初の1回だけで 生成した後はObserverパターンで必要なところだけ更新するようだよ ソースまだ読んでないからハッキリしたことは言えんが多分そんな感じ
163 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 15:38:00.45 ID:0AiZA7OjM.net] 仮想DOMツリーを使わずに差分管理する場合、変化する部分に状態管理機構(solid.jsで言えばsignal、webcomponentsで言えばslot)を打ち込む形になる。 差分管理する要素が少なく、DOMツリーをダイナミックに動かさないのであればsolid.jsのようなやり方に速度的なメリットがあり、そうでなければReactに速度や構造的なシンプルさのメリットがある。そんな感じじゃないかな。 よく知らんけど
164 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 16:59:40.38 ID:DIJBOrU7r.net] >>157 いやおまえが仮想DOM使わないと全書き換えって言ったから聞いたんじゃん
165 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 18:06:05.81 ID:6A9Aeuema.net] >>161 それはミスだ そこまで深く調べてなかった 多少コード読んだら状態管理とか変更履歴で管理してるっぽくて想像以上にガチな作りだった
166 名前:デフォルトの名無しさん mailto:sage [2022/04/06(水) 23:43:10.09 ID:ZzbxJvPPr.net] >>162 お詫びに全部調べて報告して
167 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 00:07:39.33 ID:isNt/bVX0.net] ちゃんとミスを認めてる奴に何言ってんだ、あんた
168 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 08:50:29.10 ID:48p+VEp60.net] こうやって素直にミスを認めて謝れる人めっちゃ好感持てる
169 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 09:08:43.91 ID:XKd8bK6Ir.net] でも俺の疑問はまったく解決してない ・なぜReactは仮想DOMを使っているのか? ・仮想DOMを使わなくても一部のレンダリング更新だけで済むってのか? ・そうであればブラウザのエンジン自体が部分レンダリングに対応しているのか? ・じゃあReactの仮想DOMのメリットってなんなの
170 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 09:20:11.52 ID:hrFCTtmgM.net] >>166 仮想DOM自体にはメリットは全く無くむしろオーバヘッドというデメリットがある DOMの差分更新は非常に重要で全体更新よりも圧倒的にパフォーマンスが高い DOMの差分更新はSvelteでもSolidでも各種Vanillaでも当然行われているが仮想DOMは用いられていない それらと比較してベンチマークなどでReactが遅い原因の一つとして仮想DOM使用によるオーバヘッドが考えられうる
171 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 09:24:25.64 ID:Fux/mDxCM.net] う〜ん、粛々とNG
172 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 09:35:03.84 ID:NNETluvMd.net] Reactでいう仮想DOMというのは本来は単なるフレームワークの実装の都合ってわけじゃなく、 テンプレートがレンダリング結果としてDOMオブジェクトを返しているように見えるけど実際にはそうじゃないから仮想DOMなんだよ。 Vueみたいに単なる実装の都合で内部的に仮想DOM使ってるのと比較されるからそのへん混同されがち。 その意味だとSolid.jsはどうなんだろうね。まだ触ったことないからわからないけど、テンプレートは直接DOMオブジェクトを生成するの?
173 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 09:41:42.27 ID:XKd8bK6Ir.net] 仮想DOMってただのjavascriptオブジェクトの階層構造だよね 部分レンダリング更新ってのは、この全体の階層構造のうちの一部の階層のオブジェクトが更新されて、その階層に該当するDOMだけが再レンダリングされるってことかね その階層ってのはShadowRoot単位なのかな? 想像だけど
174 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 10:05:30.92 ID:NMZY0DQdM.net] >>170 まず仮想DOMは全く関係ないので忘れて横に置いとくといいよ 実DOMを生成する時に全体を生成するのではなく現状の一部を利用して最小限のパーシャルツリーを作って入れ替えるのが部分レンダリング更新 ブラウザによる画面レンダリングも最小限となりメリットがある 今どきのフレームワークならたいてい採用されている この実現のために仮想DOMは必要としない 一方で仮想DOMは一部のフレームワークが採用している単なる内部のデータ管理方式の一つ 仮想DOMが他の方式と比べて何か有利な点は特にない 実行時に差分検出となるなど不利な点はある
175 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 10:12:41.10 ID:kSgW/1GfM.net] 「高速」の比較対象はpostして全部更新だったりする?
176 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 11:08:03.68 ID:XKd8bK6Ir.net] >>171 なるほど つまり ReactやVueはデータ管理を仮想DOMで管理してる Solid.jsやSvelt.jsはデータ管理を実DOMで管理してる この認識であってる? なぜデータ管理を実DOMで管理してるんだ?って思うけど、仮想DOM使ってないなら実DOMしかないよねってこと
177 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 12:29:30.17 ID:n/T89jyuM.net] >>173 それは正しくない どのフレームワークもデータ変更に対応して最終的に実DOM操作をして反映させる点では全て同じ データ変更がどういう時に
178 名前:ヌこで起きるかはプログラム作成時にわかっているので SvelteやSolidはそれらの情報を利用してある種のコンパイラとなり実DOM操作のJavaScriptコードを事前に生成してしまう つまりSvelteやSolidは実行時にはその生成されたJavaScriptコードが動くだけ 一方でVueやReactはデータ変更に対して仮想DOMに反映させて前後の差分検出をしてその差分を反映させるために実DOM操作をする [] [ここ壊れてます]
179 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 12:31:19.31 ID:cPE2iAv8M.net] >>173 たぶん誤解してる。仮想DOMの使用有無にかかわらず、実際のビューの状態を持っているのは常に実DOMだ。 仮想DOMが登場するのはビューの状態を更新するときで、仮想DOMの場合は論理的には(実際には更新不要な部分は使い回すような最適化はある)モデルの状態に基づいて毎回新しい仮想DOMツリー全体を作り直し、 その仮想DOMツリーをあるべき姿として実DOMを更新する。 一方で仮想DOMを使わない場合は、仮想DOMツリーの作り直しを省いて直接実DOMを更新する。
180 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 14:42:30.41 ID:XKd8bK6Ir.net] >>174 SolidやSveltのその操作用のjavascriptのコード生成ってどんな感じ? いまいち想像が足りないからわからん コードってなに? 具体例がほしいかな >>175 React : データ更新 → 仮想DOM更新 → 実DOM更新 Solid :データ更新 → 実DOM更新 こういうこと? このSolidの直にDOM更新ってどうやってツリー全体のうちの差分を算出してるんだろ? 差分とか関係なくjqueryみたいに要素を特定して更新してるのかな?
181 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 16:11:00.06 ID:LqaqpZCDM.net] SolidはデータバインディングしてるだけだからDOM上のどこを更新すればいいか最初からわかってる となると負荷がかかるだけの大げさなツリー差分計算は不要かと reactがツリー差分を計算するのは何処が変わるのかreactが把握してないから Solidはreactに似てるけど根本的なアーキテクチャは違う
182 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 16:30:15.09 ID:zMYtvFpYM.net] >>176 普通にフレームワークを使わずに書けばわかるけど 差分算出なんて全く必要のない行為 必要となるのは変更されたデータを反映するDOM操作のJavaScriptコードのみ
183 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 16:57:53.58 ID:bdIQHoGja.net] おじさんじゃねーのこれ
184 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 17:26:41.04 ID:OoJ9MQRv0.net] メモ化しなかったら子コンポーネントの要素を再度全てレンダリングしちゃうのでは?
185 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 19:00:26.65 ID:I9ZZKEcZM.net] それぞれそのへんはムダを省くよう仕掛け対応があるね フレームワークとして最低限それはやらないと
186 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 19:32:20.92 ID:XKd8bK6Ir.net] 結局みんなはっきりは理解していない感じらしいね まあ自分もなんだけど
187 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 19:52:15.69 ID:W1OrHRUza.net] >>182 で?
188 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 20:04:09.90 ID:XKd8bK6Ir.net] >>183 へ?
189 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 22:07:48.47 ID:rftQE35ra.net] solid.js作者による解説記事見つけたよ 正直震えてる アーキテクチャがやば過ぎ オワコンと言われた Reactive Programmingが復活した https://indepth.dev/posts/1289/solidjs-reactivity-to-rendering
190 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 22:17:52.74 ID:rftQE35ra.net] この記事でDOMの更新原理が全部解説されてる ただ理解が追いついてない
191 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 22:44:32.35 ID:isNt/bVX0.net] 何処でReactiveプログラミングが終わって、何処で復活したんだよ。 パラダイムの話と実装の話をごっちゃにしとらんかね。
192 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 22:49:48.63 ID:LqaqpZCDM.net] >>185 いいね
193 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 23:03:21.84 ID:w+H2FlaC0.net] createElememtしたオブジェクトをクロージャで保持してるのか 確かに生DOMだ
194 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 23:06:10.92 ID:cxGwbYOU0.net] 記事はいいけど >正直震えてる >アーキテクチャがやば過ぎ こういうの傍から見て寒すぎ
195 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 23:35:57.90 ID:LqaqpZCDM.net] DOMそのまま掴んでるってことはReact Nativeは絶望的か…ちと残念だ
196 名前:デフォルトの名無しさん mailto:sage [2022/04/07(木) 23:57:10.55 ID:Y0BVj7bxa.net] ペインの中のボタンを40近くまで連打すると詰まりだすけどreactならどうなんだろうか https://www.solidjs.com/tutorial/introduction_memos?solved
197 名前:デフォルトの名無しさん mailto:sage [2022/04/08(金) 00:02:15.46 ID:FwPcQFITM.net] >>192 フィボナッチ数の計算がべらぼうに重いだけだよ
198 名前:デフォルトの名無しさん mailto:sage [2022/04/08(金) 00:06:04.66 ID:pHvgxp+Ea.net] >>193 探したらあったのでやってみたらその通りでしゅた。 https://codesandbox.io/embed/yh4nf?codemirror=1
199 名前:デフォルトの名無しさん mailto:sage [2022/04/08(金) 11:42:33.12 ID:SI2R8TLia.net] >>191 RN的な使い方は無理だろね メモリとんでも無い事になりそう シンプルなWEBページ特化
200 名前:デフォルトの名無しさん mailto:sage [2022/04/08(金) 14:27:38.41 ID:FwPcQFITM.net] メモリは心配してないというか仮想DOMが無いから確実に減る でも仮想DOMが無いせいでDOMと結合度が高くなってるからマルチプラットフォームは難しいだろう