元スレ+ JavaScript の質問用スレッド vol.132 +

JavaScript覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

601 = :

element.classList.add() / element.classList.remove() のことか？

602 = :

>>601
ん？あったんですか？
メソッドも揃ってるなら、そろそろ脱jQueryしてみてもいい時期なのかもしれませんね

603 = :

>>602
何でも揃ってるよ

604 = :

揃える髪も無いくせに・・・

605 = :

ちょっと前に
子ノードに探してるものがあるかどうかのチェックの質問あって
forで探せよっておこられてたけど
あれもメソッドがあるw

608 = :

>>602
> メソッドも揃ってるなら、そろそろ脱jQueryしてみてもいい時期なのかもしれませんね
脱jQueryを目的としている時点でjQueryは使い続けられることが
容易に想像できるよな。手段が目的になってるわけだから

残念ながらDOM APIにあるのはjQueryのサブセットだ
更に言うならば事あるごとにループが必要でjQueryのような
簡潔な記述は到底不可能だ

DOM APIが勝っているのは、実行速度と初回ダウンロードサイズだが
実行速度はマシンスペックの高さでスマホでも問題になってないし
ダウンロードサイズはCDNを使うことで他のサイトのキャシュが活かせる
そうなるとライブラリを使わないほうが記述量は増えるので
現実的にはjQueryを使ったほうがサイズが減ることも多い

609 = :

ところでCDN使うってことは
CDNにどこからのアクセスかリファラでバレてしまうってことだよね？

610 = :

>>608
各サイトでバージョンバラッッバラなんだが…
加えてminじゃない奴使ってるクソサイトまで…

611 = :

>>610
バラバラでも無限にあるわけじゃないしw

それから自分のサイトから配信するよりもCDNを使ったほうが高速で、
自分のサイトのトラフィックを減らすという効果もある
全部自分で書くと、その分自分のサイトで配信する量が増えてしまうが
jQueryにそれを逃してやると、減らせるわけさ

612 = :

イベントリスナの掃除とかまで考えると
もうjQuery使えばいいじゃんってなりますね
jQueryを使わなくなるのは、jQueryの代わりをしてくれるライブラリやフレームワークを使う時なのかも

613 = :

リスナの掃除・・・？

614 = :

>>592-598
JavaScript, jQuery で作れる

615 = :

>>597
あるよ
jQueryは機能の拡充ではなくて基盤から提供し直す
ライブラリというよりフレームワークに近いものだから

617 = :

>>615
> ライブラリというよりフレームワークに近いものだから
プログラマが書いたコードから呼び出すのがライブラリ
プログラマが書いたコードを呼び出すのがフレームワーク
jQueryはどうみてもライブラリだ

618 = :

そもそもjQueryを使うデメリットってありますか？

619 = :

もちろん仮想DOM勢には劣るものの大抵のサイトの規模ならDOM操作の保守性は少し上がるかな。ただ一ヵ所二ヵ所くらいしかDOM操作しないのに導入するとたったそれだけのためにjQueryという巨大コードのパースが完了するまで待たされる。容量も増える。
一ヵ所二ヵ所くらいならDOMAPIで書けやと思うじゃん。
ところがあいつら書かないんじゃなくて書けないんだよな。
調べる気もなし。
強いていうならそういうゴミを量産してしまうのがデメリット。

620 = :

労力と生産性
人生には限りがある
時間を大切にね

621 = :

forループ内でsetTimeout書いてsetTimeoutの中の処理がおわったら次のループに行くようにしたいんだけど
どうすればいいのでしょう?

for () {
for () { setTimeout() }
}
な感じです。

623 = :

>>620
jQueryを導入する無駄な時間を大切にね

624 = :

>>619
> もちろん仮想DOM勢には劣るものの大抵のサイトの規模ならDOM操作の保守性は少し上がるかな。ただ一ヵ所二ヵ所くらいしかDOM操作しないのに導入するとたったそれだけのためにjQueryという巨大コードのパースが完了するまで待たされる。容量も増える。

はっきり書いておきましょう。

ただ一ヵ所二ヵ所くらいしかDOM操作しないのに
"仮想DOM" を導入すると
多数のJavaScriptファイルを読み込んだ上に
HTMLを大きく書き換えないといけないから
仮想DOM勢、つまりReactは導入されないんですよ

625 = :

ついでに仮想DOMが敗北したという話を見つけたので書いておきますね

http://html5experts.jp/shumpei-shiraishi/21754/

> laco しかし、仮想DOMは速かったけど、Angularも追いついちゃいましたね。
> しかも仮想DOMなしで。結局仮想DOMってどうだったのかなあ…と。
> 「ポイント、そこじゃなくない？」っていう(笑)。 (筆者注: ここ、lacoさんがイベントを盛り上げるため煽ってくれてます)
>
> koba04 まあ、仮想DOMだからこそ、ただの関数みたいな形でコンポーネントを簡単に作れるようになったので…。
>
> laco でも、最近Pure Componentって入ったじゃないですか。Shallow Rendererとか。
> あれってどうなんですか？この間ものすごく疑問に思って。Pure Componentにすると、
> オブジェクトの状態を自動で見て、自動で変更検知してくれるってやつですよね。 あれって、Reactがやりたかったことなんですか？
>
> koba04 あれは、オブジェクトツリーがでかくなると仮想DOM比較のコストもバカにならないので、
> その比較すらも飛ばしたい時に使うっていう感じです。
>
> laco 仮想DOMのアルゴリズムが敗北したってことじゃないですか？(笑)
>
> shumpei 煽る煽る(笑)。
>
> koba04 基本的にはそこまで必要とするものでもなくて、よっぽどパフォーマンスが求められる場面で使われるものかなと思っています。
>
> yosuke_furukawa ぼくとしては、パフォーマンスのチューニングポイントが増えたって話だと思ってます。
> 仮想DOMの敗北については、次のサーバーサイドレンダリングでぼくが話をするんで、まあここはこれくらいでいいんじゃないかなと(笑)。

626 = :

・一度使い出したら全部作り直す覚悟がないと使うのをやめられない
・そんなん要りません

627 = :

>>624
日本語読めないのかなｗ
>>619が言ってるのは一ヵ所二ヵ所のDOM操作はノー仮想DOMノーjQuery、Yes生DOMAPIだよ？ｗ
藁人形論法かな？ｗ

628 = :

>>621
Promiseで包んでawaitで待てばそれっぽいのは出来るけど
あくまでもそれっぽいでしかない
http://jsfiddle.net/ug62rr01/1/

629 = :

ajax依存のサイトのアクセス解析って一体どうやってるの？

630 = :

>>627
アホがｗ そんなことわかってるわ

>>619が一箇所二箇所しかDOM操作をしないなんて
実際にはありえない例を持ち出してきたから、

一箇所二箇所しか使わないのが世の中にありふれてるんじゃなぁ
仮想DOMなんて流行りませんわなｗｗｗ
っていう皮肉言ってんだろうが

631 = :

生jsで書くのってそんな面倒臭い？
設計段階に比べたら時間も労力も全然かからないから
気になったことがないんだけど

632 = :

IEのどのバージョンまで対象にするかによる

633 = :

>>631
面倒くさい。特に同じ要素が複数あったら嫌になる。
書くのも面倒だし読むのも面倒
本質ではない処理が大半を締め、あれじゃバグはなくならないと思う
関数型言語を勉強すると良いよ

634 = :

>>630
流行る流行らないじゃなく一ヵ所二ヵ所のDOM操作ならjQueryだろうが仮想DOMだろうが等しく無駄。無能の証明。
ゴキブリ潰すのに戦車がないと戦えませんと言って泣いているようなもの。

635 = :

DOM APIが基本的に手続き型の構造をしているのが問題
一行ずつ処理を眺めていないと最終的な結果がわからない

それに対してjQueryだとコードが宣言的になる。
「なになに（セレクタ）は、こうだ」という風に宣言的に書けるから
状態を気にしなくて良くなる。

それはCSSの書き方と違い。（CSSも宣言的な言語）

636 = :

>>634
> ゴキブリ潰すのに戦車がないと戦えませんと言って泣いているようなもの。

ゴキブリ潰すのにはスリッパ（jQuery）で十分戦えますよ？
例えが変ですねｗ

637 = :

>>633
同じ要素が複数で面倒って意味がわからない
腕が悪いやつのHTML設計で苦労させられてる感じ？

638 = :

>>632
IE9とIE9以前が対象に入ることがなくなってきた
平和でいいわ

639 = :

>>635
DOMガチャガチャいじらなきゃならない場合結局DOMの初期状態から操作ごとにどのようにDOMが変化するか実行順に追ってかないとセレクトスカるが…
操作対象全要素にidふってあれば別だが。

640 = :

>>637
普通コンポーネント的に設計しますよね？
例えば画面上にJavaScriptで拡張された入力フィールドが複数あるとか

jQueryを使うと一つだけでも複数あっても
まったく同じ書き方ができます。

それはCSSと同じなんですよ。

.klass { color: red } とすると
class=klassである要素が全て赤になります。
同等のことをjQueryで書くと
$('.klass).css({color: 'red'}) です。
CSSと文法が少し違うだけと考えられます。

でもDOM APIじゃこうは行きません

641 = :

>>639
> DOMガチャガチャいじらなきゃならない場合結局DOMの初期状態から操作ごとにどのようにDOMが変化するか実行順に追ってかないとセレクトスカるが…

そういう書き方になっちゃうからDOM APIはだめなんですね。
バグが減らないといったのはそういうことです。

642 = :

いやjQueryの話だよ。

643 = :

DOM APIの話でしょ？ 同じことをDOM APIですると
もっとひどいことになるんですからｗ

644 = :

>>640
それこそ意味がわからない
同じイベントハンドラ関数を適用すれば良いのでは
上位層でまとめて面倒みてもいいし
処理が少し違うだけなら大部分を再利用可能に作ればいいし

645 = :

いや、jQuery。
DOMを操作するんだから操作前と操作後でDOMが変化するのは変わらん。
その状態にあったセレクタ書くには結局上から見てくしかない。

646 = :

>>644
> 同じイベントハンドラ関数を適用すれば良いのでは
今はイベントハンドラの話なんかしてませんが？

647 = :

>>646
じゃあ「例えば画面上にJavaScriptで拡張された入力フィールドが複数あるとか」のところを
もっと具体的に話してもらえないかな
どんな状況で何がどう面倒なのか全然わからない

648 = :

>>645
> DOMを操作するんだから操作前と操作後でDOMが変化するのは変わらん。

それが間違った使い方。DOMを操作するとメンテナンス性が下がる
DOMは基本操作してはいけない。見た目を変えたいならそれはCSSでやるべきこと
見た目はCSSというのは、なんども言われてる話だろ

CSSで変えるのだから、ウェブデザイナが手動でclassを変更することで
JavaScriptを必要とせずに、状態に応じた見た目を作ることができる。
作業の分担ができる。JavaScriptでやるのは状態（クラス等）を変えるのみ

DOM APIでDOMをガシガシ操作なんかするからバグ減らないんだよ。

649 = :

ある要素から特定の親の要素取得するのってどうやってやるの？
jQueryでいうところの .parents('.foo') みたいなの
.parent() は .parentNode で取れるけど .parents('.foo') にあたるのはないよね
parentNode でループしながら
if (element.classList.contains('foo')) するしかないのかな

650 = :

>>648
おいおいjQueryは基本DOM操作のためのライブラリだろ…
DOM操作に使うなってんなら用なしだわ。

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ

類似してるかもしれないスレッド

• + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
• + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
• + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
• + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
• + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
• + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
• + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
• + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
• + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
• + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
• + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
• + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
• + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
• + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
• + JavaScript の質問用スレッド vol.102 + (1001) - [97%] - 2012/9/11 17:30
• + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
• + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15