Vue vs React vs Angular Part.3

**デフォルトの名無しさん** · 2019/06/12(水) 19:04:55.46

実際どうなん？
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(日) 23:35:08.81

>>421
イミフじゃねえよ
jqueryが何もしないなら何もしねえだろが
それなら読み込みすらするなアホが
バカかコイツ

**デフォルトの名無しさん** · 2020/05/31(日) 23:59:38.84

ああ、DOM構築後に何もせず、ユーザーが操作して初めて
JavaScriptの処理が走るって意味がわからんのかｗ

**デフォルトの名無しさん** · 2020/06/01(月) 00:08:08.77

てめえが散々書いてることを自分でわかってねえだろがゴミ
jquery実行した途端におっせーじゃん

**デフォルトの名無しさん** · 2020/06/01(月) 00:08:56.41

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

まあそんなの揚げ足取りかな

**デフォルトの名無しさん** · 2020/06/01(月) 00:18:03.32

>>425
じゃあJavaScriptオフにすれば？
なんでjQuery実行した遅くなるんだかｗ

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

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

内部的にはdocument要素に一つイベントハンドラをアタッチするだけ
さらに直接document要素にアタッチしているのではなくjQuery内部で
複数のイベントハンドラをまとめてるので、複数実行しても
DOM要素への操作は一回しか行われない。

**デフォルトの名無しさん** · 2020/06/01(月) 01:04:02.53

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.91

WPFだと…？

**デフォルトの名無しさん** · 2020/06/01(月) 01:21:29.25

まああれだ。雑誌編集者に対して
ボタンやらInputBoxやらアプリのUIについて
語っても殆ど意味がないのと一緒

ウェブの多くはウェブサイトで雑誌編集者が担当するような仕事
jQueryはそこに足りない動きや機能をちょっと追加するだけ
ReactやVueはアプリUIを作るためのもの
目的が全然違っている

**デフォルトの名無しさん** · 2020/06/01(月) 02:00:33.56

とりあえずこのスレ民のレベルはわかった

**デフォルトの名無しさん** · 2020/06/01(月) 02:02:35.23

そもそもこのスレに来てわざわざjqueryスゲーを長文で連投しやがるガイジは今すぐ消えろ
構ってほしいんだろうがきしょいわ
テメーの好きな巣で一生吠えてろ

**デフォルトの名無しさん** · 2020/06/01(月) 02:08:26.36

嫌なら見るな

**デフォルトの名無しさん** · 2020/06/01(月) 02:12:34.25

お前が消えろボケが
スレがちがうんだよ
毎回毎回気持ち悪い
リアルでも粘着質なんだろ
早くあっち行け

**デフォルトの名無しさん** · 2020/06/01(月) 02:41:08.49

あっちいけって言われていくわけ無いじゃんｗ

**デフォルトの名無しさん** · 2020/06/01(月) 08:05:37.75

>>422
例えば A B C という内容のリストを得たい場合、その前の状態が A B ならCを追加するのが
最適だけど A B C D だったらDを削除することになる。
生のDOM操作を最適化するというのはそういった場合分けを全部自分でやるということだからねぇ。
前の状態にかかわらず全部消してから A B C を入れなおす方が簡単だからそうする人もいるだろう。
そこはDOM操作を最適化することのメリットとデメリットのトレードオフだしな。

**デフォルトの名無しさん** · 2020/06/01(月) 09:32:10.16

>>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.62

もうエンジニアらしくパフォーマンス計測して説明してくれよw

**デフォルトの名無しさん** · 2020/06/01(月) 12:20:47.92

フレームワーク使ってるやつが、コード書かないんだからどうしようもない
jQueryのコードはいっぱい書いてきた
しかし同等のコードをフレームワークで書き直すやつはいない

**デフォルトの名無しさん** · 2020/06/01(月) 12:37:47.62

さすがにWebサイトごときにReact使う気にはなれんからゴミjqueryでもいいけどさぁ
まさかこのゴミ推奨委員の人はWebアプリにもjqueryでの構築を勧めんの？

**デフォルトの名無しさん** · 2020/06/01(月) 12:52:51.61

>>440
逆だろ。何でもかんでも「脱jQuery」とか言い出すアホに
俺は警告してるだけ。警告っていうかお前らが「脱jQuery」とかいい始めた5年で
jQueryは更に10%以上も使われてるようになったという事実を言ってるだけだが
一方フレームワークの利用者はいまだ1%未満

**デフォルトの名無しさん** · 2020/06/01(月) 12:58:57.44

>>441
アプリ自体がゴミ量産Webサイトより圧倒的に少ないんだから当たり前じゃん
でお前はアプリ開発もjqueryでやるの？

**デフォルトの名無しさん** · 2020/06/01(月) 13:57:23.29

もしかしてjQueryとフレームワーク両方でパフォーマンス計測するということすらできない人々が議論してたのか？
そりゃ決着つかないわ。

**デフォルトの名無しさん** · 2020/06/01(月) 14:01:06.77

みんなエンジニアなんだろ？>>408みたいな測定結果を持ってきて相手を黙らせればいいじゃん。
このデータは詳細不明なので役に立たないが。

**デフォルトの名無しさん** · 2020/06/01(月) 17:11:11.56

>>442
だーかーらー、「ウェブアプリではjQueryよりもフレームワークを使おう」って
言ってれば何の問題もなかったの
「jQueryは古いから脱jQueryしようキャンペーン」がクソだっていってんの

圧倒的に多いウェブサイトで使うのはjQueryが一番適してる
今からでも遅くないんだから、俺はそう主張して回ってんのｗ

**デフォルトの名無しさん** · 2020/06/01(月) 17:21:13.58

>>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.28

こんなくだらない論争してないでRecoilの展望について語れよ

**デフォルトの名無しさん** · 2020/06/01(月) 17:31:25.34

5年前の変な日本語ｗｗｗ

**デフォルトの名無しさん** · 2020/06/01(月) 17:33:30.63

>>448
Google先生に文句言うな！

**デフォルトの名無しさん** · 2020/06/01(月) 17:35:01.23

>>447
あと3つぐらい似たようなものが登場するんじゃね？
んで、1年後ぐらいにRecoilはもうオワコンとか言われる
普及する前にオワコンｗｗｗ

**デフォルトの名無しさん** · 2020/06/01(月) 18:42:27.73

Webサイトしか作れないコーダーって悲しいよな
わざわざWebアプリ用のフレームワークに噛み付いて勝ち誇って何がしたいんだか

シェア74％？
へーすごいね
一生使ってろ

**デフォルトの名無しさん** · 2020/06/01(月) 18:43:29.19

このように技術の話を、人の話にすり替えるのが流行ってるのか？

**デフォルトの名無しさん** · 2020/06/01(月) 18:46:20.43

jQueryは～、 Vueは～

↓

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

こんな感じｗ

**デフォルトの名無しさん** · 2020/06/01(月) 19:00:51.83

だって人の話だから
jQueryじゃなくてスレタイも読めないキチガイに怒ってるだけ

**デフォルトの名無しさん** · 2020/06/01(月) 20:39:10.04

>>451
そんな奴このスレにいないよ。
みんな大学で情報理論についてみっちり学び、研究室ではpythonでMLの研究に携わって、その傍らアルバイトでwebサービスの開発をして小遣い稼ぎ、その後メーカーに就職してC言語で組み込みに励んだあとにIT企業に転職してマネージャーになってコーディング卒業してるから。
webサイト作成は趣味兼副業のアフィblogのためにやってるだけだろう。

**デフォルトの名無しさん** · 2020/06/01(月) 20:48:13.50

実際ReactはWebアセンブリで消える可能性ある
jQueryは素人とかWebサイト用に残る
俺はjQueryよりReactの方が好きだけど

**デフォルトの名無しさん** · 2020/06/01(月) 20:52:59.65

>>437
隠してるだけじゃんｗ
データが刻々変化するWebアプリみたいなものは全然念頭に無いんだろうな。

**デフォルトの名無しさん** · 2020/06/01(月) 21:31:57.98

>>455
底辺組み込みをそこまで自慢しなくてもw

**デフォルトの名無しさん** · 2020/06/01(月) 21:33:22.10

>>456
そう
それは俺が前からここで言ってる
いまWebComponentを策定中だからあくまでもそれまでの繋ぎでしかない

**デフォルトの名無しさん** · 2020/06/01(月) 21:33:28.89

>>457
だから具体例を言えと言ってる
データが刻々変化する？だからなんだ？
CSSでグラフでも作ってwidthの%で表現すればいいんか？

って簡単に俺に反論されるやろ？
だからできないような具体的な例を考えてこいと言ってる

**デフォルトの名無しさん** · 2020/06/01(月) 21:35:46.98

>>459
WebComponent登場でVue、React、Angularの設計が大きく変わって
また覚え直しになるのが目に見えてるんだよなｗ

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

jQueryはそのコンポーネント同士を繋ぐ役目をするものだから
WebComponentの時代でも生き残る

**デフォルトの名無しさん** · 2020/06/01(月) 21:42:45.19

>>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.87

>>462
そうそう。そんなんでいい。それをVueとか好きなフレームワークで書いてみ

**デフォルトの名無しさん** · 2020/06/01(月) 21:49:22.79

っていうか、最初の例じゃねーかｗ
それ要素を非表示にするだけでいいだろ
なんでそんな事しねぇといけなんだ。
そこからちゃんと説明しろって

**デフォルトの名無しさん** · 2020/06/01(月) 22:14:07.76

スタイルで非表示にすればいいじゃんてのは結局直接DOM操作するのが大変だからだよなぁ。
UNIXのtopコマンドみたいなのはただ隠すだけじゃ無理があるし。

**デフォルトの名無しさん** · 2020/06/01(月) 22:23:29.85

>>406
寧ろコンソールへの表示の有無で解凍速度変わるって知らんの？
画面表示って結構オーバーヘッドなんやけど

**デフォルトの名無しさん** · 2020/06/01(月) 22:39:38.12

場末のスナック＝コボル＝jQuery

**デフォルトの名無しさん** · 2020/06/01(月) 22:41:03.24

>>461
覚え直しなわけねーじゃん
jqueryごときで脳みそ固定されてっからお前には苦痛だろうが新しく出たって1日で覚えられるわい

**デフォルトの名無しさん** · 2020/06/01(月) 23:11:58.91

jquery先生マジでwebアプリ知らんのなｗ

**デフォルトの名無しさん** · 2020/06/01(月) 23:15:49.58

>>466
いや、だからjavascriptでそれにあたるものはなんなんでしょうか？という質問なんですけど…

**デフォルトの名無しさん** · 2020/06/01(月) 23:23:52.92

正直なところリアルDOMと仮想DOMの関係をtarコマンドに例えられたのが理解できず混乱してしまったんですが、この例えって適切なんでしょうか？

**デフォルトの名無しさん** · 2020/06/01(月) 23:33:51.15

このスレの内容読んでも正しい理解から遠ざかるだけだよ

**デフォルトの名無しさん** · 2020/06/01(月) 23:43:52.04

>>404、>>466
この2つの書き込みのわかってる感はすごい。
きっと明快な説明をしてくれるはず。

**デフォルトの名無しさん** · 2020/06/02(火) 06:14:17.57

>>465
だから自分で無駄なアルゴリズム（つまり仮想DOM）考えて
無駄なアルゴリズム効率化したよ！っていうのはやめろと
最初から軽量なアルゴリズムを使えばいい
隠すだけでいいなら隠すだけでいい

> UNIXのtopコマンドみたいなのはただ隠すだけじゃ無理があるし。
一つのテキストエリアに代入すればいいだけでは？ｗ

**デフォルトの名無しさん** · 2020/06/02(火) 06:15:58.34

>>468
> 覚え直しなわけねーじゃん

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

どこかで聞いた話ですなぁｗ

**デフォルトの名無しさん** · 2020/06/02(火) 07:48:36.94

>>474
>一つのテキストエリアに代入すればいいだけでは？ｗ

結局、リストやテーブルで>>436のような更新を効率よくやるのはあきらめたと。

**デフォルトの名無しさん** · 2020/06/02(火) 08:25:02.26

>>476
効率（？）よりも素早く表示できることが重要じゃね？

**デフォルトの名無しさん** · 2020/06/02(火) 10:35:55.98

Webアプリ作れないのにわざわざjqueryサイコーしに来るなゴミ

**デフォルトの名無しさん** · 2020/06/02(火) 13:42:07.54

>>478
嫌なら見るな

**デフォルトの名無しさん** · 2020/06/02(火) 14:44:07.39

フレームワークを使った場合とそうでない場合の比較をこのスレでしても本題が進まないしな。俺はjqueryをNGにすることにしたよ。

**デフォルトの名無しさん** · 2020/06/02(火) 14:47:06.27

jqueryおじはフレームワークの普及などで、プログラミングが簡単なものになっていくのが我慢できないタイプの人なんだと思う。(よくいる)
彼らの楽してプログラムする人への嫌がらせは絶対に止めさせられないと思うのでNGするしかないよ。

**デフォルトの名無しさん** · 2020/06/02(火) 14:49:13.98

気持ちはわかるけどね。
プログラムの敷居が下がることは自分自身の価値の低下に繋がるし、自分が技術習得のために費やした時間が無駄になるように感じてしまう。この感覚は本当に怖いもんだ。

**デフォルトの名無しさん** · 2020/06/02(火) 14:55:08.02

>>481
逆だな。シンプルでいいものを古いってだけで複雑化させるなと
手段が目的になってることに警告している

**デフォルトの名無しさん** · 2020/06/02(火) 16:14:12.52

>>483
いやだからその話はスレチなのよ。ここはフレームワークを使うことを前提に話すところだからね。
あなたの指摘について話してると本題が進まないから皆迷惑してる。

**デフォルトの名無しさん** · 2020/06/02(火) 16:19:26.38

このスレは統合失調症に住み着かれてしまったんだ、あきらめろ。
統失は自分の頭の中と人の頭の中の区別がついてないらしいから、自分が迷惑してなければまさか他人が迷惑しているなんて想像もつかないらしいぞ。オワタ

**デフォルトの名無しさん** · 2020/06/02(火) 20:51:59.38

>>477
結局>>420の指摘の通りなんだろ？
生DOMで最適な操作がすぐわかるならやるけどそうでなけりゃDOM操作以外でお茶を濁すと。

**デフォルトの名無しさん** · 2020/06/02(火) 21:20:05.39

ここからUIコンポーネントのライブラリについての話

**デフォルトの名無しさん** · 2020/06/02(火) 22:53:42.91

emotion と styled-component ってどっちがおススメ？

**デフォルトの名無しさん** · 2020/06/02(火) 23:36:43.83

>>486
生DOMで最適な操作がわからないことを
今までやったことがあるか？

**デフォルトの名無しさん** · 2020/06/03(水) 00:49:20.55

フレームワーク使わないとサーバーとの通信回線が大分増えそう

**デフォルトの名無しさん** · 2020/06/03(水) 02:37:33.67

増えそう（予想ｗ）

**デフォルトの名無しさん** · 2020/06/03(水) 07:20:24.72

ReactはJSXが慣れなかった
Blazorは生HTMLそのまま書けてとても良い
ただ速度は遅いのか・・・容量重い見たいだし

**デフォルトの名無しさん** · 2020/06/03(水) 08:18:46.73

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

**デフォルトの名無しさん** · 2020/06/03(水) 12:19:20.95

>>493
おい、勝手に逃げたことにするなよｗ
仕事しろよｗ

**デフォルトの名無しさん** · 2020/06/03(水) 12:20:40.45

っていうか逃げたって言うほどレス進んでねーじゃんｗ

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

だからやったことがあるのかと

**デフォルトの名無しさん** · 2020/06/03(水) 12:44:29.95

アーナル

**デフォルトの名無しさん** · 2020/06/03(水) 12:49:02.20

あとフレームワークなら最適だっていうけど、
本当に最適になってるのかという問題がある

A
B
C

を

C
B
A

に書き換える場合、一体何回のDOM操作を行うのか？
そこがはっきりしないといかんよな

**デフォルトの名無しさん** · 2020/06/03(水) 13:02:55.71

頼むからその話もうやめてくれ…

**デフォルトの名無しさん** · 2020/06/03(水) 13:03:48.50

嫌なら見るなｗ

**デフォルトの名無しさん** · 2020/06/03(水) 13:09:37.28

荒らしにかまうな。このスレには荒らしが住み着いている。その事実を受け入れろ。

**デフォルトの名無しさん** · 2020/06/03(水) 14:17:44.99

Angular派ってどこにいるの

**デフォルトの名無しさん** · 2020/06/03(水) 22:58:56.19

angular派ってめんどくさいけど覚えたコスト無駄にしたくないから使ってるってだけでしょ

**デフォルトの名無しさん** · 2020/06/03(水) 23:30:27.85

ソートこそ最後の最終結果だけを描画する仮想DOMで早くできる分野なんじゃない？

**デフォルトの名無しさん** · 2020/06/04(木) 01:22:45.15

俺はReact使ったことない、Vueは超簡単な入門書一冊やっただけ、でangular使ってる。用途は自社サーバーの管理ツールとして使用するwebサイト開発。
もともとWPFでデスクトップアプリの開発の経験があったんだが、それと似てるからかすっと馴染んで凄く使いやすいと思ってる。
まあそもそもフロントエンドは一般教養レベルの技術しか持ってないところから始めたから感覚が全然違うだけなんかな。

**デフォルトの名無しさん** · 2020/06/04(木) 01:33:13.27

Angularでありがたいのは、公式サイトのドキュメント一通り勉強して身に付けた定石に従えばOKなところかな。
ReactとVueはあまり詳しくないのでわからないけど、フロントエンド開発は何が正攻法なのかわからなくて悩んでしまうイメージがある。もちろん経験が浅い故の悩みなんだろうけど。

**デフォルトの名無しさん** · 2020/06/04(木) 01:49:57.54

Webフロントエンドはまだ流行り廃りが激しいから、どれが正解とかは一概には言えない部分がある
が旧来のやり方で作られてるものだろうとなんだろうとWeb標準に従っていれば今後動かなくなるということはまずないので、そこは安心していい（ライブラリやフレームワークが保守されなくなることはあるが）
これから新しくやるならとりあえずそのとき一番流行ってるものを使ってみるといいと思う
トレンドの追い方は色々あるだろうけど、今から把握するならこことかおすすめ
https://2019.stateofjs.com/front-end-frameworks/

**デフォルトの名無しさん** · 2020/06/04(木) 06:02:07.69

>>503
実際に速いのかどうか。やってみないとわからない。

**デフォルトの名無しさん** · 2020/06/04(木) 06:03:24.48

>>505
> フロントエンド開発は何が正攻法なのかわからなくて悩んでしまうイメージがある。
そうではなく絶賛開発中だからだよ
一年後にはやり方が変わってる

**デフォルトの名無しさん** · 2020/06/04(木) 06:50:57.10

Javascript はweb制作管理板、CGI はWEBプログラミング板へ。

**デフォルトの名無しさん** · 2020/06/04(木) 07:47:14.48

>>495
ああ、書き方が悪かったな。DOMを使わない手段で逃げたということ。
仮想DOMの効率を比較するうえで挙げた例なのにな。

**デフォルトの名無しさん** · 2020/06/04(木) 07:48:59.07

>>510
手段が目的になってるね
フレームワークの欠点はCSSベースのよりよい方法
軽くてシンプルな方法が採用できないってのも上げておくか

**デフォルトの名無しさん** · 2020/06/04(木) 08:14:52.94

最初に挙がった話がDOM操作の効率比較なんだから当たり前。頭沸いてんのか？
それと、なんでフレームワークだとCSSが使えないと思い込んでいるんだろう。

**デフォルトの名無しさん** · 2020/06/04(木) 09:21:09.23

どうしてもこのスレでその話を続けないといけないのか？

**デフォルトの名無しさん** · 2020/06/04(木) 10:59:00.78

>>512
フレームワークでDOM操作効率化なんてしてんの？
俺ならHTML文字列を組み立てて代入するだけだなぁ
これならDOM操作は一回じゃね？

**デフォルトの名無しさん** · 2020/06/04(木) 12:41:52.47

>>514
DOM構築後は固定かよ
クソじゃん

**デフォルトの名無しさん** · 2020/06/04(木) 13:30:21.25

>>515
フレームワーク使って変えるよりも
jQuery使って変えたほうが効率的ってことだよ

**デフォルトの名無しさん** · 2020/06/04(木) 13:51:39.87

こちらに適切なスレがあるからこっちで話してね

Vue vs React vs Angular vs jQuery Part.3
https://mevius.5ch.net/test/read.cgi/tech/1560333177/

**デフォルトの名無しさん** · 2020/06/04(木) 13:54:38.79

向こうのスレでも答えが出てるなｗ

> 文字列でhtml作ってdivにまとめてブチ込むのが簡単だし高速

**デフォルトの名無しさん** · 2020/06/04(木) 13:59:59.62

いまHTML5パーサー書いてて一通りの実装が済んだんだけど、次の部品を製造するとしたら、何が求められるんだろね？
パーサーのテスト実装が途中の状態だけど。

**デフォルトの名無しさん** · 2020/06/04(木) 14:02:39.64

WHATWG Encoding standardとWHATWG HTML Standard の Parsing まで実装した。
Chromeがどうやら属性値のエスケープなどごく一部を除いて改行の移動する位置まで厳格に仕様通りなので、Chromeの出力をテストデータにしてるけど。

**デフォルトの名無しさん** · 2020/06/04(木) 14:03:39.87

というより、Chromeのアルゴリズムをそのまま仕様にしてるのかね。

**デフォルトの名無しさん** · 2020/06/04(木) 14:10:11.05

Chromeがなぜ属性値のエスケープを仕様通りにしないのかも気になる。
パーシングと直列化を繰り返すと危険なHTMLに変化させることが出来るのだろか？
もしそうなら仕様の方を修正してほしい。