>>597
> 実際、ES5 で生産性は上がっているから
ES5 では所詮ES5でやれる範囲止まりなんだよ。

だから、セレクタにマッチした複数の要素にイベントを割り当てる
$(selector).on('click', ・・・)や

複数のイベントに同じハンドラを適用するとか
$(selector).on('load, resize', ・・・)や

DOM関数の生産性は上げられない。
あくまでDOM APIからもらってきて、
それを処理するところしか生産性があがらない。

jQueryのキモは、セレクタに一致した0個以上の要素に
一括して処理できるところにあるわけで。

data() で data 独自属性の書き換えは出来ないのか
jQuery で data 独自属性を書き換えるには attr() しか選択肢がない

>>600
> HTML5 に追従するなら element.dataset で実装して欲しかった

element.datasetのどの機能に対応して欲しいの？

element.datasetと全く同じものjQueryで実装してくれよというのは、
jQueryはpolyfillライブラリじゃないんだけど？で終わる話。

jQueryは0個以上の要素を扱うライブラリなので
$(selectoer).data('name', 1) とか出来るようにするもの。
要素一個一個で操作するためのelement.datasetと
data()では全然目的が違うでしょ。

>>598
> $('#id').contents().filter(function() {
> 　　return this.nodeType === 3;
> }).each(function() {
> 　　console.log(this);
> });
生のテキストノードを参照してるようだけど...
nodeTypeプロパティも DOM 規定のもの
結局、DOM API を使わないとテキストノードを操作できない

>>603
data() で data 独自属性を参照する必要はないでしょ
あなたのいうとおり、違う機能なんだから
しかも読み取るだけで書き換え出来ないとか中途半端な仕様なら全く持って不要

>>602
> data() で data 独自属性の書き換えは出来ないのか
> jQuery で data 独自属性を書き換えるには attr() しか選択肢がない

この勘違い、やっぱりしている人がいるんだよね。
常々、この区別が頭のなかではっきりしてない人いるんだろうなって思っていたけどさ。
単純にHTML（要するにタグ）とDOMオブジェクトが持っている情報は別ってだけ。

** jQueryを使わないで ** 説明するね。

<input id="id" type="checkbox" checked="checked">

var chk = document.getElementById('id');
console.log(chk.getAttribute('checked')); // checked
chk.checked = false;
console.log(chk.getAttribute('checked')); // checked

チェックボックスのチェックは外れているけど、
二回目でも、checkedって表示されるんだよ。

これがchk.removeAttribute('checked')であれば、二回目はnullになる。

つまりね。「HTMLの属性」を書き換えるのは、どちらにしろsetAttributeなの。
DOMの状態を変えるだけでは、HTMLの属性は変わらないの。
念の為に言っておくけど、ここまでjQueryの話してないからね。


だからjQueryのdata()も（ついでにprop()も）一緒なんだよ。
DOMの状態を変えるものと、HTML属性を変えるものは最初から別のもの

>>605
> しかも読み取るだけで書き換え出来ないとか中途半端な仕様なら全く持って不要

>>606でちゃんと説明したからね。
「HTML属性」を書き換えるのはsetAttribute（jQueryではattr）でやるべきこと。

data()はDOMの状態を変えるものであって、HTML属性を **変えてはならない**
だから中途半端ではなく、意図して作られた機能

>>601
そもそも、複数の要素に同じイベントを割り当てる機会がほぼないから問題ない
上位ノードで一つ監視すれば済む
君のいう生産性は運用次第で何とかなる問題だから考慮する必要がない人もいることは覚えておいたほうがいい

>>604
> 生のテキストノードを参照してるようだけど...
> nodeTypeプロパティも DOM 規定のもの
> 結局、DOM API を使わないとテキストノードを操作できない

ん？ テキストノードの操作って他に何をやりたいの？

nodeTypeプロパティを使って、テキストノードを取得していることに
文句を言ってるだけ？ それがいやならプラグイン作ればいいだけの話だと思うけど
$('#id').textnodes() とか簡単に作れると思うよ。

>>608
> そもそも、複数の要素に同じイベントを割り当てる機会がほぼないから問題ない
> 上位ノードで一つ監視すれば済む

それを言ったら、element.addEventListenerは要らないって言っているのと同じだけど？
window.addEventListenerさえあれば十分ですよね？ｗ
あなた、DOMの仕様に文句をつけてるよ！
あと、バブリングしないイベントもありますので～♪

それから上位ノード一つ監視するにしても、jQueryだと生産性が上がるよ。
特定のクラスだけ監視する時に書くコードはこれだけでいいからね。
いちいちフィルタリングコードを書かなくて良い。
$(document).on('click', '.klass', function() {・・・})

ということで、ES5で生産性上げるといってもやっぱり
ES5の範囲止まりで、DOMの生産性はあがりませんでしたと
さっきの私の話の続きになりましたねｗ

>>606
おまえにいわれなくともわかってるわ
おまえも主張するようにHTML属性の読み書きは attr() の役割なんだよ
data独自属性の読み取りも attr() の役割
data() でHTML属性を参照するのは役割が違うが、拡張されたのならどんな機能が実装されたか確認するだろ
すると、初回読み込み時だけ data 独自属性が合ったらそちらを参照する仕様ときたもんだ
そんな中途半端な仕様にするならdata独自属性の attr() に任せて余計な事しなければいいだろ

>>611
> おまえにいわれなくともわかってるわ

重要なのは、お前がわかってるかどうかじゃなくて
他の人がわかってるかどうかなんだよねｗ

このままだと、"他の人が" data()はHTML属性を書き換えないという
問題があると勘違いされてしまうだろ？

じゃなくて、HTML属性を変えないのは、問題ではなくて
そういう機能だって明言しただけ。

うん。お前はわかっていたんだよね。
大丈夫、 "他の人に" 言ってるだけだからｗ

> すると、初回読み込み時だけ data 独自属性が合ったらそちらを参照する仕様ときたもんだ
え？ わかってるのかな？ｗ

チェックボックスのcheckedも同じ動きするんだけど？
初回のHTML属性の値を反映するが、checkedに代入してもHTML属性の方は変わらない。

やっぱり、お前、実はわかってないだろｗ

>>610
おまえは上位ノードといったらルートノードしか思いつかないのか

通常は必要最小限の上位ノードを指定する
例えば、table要素内で click 判定できれば良いのなら、table要素ノードを指定する
全てのイベントでdocumentを指定する必要はない
煽るのが得意なようだが、もう少し経験を積んでから他人に指摘するほうがいいと思うぞ

>>613
> おまえは上位ノードといったらルートノードしか思いつかないのか

おまえは、
$(document).on('click', '.klass', function() {・・・})
というコードを見たら

$('#wrapper').on('click', '.klass', function() {・・・})
というコードも書けるって、思いつかないのか？


jQueryでも 通常は必要最小限の上位ノードを指定する
jQueryでも 例えば、table要素内で click 判定できれば良いのなら、table要素ノードを指定する
jQueryでも 全てのイベントでdocumentを指定する必要はない

煽るのが得意なようだが、もう少し経験を積んでから他人に指摘するほうがいいと思うぞ

例えば、table要素内で click 判定できれば良いのなら、table要素ノードを指定する
例えば、table要素内で th の時だけ click 判定したいのなら、table要素ノードを指定する

そしておもむろにこう書く！

$('table').on('click', 'th', function() {・・・})

すげーぜ、jQueryの生産性♪

しかもこれ、すべてのtableに一度にイベントハンドラつけてるんだぜ！

このjQuery信者は話すたびにボロが出てるな...

>>616
ぶっちゃけ、今日はワンサイドゲームで楽しいよｗ

>>614
あなたは趣旨を理解して話すことが出来ない人なのか？

・あなたは複数ノードにイベント定義できるのが jQuery のメリットだといった
・私は複数ノードにイベント定義する機会がほとんどないといった
・あなたはjQueryでも上位ノードで監視できるといった

で、私は何を反論する必要があるのだ？

思い込みが強くて論理的に考えられない人って怖いです

>>618
俺の言ったこと理解してないじゃんんｗ

× ・あなたは複数ノードにイベント定義できるのが jQuery のメリットだといった
○ ・あなたは複数ノードにイベント定義できるので生産性が高くなり、それが jQuery のメリットだといった

× ・私は複数ノードにイベント定義する機会がほとんどないといった
○ ・わ、私は、複数ノードにイベント定義する機会なんて、ほとんどないんだからねっ！

×・あなたはjQueryでも上位ノードで監視できるといった
○・あなたはjQueryでも上位ノードで監視でき、その場合でも生産性が高くなるといった


> で、私は何を反論する必要があるのだ？
そりゃ

1. 複数ノードにイベントを定義することが、「ほとんど」ではなく「100%ない」と断定する
（一つでもあればjQueryの方が生産性高くなるので当然ですね）

2. 上位ノードで監視して子要素を制限する例でのjQueryの生産の高さを否定する

この2つを反論しなければならないのでは？

他にも言ってないだけで、セレクタに一致する複数の要素に、特定のメソッドを適用する場合のjQueryの生産性の高さ
| 例 $('#form1 :button').prop('disable', true);
| // フォーム1以下のボタンタイプの要素（button, type=button, image, submit等)を全部無効にする
とか、山ほど反論する必要がありますが。

jQueryはDOMの生産性を上げるために作られたのだから、
jQueryの方が生産性が高いのは当たり前なんだよ。

不思議なのは、その当たり前のことに否定していること。
生産性の高さだけは素直には認めろよ。

反論する余地があると言ったら
生産性は落ちるが、今はjQueryを読み込まなくても頑張れるぐらいになった。
頑張れば、初回のjquery.js（gzip圧縮時30KB)のファイルダウンロードと、
jQuery初期化のための数ミリ秒のコストが省けるんだ。
ぐらいしかないだろ？

所でjQueryを使うことで30KB余計にファイルサイズが増えるが、
jQueryを使うと、アプリの方のコードは減るんだよね。
アプリの方のコードがどれくらいになったら、jQueryを使ったほうが
サイズが少なくなるだろうか。

lodashにstartCase()ってのが追加された。
3.0.2くるかな？

>jQueryの方が生産性が高いのは当たり前なんだよ。
>不思議なのは、その当たり前のことに否定していること。

そんな奴いるのかw
ライブラリ否定厨は頭がおかしいな

>>553-
これってremoveEventでunload時にonload()呼ばなくていいんですか？
あとこれってイベントがloadでない例えばclickとかでもクロージャー使うとだめですか？

ライブラリ信者の暴れぶりが尋常でなくて、むしろ清々しささえ感じる

などとあおっている奴よりも、よっぽど役に立ってるがなｗ

うん、さすがに>>620とか読んでて気持ち悪い

などとあおっている奴よりも、略

昨日はライブラリ否定厨がでなかったみたいだね。
これだけ長くやりとりしているのに、ほとんど荒れてない。
本当に荒らしているのは誰かよく分かる流れだ。

結構参考になるからjQueryの話はok
lodashの方はどうでもいい

でもlodashの方がJavaScript（ECMAScript）に近いんだよね。

jQuery・・・DOM APIを改善するライブラリ
lodash・・・ECMAScriptを改善するライブラリ
(lodashの元となったunderscoreも同様）

それぞれクロスブラウザ対応のためという使い方を除くと

jQuery・・・DOM操作が関数型プログラミングできる
lodash・・・ECMAScriptよりも多くの関数型プログラミングの機能が使える。

こういった特徴がある。

lodashの機能というのは、ECMAScript自体追加された関数型プログラミングの機能の代替だから
JavaScriptで関数型プログラミングは既定路線。素直に勉強した方がいいよ

参考 JavaScriptで学ぶ関数型プログラミング
http://www.oreilly.co.jp/books/9784873116600/
（この本でもunderscoreは説明されている。付録C 本書に登場するUnderscoreの関数）

lodashは単により多くの関数型プログラミング機能を提供してくれるだけだから
関数型プログラミングではないDOM APIを関数型にしてくれるjQueryよりも
そこまで重要じゃない。ECMAScript7や8になればさらに不要になるだろう。

jQueryは、DOM APIが関数型プログラミング用のAPIに大幅（というより完全に別物）に
変わらない限り、直接DOM APIを実行する代わりとして使われるだろうね。
DOMはJavaScriptだけのものじゃないから、なかなか難しいかな。

ES6のclassやthenってまだchromeやfirefoxで使えませんか？
今はメジャーな最新バージョンのブラウザならES5.1で書いても大丈夫そうですけどES6っていつ頃メジャーになりますか？

>>632
http://kangax.github.io/compat-table/es6/

EcmaScript6の対応は一番いい
IE Technical PreviewやFirefox 37でも69%だよ。

IE Technical Preview（IE12？ spartan？）移行は
自動更新になるだろうから、ネックはIE11。
そのIE11を搭載しているWindows7のサポート期間
2020年1月14日までだから、あと5年はES6使えないだろうね。

もっともWindows7からWindows10へのアップグレードは
無料になるらしいから、もっと早く移行が完了する可能性もある。

その5年の間にES6の対応も進むだろうから、
まあ普通に使えるのは5年後ぐらいじゃない？

あ、Android端末を忘れていたｗ
スマホの標準ブラウザを考えると少し厳しいかもね。
まあ5年あれば使うような人は買い換えるかな？

>>632
classは文法だから、ES6→ES5コンバーターを使わなければ対応できないけど、
then（Promise）ならPolyfillライブラリを導入するだけで対応できるだろう。

jQueryのPromiseも同じような仕様だったはず。
jQueryはどちらにしろ使うので、二重に同様のライブラリを入れるのは
CPUとメモリの無駄だから、今のところはjQueryのPromiseを使ってるよ。

>>555
これは循環参照じゃないなの？

var a = [巨大な配列];
function onload() {
}
window.addEventHandler('load', onload);

>>635
書き換えるなよｗ >>555が言っている内容と違ってるじゃん。

function onload() {
}

function foo() {
var a = [巨大な配列];
window.addEventHandler('load', onload);
}

勝手にaのスコープ（ 生存期間）を変えないように。

循環参照の話題自体が循環参照してる…
誰かガベージコレクトしてくれ

クロージャー使うとと循環参照している
→別に循環参照してもいいんだよ。
→DOMとの間で循環参照すると古いIEで問題が出るだけ。
→だから循環参照するからクロージャー使ったらだめなんでしょ？
→循環参照してもDOMとの間でなければいいんだよ。
→そう。そしてjQueryを使えばクロージャー使ってもDOMとの間で循環参照にならない。
→jQueryは開発効率がいい！

ここまでが一連の流れｗ

jQuery 使わずとも

function onload() {
...
window.removeEventHandler('load', onload);
}
としとけばいいんでない
一度しか実行されないハンドラは少数に限られるだろうから

>>636
わざわざonloadっていう関数作っても
スコープの外は参照できるんだから結局循環参照するのでは？
aは開放されるけどbは開放されない

var b = [巨大な配列];
function onload() {
}

function foo() {
var a = [巨大な配列];
window.addEventHandler('load', onload);
}

>>555
巨大な配列がDOMでなければ循環参照しないはずだが
クロージャを少なくする設計には賛成だが、循環参照は関係ない

循環参照の話を循環させるなっての

(function(){
var hello = 'hello world';
function load(){
console.log(hello);
}
window.addEventHandler('load', load);
}())

これを循環参照しないようにしたコードをおしえて

>>643
初めから循環参照してません

やはり、「IE8 で>>534を実現する方法」は存在しないのでしょうか

(function(){
var hello = 'hello world';
function load(){
var age = 10;
console.log(hello);
}
window.addEventHandler('load', load);
}())

じゃあこれは循環参照しますか？

Listenerで読み替えてください

scriptのsrcを書き換えただけじゃ通信が起こらないんですが
scriptを削除して挿入しなおさないかぎり通信しないですか？

>>648
循環参照しません
基本的な循環参照規則を学んでから質問してください
質問前にコードが動くことを確かめてください