私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.132 +

みんなの評価 :
レスフィルター : (試験中)
element.classList.add() / element.classList.remove() のことか?
>>602
何でも揃ってるよ
何でも揃ってるよ
ちょっと前に
子ノードに探してるものがあるかどうかのチェックの質問あって
forで探せよっておこられてたけど
あれもメソッドがあるw
子ノードに探してるものがあるかどうかのチェックの質問あって
forで探せよっておこられてたけど
あれもメソッドがあるw
その流れは知らんけど既に目当てのnodeが参照できているなら
Node#contains() で結果をbooleanで取れる
Node#contains() で結果をbooleanで取れる
>>602
> メソッドも揃ってるなら、そろそろ脱jQueryしてみてもいい時期なのかもしれませんね
脱jQueryを目的としている時点でjQueryは使い続けられることが
容易に想像できるよな。手段が目的になってるわけだから
残念ながらDOM APIにあるのはjQueryのサブセットだ
更に言うならば事あるごとにループが必要でjQueryのような
簡潔な記述は到底不可能だ
DOM APIが勝っているのは、実行速度と初回ダウンロードサイズだが
実行速度はマシンスペックの高さでスマホでも問題になってないし
ダウンロードサイズはCDNを使うことで他のサイトのキャシュが活かせる
そうなるとライブラリを使わないほうが記述量は増えるので
現実的にはjQueryを使ったほうがサイズが減ることも多い
> メソッドも揃ってるなら、そろそろ脱jQueryしてみてもいい時期なのかもしれませんね
脱jQueryを目的としている時点でjQueryは使い続けられることが
容易に想像できるよな。手段が目的になってるわけだから
残念ながらDOM APIにあるのはjQueryのサブセットだ
更に言うならば事あるごとにループが必要でjQueryのような
簡潔な記述は到底不可能だ
DOM APIが勝っているのは、実行速度と初回ダウンロードサイズだが
実行速度はマシンスペックの高さでスマホでも問題になってないし
ダウンロードサイズはCDNを使うことで他のサイトのキャシュが活かせる
そうなるとライブラリを使わないほうが記述量は増えるので
現実的にはjQueryを使ったほうがサイズが減ることも多い
ところでCDN使うってことは
CDNにどこからのアクセスかリファラでバレてしまうってことだよね?
CDNにどこからのアクセスかリファラでバレてしまうってことだよね?
>>610
バラバラでも無限にあるわけじゃないしw
それから自分のサイトから配信するよりもCDNを使ったほうが高速で、
自分のサイトのトラフィックを減らすという効果もある
全部自分で書くと、その分自分のサイトで配信する量が増えてしまうが
jQueryにそれを逃してやると、減らせるわけさ
バラバラでも無限にあるわけじゃないしw
それから自分のサイトから配信するよりもCDNを使ったほうが高速で、
自分のサイトのトラフィックを減らすという効果もある
全部自分で書くと、その分自分のサイトで配信する量が増えてしまうが
jQueryにそれを逃してやると、減らせるわけさ
イベントリスナの掃除とかまで考えると
もうjQuery使えばいいじゃんってなりますね
jQueryを使わなくなるのは、jQueryの代わりをしてくれるライブラリやフレームワークを使う時なのかも
もうjQuery使えばいいじゃんってなりますね
jQueryを使わなくなるのは、jQueryの代わりをしてくれるライブラリやフレームワークを使う時なのかも
>>592-598
JavaScript, jQuery で作れる
JavaScript, jQuery で作れる
>>615
> ライブラリというよりフレームワークに近いものだから
プログラマが書いたコードから呼び出すのがライブラリ
プログラマが書いたコードを呼び出すのがフレームワーク
jQueryはどうみてもライブラリだ
> ライブラリというよりフレームワークに近いものだから
プログラマが書いたコードから呼び出すのがライブラリ
プログラマが書いたコードを呼び出すのがフレームワーク
jQueryはどうみてもライブラリだ
もちろん仮想DOM勢には劣るものの大抵のサイトの規模ならDOM操作の保守性は少し上がるかな。ただ一ヵ所二ヵ所くらいしかDOM操作しないのに導入するとたったそれだけのためにjQueryという巨大コードのパースが完了するまで待たされる。容量も増える。
一ヵ所二ヵ所くらいならDOMAPIで書けやと思うじゃん。
ところがあいつら書かないんじゃなくて書けないんだよな。
調べる気もなし。
強いていうならそういうゴミを量産してしまうのがデメリット。
一ヵ所二ヵ所くらいならDOMAPIで書けやと思うじゃん。
ところがあいつら書かないんじゃなくて書けないんだよな。
調べる気もなし。
強いていうならそういうゴミを量産してしまうのがデメリット。
forループ内でsetTimeout書いてsetTimeoutの中の処理がおわったら次のループに行くようにしたいんだけど
どうすればいいのでしょう?
for () {
for () { setTimeout() }
}
な感じです。
どうすればいいのでしょう?
for () {
for () { setTimeout() }
}
な感じです。
promiseとreduceを使え。
setTimeoutのコールバックのケツでresolveしろ
setTimeoutのコールバックのケツでresolveしろ
>>620
jQueryを導入する無駄な時間を大切にね
jQueryを導入する無駄な時間を大切にね
>>619
> もちろん仮想DOM勢には劣るものの大抵のサイトの規模ならDOM操作の保守性は少し上がるかな。ただ一ヵ所二ヵ所くらいしかDOM操作しないのに導入するとたったそれだけのためにjQueryという巨大コードのパースが完了するまで待たされる。容量も増える。
はっきり書いておきましょう。
ただ一ヵ所二ヵ所くらいしかDOM操作しないのに
"仮想DOM" を導入すると
多数のJavaScriptファイルを読み込んだ上に
HTMLを大きく書き換えないといけないから
仮想DOM勢、つまりReactは導入されないんですよ
> もちろん仮想DOM勢には劣るものの大抵のサイトの規模ならDOM操作の保守性は少し上がるかな。ただ一ヵ所二ヵ所くらいしかDOM操作しないのに導入するとたったそれだけのためにjQueryという巨大コードのパースが完了するまで待たされる。容量も増える。
はっきり書いておきましょう。
ただ一ヵ所二ヵ所くらいしかDOM操作しないのに
"仮想DOM" を導入すると
多数のJavaScriptファイルを読み込んだ上に
HTMLを大きく書き換えないといけないから
仮想DOM勢、つまりReactは導入されないんですよ
ついでに仮想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の敗北については、次のサーバーサイドレンダリングでぼくが話をするんで、まあここはこれくらいでいいんじゃないかなと(笑)。
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の敗北については、次のサーバーサイドレンダリングでぼくが話をするんで、まあここはこれくらいでいいんじゃないかなと(笑)。
・一度使い出したら全部作り直す覚悟がないと使うのをやめられない
・そんなん要りません
・そんなん要りません
生jsで書くのってそんな面倒臭い?
設計段階に比べたら時間も労力も全然かからないから
気になったことがないんだけど
設計段階に比べたら時間も労力も全然かからないから
気になったことがないんだけど
DOM APIが基本的に手続き型の構造をしているのが問題
一行ずつ処理を眺めていないと最終的な結果がわからない
それに対してjQueryだとコードが宣言的になる。
「なになに(セレクタ)は、こうだ」という風に宣言的に書けるから
状態を気にしなくて良くなる。
それはCSSの書き方と違い。(CSSも宣言的な言語)
一行ずつ処理を眺めていないと最終的な結果がわからない
それに対してjQueryだとコードが宣言的になる。
「なになに(セレクタ)は、こうだ」という風に宣言的に書けるから
状態を気にしなくて良くなる。
それはCSSの書き方と違い。(CSSも宣言的な言語)
>>637
普通コンポーネント的に設計しますよね?
例えば画面上にJavaScriptで拡張された入力フィールドが複数あるとか
jQueryを使うと一つだけでも複数あっても
まったく同じ書き方ができます。
それはCSSと同じなんですよ。
.klass { color: red } とすると
class=klassである要素が全て赤になります。
同等のことをjQueryで書くと
$('.klass).css({color: 'red'}) です。
CSSと文法が少し違うだけと考えられます。
でもDOM APIじゃこうは行きません
普通コンポーネント的に設計しますよね?
例えば画面上にJavaScriptで拡張された入力フィールドが複数あるとか
jQueryを使うと一つだけでも複数あっても
まったく同じ書き方ができます。
それはCSSと同じなんですよ。
.klass { color: red } とすると
class=klassである要素が全て赤になります。
同等のことをjQueryで書くと
$('.klass).css({color: 'red'}) です。
CSSと文法が少し違うだけと考えられます。
でもDOM APIじゃこうは行きません
>>639
> DOMガチャガチャいじらなきゃならない場合結局DOMの初期状態から操作ごとにどのようにDOMが変化するか実行順に追ってかないとセレクトスカるが…
そういう書き方になっちゃうからDOM APIはだめなんですね。
バグが減らないといったのはそういうことです。
> DOMガチャガチャいじらなきゃならない場合結局DOMの初期状態から操作ごとにどのようにDOMが変化するか実行順に追ってかないとセレクトスカるが…
そういう書き方になっちゃうからDOM APIはだめなんですね。
バグが減らないといったのはそういうことです。
DOM APIの話でしょ? 同じことをDOM APIですると
もっとひどいことになるんですからw
もっとひどいことになるんですからw
いや、jQuery。
DOMを操作するんだから操作前と操作後でDOMが変化するのは変わらん。
その状態にあったセレクタ書くには結局上から見てくしかない。
DOMを操作するんだから操作前と操作後でDOMが変化するのは変わらん。
その状態にあったセレクタ書くには結局上から見てくしかない。
>>645
> DOMを操作するんだから操作前と操作後でDOMが変化するのは変わらん。
それが間違った使い方。DOMを操作するとメンテナンス性が下がる
DOMは基本操作してはいけない。見た目を変えたいならそれはCSSでやるべきこと
見た目はCSSというのは、なんども言われてる話だろ
CSSで変えるのだから、ウェブデザイナが手動でclassを変更することで
JavaScriptを必要とせずに、状態に応じた見た目を作ることができる。
作業の分担ができる。JavaScriptでやるのは状態(クラス等)を変えるのみ
DOM APIでDOMをガシガシ操作なんかするからバグ減らないんだよ。
> DOMを操作するんだから操作前と操作後でDOMが変化するのは変わらん。
それが間違った使い方。DOMを操作するとメンテナンス性が下がる
DOMは基本操作してはいけない。見た目を変えたいならそれはCSSでやるべきこと
見た目はCSSというのは、なんども言われてる話だろ
CSSで変えるのだから、ウェブデザイナが手動でclassを変更することで
JavaScriptを必要とせずに、状態に応じた見た目を作ることができる。
作業の分担ができる。JavaScriptでやるのは状態(クラス等)を変えるのみ
DOM APIでDOMをガシガシ操作なんかするからバグ減らないんだよ。
ある要素から特定の親の要素取得するのってどうやってやるの?
jQueryでいうところの .parents('.foo') みたいなの
.parent() は .parentNode で取れるけど .parents('.foo') にあたるのはないよね
parentNode でループしながら
if (element.classList.contains('foo')) するしかないのかな
jQueryでいうところの .parents('.foo') みたいなの
.parent() は .parentNode で取れるけど .parents('.foo') にあたるのはないよね
parentNode でループしながら
if (element.classList.contains('foo')) するしかないのかな



類似してるかもしれないスレッド
- + 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
トップメニューへ / →のくす牧場書庫について