JavaScript ライブラリ総合質問所 vol.5 [無断転載禁止]©2ch.net
JavaScriptライブラリ を自ら学ぶ人のための質問スレッドです。
■質問を書く上で
(1) 質問にならない投稿はご遠慮ください。(煽り、コード制作依頼など)
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 長い間連続して質問する場合にレス番を名前にしてあれば、質問の流れが回答者に伝わりやすくなります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。質問テンプレートを活用してみてください。
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【ライブラリ】使用しているライブラリ名を記入してください。(ex: jQuery)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/ >>55
関数型を理解してくださいとしか言いようがないな。
関数型言語から来たものなのに副作用に依存するとか
ちょっとセンスがわるい >>56
君にセンスを理解してもらう必要はないんだけど…、頭が固いと大変だね というか、>>55は返り値を使ってるけどね
自分の世界観から抜けられないだけのような >>59
冗長合戦したいなら$()が冗長だから出直しておいで この程度で冗長とか正しい書き方とか、偏執的にも程がある コードだけ読んで批判は聞き流せばいい
相手の為を思って叱ってくれる人も中にはいるが、こいつのはただjQueryスレに誘導するためにこき下ろしているだけだからな jQueryの話題をjQueryスレに誘導することに
なんの問題があるんだ？ｗ ライブラリスレでjQueryの質問しても何の問題もない
荒らしのたてたスレに誘導する必要もない そしたら今度はこっちがjQueryで占領されるわからないのかなぁ？ｗ こっちはjQueryを含めるライブラリ全部のスレ
向こうはJavaScriptとjQueryのスレってことでいいじゃないか >>67
タイトルで誤魔化してるが、向こうはただのjQueryスレ
JavaScriptの質問はスレ違い ふたを開けてみれば、jQuery 3.0はあまり変わってないな
もっと思い切ったAPI変更が欲しかったら >>75
もう完成されているんだよ。
アドビ イラストレータと同じww 基本的に後方互換性重視だな
Deferedを廃止してPromiseを使うとか、classListを実装するとか、eachをforEach互換にするとか、標準に近づけてほしかったな >>77
互換性をなくしてまで仕様を変える意味は？ 学習コストの低下と汎用性じゃない？
メジャーバージョンアップで互換性がなくなるなんて良くあること
個人的にはDeferedはPromiseに変えて良かった気がしないでもない >>79
> 学習コストの低下と汎用性じゃない？
学習コストは一度覚えればいいだけ
過去のソースを書き換えるほうが手間がかかる。
汎用性は意味不明。標準よりも高機能のほうが汎用性は高いし。 > 個人的にはDeferedはPromiseに変えて
機能が低下している。 PromiseはAndroid4.4が非対応だからな。
標準のPromiseを使うことはできないのだ。 > 学習コストは一度覚えればいいだけ
さすがにこれはない
jQuery一色に染まってるな 多機能が必ずしもいいとは限らんのよ
Promiseは内部的にPolyfillを作ればいいだけでPromisesの実装が進めばPolyfillは削除できる
event.pageXの独自拡張が削除されたように標準を使ってもらう形の進化は有りだと思う slim版で$.ajax()が削除されたのはFetch APIの実装が整ったら削除するための布石かな
実装が整ったからAPI削除ってjQuery 3.0でもいくつかあったよね >>13にまとめられてなかったっけ？
削除されたAPIはajaxのcompleteが記憶に新しいが
$.parseJSONの非推奨も次で削除する為の準備段階な印象 >>87
ありがとうございます。
リンク先参照します >>84
> Promiseは内部的にPolyfillを作ればいいだけでPromisesの実装が進めばPolyfillは削除できる
それをいうなら、jQuery 3.0のDefferedはPromise互換なので、
Promiseを使ってDefferedを実装すれば良いだけ。 >>85
Fetch APIはあまり関係ないと思うよ。
Slim build
https://blog.jquery.com/2016/06/09/jquery-3-0-final-released/
> Finally, we’ve added something new to this release. Sometimes you don’t need ajax,
> or you prefer to use one of the many standalone libraries that focus on ajax requests.
> And often it is simpler to use a combination of CSS and class manipulation for all your
> web animations. Along with the regular version of jQuery that includes the ajax and
> effects modules, we’re releasing a “slim” version that excludes these modules. All in all,
> it excludes ajax, effects, and currently deprecated code. The size of jQuery is very rarely
> a load performance concern these days, but the slim build is about 6k gzipped bytes
> smaller than the regular version ? 23.6k vs 30k. These files are also available in the npm package and on the CDN:
要するにjQueryをDOM用のライブラリだけとして使いたい人のため。それで6KBのサイズ削減ができる。
Ajax関連はいろんなライブラリに搭載されてるから機能が重複しやすかった。 >>85
> 実装が整ったからAPI削除ってjQuery 3.0でもいくつかあったよね
実装が整ったという理由で消えたAPIはないよ。
jQueryの互換性は高い。
jQueryはDOM APIよりも使いやすいという利点のライブラリなんだから
実装が整った程度じゃAPI削除する理由にはなりえない。 >>89
> Promiseを使ってDefferedを実装すれば良いだけ。
Promiseをprototype拡張するつもりか >>92
prototype拡張は駄目なやり方だという設計してるのがjQueryなんでぇ。
当然jQueryと同じようにラップするに決まってるでしょう（笑） そもそもDOM APIはPromiseを使うべきだろうな。
将来はイベントハンドラとか全部Promiseに置き換わるはず ん？標準のPromiseにprogressってあったっけ？
標準のPromiseは基本機能しかサポートしてないから
普通はQとかを使うのが常識だと思ってたが。 >>93
Promiseをラップするぐらいなら、現行のPrpmise互換オブジェクトの方が数段マシだと思うが
拡張部分とPromise互換部分の整合性をとるのが面倒で内部的にPromiseを使うメリットが感じられん そもそもさ、notifyとprogressの事を忘れてないか？
http://blog.toshimaru.net/jquerydeferred-is-most-important-client/
> deferredへ通知する: notify()とprogress()
>
> jQuery1.7からresolve/rejectに加えて、progressが導入された。、
> progress()により、deferred内でnotify()がコールされたときに実行される
> コールバック関数を登録することができ、resolved状態に対する「進捗(progress)」を
> 表現できるようになった。notify()で事前にコールバックを登録しておくことで例えば、
> ロードに時間がかかるリソースを持つdeferredオブジェクトの定期的に更新されるプログレスバーを描画できる。
> deferredはロード中に通知(notify)され、ロード完了時に解決(resolve)される。
jQueryでDeferredを使ってる所っていうのはAjax通信の部分だけだと思うが、
Ajax通信を置き換える目的ならば、XMLHttpRequestにあるprogress相当の機能を実装する必要がある。
ってことは素のPromiseオブジェクトでは明らかに機能不足なんだよ。
そういう前提において、DefferedにPromiseと互換性を持たせる（jQuery 3.0で実現したこと）のではなく
Promiseを使えって言うならば、足りない機能を実装するしか無いだろ。
そして>>96の言うとおり標準のPromiseをラップして使うメリットはないので
DefferedのままPromiseと互換性をもたせるのが一番すぐれたやり方なわけだよ。 そもそも、「>>77や>>84が目指しているゴール」と「現行jQuery擁護派のゴール」が違いすぎるので議論にならない
反論するなら相手の立場になって反論しないとな
でなければ、ただの宗教戦争だ まあ確かに、Promise派としてはprogressはXMLHttpRequestと同じ方法で実装してくれれば満足するだろうね >>98
そうか？単に標準のXMLHttpRequestで必要とされている機能を
満たすにはPromiseの機能だけでは不足しているから
拡張する必要があるってことに気づいているかどうかだと思うぞ。 >>99
XMLHttpRequestと同じ方法ってことは、
Promiseを返さないってこと？ >>101
そういうことになるね
>>97はjQueryの既存概念にとらわれすぎているようだけど、DOMのInterfaceで実装する仮定で想像してみればいいたい事の大体はわかると思うよ
そもそも、Ajaxの返り値の話なんて誰もしてないから Promiseを返せと言ったりPromiseを返すなと言ったり
意味不明だなｗ
結局のところPromiseを使う理由はないってことか。
互換性を切るなんてもっての外だし、
あえて互換性を切ってまでDefferedの仕様を変える意味はないし、
やはり今の仕様が一番最善ってことか。 >>103
独り合点してないでもう一度、読み直して来たら？
jQuery.Defered === Promise && ajax() !== jQuery.Defered だからFetch APIっていうのがあるんだよ。
互換性の問題があるからjQueryは仕様を変えてはいけない。これは大前提。
そして標準でXMLHttpRequestをPromiseベースに改良したFetch APIが普及しつつある。
最新版のSafariやAndroid 4系やIEで動かなかったりするからまだ乗り換えることはできないけど、
これを使えばjQueryでDeferredを使うもの＝Ajax関連は必要なくなる。
だからjQuery 3.0ではAjax関連を取り除いたSlim buildっていうのを用意した。
Promiseを使いたいならjQuery 3.0 Slim build + Fetch APIを使えばいいだけなんだから
互換性を切ってまでDeferredをやめてPromiseに変える合理的な理由はないでしょ？
Slim buildを用意することでPromiseベースのAjax通信（つまりFetch API）への移行を
サポートしてるわけでDeferredを使っていることは失望するポイントにはならないんだよ。
元来jQueryはブラウザ間の互換性を吸収するためにも用いられてきたけど、
本質を理解している人はわかってると思うけど、互換性を吸収する部分は実はおまけ機能で
真の姿は関数型風のDOM操作ライブラリ。今それになろうとしているということ。
だから関数型の考え方を理解して使いこなせる人だけがjQueryの凄さを理解できる。
jQueryに意味がないと言ってる人は、関数型の考え方を理解していないはず。 >>104
読み直した。それであなたが言いたいポイントは？ >>106
君は「相手の立場で物事を考える」って出来る？
「インデントにタブ/半角スペースのどちらを使うべきか」の命題でタブ派が半角スペース派に「誰でも納得出来る明確なメリット」を主張できると思う？
元々の立ち位置が絶対的に違うのに、自分の立場でしか物事を考えられない人は議論に向いてないと思うよ 議論したいなら、少なくとも聞かれたときには
自分が言いたいポイントを明確に答えられなければならない。
それが言えないってことは、そもそもお前は議論していない。 >>108
>>104が読めないの？
ajaxの返り値がPromiseでなく、jQuery.Defered === Promise であればいいでしょ
>>103の「結局のところPromiseを使う理由はないってことか」は文意を読めてないだけでしょ
いい加減、疲れるんだけど あと、>>107もいいたいことの一つなんだけどね
>>77に対して「jQueryマンセー」な反論を返すのはただの思想の押しつけ
明らかな間違いを是正するならともかく、どちらが正しいという問題でもないよね
なぜそこまで確信的な論調になるのか、俺には理解できないよ > ajaxの返り値がPromiseでなく、jQuery.Defered === Promise であればいいでしょ
なんで互換性をなくしてまでPromiseにしないといけないのかわからん。
PromiseはDeferredに比べてprogressの機能が足りない。
だからPromiseに置き換えることはできない。
jQuery 3.0でDeferredはPromiseと互換性があるものになった。
だからPromiseではなくても互換性があるDeferredで十分って話だろ。
それにPromiseをサポートしてないブラウザはどうするのか？
jQuery自身にPromiseのpolyfill機能でも搭載するのか？ｗ
提案してみれば？jQueryにPromiseのpolyfill機能を付け加えて
DeferedをPromiseに変えて互換性を壊しましょうってｗ
互換性がないものに変わることで、既存のコードを書き換えないといけないならば
Fetch APIに変更すればいいだけじゃないか。そのためにjQueryはSlim Buildを用意したというのに。
>>111
あのさ（苦笑）jQueryの機能が素晴らしいって言ってるんじゃなくて
jQueryの選択は正しいって言ってるの。論理的にね。
どうもjQueryを擁護したら、なんにも考えずにjQueryを叩くやつがいるよな。
jQueryに親でも殺されたか？ｗ >>112
思想の違いってものが理解できないタイプなんだね
他人の思想にいちいち噛みつく辺りが嫌われてるのが理解できないか、理解した上でスルーしてるのか知らないけど
俺からすれば君はjQueryの布教活動しているようにしか見えないけどね 思想の違い？
互換性を保ちましょう。（Deferredの仕様は変えない）
標準への対応をしましょう。（DeferredのPromise互換）
将来への対応をしましょう。（Ajax部分を取り除いたSlim Buildの作成）
が俺とjQueryの思想だが、
じゃあお前の思想は？ｗ
お前の思想は何も考えずに適当に思いついたことを言ってるだけだろｗ 布教活動もクソも延々と啓蒙（）で荒らしてるやつじゃん 啓蒙はしてるが荒らしはしていない。
jQueryの話題をすることが荒らしというならば
それはお前がjQueryが憎いだけだｗ
ここはjQueryの話題OKのスレのはずだがね http://dictionary.goo.ne.jp/jn/67123/meaning/m0u/
［名］(スル)《「啓」はひらく、「蒙」はくらいの意》人々に正しい知識を与え、
合理的な考え方をするように教え導くこと。「大衆を―する」「―書」 >>114
・標準のAPIを使いましょう
・標準に準拠する為なら後方互換性は切り捨てても構いません > ・標準のAPIを使いましょう
何のために？
念の為に言っておくけど、 jQueryの本質は
DOM操作を関数型風にやること。
で標準のAPIっていうのはFetch APIのことだと思うけど、
jQuery（Slim build） + Fetch APIをすればいいよね？
jQueryは本来の用途であるDOM操作に専念させる。
Fetch APIを使えばいいのに何のために中途半端な対応を選んでいるの？
$.ajaxの戻り値だけをPromiseに変更するの互換性を切り捨てているのに
中途半端対応でしか無いんだけど
jQueryの標準への対応方法（Slim build）ではなくて
中途半端な対応をするべきだという合理的な理由を言ってくれ。 標準のAPIを使いましょうといわれても
標準のAPIを搭載していないブラウザがあるよね
Android 4.4とか jQueryのDeferredがPromiseと互換性がある
ってことの意味を理解してないんじゃないだろうか？
互換性があるからこのようにPromiseとDeferredは混ぜて使える。
https://jsfiddle.net/axL7p4d4/
function timeout(ms) {
return new Promise(function(resolve, reject) {
setTimeout(function() {
resolve();
}, ms);
});
}
console.log('start')
timeout(3000).then(function() {
console.log('get')
return $.get('/');
}).then(function(html) {
console.log(html.split("\n")[0])
console.log('wait')
return timeout(3000);
}).then(function() {
console.log('end')
}); まだやっているのか…
反論してる奴は話にならん
jQuery3.0が後方互換性重視な事は>>77で指摘済み
現行jQueryの思想から外れている事は百も承知
標準に合わせるメリットは「学習コスト」と「コードの可搬性」だけで十分だ
上の掛け合いは保守派と革新派が言い争っているに過ぎない
お互いの理想の形が一致しない議論に参加するのは時間の無駄 >>125
文体が似ているやつは全員一緒ですよねｗ >>124
> 標準に合わせるメリットは「学習コスト」と「コードの可搬性」だけで十分だ
だから標準＝Fetch APIでしょ？jQueryとFetch APIを組み合わせて
使っていいんだよ？そのためのSlim Buildなんだから。
お前が言ってるのは、標準のFetch APIではなくてjQueryのAjaxを使うことで
学習するコストが必要になるが、戻り値がPromiseだと（一部の）学習コストがさがる
って言ってるから謎なんだよ。Fetch API使ったほうが明らかに学習コストは減るだろ。
俺はFetch APIを使うのが一番学習コストが下がるからjQueryはそのままでいいって言ってる。
新しく使う人はFetch APIを使うだろうし、そうでない人、jQueryのAjax機能をすでに使ってる人は
当然今までのDefferedの知識があるからこちらも学習コストが下がる（正確には上がらない）
あとコードの可搬性で言えば、Android 4.4はどうする？Promiseはどこでも動くわけじゃないぞ。
PromiseのPolyfillライブラリを導入しろって？俺ならFetch APIのPolyfillごと導入するがねｗ >>125
面倒くさいから名前もIDも書くつもりはないけど別に隠すしてないよ？
だから、わかると言われても・・・。
もしかして見抜いたり！とか思ってる？ あ、それからもう一つあった。
jQueryのDefferedがPromise互換になった今
どんな学習コストがかかるのかも聞いてなかったね。 >>127
お前が問題にしているのは「jQuery.ajaxの返り値」であってPromiseは関係ない
ajaxの返り値はjQuery.DeferredでもPromiseでもない抽象オブジェクトで十分だが、それは別の話だ
お前が勝手に話を広げただけ >>130
jQueryでPromiseが使われてるのはajax関連（getやpost含む）ぐらいなもんだろ。
少なくとも俺はajax関連以外でDeferredを使った記憶はない。
他にjQueryの一体どこでDeferred使えっていうんだよｗ
ajaxを標準にしろって言うならば、Fetch APIを使えばいいわけで
非標準のjQueryのajax と 標準のPromiseを混ぜる理由がない。
それに結局Android 4.4はどうするのかにも答えてないし。 訂正
jQueryでDeferredが使われてるのはajax関連（getやpost含む）ぐらいなもんだろ。 >>129
別にPromiseだけに拘ってはいない
お前がしつこいほどに「jQuery.ajaxの返り値」を論旨に置いてるだけだ
Promiseについては前方互換性、可搬性が主だが、「Promise.allがjQuery.jQuery.Deferred.allに存在しない」もあるので学習コストが同じわけではないだろうな >>133
あー、なるほどねｗ やっとわかったわ。
お前、Promise.all みたいに Deferred.allしたいと思ってるだろｗ
そんなのする必要ねーよ？
jQueryを使っていてDeferredが出てくるのは戻り値としてだけ。
自分でDeferredオブジェクトを作る必要はない。（作りたいなら作ってもいいがね）
っていうかなんのために作るのさ？ｗ
Promise.allを使いたければ、Promise.allをそのまま使え。
その引数にDeferredオブジェクトを渡すことができる。
互換性があるからね。 >>131-132
> jQueryでDeferredが使われてるのはajax関連（getやpost含む）ぐらいなもんだろ。
それはお前が自前でPromiseを使った非同期処理を書いたことがないからそう思うだけだ
何の為にjQuery.Deferredが公開APIになっているのか、を良く考えろ >>135
> それはお前が自前でPromiseを使った非同期処理を書いたことがないからそう思うだけだ
そういうレスするってことは>>134は正しかったようだなｗ
レスするならそうじゃなくてお前がいつどこでjQuery.Deferredを使うのか答えてほしいもんだがｗ
jQuery.DeferredがでてくるのはjQuery ajax関連の戻り値としてだけ。理解した？OK？
> 何の為にjQuery.Deferredが公開APIになっているのか、を良く考えろ
いや、単に世の中にPromiseが普及する前（標準化される前、ブラウザに搭載される前）に
jQuery.Deferredが世に出ただけの話だけど？？？
お前は何のためだと思ってたんだい？
https://api.jquery.com/category/deferred-object/
The Deferred object, introduced in jQuery 1.5,
https://blog.jquery.com/2011/01/31/jquery-15-released/
jQuery 1.5 Released Posted on January 31, 2011 by John Resig
http://caniuse.com/#search=Promise
Firefox 27, Chrome 32 Partial Support
2014年01月15日 11時39分 更新 「Google Chrome 32」の安定版リリース
http://www.itmedia.co.jp/news/articles/1401/15/news061.html
https://ja.wikipedia.org/wiki/Mozilla_Firefox%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AE%E5%A4%89%E9%81%B7#Firefox_27
> 2014年2月4日にリリースされ、 jQuery.Deferredオブジェクトを戻り値ではなく自分で作成したのは
iframeを使ったときにページがロードされたあとを検出するときに使ったぐらいかな。
古いブラウザまで考えるとiframeのページロード後の検出は意外と面倒だったんだよね。
onloadが変なタイミングで発生したりOperaがページロード前はabout:blank状態だったりとか。
Promise（Deferred）はresolveになった後に変化できないから、
clickみたいに何度も発生するイベントでは使えないしね。
今ならPromiseを使うだろうけど、昔はPromiseはブラウザに搭載されてなかったし。その頃の話だよ。
Polyfillもあったかどうか怪しい。jQuery使ってたからDeferredを使うのが楽だった。
で、jQuery.Deferredが出てくるのはajax関連の戻り値としてだけで自分で作る必要はなく
互換性があるのでjQuery.DeferredとPromiseを混ぜて使えばOKなので、
最初から言っているとおり、jQueryは今の状態が一番適切だと思うが？
標準が使いたければ、Ajax関連ごとFetch APIに置き換えればよい。そのためのjQuery 3.0のSlim build。 >>134
jQuery.Deferredは自前でDeferredオブジェクトを作れるようにする為に存在するのであってそれ以上でもそれ以下でもない
お前が「jQuery.Deferredを使う必要がない」というならお前と議論するのは時間の無駄だ
jQuery.Deferredが要らんというならさっさと廃止するようにリクエストしろ
「お前が必要と思うもの」を他人に押し付けるな >>138
なに一人で空回りしてるんだよｗ
「お前が必要と思うもの」を押し付けてるのはお前だろ。
jQueryのDeferredをPromiseに変更することが必要なんだろ？ｗ
俺は現状維持でいいと言ってるの。なにも必要と思ってない。
jQuery.Deferredは自前でDeferredオブジェクトを作れるようにする為に存在するのであって
それ以上でもそれ以下でもないから、「自前でDeferredオブジェクト絶対に作らなければいけないんだ！」って
思うお前がおかしい。作れるからって作らなければいけないわけじゃないんだよｗ
もちろんjQuery内部では作る必要があるから作っているだろうが、
それをPromiseに置き換えるならば、Andorid 4.4などでPromiseをサポートしてないから
jQueryは自前でPromsiseを実装しなければいけなくなる。
その自前実装の亜種がDeferredでありPromiseと互換性があるオブジェクト
あれ？ お前の願い叶ってね？ｗ
お前がなにを言いたいのかさっぱりわからんね。現状維持でなにが悪い？
お前の根本的な間違いは、jQuery.Deferredを使ってjQuery.Deferredオブジェクトを作るときの
使い方が違うから、学習コストが〜って言ってるだけだろ？
だがそもそも（jQuery内部以外では）jQuery.Deferredを（今の時代は）使う必要がないから
学習コストもなにもねぇだろ。
新しく使う人→Fetch API使うからDeferredの学習コストは0
前から使ってる人→すでに知ってるからDeferredの学習コストは0
現状維持ならどちらの人でも学習コスト0だろ。
むしろお前の言うようにajaxの戻り値をPromiseにしたほうが互換性なくなるから
その違いを埋めるための学習コストやコード修正コストがかかるんだが。
もう少し論理的に考えな。お前は一体どうしてほしいんだ？ > jQuery.Deferredが要らんというならさっさと廃止するようにリクエストしろ
重要なのはDeferredがPromise互換になることであって
Deferredをなくすことじゃないんだよ。
DeferredがPromise互換になることで、Promise.allなどの引数に使えるようになる。
そしてDeferredがPromise互換になることは実現済み。
だからこれ以上Deferredを変える必要はない。
むしろDeferredいらん、Promiseに変えろと言っていたのは
お前だったはずだが？廃止するようにリクエストしろよｗ >>139
> 「お前が必要と思うもの」を押し付けてるのはお前だろ。
お前は俺に反論してきたが、俺はお前に何も要求していない(不当な反論があれば釈明はする)
例えば、>>124の「Promise.allをそのまま使え」は余計なお世話だ
(これにはさすがにカチンときて「jQuery.Deferredを廃止するようリクエストしろ」と要求したが、本意ではない)
jQuery.Deferredを使うならjQuery.whenで事足りるからな
「jQuery.Deferredを（今の時代は）使う必要がない」とかいうお前の勝手な考えはどうでもいい
> 新しく使う人→Fetch API使うからDeferredの学習コストは0
お前が何度も指摘しているFetch APIもまるで関係がない
>>130に書いたようにajax()の返り値がPromiseになることを望んでないからな
お前は異常なほどに「jQuery.ajaxの返り値」に拘っているが、俺は一言もajax()には触れてない
> jQueryは自前でPromsiseを実装しなければいけなくなる。
その通り
jQuery.DeferredはPromiseのPolyfillであれば良い
ここまでの流れは基本的には>>111の指摘通り
俺は俺の思想を主張するが、お前はお前の思想を主張するだけ
思想の違いを理解するために説明しあうことは有意義だが、相手の思想を撤回させようとするのは無駄な事だ
お前はそれをしようとしてる jQuery.Deferredを廃止してjQuery.Promiseが実装されれば>>77の望みは達成できるのかもしれないね >>142
確かにjQuery.Deferredを書き換えるよりも現実的だな >>141
> 例えば、>>124の「Promise.allをそのまま使え」は余計なお世話だ
なぜ？ Promise.allを使いたければ、標準のPromise.allを使えばいいだろ？
なんでそこで、Deferred.allを使いたいと思ったんだ？
> jQuery.Deferredを使うならjQuery.whenで事足りるからな
事足りるんじゃなくて、えとな。話聞いてる？
DeferredはPromsieが登場するよりも前に生まれたの。
事足りんじゃなくて、当時はそれを使うしかなかった。
今はPromiseがあるから、それを使えばいいだろ。
DeferredはPromiseと互換性があるのだから
Promiseのように使うことができる。
jQuery.Deferredオブジェクトを"作る" ときにはPromiseの作り方と違うから
学習コストはいるが、そこでちょっと待てって話だよ。
jQuery.Deferredオブジェクトを作ることがあるのかと。
答えは "ない" だ。昔（Promiseがなかった時代）はjQuery.Deferredを汎用的なPromiseの代用として
使う事もあったかもしれないが、今はPromiseをそのまま使えばいいのだから、もはや作ることはない。
PromiseとDeferredのオブジェクトの作り方は違うが作ることはないのだから学習コストも発生することはない。
今はjQueryのAjax関連の戻り値として、Promiseオブジェクトと互換性のあるDeferredのオブジェクトが
でてくるだけでその戻り値はPromiseオブジェクトであると思って使えば良い。互換性がある。
だから学習コストはかからない。
現状でお前の言う学習コストはどこにもかからないんだよ。
> 「jQuery.Deferredを（今の時代は）使う必要がない」とかいうお前の勝手な考えはどうでもいい
それをいうなら、お前の勝手な考えはどうでもいいｗ >>141
> お前は異常なほどに「jQuery.ajaxの返り値」に拘っているが、俺は一言もajax()には触れてない
お前がなぜajaxに触れていないかのほうが問題。
jQueryでDeferredがでてくるのはajaxの戻り値としてだけだ。
jQuery.ajaxの返り値に拘るなというのなら、じゃあ聞こう。
どこで Deferred がでてくるんだ？
お前は何にこだわっているのかという質問だよ。 >>142
> jQuery.Deferredを廃止してjQuery.Promiseが実装されれば>>77の望みは達成できるのかもしれないね
そこは>>77の望みってなんだよｗｗｗって笑うところだねｗ
さて何だったかねぇ。 何か目的があって>>77はjQuery.Promiseに変えろと言ってるわけじゃないんだよね。
jQuery.Deferredが気に食わないからjQuery.Promiseに変えろと言ってるだけ
気に食わないだけで、肝心の気に食わない理由がない。 「jQuery.Deferredを廃止してjQuery.Promiseが実装されれば>>77の望みは達成できるのかもしれないね」
>>77「確かにjQuery.Deferredを書き換えるよりも現実的だな」
「jQuery.Promiseが実装されれば何が嬉しいんだい？」
>>77「jQuery.PromiseはES6のPromiseと全く同じだから学習コストが下がる！」
「全く同じというのならPromiseをそのまま使えばいいのでは？」
>>77「・・・」
ここまでが想定済みの流れｗ PromiseもFetch APIも実装されてないブラウザがある以上、素のままでは書けないのでPolyfillを適用する必要がある
jQueryを使うなら他にPolyfillライブラリを適用するコストをかけたくないからjQueryだけで完結できれば一番良いというだけ
俺の望みは>>124で書いたことですべて
お前に伝わってないようだが、釈明するのは時間の無駄だと悟ったのでもうしない
悪しからず ちなみにDeferredをPromise.allの引数としてそのまま使えることの証明
https://jsfiddle.net/axL7p4d4/1/
function timeout(ms) {
return new Promise(function(resolve, reject) {
setTimeout(function() {
resolve();
}, ms);
});
}
Promise.all([
timeout(3000),
$.get('/'),
timeout(3000),
]).then(function(data) {
console.log(data[1].split("\n")[0])
}); >>149
> PromiseもFetch APIも実装されてないブラウザがある以上、素のままでは書けないのでPolyfillを適用する必要がある
> jQueryを使うなら他にPolyfillライブラリを適用するコストをかけたくないからjQueryだけで完結できれば一番良いというだけ
それについてはとっくにレスしたよね？
だからPolyfillを適用すれば良い。標準のFetch APIを使うならばjQueryをajax用途として
使う必要はない。だからjQuery 3.0でajax部分を取り除いたSlim buildができたわけ。
jQueryがいくら頑張ろうがPolyfillになることはない。$.Promiseとかになるんだから。
だからお前の目的であるはずの標準APIを使うことはできない。
jQueryでは標準APIと同等のものになることはないのに、
なんでお前はPolyfillではなくjQueryを使おうとしてるんだ？
そこが意味わからんよね。言ってることとやろうとしてることが矛盾してるだろ
標準大好きならば、標準APIのPolyfill + jQuery 3.0 Slim buildの一択だろ。
jQueryはDOM操作用のライブラリに専念させろよ。 >>149
> お前に伝わってないようだが、釈明するのは時間の無駄だと悟ったのでもうしない
それがいいんじゃね？ｗ
俺はお前の言うこと全てに対して反論をしている。
そしてお前は言い返すのをやめた。
万事解決ｗ 結局>>77が一番jQueryを使い続けたがってるってオチかｗ
jQueryが提供しているAPIにはjQuery.eachやjQuery.mapのように
当時は標準JavaScriptにはなかったが、今は標準で提供されている機能がある。
超古いブラウザのサポートが必要ならjQueryのメソッドを使うが
そうでない場合には俺は標準のメソッドを使っているよ。
Promiseも同じ扱いだろ。現在非対応のブラウザにも対応する必要があるなら
jQuery.Deferred（もしくは PromiseのPolyfill）を使うことになるが、
近い将来Promiseを使えば良くなる。jQuery.Deferredを使う必要はない。
その今の時代においてjQuery.Promiseに仕様変更してまで
jQuery.Promiseを使いたいっていう考えが意味不明。
素直に標準のPromiseを使えばいいじゃねーかw 意味不明なら無理に反論しなけりゃいいのに
ここは相変わらずだな >>154
「意味不明なら無理に反論しなけりゃいい」っていう考えがおかしい。
意味不明なことを言っているのなら、意味不明と言ってあげることが本人のためだし
意味不明ということで、相手に反論の余地を与えている。
そこで相手がちゃんと意味を説明できれば、それでいいんだが、
意味不明と言われて黙るってことは、どういうことかがわかるでしょう？
意味不明だっていうことは反論じゃない。
誤字脱字の指摘と同様、意味を明確にしろっていう指摘でしかないよ
（誤字脱字を指摘した程度で、反論したって思うやつはいないｗ） 
