Vue vs React vs Angular Part.3

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2019/06/12(水) 19:04:55.46ID:x67noP4p
実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
※前スレ
Vue vs React vs Angular Part.2
https://mevius.5ch.net/test/read.cgi/tech/1552136553/
※前前スレ
Vue vs React vs Angular
http://mevius.5ch.net/test/read.cgi/tech/1545395856/

★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください
2020/05/31(日) 16:26:37.16ID:FFfnQQzy
>>395
よっぽどの職人とかじゃない限り凡人がコンパイラの最適化を超えるとかいい加減無理だろ
2020/05/31(日) 16:50:56.70ID:PGtiFJnl
>>404
「v」のある無しで展開時に詳細を出力するかどうかの違いということですよね？
これをjavascriptの話とした場合、展開時の詳細にあたるものは具体的にはなんなのでしょうか？
2020/05/31(日) 17:05:12.54ID:iwS1y3tF
初心者向けにはこの記事がわかりやすいと思う
↓
https://www.google.com/amp/s/employment.en-japan.com/engineerhub/entry/2020/02/18/103000%3famp=1

簡単に言えば
・DOMの操作はきちんとやらないとレンダリングの負荷が大きくなる
・仮想DOMはDOMの操作を上手いことやってくれるので速い
・とは言え仮想DOMを使うこと自体がオーバーヘッドなのでDOMの直接操作を無駄なく行った場合よりは遅い
2020/05/31(日) 17:51:15.80ID:x+1l8ufV
https://i.imgur.com/IFVxEh2.jpg
2020/05/31(日) 18:21:47.85ID:87/vy3Ai
コンパイルした時点で仮想DOMなんてものは無くなるので、理論的には仮想DOMを使うことによるオーバーヘッドも消せるということか。
そして>>408を見る限りはコンパイラが優秀なので実際にオーバーヘッドを消せているということかな。
まあこの実験のデータセットがリアクトコンパイラにとって有利なものだったという可能性もあるのでもう少しデータの詳細が知りたいが。
2020/05/31(日) 19:07:31.06ID:5WJ7AaAn
Domが読み込まれる前の
createdの段階で実行するから
早くなるんだろう。この段階はelもrefも

起きてないフェーズなんだから
jquery なんて使ったらモトメこうもない

台無しだろう。
2020/05/31(日) 19:12:25.04ID:5WJ7AaAn
>>410
モトメじゃなくて元もwww
2020/05/31(日) 22:15:08.01ID:JRHRMyge
>>407
> ・DOMの操作はきちんとやらないとレンダリングの負荷が大きくなる

そのとおりだが「きちんとやってないコード」っていうのがどういうものかって話なんだよな

ぶっちゃけ、どんなバカならそんなコードを書くんだよ？って
いいたくなるような話なんだよねこれ

現実にやりそうな「きちんとやってないコード」の例を
出せる人がいるなら見てみたい
そしたら（jQueryは）普通どうやるのかを俺は言えると思うね
2020/05/31(日) 22:15:41.30ID:JRHRMyge
>>409
> コンパイルした時点で仮想DOMなんてものは無くなるので、
誰がそんな話してるんだ？
無くなるわけないぞ
2020/05/31(日) 22:20:45.56ID:JRHRMyge
>>410
> Domが読み込まれる前の
> createdの段階で実行するから

もうJavaScriptの常識を忘れたのか？
DOMが読み込まれる前にJavaScriptを実行すると遅くなるだろ

jQueryの特徴の一つはDOMContentLoadedで処理をするというところ
レンダリングをブロックせずにDOMが読み込まれた直後に実行されるから速い

さらに最適化をするならば、</body>の直前でJavaScriptを読み込む
JavaScriptの実行はなるべく後で行うことで
すばやくレンダリングさせることができる。

というのは常識的な知識だったはずなんだがなぁ
2020/05/31(日) 22:22:33.40ID:JRHRMyge
結局仮想DOMのアイデアっていうのは

1. すげー遅くなるアイデアを最初に言って
2. それを改善するアイデアで相殺することで
3. 遅くならないということを、（遅いアイデアより）速くなる

と言ってるだけ
2020/05/31(日) 22:26:16.77ID:DRV8bcqm
>>415
お前が作ったわけでもねーしお前がweb準拠を策定しているわけでもねえのに何偉そうに吠えてんだよゴミカス
2020/05/31(日) 22:35:34.04ID:JRHRMyge
>>416
お前が世界を作った訳でもねーのに何偉そうに吠えてんだよゴミカス
2020/05/31(日) 22:37:06.99ID:lLPzLHf4
常識かもしれんが
バッドノウハウの類いに聞こえるな
2020/05/31(日) 23:01:44.07ID:DRV8bcqm
ゴミカスはDOM構築後にjqueryを読み込むから速いとかゴミ説明して勝ち誇ってるが
それは読み込んだだけでjqueryを何も実行しない（＝jqueryを使っていない）だけだろ
これで速いとかアホかこいつ
2020/05/31(日) 23:14:07.26ID:lymCwRQ/
>>415
これは、DOMの直接操作なら常に最適な操作ができるという前提の発想だな。
最適操作が自明な範囲しか念頭に無いんだろうな。
2020/05/31(日) 23:16:48.38ID:JRHRMyge
>>418
うん。だから俺は<head>で読み込むようにしてるよ
ファイルサイズは80KB、gzip圧縮時でわずか30KBしかない

>>419
イミフｗ
HTMLはそのまま表示するのが一番早い。デザインはもちろんCSS。
ページの初回表示時はJavaScriptを使わず単にページを表示するだだけ
静的なHTML+CSSが早いのは誰にも否定できない

そしてjQueryはそこにユーザーのアクションに対して動きをつける。
つまりユーザーが操作するまではjQueryは何もしない。だから軽い。
JavaScriptを実行しなければページが表示されないフレームワークでは太刀打ちできない
2020/05/31(日) 23:21:06.36ID:JRHRMyge
>>420
> これは、DOMの直接操作なら常に最適な操作ができるという前提の発想だな。

重要なのはそこ。最初から最適な操作ができるという前提の話をしている。

最適な操作でなければ遅くなる。理屈上はそのとおり。
では「最適な操作ができていない」というのはどういうときか？

そんなコードを書くやつがいるのか？という話をしている


仮想DOMというのは
1. 最適な操作にならない、奇抜なアイデアを持ち出す
2. 奇抜なアイデアを改善するアイデアを出す
3. （最適じゃない奇抜なアイデアを）改善したと言っている
2020/05/31(日) 23:35:08.81ID:pA4LVr9r
>>421
イミフじゃねえよ
jqueryが何もしないなら何もしねえだろが
それなら読み込みすらするなアホが
バカかコイツ
2020/05/31(日) 23:59:38.84ID:JRHRMyge
ああ、DOM構築後に何もせず、ユーザーが操作して初めて
JavaScriptの処理が走るって意味がわからんのかｗ
2020/06/01(月) 00:08:08.77ID:0Y4JhCWi
てめえが散々書いてることを自分でわかってねえだろがゴミ
jquery実行した途端におっせーじゃん
2020/06/01(月) 00:08:56.41ID:ZvU3LrYi
>>424
ユーザーが操作する前にハンドラーをアタッチするよね
現時点で存在しない動的エレメントの場合は監視もするね

まあそんなの揚げ足取りかな
2020/06/01(月) 00:18:03.32ID:Y6C/Hhni
>>425
じゃあJavaScriptオフにすれば？
なんでjQuery実行した遅くなるんだかｗ

> ユーザーが操作する前にハンドラーをアタッチするよね
> 現時点で存在しない動的エレメントの場合は監視もするね

存在しない動的エレメント（例 A要素）の監視をするならこれだけ
$(document).on('click', 'a', function() { .. })

内部的にはdocument要素に一つイベントハンドラをアタッチするだけ
さらに直接document要素にアタッチしているのではなくjQuery内部で
複数のイベントハンドラをまとめてるので、複数実行しても
DOM要素への操作は一回しか行われない。
2020/06/01(月) 01:04:02.53ID:ZvU3LrYi
jQueryは基本CSSセレクタで指定した要素に対して処理を指示するものだから、コードの簡潔化を図ろうとして極めて行くとCSSに詳しくなる
CSSのセレクタはhtmlの構造で決まるものだから、きれいなhtmlを意識する様になる
結果的にhtml、CSS、JavaScriptの3つの基本に詳しくなる

WebAssemblyは別にしてReactとかのWebフレームワークも最終的にはその3つが生成されるんだけど、見えづらいせいか少し基本を軽んじるきらいはあるんじゃないかな

ただ自分はVue使いなんだけど当然ながら素晴らしい
特にVueテンプレートファイルのhtml、CSS、JavaScriptを1つのファイルにまとめられるのは素敵
特にCSSのスコープ定義で局所化したりできるのは痺れる
WebPackの功績が大きいのかも知れないけど
Wpfのデータバインドを意識したモデル、ビュー構造も最高に好き
2020/06/01(月) 01:13:40.91ID:RpkIRyj6
WPFだと…？
2020/06/01(月) 01:21:29.25ID:Y6C/Hhni
まああれだ。雑誌編集者に対して
ボタンやらInputBoxやらアプリのUIについて
語っても殆ど意味がないのと一緒

ウェブの多くはウェブサイトで雑誌編集者が担当するような仕事
jQueryはそこに足りない動きや機能をちょっと追加するだけ
ReactやVueはアプリUIを作るためのもの
目的が全然違っている
2020/06/01(月) 02:00:33.56ID:8MAPJOWk
とりあえずこのスレ民のレベルはわかった
2020/06/01(月) 02:02:35.23ID:0Y4JhCWi
そもそもこのスレに来てわざわざjqueryスゲーを長文で連投しやがるガイジは今すぐ消えろ
構ってほしいんだろうがきしょいわ
テメーの好きな巣で一生吠えてろ
2020/06/01(月) 02:08:26.36ID:Y6C/Hhni
嫌なら見るな
2020/06/01(月) 02:12:34.25ID:0Y4JhCWi
お前が消えろボケが
スレがちがうんだよ
毎回毎回気持ち悪い
リアルでも粘着質なんだろ
早くあっち行け
2020/06/01(月) 02:41:08.49ID:Y6C/Hhni
あっちいけって言われていくわけ無いじゃんｗ
2020/06/01(月) 08:05:37.75ID:M7ivFsPk
>>422
例えば A B C という内容のリストを得たい場合、その前の状態が A B ならCを追加するのが
最適だけど A B C D だったらDを削除することになる。
生のDOM操作を最適化するというのはそういった場合分けを全部自分でやるということだからねぇ。
前の状態にかかわらず全部消してから A B C を入れなおす方が簡単だからそうする人もいるだろう。
そこはDOM操作を最適化することのメリットとデメリットのトレードオフだしな。
2020/06/01(月) 09:32:10.16ID:Y6C/Hhni
>>436
もう少し実際にありそうな例で具体的に
言ってくれないと簡単に反論できるかなぁｗ

例えば A B C という内容のリストを得たい場合
その前（現在の状態）がA Bなら以下の通りで

<ul id="list" class="a b">
<li class="a">A</li>
<li class="b">B</li>
<li class="c">C</li>
<li class="d">D</li>
</ul>

#list > li { display: none; }
#list.a > li.a { display: block; }
#list.b > li.b { display: block; }
#list.c > li.c { display: block; }
#list.d > li.d { display: block; }

$('#list').attr('class', 'a b c'); を実行すれば望んだ状態が得られる

クラスを書き換えるだけでDOMツリーは変更しないから速いことが想定できるし
CSSを変えてるだけだからブラウザが必要最小限のレンダリングを行うだろうと期待できる

DOM操作は必要最小限にしよう。これはたった一行で処理も速い。
2020/06/01(月) 11:54:00.62ID:LV1YXxu/
もうエンジニアらしくパフォーマンス計測して説明してくれよw
2020/06/01(月) 12:20:47.92ID:ELGuH/q/
フレームワーク使ってるやつが、コード書かないんだからどうしようもない
jQueryのコードはいっぱい書いてきた
しかし同等のコードをフレームワークで書き直すやつはいない
2020/06/01(月) 12:37:47.62ID:0Y4JhCWi
さすがにWebサイトごときにReact使う気にはなれんからゴミjqueryでもいいけどさぁ
まさかこのゴミ推奨委員の人はWebアプリにもjqueryでの構築を勧めんの？
2020/06/01(月) 12:52:51.61ID:SacmN/TG
>>440
逆だろ。何でもかんでも「脱jQuery」とか言い出すアホに
俺は警告してるだけ。警告っていうかお前らが「脱jQuery」とかいい始めた5年で
jQueryは更に10%以上も使われてるようになったという事実を言ってるだけだが
一方フレームワークの利用者はいまだ1%未満
2020/06/01(月) 12:58:57.44ID:0Y4JhCWi
>>441
アプリ自体がゴミ量産Webサイトより圧倒的に少ないんだから当たり前じゃん
でお前はアプリ開発もjqueryでやるの？
2020/06/01(月) 13:57:23.29ID:LV1YXxu/
もしかしてjQueryとフレームワーク両方でパフォーマンス計測するということすらできない人々が議論してたのか？
そりゃ決着つかないわ。
2020/06/01(月) 14:01:06.77ID:LV1YXxu/
みんなエンジニアなんだろ？>>408みたいな測定結果を持ってきて相手を黙らせればいいじゃん。
このデータは詳細不明なので役に立たないが。
2020/06/01(月) 17:11:11.56ID:SacmN/TG
>>442
だーかーらー、「ウェブアプリではjQueryよりもフレームワークを使おう」って
言ってれば何の問題もなかったの
「jQueryは古いから脱jQueryしようキャンペーン」がクソだっていってんの

圧倒的に多いウェブサイトで使うのはjQueryが一番適してる
今からでも遅くないんだから、俺はそう主張して回ってんのｗ
2020/06/01(月) 17:21:13.58ID:SacmN/TG
>>408
なんでいちいちサイトを隠すかね？そんなのすぐ見つけられるというのに

Comparing React.js performance vs. native DOM
https://objectpartners.com/2015/11/19/comparing-react-js-performance-vs-native-dom/

Reactを利用したいくつかの個人的な実験に取り組んでいる間に、意外にもパフォーマンスのボトルネックに遭遇しました。
さて、これは私にとってパフォーマンスの恩恵のようには感じられませんでした。インターウェブをサーフィンした後、
Reactに関する同様のパフォーマンスの懸念の事例証拠を見つけたようです。それを念頭に置いて、
私はJSを介してネイティブDOM操作で実装した代替アプローチに取り組み始めましたが、
Reactバージョンよりもパフォーマンスが優れていることがわかりましたが、実際には1対1の比較ではありませんでした。

実行時間

2000要素では、DOMバージョンはデスクトップの時間に匹敵しますが、12秒のリードで、NexusのReactより先を進みます。
4000行までに、Reactバージョンは2.25分でレンダリングするのに苦労しており、DOMバージョンの2倍以上遅いです。
なぜそうなのかをお話ししたいと思いますが、Reactバージョンでは2倍の作業を行う必要があると推測できます。
仮想DOMと実際のDOMの両方を操作してコンポーネントをレンダリングしているためです。

メモリ消費

したがって、モバイル環境でReactを検討する場合、メモリ消費は最適化するか、少なくとも認識しておく必要があるようです。
これは、環境がディスクなどに対して何らかの仮想メモリページのスワッピングを開始する必要がある場合に、
アプリ全体でReactアプリに見られる速度低下の一部である可能性があります。

概要

React.jsは、ブラウザーアプリケーションのビューレイヤーで状態を管理するための優れたアプローチであることは間違いありません。
しかし、私自身の限られた経験から、レンダリングに費やされた時間から消費されたメモリの量をそのまま比較するだけでなく、
Reactのようなライブラリから得られる便利さに対して支払うべき明確な代償があります。
純粋なパフォーマンスの観点からは、特定の問題に対する純粋なJS DOMアプローチを評価することにはいくつかのメリットがあるように思われます。
2020/06/01(月) 17:28:38.28ID:GTAzkg2N
こんなくだらない論争してないでRecoilの展望について語れよ
2020/06/01(月) 17:31:25.34ID:RpkIRyj6
5年前の変な日本語ｗｗｗ
2020/06/01(月) 17:33:30.63ID:SacmN/TG
>>448
Google先生に文句言うな！
2020/06/01(月) 17:35:01.23ID:SacmN/TG
>>447
あと3つぐらい似たようなものが登場するんじゃね？
んで、1年後ぐらいにRecoilはもうオワコンとか言われる
普及する前にオワコンｗｗｗ
2020/06/01(月) 18:42:27.73ID:0Y4JhCWi
Webサイトしか作れないコーダーって悲しいよな
わざわざWebアプリ用のフレームワークに噛み付いて勝ち誇って何がしたいんだか

シェア74％？
へーすごいね
一生使ってろ
2020/06/01(月) 18:43:29.19ID:1M1uJIUJ
このように技術の話を、人の話にすり替えるのが流行ってるのか？
2020/06/01(月) 18:46:20.43ID:1M1uJIUJ
jQueryは〜、 Vueは〜

↓

お前はコーダーだ、お前はjQuery使ってろ、お前は！お前は！


こんな感じｗ
2020/06/01(月) 19:00:51.83ID:YLFWVkAE
だって人の話だから
jQueryじゃなくてスレタイも読めないキチガイに怒ってるだけ
2020/06/01(月) 20:39:10.04ID:wdhscBPR
>>451
そんな奴このスレにいないよ。
みんな大学で情報理論についてみっちり学び、研究室ではpythonでMLの研究に携わって、その傍らアルバイトでwebサービスの開発をして小遣い稼ぎ、その後メーカーに就職してC言語で組み込みに励んだあとにIT企業に転職してマネージャーになってコーディング卒業してるから。
webサイト作成は趣味兼副業のアフィblogのためにやってるだけだろう。
2020/06/01(月) 20:48:13.50ID:l4HIPpsU
実際ReactはWebアセンブリで消える可能性ある
jQueryは素人とかWebサイト用に残る
俺はjQueryよりReactの方が好きだけど
2020/06/01(月) 20:52:59.65ID:M7ivFsPk
>>437
隠してるだけじゃんｗ
データが刻々変化するWebアプリみたいなものは全然念頭に無いんだろうな。
2020/06/01(月) 21:31:57.98ID:0Y4JhCWi
>>455
底辺組み込みをそこまで自慢しなくてもw
2020/06/01(月) 21:33:22.10ID:0Y4JhCWi
>>456
そう
それは俺が前からここで言ってる
いまWebComponentを策定中だからあくまでもそれまでの繋ぎでしかない
2020/06/01(月) 21:33:28.89ID:xlNGyQiU
>>457
だから具体例を言えと言ってる
データが刻々変化する？だからなんだ？
CSSでグラフでも作ってwidthの%で表現すればいいんか？

って簡単に俺に反論されるやろ？
だからできないような具体的な例を考えてこいと言ってる
2020/06/01(月) 21:35:46.98ID:xlNGyQiU
>>459
WebComponent登場でVue、React、Angularの設計が大きく変わって
また覚え直しになるのが目に見えてるんだよなｗ

WebComponentだと配布の容易性からフレームワークを
使わないで実装するのが流行るだろう

jQueryはそのコンポーネント同士を繋ぐ役目をするものだから
WebComponentの時代でも生き残る
2020/06/01(月) 21:42:45.19ID:M7ivFsPk
>>460
具体例って、

<ul>
<li>A</li>
<li>B</li>
<li>C</li>
</ul>

を

<ul>
<li>A</li>
<li>B</li>
<li>C</li>
<li>D</li>
</ul>

にするとかそういうレベルで言わないと理解できないんだろうか。
2020/06/01(月) 21:48:41.87ID:xlNGyQiU
>>462
そうそう。そんなんでいい。それをVueとか好きなフレームワークで書いてみ
2020/06/01(月) 21:49:22.79ID:xlNGyQiU
っていうか、最初の例じゃねーかｗ
それ要素を非表示にするだけでいいだろ
なんでそんな事しねぇといけなんだ。
そこからちゃんと説明しろって
2020/06/01(月) 22:14:07.76ID:M7ivFsPk
スタイルで非表示にすればいいじゃんてのは結局直接DOM操作するのが大変だからだよなぁ。
UNIXのtopコマンドみたいなのはただ隠すだけじゃ無理があるし。
2020/06/01(月) 22:23:29.85ID:lf51+gry
>>406
寧ろコンソールへの表示の有無で解凍速度変わるって知らんの？
画面表示って結構オーバーヘッドなんやけど
2020/06/01(月) 22:39:38.12ID:80Xi+K8a
場末のスナック＝コボル＝jQuery
2020/06/01(月) 22:41:03.24ID:0Y4JhCWi
>>461
覚え直しなわけねーじゃん
jqueryごときで脳みそ固定されてっからお前には苦痛だろうが新しく出たって1日で覚えられるわい
2020/06/01(月) 23:11:58.91ID:betc8EO5
jquery先生マジでwebアプリ知らんのなｗ
2020/06/01(月) 23:15:49.58ID:xZL8Ap71
>>466
いや、だからjavascriptでそれにあたるものはなんなんでしょうか？という質問なんですけど…
2020/06/01(月) 23:23:52.92ID:xZL8Ap71
正直なところリアルDOMと仮想DOMの関係をtarコマンドに例えられたのが理解できず混乱してしまったんですが、この例えって適切なんでしょうか？
2020/06/01(月) 23:33:51.15ID:mCx+eQal
このスレの内容読んでも正しい理解から遠ざかるだけだよ
2020/06/01(月) 23:43:52.04ID:QvRK6jc/
>>404、>>466
この2つの書き込みのわかってる感はすごい。
きっと明快な説明をしてくれるはず。
2020/06/02(火) 06:14:17.57ID:YnHhgZXY
>>465
だから自分で無駄なアルゴリズム（つまり仮想DOM）考えて
無駄なアルゴリズム効率化したよ！っていうのはやめろと
最初から軽量なアルゴリズムを使えばいい
隠すだけでいいなら隠すだけでいい

> UNIXのtopコマンドみたいなのはただ隠すだけじゃ無理があるし。
一つのテキストエリアに代入すればいいだけでは？ｗ
2020/06/02(火) 06:15:58.34ID:YnHhgZXY
>>468
> 覚え直しなわけねーじゃん

ん？捨てるだけっていいたいんですかね？ｗ
今までフレームワークで作っていたものが
ブラウザネイティブでできるようになったから
フレームワークは不要になると

どこかで聞いた話ですなぁｗ
2020/06/02(火) 07:48:36.94ID:PNH+YxIC
>>474
>一つのテキストエリアに代入すればいいだけでは？ｗ

結局、リストやテーブルで>>436のような更新を効率よくやるのはあきらめたと。
2020/06/02(火) 08:25:02.26ID:YnHhgZXY
>>476
効率（？）よりも素早く表示できることが重要じゃね？
2020/06/02(火) 10:35:55.98ID:aF6gXvXJ
Webアプリ作れないのにわざわざjqueryサイコーしに来るなゴミ
2020/06/02(火) 13:42:07.54ID:EzV2+lxf
>>478
嫌なら見るな
2020/06/02(火) 14:44:07.39ID:Jz8TBM1T
フレームワークを使った場合とそうでない場合の比較をこのスレでしても本題が進まないしな。俺はjqueryをNGにすることにしたよ。
2020/06/02(火) 14:47:06.27ID:Jz8TBM1T
jqueryおじはフレームワークの普及などで、プログラミングが簡単なものになっていくのが我慢できないタイプの人なんだと思う。(よくいる)
彼らの楽してプログラムする人への嫌がらせは絶対に止めさせられないと思うのでNGするしかないよ。
2020/06/02(火) 14:49:13.98ID:Jz8TBM1T
気持ちはわかるけどね。
プログラムの敷居が下がることは自分自身の価値の低下に繋がるし、自分が技術習得のために費やした時間が無駄になるように感じてしまう。この感覚は本当に怖いもんだ。
2020/06/02(火) 14:55:08.02ID:EzV2+lxf
>>481
逆だな。シンプルでいいものを古いってだけで複雑化させるなと
手段が目的になってることに警告している
2020/06/02(火) 16:14:12.52ID:Jz8TBM1T
>>483
いやだからその話はスレチなのよ。ここはフレームワークを使うことを前提に話すところだからね。
あなたの指摘について話してると本題が進まないから皆迷惑してる。
2020/06/02(火) 16:19:26.38ID:XUL0AfH0
このスレは統合失調症に住み着かれてしまったんだ、あきらめろ。
統失は自分の頭の中と人の頭の中の区別がついてないらしいから、自分が迷惑してなければまさか他人が迷惑しているなんて想像もつかないらしいぞ。オワタ
2020/06/02(火) 20:51:59.38ID:PNH+YxIC
>>477
結局>>420の指摘の通りなんだろ？
生DOMで最適な操作がすぐわかるならやるけどそうでなけりゃDOM操作以外でお茶を濁すと。
2020/06/02(火) 21:20:05.39ID:y2pssUuQ
ここからUIコンポーネントのライブラリについての話
2020/06/02(火) 22:53:42.91ID:22TYrFrm
emotion と styled-component ってどっちがおススメ？
2020/06/02(火) 23:36:43.83ID:HsElvnUb
>>486
生DOMで最適な操作がわからないことを
今までやったことがあるか？
2020/06/03(水) 00:49:20.55ID:IabKp2q1
フレームワーク使わないとサーバーとの通信回線が大分増えそう
2020/06/03(水) 02:37:33.67ID:8UYALONQ
増えそう（予想ｗ）
2020/06/03(水) 07:20:24.72ID:XM98eiL0
ReactはJSXが慣れなかった
Blazorは生HTMLそのまま書けてとても良い
ただ速度は遅いのか・・・容量重い見たいだし
2020/06/03(水) 08:18:46.73ID:PFUYBSjI
>>489
>>436のように状況によって判断する必要があって最適操作というものが多岐にわたる場合はあるよな。
実際jQuery君は逃げたし。
494デフォルトの名無しさん
垢版 |
2020/06/03(水) 12:19:20.95ID:acb2GgKY
>>493
おい、勝手に逃げたことにするなよｗ
仕事しろよｗ
495デフォルトの名無しさん
垢版 |
2020/06/03(水) 12:20:40.45ID:acb2GgKY
っていうか逃げたって言うほどレス進んでねーじゃんｗ

> >>436のように状況によって判断する必要があって最適操作というものが多岐にわたる場合はあるよな。

だからやったことがあるのかと
2020/06/03(水) 12:44:29.95ID:JLhL0PQJ
アーナル
497デフォルトの名無しさん
垢版 |
2020/06/03(水) 12:49:02.20ID:acb2GgKY
あとフレームワークなら最適だっていうけど、
本当に最適になってるのかという問題がある

A
B
C

を

C
B
A

に書き換える場合、一体何回のDOM操作を行うのか？
そこがはっきりしないといかんよな
2020/06/03(水) 13:02:55.71ID:Y4Wo8X9c
頼むからその話もうやめてくれ…
499デフォルトの名無しさん
垢版 |
2020/06/03(水) 13:03:48.50ID:acb2GgKY
嫌なら見るなｗ
2020/06/03(水) 13:09:37.28ID:iKVvtebg
荒らしにかまうな。このスレには荒らしが住み着いている。その事実を受け入れろ。
2020/06/03(水) 14:17:44.99ID:llXSixd1
Angular派ってどこにいるの
2020/06/03(水) 22:58:56.19ID:7+I+fFTj
angular派ってめんどくさいけど覚えたコスト無駄にしたくないから使ってるってだけでしょ
2020/06/03(水) 23:30:27.85ID:IabKp2q1
ソートこそ最後の最終結果だけを描画する仮想DOMで早くできる分野なんじゃない？
2020/06/04(木) 01:22:45.15ID:LYOI3JL5
俺はReact使ったことない、Vueは超簡単な入門書一冊やっただけ、でangular使ってる。用途は自社サーバーの管理ツールとして使用するwebサイト開発。
もともとWPFでデスクトップアプリの開発の経験があったんだが、それと似てるからかすっと馴染んで凄く使いやすいと思ってる。
まあそもそもフロントエンドは一般教養レベルの技術しか持ってないところから始めたから感覚が全然違うだけなんかな。
2020/06/04(木) 01:33:13.27ID:LYOI3JL5
Angularでありがたいのは、公式サイトのドキュメント一通り勉強して身に付けた定石に従えばOKなところかな。
ReactとVueはあまり詳しくないのでわからないけど、フロントエンド開発は何が正攻法なのかわからなくて悩んでしまうイメージがある。もちろん経験が浅い故の悩みなんだろうけど。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況