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

**デフォルトの名無しさん** · 2018/06/02(土) 14:31:23.04

JavaScript を自ら学ぶ人のための質問スレッドです。

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。

前スレ
+ JavaScript の質問用スレッド vol.125 +
https://mevius.5ch.net/test/read.cgi/tech/1518940081/

（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです）

**デフォルトの名無しさん** · 2018/11/13(火) 14:08:07.48

こうやって見ると、おめでとう。ようやく今年、JavaScriptライブラリ未使用の
ウェブサイトが少しだけ増えた。だがjQueryを使用してるサイトも同じだけ増えたｗ

って感じだなｗ

>>520にはJavaScriptを使ってないサイトはデータとして出てきてないね
HTMLとCSSだけのページも相当数あるだろうにそのデータはないのかな？
それがないとJavaScriptライブラリを使わないで、
JavaScriptを使ってるサイトの割合はわからないね

**デフォルトの名無しさん** · 2018/11/13(火) 14:09:29.80

訂正

× まとめると、ウェブサイトでJavaScript言語を使用しているのは95%で
○ まとめると、ウェブサイトでクライアントサイド言語を使用しているサイトのうちJavaScriptを使用しているのは95%で

**デフォルトの名無しさん** · 2018/11/13(火) 15:49:33.25

ライブラリ未使用とかこだわりポイントが意味不明
ESでもスタンダードライブラリの仕様策定と実装が進んでるじゃん
エクステンシブルWebの精神で行くと小さなライブラリたくさん組み合わせるのがセオリーだし
そういう点でjQueryって組み合わせづらくて古臭いねって言うのだけは分かる

**デフォルトの名無しさん** · 2018/11/13(火) 16:43:01.03

> そういう点でjQueryって組み合わせづらくて古臭いねって言うのだけは分かる

ふーん、どんな所がか言える？
言えないでしょう？

**デフォルトの名無しさん** · 2018/11/13(火) 19:22:34.71

>>520
相変わらず意図的に間違えてるよな。
いや実は素で間違えているのかもしれんが、多すぎて意図的だと読めるんだよ、普通の人には。
まあもういいが。

>>523
> ライブラリ未使用とかこだわりポイントが意味不明
彼等はそこにこだわっているわけではないと思うが。

結局この話題はひたすらに水掛け論だな。
本来は、「なければないでも出来るが、面倒だからjQueryを使う」というスタンスが正しいのだが、
jQueryが無いと何も出来ない奴が大量にいるからか、ひたすら連呼するから話が進まない。

ま、結果は待つしかないし、待てばいいだけだが。
「jQuery、いつ止めるの？今でしょ！」な人が今止めてるだけ。
GitHubも公式声明出しているが、当然だがプログラマ目線だ。
https://githubengineering.com/removing-jquery-from-github-frontend/
実際の所、1回作って終わりのWebページならほぼどうでもいいのも事実だし、
彼等が脱jQueryするかはまた別の問題だ。

ただ俺は、デザイナが無理してJavaScriptをいじること自体が間違いだと思っていて、
今のところ静的HPフレームワークに吸収されるのではないか、と見ている。
WordPress等も普通なら吸収する方向に動いているはずだが、そうでもないのか？

**デフォルトの名無しさん** · 2018/11/13(火) 19:37:33.16

ねえ、これいつまで続くの？

**デフォルトの名無しさん** · 2018/11/13(火) 19:57:23.03

>>525
> 相変わらず意図的に間違えてるよな。
いつもどおりですが、どこをどう間違えているかを言わない。

> jQueryが無いと何も出来ない奴が大量にいるからか、ひたすら連呼するから話が進まない。
誰もそんな事は言ってない。いつもの思い込み。お前の願望。

話が進まないのは、お前が答えるべきことに何一つ答えないからやで
毎回毎回。答えない。言わないと。俺が教えてやってると言うのにｗ

> ま、結果は待つしかないし、待てばいいだけだが。
もう3年待った

> 「jQuery、いつ止めるの？今でしょ！」な人が今止めてるだけ。
あ、止めたんだｗ飽きたんだね。ネガティブキャンペーンに

> GitHubも公式声明出しているが、当然だがプログラマ目線だ。
見るのはそこじゃない。本来書いてあるべきことのの
「やめてどういうメリットがあったかが書かれてない」ってのが重要

あれ読んでも「あ、やめたんすね。GitHubレベルの技術者でも
大変で時間がかかったんですね。メリットは？」って思うだけ

**デフォルトの名無しさん** · 2018/11/13(火) 19:58:21.09

もしかして：自演

**デフォルトの名無しさん** · 2018/11/13(火) 19:58:57.20

>>526
> ねえ、これいつまで続くの？

jQueryの使用率が今より10%さがるか、Bootstrap、Modernizer、Underscoreを除く
他のUI関連のフレームワーク・ライブラリの使用率が10%を超えたらかな

（なぜこの3つを除くかというと、Bootstrapは本来CSSフレームワークで
JavaScript部分にはjQueryを使っているから。Modernizerはブラウザが搭載している
機能判定をする補処的なライブラリでそれ自体で何かをするものじゃないから。
Underscoreは古いブラウザでも使える関数型風のライブラリでUIとは関係ない。
そして俺のお気に入りの一つだからｗ）

あいつがやめなくても俺がやめてあげよう。
だからすぐだよ！（皮肉ｗ）

**デフォルトの名無しさん** · 2018/11/13(火) 20:10:44.94

https://github.com/twbs/bootstrap/issues/23204
によるとjQuery外すつもりだが人手が足りなくて無理らしい。Please help!とか言ってるわｗ

**デフォルトの名無しさん** · 2018/11/13(火) 20:28:06.61

>>524
全てだよ
jQueryって簡単に言うとライブラリと言うよりフレームワークだから
まずjQueryオブジェクトにラップする時点で
どう考えても他のDOM操作系のライブラリと相互親和性低いじゃん
jQueryはjQueryの世界で閉じちゃってるのは紛れもない事実
だからJSかjQueryかみたいな比較もしばしばされるでしょ？
それが良いとこでもあり悪いとこでもあるけど、
先にも述べたように某マニフェスト的な精神で見ると古臭い

**デフォルトの名無しさん** · 2018/11/13(火) 20:30:56.09

> jQueryって簡単に言うとライブラリと言うよりフレームワークだから

jQuery: The Write Less, Do More, JavaScript Library.
https://jquery.com

**デフォルトの名無しさん** · 2018/11/13(火) 20:38:55.64

jqueryはdesignerが触れるという意味において、流行ってるな。

**デフォルトの名無しさん** · 2018/11/13(火) 21:18:27.76

>>532
自身がどう名乗ってるかはどうでもいい
そういう話はしていないから
ここでは
問題解決のための汎用性が高い機能を集めたもの：ライブラリ
問題解決のための枠組みを提供するもの：フレームワーク
という専ら粒度的な意味で使ってることは君も分かりきってるのに
全く無駄でしか無いレスを返すのは控えてくれ
一度警告したから、次からは取合ないよ

**デフォルトの名無しさん** · 2018/11/13(火) 21:32:36.37

お前がどう思ってるかはどうでもいい。

**デフォルトの名無しさん** · 2018/11/13(火) 22:02:02.21

>>527
君との話が進まないのは、君が毎回誤解/曲解して、その修正に1レス以上必要だからだ。
だからまじめにいちいち修正してたらいつまで経っても進めないし、
ならばと誤解を無視して強引に進めたら周りが混乱したようだし、これも不味かった。

GitHubが何を言ってるのか分からないのは、君がプログラマではないからだ。
(ただ、君はデザイナなのだから、分からなくてもいい)
プログラマなら、ああ、なるほどね、と理解は出来る。共感するかはまた別だが。

とはいえ、イノベーター連中が騒いでいたのとは違い、GitHubはおそらくアーリーアダプターに位置する。
この彼等が動いた、というのは大きいんだよ。

まあとにかく、君の言い分は分かった。
いずれにしても水掛け論だし、俺はここら辺でももういい。

プログラマにとっては、jQueryの問題点は色々あって、それはもう共通認識だ。
だからこそ、いつ脱jQueryするか、という話になる。
勿論、ずっとしない、というのも一つの選択だ。ただ、これもまた、非常に勇気の要る選択ではあるんだよ。
だからみんな顔色をうかがっているわけでさ。

君みたいなデザイナも脱jQueryするかは俺には分からん。
ただ、俺はデザイナは脱JavaScriptするべきだし、環境もそう整備される、と思っている。

**デフォルトの名無しさん** · 2018/11/14(水) 01:38:21.51

>>531
> まずjQueryオブジェクトにラップする時点で
> どう考えても他のDOM操作系のライブラリと相互親和性低いじゃん
「ラップしてるから親和性低いはずだ」というのが根拠ない思い込みで、
他のDOM操作系ライブラリの方に問題があったら話は別だが、
jQueryは標準のDOM APIとの親和性が高い

例えば、これはDOM APIのquerySelectorAllを使って
要素を繰り返すコードだが
const es = document.querySelectorAll("li");
for(const e of es) {
　　console.log(e.textContent); // 当然のことながらeはDOM APIの要素
};

jQueryでも、そのまま使える。
const es = $("li");
for(const e of es) {
　　console.log(e.textContent); // eはDOM APIの要素
};

その逆でDOM APIの関数の戻り値をjQueryで使いたければ、そのままjQueryに渡せばよい
$( document.querySelectorAll("li") ).css({color: 'red'});
実際に動くサンプル
https://jsfiddle.net/x7nvc4og/

また以下のDOM APIのaddEventListenerとeventを使ったイベントハンドラだが
jQueryでも同じイベントハンドラがそのまま使える
https://developer.mozilla.org/ja/docs/Web/API/Event/target
実際に動くサンプル
https://jsfiddle.net/26Lw4kdg/

見てわかるようにjQueryはDOM APIと混ぜて使えるほど、親和性が高いんだよ

**デフォルトの名無しさん** · 2018/11/14(水) 01:57:17.84

jQueryがなぜDOM APIとこんなにも親和性が高いかと言うと、
DOM APIとの互換性を強く意識して設計されているからなんだよ

例えば、jQueryのEventオブジェクト
https://api.jquery.com/category/events/event-object/
ここに書いているように、独自に作り出されたものじゃなく、
標準のDOM APIのEventオブジェクトへのPolifillになっている

> jQuery's event system normalizes the event object according to W3C standards.
> The event object is guaranteed to be passed to the event handler.
> Most properties from the original event are copied over and normalized to the new event object.

Google翻訳

> jQueryのイベントシステムは、W3C標準に従ってイベントオブジェクトを正規化します。
> イベントオブジェクトは、イベントハンドラに渡されることが保証されています。
> 元のイベントのほとんどのプロパティは、新しいイベントオブジェクトにコピーされ、正規化されます。

またjQueryはDOM APIの document.querySelectorAll の戻り値であるNodeListに相当するものに
メソッドを追加したもの。NodeListにあるメソッドは要素を繰り返すためのものばかりで
NodeListの全ての要素に対して、一括でなにかをするメソッドはない

その反対でjQueryには要素一つを表すものは存在しない。NodeList相当のjQueryオブジェクトしか無いので
要素一つに対して何かをする場合は、DOM APIの要素をそのまま利用している
（例えばjQueryのeachメソッドのループ内で参照する要素一つやイベントハンドラ内のthisがDOM要素）

つまり
標準のDOM API・・・単一の要素に対してメソッドを呼び出す
jQuery・・・複数の要素に対してメソッドを呼び出す（単一要素を処理するときはDOM要素を使っている）

と機能を提供している対象が違っており、それぞれお互いを補完する形になっている。

**デフォルトの名無しさん** · 2018/11/14(水) 01:58:06.99

>>536
> 君との話が進まないのは、君が毎回誤解/曲解して、その修正に1レス以上必要だからだ。
一つも修正してないじゃんｗ

**デフォルトの名無しさん** · 2018/11/14(水) 02:00:25.32

なんでDOM APIとの互換性を考慮する必要があるの？ｗｗ
jQueryで全部できるんじゃないんですくぁ～？ｗｗｗｗｗ

**デフォルトの名無しさん** · 2018/11/14(水) 02:08:33.10

>>540
> なんでDOM APIとの互換性を考慮する必要があるの？ｗｗ
> jQueryで全部できるんじゃないんですくぁ～？ｗｗｗｗｗ

だから、アンチjQueryが、jQueryを使っているならば
全部jQueryの世界で閉じてるはずだ！
jQueryで全部できるんじゃないですか～って
思ってるのがそもそも間違いってことだよｗ

jQueryを使ったプログラミングでは日常的に標準のDOM要素を使っている。
実際にonのイベントハンドラ内のthisとかDOM要素なんだから。
jQueryは設計の時点で、標準のDOM要素を使うことを想定してある

それを知らないで、コードを上っ面だけ眺めて、全部jQueryでやってるように見える。
これ全部jQueryの世界だ。DOM APIの世界と全く違う！独自の世界だ！！
なんて言ってるから、呆れるわけでｗ

**デフォルトの名無しさん** · 2018/11/14(水) 02:23:13.08

そうだ。良いことを思いついた。
NodeListにjQueryと同等のメソッドを追加すれば良いんじゃね！

標準のクラスを拡張するのはPrototype.jsで標準のメソッドとかぶり
痛い目を見た歴史があるが今の人類ならやれるかもしれん

jQueryの本質 = DOM APIに足りないNodeListへの一括操作メソッドを
提供してるってのがよく分かるだろう？
そうすりゃ標準のDOM APIを使っているように見えて
アンチjQueryさんも便利だねって満足するだろｗ

document.querySelectorAll("li").css({color: 'red'}) とか
document.querySelectorAll("li").on(function() {・・・} ) とか

左側が長すぎでバランス悪いな

document.querySelectorAll("li").addEventListener(function() {・・・} )

標準さんには、やっぱりこうか？ｗ

**デフォルトの名無しさん** · 2018/11/14(水) 06:45:30.47

NodeListには全くタイプの異なる要素が含まれる可能性がある
それこそTextNodeとかも入りうるのにイベントやスタイルを一括処理するメソッドが入るのは不自然だろう
fiilterとか全部入れないといけなくなるし
そこはAPI提供先の言語の機能を借りた方が良いだろう
DOMってJSだけのものではないからね

**デフォルトの名無しさん** · 2018/11/14(水) 08:37:27.50

>>543
> NodeListには全くタイプの異なる要素が含まれる可能性がある
なかなかおもしろいツッコミをしてくれたね解説したくなっちゃうよｗ
jQueryは素晴らしくてなぁ「全くタイプの異なる要素が含まれる可能性」があっても問題ないんだよ

これを見てほしい。なんとjQueryの引数には、セレクタや単一の要素、要素の配列だけではなく
任意のオブジェクトを渡すことができると、仕様にしっかりと明記されてるんだ

http://api.jquery.com/jQuery/#jQuery-object
> jQuery( object )
> object
> Type: PlainObject
> A plain object to wrap in a jQuery object.

だからタイプの異なる要素が含まれても問題ないと言うか、
必然的にそうなったと言うか、普通に作るとそうなるというか・・・
これjQueryが素晴らしいって話というよりも
「全くタイプの異なる要素が含まれても問題ない」ということに君が気づいていないだけ

これjQueryのプラグインを作ると理解できるんだよね。
例えば、console.logにA要素のURLとその文字列長を出力するlenという
jQueryプラグインを作る。そのコードは以下の通り

(function( $ ){
　　$.fn.len = function() {
　　　 return this.each(function() {
　　　　　console.log(this.toString() + ':' + this.toString().length);
　　　　});
　　}
})( jQuery );

$("a").len(); と書くと全てのA要素のURLとその文字列長を出力する。

**>>544の続き** · 2018/11/14(水) 08:38:50.65

上でjQueryには配列で管理していると書いたが、
上のコードにもあるように、eachメソッドでループしてそれぞれの
要素に対してメソッドを実行している。

jQuery関数の引数にセレクタを渡すとDOM要素の配列として内部で持ってるわけ
そしてそれぞれの要素に対してメソッド（今回はtoString() ）を実行しているだけなんだ。

ということは、つまり、このプラグインは、以下のような使い方もできる。
$(["red", "blue", "green"]).len();

jQueryオブジェクトでラップして使うための要件を要約すると

1. jQuery関数に渡したものは、配列に出来さえすればいい（すべてできる）
2. 配列をeachでループできればいい（配列なのでループできる）
3. オブジェクトに使用するメソッドが生えてさえすればいい

たったこれだけなんだ。DOM要素でなければいけないなんて要件はない。
配列化された個々のオブジェクトに使用するメソッドがあればいいだけなんだよ
（もちろんメソッドの有無を判定して、なければスキップすることもできる）

つまりな、全く異なるオブジェクトが入ろうが、ループで回してオブジェクトに
メソッドが生えていればそれを呼び出すだけなんだから、
まったく異なるタイプのオブジェクトだって対応できるんだよ

**デフォルトの名無しさん** · 2018/11/14(水) 08:45:00.29

これは、ダックタイピングの考え方そのものだよね
型は関係ない。使用するメソッドさえあればいい。

jQueryはDOMを扱うライブラリだから、
DOM要素でなければ引数に出来ないと思い込みがちなのはわかる。

だけど、jQueryで提供しているメソッドこそ、DOM操作用のメソッドってだけで
単一の要素を配列として操作するという設計は、DOM専用のものではなく
DOM以外にも適用可能なわけだ。

まさにこのような使い方ができる通り
$(["red", "blue", "green"]).len();

貼り忘れていた。実際に動くサンプル
https://jsfiddle.net/vxpk0yef/

**デフォルトの名無しさん** · 2018/11/14(水) 08:54:39.25

まあ、よくよく考えてみると、

> NodeListには全くタイプの異なる要素が含まれる可能性がある

$('.foo')と書いたって、全くタイプの異なる要素が含まれる可能性があるわけで。

例えば、$('.foo').prop('checked')と書いても、checkedプロパティが
存在しない要素の可能性もあるわけで、最初から対応済み。
（プロパティがなければスキップされる）今更なんだよねｗ

**デフォルトの名無しさん** · 2018/11/14(水) 12:49:14.50

>>540
そういう大言はせめて、addEventListenerの第三引数が実装されてから、いえ

**デフォルトの名無しさん** · 2018/11/14(水) 12:58:16.26

>>543
俺はjQuery擁護派でも何でもないので、純粋に知的好奇心から尋ねるが、NodeListにテキストノードが入る再現コードは何だろう？
確かに、仕様上は要素ノードに限定されてはいないのだが、再現コードが分からんhttps://triple-underscore.github.io/DOM4-ja.html#interface-nodelist

**デフォルトの名無しさん** · 2018/11/14(水) 13:00:03.13

>>548
それは互換性上の問題だから仕方ないね。
昔のIEには第三引数相当の機能がなかったんだから

別に今でも必要なら使える。jQueryは混ぜて使えるから
本格的な対応はjQuery 4.0の登場を待ちましょう。

https://github.com/jquery/jquery/wiki/jQuery-4.0-Event-Design

> Support all addEventListener options
> Avoid the need for a jQuery.Event wrapper
> Eliminate manual .trigger() bubbling and method calls
> Remove special events hooks
> Provide backcompat through Migrate 4.0

もうそろそろ3.4がリリースされる予定
今年の年末に4.0のベータ版を出すという話があったけど
遅れてるんだろうね

**デフォルトの名無しさん** · 2018/11/14(水) 13:24:10.18

>>549
わかってると思うがNodeListはNodeのコレクションなので、
理屈上はNode自身とそのサブクラスはコレクションに入れることができる
TextNodeはNodeのサブクラスなので入れることはできる
https://developer.mozilla.org/en-US/docs/Web/API/Text

>>543は全くタイプの異なる要素が入る可能性と言ってるがNodeでないものは入らない。

jQueryで言えば、contents()メソッドを使うと、jQueryオブジェクトにテキストノードが入る

サンプル
https://jsfiddle.net/32mwdfnc/
$("#id").contents().each(function() {
　console.log(this.toString());
});

出力結果
[object Text]
[object HTMLSpanElement]
[object Text]
[object HTMLSpanElement]

俺の知る限りjQueryでテキストノードを取得する方法はこれだけだろう。
セレクタを使用している以上、セレクタから引っ張ってこれないものはメソッドを使って取得するしか無い

話はそれたが、NodeListにテキストノードが入る再現コードだが、同様に同じくセレクタから引っ張ってくる
DOM APIのqueryselectorAllでもテキストノードは取得できないはず
セレクタではなくXPathを使用すればテキストノードも引っ張ってこれるが、これはNodeListではない

将来テキストノードを取得するためのセレクタができる可能性はゼロではないと思うが
それはそれとして、図らずともjQueryはすでにテキストノードにも対応してる
（ contents()メソッドの存在）ってことが示せたと思う

**デフォルトの名無しさん** · 2018/11/14(水) 13:31:51.54

ああそうか、NodeListを返すなら、queryselectorAll限定である必要はないな。
jQueryのcontents()メソッドに対応するDOM APIってことで調べたら、
childNodesがテキストノードも含まれるNodeListを返したよ
https://developer.mozilla.org/ja/docs/Web/API/Node/childNodes

**デフォルトの名無しさん** · 2018/11/14(水) 16:03:13.17

ローカルのjavascriptから公開されているAPIにアクセスできません
ググったらAPIを置いてる方で許可しろと出ましたが、公開している以上それはしてるはず？
他にブラウザのセキュリティを切るというのもありましたが、それはしたくありません

エラー内容（URLのhを抜いています）
クロスオリジン要求をブロックしました: 同一生成元ポリシーにより、ttps://ext.nicovideo.jp/api/getthumbinfo/sm500873 にあるリモートリソースの読み込みは拒否されます (理由: CORS ヘッダー ‘Access-Control-Allow-Origin’ が足りない)。
NetworkError: A network error occurred.

コード（htmlのボタンをクリックしたらgetJSON()。ググったのをコピーしてURLを変えただけ）
function getJSON(){
var req = new XMLHttpRequest();
req.onreadystatechange = function() {
if(req.readyState == 4 && req.status == 200){
alert(req.responseText);
}
};
// req.open("GET", "sm500873", false); // ローカルに保存したものはOK
req.open("GET", "ttps://ext.nicovideo.jp/api/getthumbinfo/sm500873", false); // ←エラー　h抜き
req.send(null);
}

実際にアクセスしたいAPI
SOLD OUT 2 API　ttps://so2-docs.mutoys.com/common/api.html

コードが間違っている
API側で許可されていない。普通は使う側がセキュリティを切る
その他
どれでしょう？

**デフォルトの名無しさん** · 2018/11/14(水) 16:25:09.78

>>553
とても明確に理由が示されているのだが > CORS
下のSOLD OUTの方がどうなってるかは知らん

CORSについてはブラウザでやるのを諦めるのが正解

**553** · 2018/11/14(水) 17:27:47.03

>>554
レスありがとうございます
ニコ動のAPIのように公開されているものでも、CORSは許可していないということですか？
API公開≒CORS許可で、こちらに何か足りないと思ってました
保存したものなら大丈夫なので、保存だけ別の方法を探してみます

**デフォルトの名無しさん** · 2018/11/14(水) 17:32:04.39

ログインすりゃ使えるんじゃね？知らんけど
無制限に許可なんかしたら負荷かけられまくるんだから
誰がAPIを叩いたか知るためにもログイン必須はおかしくないでしょ？

**デフォルトの名無しさん** · 2018/11/14(水) 17:47:55.65

基本的に外部サイトへのリクエストはセキュリティ上の理由で禁止されてるんだけど、それを許可するのがCORS
これは外部サイト（ここではAPI）側でしか設定できないから、迂回するにはCORSヘッダを付加するプロキシサーバーみたいなのを建てるしかない
GET限定で良ければ誰かが建てたそういうサーバーがある（CORS Anywhereとかcrossorigin.meとか）けど、利用する場合は自己責任で
（レスポンスが改ざんされたり、動いてなかったりするかもしれない）

**デフォルトの名無しさん** · 2018/11/14(水) 19:32:52.05

>>557
なんやこれ便利すぎるｗｗｗ
jQuery糖質キチガイに辟易しながらもこのスレ覗いてて良かったｗｗｗｗ

**デフォルトの名無しさん** · 2018/11/14(水) 20:52:38.60

>>544
問題あるかないかの話はしてないよ
そりゃ問題ないように作るということは幾らでもできるから
でもNodeListというクラスのメソッドとしては性質上「不自然」だって言ってるの
適当にコーディングするためのjQueryでは許されても標準では許されないよ

**デフォルトの名無しさん** · 2018/11/14(水) 21:58:20.23

jQueryが受けているのは「初心者にとって丁度いいから」というのもある。
PHPがそうだが、上級者から見ると「なんでこうした？」というのが多いが、
初心者にとってはそれくらいベタの方が使いやすい。
だからPHPも初心者受けは良い。同様に、jQueryも初心者受けは良い。ベタだからだ。
(フレームワークは初心者にとっては何をどう使えばいいかさっぱり分からない。
これがjQueryにはない、ということ。）

ただ、jQueryは低レベルすぎて、短く書けるだけで、やること/管理することが減るわけではないから、
上級者にとっては導入のメリットがない。
むしろ、依存関係が増え、記述が冗長になる（複数の書き方が混在する）という意味で悪だ。
だから、腕前を上げるに従い脱jQueryを目指すのも自然なことで、「自転車の補助輪だ」というのも当たってる。
タイピング量なんて全くどうでもいいし。

ただこれらは「上級者」に近くなってこないと理解出来ないし、
当然デザイナと話をしてても水掛け論にしかならず、話は堂々巡りだ。
ある意味、デザイナがプログラミングまで出張ってきているJavaScriptの世界が特殊なのだろう。
アプリを組めるレベルになってくるとjQueryの問題点は自明として、
それ以下だと認識出来ないから、意外にずっと使われるのかもね。ある意味PHPもそうだし。

あれは、「サイトの数」で比較するからjQueryのシェアが高く見えるんだろうな。
実際の「Web閲覧時間」での比較が出来れば一番良いのだけど、これは直接的には無理だから、
現実的には「サイト数をPVで加重平均」したものが妥当かな？
これだと実際に見られているシェアとなり、感覚的にも一致するはずだし。

>>544
> jQueryは素晴らしくてなぁ「全くタイプの異なる要素が含まれる可能性」があっても問題ないんだよ
それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。

ま、NodeListについては、DOM自体がいまいちOOPに乗り切れてないことの問題ではあるが。

**デフォルトの名無しさん** · 2018/11/14(水) 22:50:55.26

> それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。

また、それがどこか答えない。
同じことの繰り返しだな。

通じない？当たり前だ
お前が何も言ってないんだから

**デフォルトの名無しさん** · 2018/11/14(水) 23:02:21.85

>>561
いやモロに書いてるがな。

マジな話、お前英語も読めないよな？語学の問題ではなくて、知能の問題で。
日本語だけ2行ずつしか読めない、ってのもあり得ないし。

それともお前の頭の中ではスコープ外で話題を追跡出来てないのか？
俺が言ってるのは当然>>525内URLの事だぞ。

**デフォルトの名無しさん** · 2018/11/14(水) 23:08:02.36

> いやモロに書いてるがな。

いつもどおり。リンクを示せば良いものを
書いていると書くだけでおしまい。
やり口がかわらんなぁｗ

**デフォルトの名無しさん** · 2018/11/14(水) 23:09:10.35

訂正
× リンクを示せば良いものを
○ 引用するなどして、具体的な箇所を示せば良いものを

**デフォルトの名無しさん** · 2018/11/14(水) 23:16:47.50

>>563
お前もいつも通り連呼リアンだよな。
普通は562は「リンクを示した」と言うぜ。

お前、煽り抜きで頭おかしいと思うぜ。マジで池沼。
同様の奴が他に2人いると書いたが、お前が一番程度が酷い。
さすがにそれだとリアルの普通の会話も成立しないだろ。

**デフォルトの名無しさん** · 2018/11/14(水) 23:22:14.41

>>564
英語読めるつもりなんだろ？自分で読めよ。
というか、あれ、脱jQueryが気になる奴は、読む価値はあると思うぜ。

お前は読んでも全部読むうちに忘れちゃうんだろうけどさ。
それでもお前の頭は交換不可能で、お前自身で鍛えるしかないんだから、
無い頭使って一生懸命読めよ。
それを繰り返してたら、お前のその頭も少しはましになるよ。

**デフォルトの名無しさん** · 2018/11/14(水) 23:27:59.81

なお、GitHubの公式声明の内容は割と普通のことなので、
普通に脱jQueryを実行出来る人は特に読む意味はありません。

何故脱jQueryなのか？に疑問を持つ人は、読む価値があると思います。

**デフォルトの名無しさん** · 2018/11/14(水) 23:32:34.35

だから、GitHubの声明には本来書いてあるはずのjQueryをなくして
その結果、何が得られたかが「書いてない」ってのが、注目する点なんだってばｗ

**デフォルトの名無しさん** · 2018/11/14(水) 23:49:27.00

>>568
お前はそれを連呼しているが、実際そうじゃない。

やっぱりお前、英語も読めないよな。まあ、当然か。
語学以前に論理/記憶がお前の頭にはないからな。

まあ、そういう池沼レベルの奴でも使える、というのはjQueryの利点ではあるよ。
お前も>>409で指摘している点だ。
Excelだって数式までは宣言型で逐次処理無し（順序の概念無し）なのでアホでも使えるし。

**デフォルトの名無しさん** · 2018/11/15(木) 00:17:06.64

はい、想定通りのレスきました

**デフォルトの名無しさん** · 2018/11/15(木) 00:22:47.33

>>552
なるほど、childNodesか
https://dom.spec.whatwg.org/#dom-node-childnodes

**デフォルトの名無しさん** · 2018/11/15(木) 00:29:18.03

>>550
昔のIEが対応外になっている時点で関係ない
そして、俺はDOM API不要論者(>>540)に反論しただけなので、あなたのは論点がずれてる

**デフォルトの名無しさん** · 2018/11/15(木) 00:47:30.01

いつものインタビュー貼っておきますね
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

**デフォルトの名無しさん** · 2018/11/15(木) 00:58:36.39

>>553-557
自分のPC にサーバーを立てて、サーバー経由でアクセスしないと、
ブラウザからでは、CORS でアクセスできない

例えば、自分のPC 内のHTML ファイルを、ブラウザで起動して、
そのページから、5ch へアクセスできない。
iframe 内に読み込んでも、iframe 内外が、別ドメインだからアクセスできない

ruby -run -e httpd . -p 8080

1-liner で、Web サーバーを起動して、そのindex.html からは、別ドメインにもアクセスできる

**デフォルトの名無しさん** · 2018/11/15(木) 01:02:00.51

>>572
そして、俺はDOM API不要論者(>>540)に反論しただけなので、あなたのは論点がずれてる

そうだね。俺のレスへの返信じゃなかったわｗ
俺はDOM API不要論者じゃないので。

俺は >>550にも書いてあるように混ぜて使って良い派
むしろ普段から混ぜて使っているんだよ派か
（jQueryで出てくるthisはDOM要素だから）

**デフォルトの名無しさん** · 2018/11/15(木) 01:03:57.60

>>574
オリジンが違うんだから出来ねーよ

**デフォルトの名無しさん** · 2018/11/15(木) 15:35:01.66

オリジンが違ってもアクセスはできるだろ
取得した中身が読み取れないだけ

**デフォルトの名無しさん** · 2018/11/15(木) 17:42:32.99

アクセス拒否されるし取得できない。
何いってんだコイツ

**デフォルトの名無しさん** · 2018/11/15(木) 20:16:01.66

何いってんだコイツはお前だアホ
await fetch('https://developer.mozilla.org/',{mode:'no-cors'})
アクセスしてるだろうが
もし拒否されるのならServiceWorker導入ページでどうやって
外部リソースをリクエストしたりキャッシュしたりするつもりなんだ？
人様にケチ付ける前に自分が無知であることを知れよ

**デフォルトの名無しさん** · 2018/11/15(木) 21:17:25.79

元々の文脈考えたらアクセスできない、で良くね？
オリジン違えば非同期通信でAPIのレスポンスは取ってこれない
jsonp対応してれば行けるだろうがそれはまた別の話だ

**デフォルトの名無しさん** · 2018/11/16(金) 01:36:26.11

>>579
そもそも文法エラーだなそれ。
出直してこいｗ

**デフォルトの名無しさん** · 2018/11/16(金) 03:07:01.97

> 人様にケチ付ける前に自分が無知であることを知れよ
で自分を人様って言ってるのも色々アレ

**デフォルトの名無しさん** · 2018/11/16(金) 03:15:01.26

まあそれは煽りでよく見る

**デフォルトの名無しさん** · 2018/11/16(金) 05:29:59.60

>>580
元の文脈的にサムネイルとかのメディアデータへのリンクが分かるのなら
それはimgやvideoタグで表示されられるかも

**デフォルトの名無しさん** · 2018/11/18(日) 22:16:13.60

JAVAscriptと書くのは普通ですか？
ネットで見たのですが

**デフォルトの名無しさん** · 2018/11/18(日) 23:02:17.55

好きに書けばいいんです

**デフォルトの名無しさん** · 2018/11/19(月) 08:23:17.32

JaVa$cRiPt

**デフォルトの名無しさん** · 2018/11/29(木) 23:02:47.57

勉強にのためにライブラリのjplayerを解読しようとしてるが
難しすぎる。
おまえら、javascript勉強してるってこは
ライブリとかもすらすら読んでわかるの？

**デフォルトの名無しさん** · 2018/11/29(木) 23:33:09.60

>>588
前提でJQueryとかの知識がいるからじゃない？
こういうやつとか初心者が試行錯誤でやったやつの方がわけわからん
https://qiita.com/ryuichi1208/items/f9e6ac2b99bbe4fc82d3

**デフォルトの名無しさん** · 2018/11/29(木) 23:41:56.52

jQuery使わなかったらもっと難解になるんだよな

**デフォルトの名無しさん** · 2018/11/30(金) 00:00:53.52

>>588
覚えればすむものは楽なんだよ。
単に覚えればいいだけ理解すればそれで終わりなんだから。

大変なのは>>589みたいなもの。ありえないほど短いコードで
実現しているから凄いといわれるけど一般的にはクソコードと言われる類。

なぜかというと、コードというのは簡単に読めるものじゃないといけない
もちろん知識をつけたもの、能力がある人にとってね。

知識があって能力がある人でも読むのに時間がかかるような
無駄な処理ばかりで何をやってるか分からないようなものは大変
それが「解読」という作業。これはコードに問題がある。

知識がなくてわからないのは解読じゃなくて単に読めないだけ
読んでる人に問題がある

**デフォルトの名無しさん** · 2018/11/30(金) 08:44:57.62

7行テトリスは、まるで暗号

jQuery のCSS セレクターを学べば？
基本的には、# . > など、Emmet と同じ

Ruby のNokogiri でもよい

**デフォルトの名無しさん** · 2018/12/02(日) 13:56:14.24

やっぱ、オレの勉強不足だな。
もっとjavascript勉強しよ。
日経ソフトウェア読んでると、javascriptに
Reactという仮想DOMとか出てきてるし
どんどん新しい技術出てきてる

**デフォルトの名無しさん** · 2018/12/02(日) 16:53:20.50

仮想DOMは、なんでDOMを全部再構築するというアイデアが
出発点になってるのかわからない。
jQueryがやってるように普通に必要なところだけDOMを更新すればいいだろう

**デフォルトの名無しさん** · 2018/12/02(日) 16:55:13.96

なるだけ参照透明にしたいからじゃない？

**デフォルトの名無しさん** · 2018/12/02(日) 17:19:20.90

部分更新も、複数回のDOM操作がinnerHTML差し替え1回で済ませられたらメリットはあるんじゃね。

**デフォルトの名無しさん** · 2018/12/02(日) 17:22:34.32

>>594
遅延描画したいからだよ。以下参照。
https://qiita.com/risagon/items/019942c60e9c3e6c05a5

**デフォルトの名無しさん** · 2018/12/02(日) 17:53:11.92

複雑になってくると毎回全部再構築した方が楽だと思うけど
昔はDOMが遅くて実現が難しいとかじゃなかったっけ

**デフォルトの名無しさん** · 2018/12/02(日) 17:59:05.26

>>598
jQuery死ね

**デフォルトの名無しさん** · 2018/12/02(日) 20:39:03.60

推薦書

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発、
花谷拓磨、2018/10/17

基礎から学ぶ Vue.js、mio、2018/5/29

Node.js超入門、掌田津耶乃、2017

Electronではじめるアプリ開発
~JavaScript/HTML/CSSでデスクトップアプリを作ろう
野口将人・倉見洋輔、2017

入門 React ――コンポーネントベースのWebフロントエンド開発、2015

Reactビギナーズガイド ――コンポーネントベースのフロントエンド開発入門
Stoyan Stefanov, 2017
https://github.com/stoyan/reactbook

初めてのJavaScript 第3版 ――ES2015以降の最新ウェブ開発、オライリー、2017

**デフォルトの名無しさん** · 2018/12/02(日) 20:50:24.13

VueはVue.js入門が出たから猫の方はいらんよ

**デフォルトの名無しさん** · 2018/12/03(月) 08:37:17.60

>>598
> 複雑になってくると毎回全部再構築した方が楽だと思うけど
> 昔はDOMが遅くて実現が難しいとかじゃなかったっけ

つまりマッチポンプってこと？

1. jQueryなどを使って必要な部分だけ構築する・・・一番速い
2. （アホな）アイデア思いついた！全部再構築したほうがいいんじゃね？・・・遅い
3. VirtualDOM使えば（jQueryほど速くないけど）全部再構築しても遅くならない！

VirtualDOMって遅くならないだけなんだよね
決してjQueryよりは速くはならない

**デフォルトの名無しさん** · 2018/12/03(月) 08:40:10.65

>>594
そもそも遅延描画する必要がないですよね
仮想DOM使っても結局変更部分はDOM操作をするんだから
仮想DOMを使わずに、変更部分をDOM操作すればもっと速いですよね

なんで仮想DOMは速いって嘘をつくんだろう？
遅くならないって言えばいいのに

**デフォルトの名無しさん** · 2018/12/03(月) 08:55:08.53

そもそも、仮想DOMの方が常にjQueryより速いと主張する奴がいるという思い込みじゃね？

**デフォルトの名無しさん** · 2018/12/03(月) 09:07:38.44

例えば>>597にも書いてますね。

> VirtualDOMの仕事ってなに？(Reactの表示速度がはやい理由)

「Reactの表示速度が遅くならない理由」と書けばいいのに

もともとDOM全部再構築なんて遅くなるような馬鹿げたことはやってないんですよ
逆にどうやってjQueryでDOM全部再構築をやれと？
めんどくさくてやってられないし遅いのでやらない

遅くなるDOM全再構築なんて馬鹿げたことをやって
遅いだろう？でもこれだと遅くないんだぜってっていうのが
マッチポンプなんですよ

**デフォルトの名無しさん** · 2018/12/03(月) 09:08:21.84

まぁ藁人形論法だね。
その他によく知らない初心者が勘違いしたまま質の悪いウソ情報をネットに垂れ流してるというのもある。

**デフォルトの名無しさん** · 2018/12/03(月) 09:11:08.96

>>597は典型的な勘違いして垂れ流してる初心者だなｗ
こんなのよりReact登場初期の、初心者が知ったかでイキってられない時期に書かれた記事読んだ方がいい。

**デフォルトの名無しさん** · 2018/12/03(月) 09:19:09.58

「今までは、基本的に受け取った情報を元にDOMを
一から作成してブラウザに描画することが多かった」

こんなことやってませんからね

サーバーを介さないクライアントだけで処理できるもの、
例えばボタンがクリックされた時に何かを行う処理は
必要最小限のDOMしか変更しないんので速い

「受け取った情報を元に」と書いてあるからAjax前提の話か
ページ遷移の時の話だろうけど、ページ全体を読み込むよりかは
一部分のほうが早いのは当然として、それはAjaxを使えばいい。
Ajaxを使って、必要最小限のところだけ書き換えるのが普通

DOMを一から作成してブラウザに描画とかしないから

**デフォルトの名無しさん** · 2018/12/03(月) 12:37:01.63

SPAだと自前でページ遷移作ることになるやろ

**デフォルトの名無しさん** · 2018/12/03(月) 15:23:56.50

SPAにページ遷移という概念が存在するとは限らない
SPAはアプリケーションなのだから
ただ単純に実際のページ遷移を伴わない技術はpjaxと言ったほうが良い

**デフォルトの名無しさん** · 2018/12/03(月) 21:51:55.26

あれ？いつもの奴ではないjQuery廚が沸いている？

が、まあいい。
そもそも素人向けの解説は当然色々端折るので厳密にはそれなりに間違いを含む。
これは至極当然だ。それに対して発狂しても意味がない。
それらは、「このレベル向けの解説ならこの程度で妥当か？」で判定されるべきだ。
この点、俺は597はまあまあだと思うが。

そもそも詳しく分かるんなら、もっと詳しい解説をググればいいだけだ。以下とか。
http://steps.dodgson.org/b/2014/12/11/why-is-real-dom-slow/
https://postd.cc/the-inner-workings-of-virtual-dom/

jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。
だったらフレームワークにしちゃおうぜ、という話であってさ。

俺はReactが実際どこまで端折っているのかは知らんが、(使ってないし、使う予定もない）
上記2つの記事が正しければ、限界まで端折っている。
> React は処理を省いたコンポーネントの render() を呼びださない。 (1つ目のリンク）
> フローチャート内、renderはど頭の処理 (2つ目のリンク）
仮に現状では限界まで端折れていないとしても、
Reactのアップデート共に改善されて最終的には限界まで端折ることになる。
この辺の、改善を外部のアップデートに期待出来ることも、フレームワーク等を導入するメリットでもあるだろ。

**デフォルトの名無しさん** · 2018/12/03(月) 21:52:51.04

その記事内にもあるが、
> ウェブ開発者が文句をいう DOM の遅さは大半がレンダリング由来だったりする。
これは全くその通りで、レンダリングさえしなければDOMは遅くない。
(jQuery廚が居るから一応言っておくが、クエリもそれなりに遅い。
ただ、Reactとか使う人はクエリはほぼ全くしないはず。というかこの構成だと禁止かも？）
つまり、document.create等は十分速く（＝仮想DOM構築も速い）、レンダリングだけが遅いから、
どうにかしてレンダリングを止めさせよう（少なくしよう）というのが遅延描画だ。
それが必要かどうかは場合による。
描画しなくて済む範囲が多ければ、当然ぶっちぎりで速い。
jQueryは生JavaScriptよりも本質的に遅いから、遅延描画が効くようなら、

生JavaScriptで遅延描画>フレームワークで遅延描画>>>生JavaScriptで描画>jQueryで描画

となる。
ただし遅延描画の肝心要のoffsetTop等がこれまた致命的に遅いので、（レンダリングを要する為）
単純に遅延描画にすれば（体感的に）速くなる訳でもない。
jQueryを使ってて許されてるのなら、そのサイトはスピード狂ではないので、
遅延描画を要求されることもないのではないかな？

ただそもそも、遅延描画が効くサイト構成の所も少ないかも。
例えばアマゾン、商品一覧はいちいち「次のページ」を押して遷移するようになっている。
SPAでページ毎に商品表示部分を全面描画してる。
（ページ全体の全面描画ではなく、商品部分の全面描画。念のため）
ページ内商品点数は36なので、この程度では遅延描画はあまり効果がない。
（というか下手にやると余計に遅くなる。少なくともPC環境ではそう。モバイルだと違うかも）

俺はこういうのは無限スクロールでぐりぐりやってればいくらでも見える方が好きなのだけど、
そういうサイトは確かに少ない。
(とりあえず150点くらい表示出来るオプション付けてくれ、と思うが、そういうところもない)

**デフォルトの名無しさん** · 2018/12/03(月) 21:54:09.89

2つ目の記事ではサーチのサジェストが例に挙げられている。
この場合、エレメントが選択的に削除されるので、確かにVirtualDOMの出番ではある。
jQueryでよくやるように、宣言的に記述する場合、
サーチサジェスト部分,innerHTML= となるが、生DOMでは全面書き換えとなる。
VirtualDOMなら同じ記述でも自動的に選択的に描画してくれる為、（一般的には）速くなる。
なお、やれば分かるが、この場合の選択的描画を自前でやると結構ウザイコードになる。
自動でやってくれるのならその方が断然楽だ。

とはいえ、俺はVirtualDOMは流行らないと思う。理由は、
・そもそも遅延/選択的描画が効く構成の所が少ない
・遅延/選択的描画するにしても再描画区画は確定的であり、フレームワークを導入するまでもない
・APIが超絶イマイチ
仮想DOMなんてユーザーに意識させてる時点でアウト。
あれはcssプロパティ draw:lazy ならブラウザが自動的に対処してくれる、程度でなきゃ駄目なのさ。
実験としては面白いと思うし、今のJavaScriptで動かすなら今の実装で致し方ないが。

しかしまあそれを言ったら、jQueryが流行った理由は
・時代がそれを必要としていた
・馬鹿には丁度いい頃合いだった
であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
発狂するくらいならフレームワークとか見た方がいいと思うぜ。
使う必要はないが、何故そんなフレームワークが出てきたのか、には意味があるから。

**デフォルトの名無しさん** · 2018/12/04(火) 00:09:05.94

> であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。

そんなデータどこにもないですよね？

**デフォルトの名無しさん** · 2018/12/04(火) 00:10:53.45

>>611
> jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
> やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。

なんで遅延描画をしなければならないって
危機的状況に陥ってるの？w

まずそんなものは不要ですって認めるところから始めようか

**デフォルトの名無しさん** · 2018/12/04(火) 01:15:34.56

君が現実に目を瞑るのは自由だが、
jQueryは本質的に「絶対に速度面では勝てないプラットフォーム」だから、
まともな奴なら確実に移行する。それがいつか、の問題でしかない。

ただ書いたとおり、遅延/選択的描画はブラウザにやらせるべき物で、
自前でやっても下手にやると余計に遅くなるのも事実。
React等はおそらく実験的プラットフォームで、そこから標準化しようという算段だろうが、これはまだかなり遠い。
とはいえ、遅延/選択的描画は正しく使えばぶっちぎりで速くなるから、
ブラウザが勝手にやってくれるのなら使わない奴は居ないと思う。
勿論その時はjQueryを使っていても恩恵があるし、仮想DOMを使っている自覚も無いはずだが。
結果、仮想DOM自体がjQueryキラーになることはない。この辺が>>604の指摘だよ。

宣言スタイルで記述すると、選択的描画は出来ず、基本的に「ここから下は全部再構築」になる。当然遅い。
仮想DOMはこのときにも速度が低下しない、って話さ。
ただしこれは「生JSで遅延/選択的描画を自前で実装した場合」比だから、
jQueryを使った場合は(当然全構築するから)ぶっちぎりで遅い。
つまり、React等は最初からjQueryなんて比較相手にしてない。

勿論jQueyで遅延/選択的描画を自前で実装することも出来るけど、そんな奴は普通居ない。
この場合は自前で描画関連の全DOMへの参照を保持しており、queryの必要がないから。
そして内部状態管理バリバリのステートフルなコードになり、
jQueryを使わないと何も出来ないような奴らではどうにもならない。
実際、君は2つ目の例(サーチサジェスト）とか、全DOM再構築コードを書くだろ。

jQueryの利点はデタラメなHTMLでもなんとでもなることだが、これ自体が減りつつある。
というか、デタラメなHTMLになるのは手で先にHTMLを書くからで、
DBからHTMLを生成する場合、デタラメなHTMLを生成する方が面倒だから。
つまり、鯖がhtmlを直接配信しているのならjQueryがフィットするが、
鯖でPHP等でhtmlを生成するのなら、本来はjQueryなんて要らないhtmlを普通に吐ける。
(実際そうかは別として)
いずれにしても、jQueryロック状態はあまりよろしくはないと思うぜ。それもまた自由だが。

**デフォルトの名無しさん** · 2018/12/04(火) 04:16:52.76

いちいち長すぎだろ…要点まとめるぐらいできないのか

**デフォルトの名無しさん** · 2018/12/04(火) 06:15:12.11

>>616
お前うざいよ

**デフォルトの名無しさん** · 2018/12/04(火) 06:51:59.52

ブラウザにやらせるべきって言ってもブラウザ側にも限界があるし
PauseFrameとかその時その時のベストプラクティスを徹底するのも難しい
その辺りをケアしてくれるのがフレームワークのメリットなのだから

**デフォルトの名無しさん** · 2018/12/04(火) 08:59:31.22

>>619
現状のフレームワーク等はいい実験をしているとは思う。
ただ、描画に関してはブラウザの方が主管なので、本来は丸投げ出来るべきだ。
現行のAPIを組み合わせてもこれは無理だから現状は致し方ないとしても。

> PauseFrame
使いどころは、
A. ajaxで将来的に書き換えると分かっているframeを停止する
B. 画面外のframeを停止する
として、AはJS側でいいが、Bはブラウザが勝手にやるべきだ。

根本的な問題は、CSSが全く拡張不能なこと。CSSで
・pause: auto ならオフスクリーンの場合はpause『してもよい』
という拡張が出来れば、これが一番自然だ。仮想DOMについては、
・draw: lazy でオフスクリーンなら描画『しなくてもいい』
となる。ここら辺まで出来れば、
フレームワーク導入コストはほぼ０となり、もっと面白くなるのだけどね。