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です）
+ JavaScript の質問用スレッド vol.126 +
■ このスレッドは過去ログ倉庫に格納されています
2018/06/02(土) 14:31:23.04ID:B1JKBGEy
538デフォルトの名無しさん
2018/11/14(水) 01:57:17.84ID:Da4Ohzbn 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要素を使っている）
と機能を提供している対象が違っており、それぞれお互いを補完する形になっている。
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要素を使っている）
と機能を提供している対象が違っており、それぞれお互いを補完する形になっている。
539デフォルトの名無しさん
2018/11/14(水) 01:58:06.99ID:Da4Ohzbn540デフォルトの名無しさん
2018/11/14(水) 02:00:25.32ID:sJwxMrq1 なんでDOM APIとの互換性を考慮する必要があるの？ｗｗ
jQueryで全部できるんじゃないんですくぁ〜？ｗｗｗｗｗ
jQueryで全部できるんじゃないんですくぁ〜？ｗｗｗｗｗ
541デフォルトの名無しさん
2018/11/14(水) 02:08:33.10ID:Da4Ohzbn >>540
> なんでDOM APIとの互換性を考慮する必要があるの？ｗｗ
> jQueryで全部できるんじゃないんですくぁ〜？ｗｗｗｗｗ
だから、アンチjQueryが、jQueryを使っているならば
全部jQueryの世界で閉じてるはずだ！
jQueryで全部できるんじゃないですか〜って
思ってるのがそもそも間違いってことだよｗ
jQueryを使ったプログラミングでは日常的に標準のDOM要素を使っている。
実際にonのイベントハンドラ内のthisとかDOM要素なんだから。
jQueryは設計の時点で、標準のDOM要素を使うことを想定してある
それを知らないで、コードを上っ面だけ眺めて、全部jQueryでやってるように見える。
これ全部jQueryの世界だ。DOM APIの世界と全く違う！独自の世界だ！！
なんて言ってるから、呆れるわけでｗ
> なんでDOM APIとの互換性を考慮する必要があるの？ｗｗ
> jQueryで全部できるんじゃないんですくぁ〜？ｗｗｗｗｗ
だから、アンチjQueryが、jQueryを使っているならば
全部jQueryの世界で閉じてるはずだ！
jQueryで全部できるんじゃないですか〜って
思ってるのがそもそも間違いってことだよｗ
jQueryを使ったプログラミングでは日常的に標準のDOM要素を使っている。
実際にonのイベントハンドラ内のthisとかDOM要素なんだから。
jQueryは設計の時点で、標準のDOM要素を使うことを想定してある
それを知らないで、コードを上っ面だけ眺めて、全部jQueryでやってるように見える。
これ全部jQueryの世界だ。DOM APIの世界と全く違う！独自の世界だ！！
なんて言ってるから、呆れるわけでｗ
542デフォルトの名無しさん
2018/11/14(水) 02:23:13.08ID:Da4Ohzbn そうだ。良いことを思いついた。
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() {・・・} )
標準さんには、やっぱりこうか？ｗ
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() {・・・} )
標準さんには、やっぱりこうか？ｗ
543デフォルトの名無しさん
2018/11/14(水) 06:45:30.47ID:tTVxQWlP NodeListには全くタイプの異なる要素が含まれる可能性がある
それこそTextNodeとかも入りうるのにイベントやスタイルを一括処理するメソッドが入るのは不自然だろう
fiilterとか全部入れないといけなくなるし
そこはAPI提供先の言語の機能を借りた方が良いだろう
DOMってJSだけのものではないからね
それこそTextNodeとかも入りうるのにイベントやスタイルを一括処理するメソッドが入るのは不自然だろう
fiilterとか全部入れないといけなくなるし
そこはAPI提供先の言語の機能を借りた方が良いだろう
DOMってJSだけのものではないからね
544デフォルトの名無しさん
2018/11/14(水) 08:37:27.50ID:Da4Ohzbn >>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とその文字列長を出力する。
> 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とその文字列長を出力する。
545>>544の続き
2018/11/14(水) 08:38:50.65ID:Da4Ohzbn 上でjQueryには配列で管理していると書いたが、
上のコードにもあるように、eachメソッドでループしてそれぞれの
要素に対してメソッドを実行している。
jQuery関数の引数にセレクタを渡すとDOM要素の配列として内部で持ってるわけ
そしてそれぞれの要素に対してメソッド（ 今回はtoString() ）を実行しているだけなんだ。
ということは、つまり、このプラグインは、以下のような使い方もできる。
$(["red", "blue", "green"]).len();
jQueryオブジェクトでラップして使うための要件を要約すると
1. jQuery関数に渡したものは、配列に出来さえすればいい（すべてできる）
2. 配列をeachでループできればいい（配列なのでループできる）
3. オブジェクトに使用するメソッドが生えてさえすればいい
たったこれだけなんだ。DOM要素でなければいけないなんて要件はない。
配列化された個々のオブジェクトに使用するメソッドがあればいいだけなんだよ
（もちろんメソッドの有無を判定して、なければスキップすることもできる）
つまりな、全く異なるオブジェクトが入ろうが、ループで回してオブジェクトに
メソッドが生えていればそれを呼び出すだけなんだから、
まったく異なるタイプのオブジェクトだって対応できるんだよ
上のコードにもあるように、eachメソッドでループしてそれぞれの
要素に対してメソッドを実行している。
jQuery関数の引数にセレクタを渡すとDOM要素の配列として内部で持ってるわけ
そしてそれぞれの要素に対してメソッド（ 今回はtoString() ）を実行しているだけなんだ。
ということは、つまり、このプラグインは、以下のような使い方もできる。
$(["red", "blue", "green"]).len();
jQueryオブジェクトでラップして使うための要件を要約すると
1. jQuery関数に渡したものは、配列に出来さえすればいい（すべてできる）
2. 配列をeachでループできればいい（配列なのでループできる）
3. オブジェクトに使用するメソッドが生えてさえすればいい
たったこれだけなんだ。DOM要素でなければいけないなんて要件はない。
配列化された個々のオブジェクトに使用するメソッドがあればいいだけなんだよ
（もちろんメソッドの有無を判定して、なければスキップすることもできる）
つまりな、全く異なるオブジェクトが入ろうが、ループで回してオブジェクトに
メソッドが生えていればそれを呼び出すだけなんだから、
まったく異なるタイプのオブジェクトだって対応できるんだよ
546デフォルトの名無しさん
2018/11/14(水) 08:45:00.29ID:Da4Ohzbn これは、ダックタイピングの考え方そのものだよね
型は関係ない。使用するメソッドさえあればいい。
jQueryはDOMを扱うライブラリだから、
DOM要素でなければ引数に出来ないと思い込みがちなのはわかる。
だけど、jQueryで提供しているメソッドこそ、DOM操作用のメソッドってだけで
単一の要素を配列として操作するという設計は、DOM専用のものではなく
DOM以外にも適用可能なわけだ。
まさにこのような使い方ができる通り
$(["red", "blue", "green"]).len();
貼り忘れていた。実際に動くサンプル
https://jsfiddle.net/vxpk0yef/
型は関係ない。使用するメソッドさえあればいい。
jQueryはDOMを扱うライブラリだから、
DOM要素でなければ引数に出来ないと思い込みがちなのはわかる。
だけど、jQueryで提供しているメソッドこそ、DOM操作用のメソッドってだけで
単一の要素を配列として操作するという設計は、DOM専用のものではなく
DOM以外にも適用可能なわけだ。
まさにこのような使い方ができる通り
$(["red", "blue", "green"]).len();
貼り忘れていた。実際に動くサンプル
https://jsfiddle.net/vxpk0yef/
547デフォルトの名無しさん
2018/11/14(水) 08:54:39.25ID:Da4Ohzbn まあ、よくよく考えてみると、
> NodeListには全くタイプの異なる要素が含まれる可能性がある
$('.foo')と書いたって、全くタイプの異なる要素が含まれる可能性があるわけで。
例えば、$('.foo').prop('checked')と書いても、checkedプロパティが
存在しない要素の可能性もあるわけで、最初から対応済み。
（プロパティがなければスキップされる）今更なんだよねｗ
> NodeListには全くタイプの異なる要素が含まれる可能性がある
$('.foo')と書いたって、全くタイプの異なる要素が含まれる可能性があるわけで。
例えば、$('.foo').prop('checked')と書いても、checkedプロパティが
存在しない要素の可能性もあるわけで、最初から対応済み。
（プロパティがなければスキップされる）今更なんだよねｗ
548デフォルトの名無しさん
2018/11/14(水) 12:49:14.50ID:6FVvsHpP >>540
そういう大言はせめて、addEventListenerの第三引数が実装されてから、いえ
そういう大言はせめて、addEventListenerの第三引数が実装されてから、いえ
549デフォルトの名無しさん
2018/11/14(水) 12:58:16.26ID:6FVvsHpP >>543
俺はjQuery擁護派でも何でもないので、純粋に知的好奇心から尋ねるが、NodeListにテキストノードが入る再現コードは何だろう？
確かに、仕様上は要素ノードに限定されてはいないのだが、再現コードが分からんhttps://triple-underscore.github.io/DOM4-ja.html#interface-nodelist
俺はjQuery擁護派でも何でもないので、純粋に知的好奇心から尋ねるが、NodeListにテキストノードが入る再現コードは何だろう？
確かに、仕様上は要素ノードに限定されてはいないのだが、再現コードが分からんhttps://triple-underscore.github.io/DOM4-ja.html#interface-nodelist
550デフォルトの名無しさん
2018/11/14(水) 13:00:03.13ID:Da4Ohzbn >>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のベータ版を出すという話があったけど
遅れてるんだろうね
それは互換性上の問題だから仕方ないね。
昔の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のベータ版を出すという話があったけど
遅れてるんだろうね
551デフォルトの名無しさん
2018/11/14(水) 13:24:10.18ID:Da4Ohzbn >>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()メソッドの存在 ）ってことが示せたと思う
わかってると思うが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()メソッドの存在 ）ってことが示せたと思う
552デフォルトの名無しさん
2018/11/14(水) 13:31:51.54ID:Da4Ohzbn ああそうか、NodeListを返すなら、queryselectorAll限定である必要はないな。
jQueryのcontents()メソッドに対応するDOM APIってことで調べたら、
childNodesがテキストノードも含まれるNodeListを返したよ
https://developer.mozilla.org/ja/docs/Web/API/Node/childNodes
jQueryのcontents()メソッドに対応するDOM APIってことで調べたら、
childNodesがテキストノードも含まれるNodeListを返したよ
https://developer.mozilla.org/ja/docs/Web/API/Node/childNodes
553デフォルトの名無しさん
2018/11/14(水) 16:03:13.17ID:DuV4GknS ローカルの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側で許可されていない。普通は使う側がセキュリティを切る
その他
どれでしょう？
ググったら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側で許可されていない。普通は使う側がセキュリティを切る
その他
どれでしょう？
554デフォルトの名無しさん
2018/11/14(水) 16:25:09.78ID:CNd6PM4x555553
2018/11/14(水) 17:27:47.03ID:DuV4GknS >>554
レスありがとうございます
ニコ動のAPIのように公開されているものでも、CORSは許可していないということですか？
API公開≒CORS許可で、こちらに何か足りないと思ってました
保存したものなら大丈夫なので、保存だけ別の方法を探してみます
レスありがとうございます
ニコ動のAPIのように公開されているものでも、CORSは許可していないということですか？
API公開≒CORS許可で、こちらに何か足りないと思ってました
保存したものなら大丈夫なので、保存だけ別の方法を探してみます
556デフォルトの名無しさん
2018/11/14(水) 17:32:04.39ID:Da4Ohzbn ログインすりゃ使えるんじゃね？知らんけど
無制限に許可なんかしたら負荷かけられまくるんだから
誰がAPIを叩いたか知るためにもログイン必須はおかしくないでしょ？
無制限に許可なんかしたら負荷かけられまくるんだから
誰がAPIを叩いたか知るためにもログイン必須はおかしくないでしょ？
557デフォルトの名無しさん
2018/11/14(水) 17:47:55.65ID:1irFmXR9 基本的に外部サイトへのリクエストはセキュリティ上の理由で禁止されてるんだけど、それを許可するのがCORS
これは外部サイト（ここではAPI）側でしか設定できないから、迂回するにはCORSヘッダを付加するプロキシサーバーみたいなのを建てるしかない
GET限定で良ければ誰かが建てたそういうサーバーがある（CORS Anywhereとかcrossorigin.meとか）けど、利用する場合は自己責任で
（レスポンスが改ざんされたり、動いてなかったりするかもしれない）
これは外部サイト（ここではAPI）側でしか設定できないから、迂回するにはCORSヘッダを付加するプロキシサーバーみたいなのを建てるしかない
GET限定で良ければ誰かが建てたそういうサーバーがある（CORS Anywhereとかcrossorigin.meとか）けど、利用する場合は自己責任で
（レスポンスが改ざんされたり、動いてなかったりするかもしれない）
558デフォルトの名無しさん
2018/11/14(水) 19:32:52.05ID:XHaWO18a559デフォルトの名無しさん
2018/11/14(水) 20:52:38.60ID:tTVxQWlP >>544
問題あるかないかの話はしてないよ
そりゃ問題ないように作るということは幾らでもできるから
でもNodeListというクラスのメソッドとしては性質上「不自然」だって言ってるの
適当にコーディングするためのjQueryでは許されても標準では許されないよ
問題あるかないかの話はしてないよ
そりゃ問題ないように作るということは幾らでもできるから
でもNodeListというクラスのメソッドとしては性質上「不自然」だって言ってるの
適当にコーディングするためのjQueryでは許されても標準では許されないよ
560デフォルトの名無しさん
2018/11/14(水) 21:58:20.23ID:rJwbd1Hm jQueryが受けているのは「初心者にとって丁度いいから」というのもある。
PHPがそうだが、上級者から見ると「なんでこうした？」というのが多いが、
初心者にとってはそれくらいベタの方が使いやすい。
だからPHPも初心者受けは良い。同様に、jQueryも初心者受けは良い。ベタだからだ。
(フレームワークは初心者にとっては何をどう使えばいいかさっぱり分からない。
これがjQueryにはない、ということ。）
ただ、jQueryは低レベルすぎて、短く書けるだけで、やること/管理することが減るわけではないから、
上級者にとっては導入のメリットがない。
むしろ、依存関係が増え、記述が冗長になる（複数の書き方が混在する）という意味で悪だ。
だから、腕前を上げるに従い脱jQueryを目指すのも自然なことで、「自転車の補助輪だ」というのも当たってる。
タイピング量なんて全くどうでもいいし。
ただこれらは「上級者」に近くなってこないと理解出来ないし、
当然デザイナと話をしてても水掛け論にしかならず、話は堂々巡りだ。
ある意味、デザイナがプログラミングまで出張ってきているJavaScriptの世界が特殊なのだろう。
アプリを組めるレベルになってくるとjQueryの問題点は自明として、
それ以下だと認識出来ないから、意外にずっと使われるのかもね。ある意味PHPもそうだし。
あれは、「サイトの数」で比較するからjQueryのシェアが高く見えるんだろうな。
実際の「Web閲覧時間」での比較が出来れば一番良いのだけど、これは直接的には無理だから、
現実的には「サイト数をPVで加重平均」したものが妥当かな？
これだと実際に見られているシェアとなり、感覚的にも一致するはずだし。
>>544
> jQueryは素晴らしくてなぁ「全くタイプの異なる要素が含まれる可能性」があっても問題ないんだよ
それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。
ま、NodeListについては、DOM自体がいまいちOOPに乗り切れてないことの問題ではあるが。
PHPがそうだが、上級者から見ると「なんでこうした？」というのが多いが、
初心者にとってはそれくらいベタの方が使いやすい。
だからPHPも初心者受けは良い。同様に、jQueryも初心者受けは良い。ベタだからだ。
(フレームワークは初心者にとっては何をどう使えばいいかさっぱり分からない。
これがjQueryにはない、ということ。）
ただ、jQueryは低レベルすぎて、短く書けるだけで、やること/管理することが減るわけではないから、
上級者にとっては導入のメリットがない。
むしろ、依存関係が増え、記述が冗長になる（複数の書き方が混在する）という意味で悪だ。
だから、腕前を上げるに従い脱jQueryを目指すのも自然なことで、「自転車の補助輪だ」というのも当たってる。
タイピング量なんて全くどうでもいいし。
ただこれらは「上級者」に近くなってこないと理解出来ないし、
当然デザイナと話をしてても水掛け論にしかならず、話は堂々巡りだ。
ある意味、デザイナがプログラミングまで出張ってきているJavaScriptの世界が特殊なのだろう。
アプリを組めるレベルになってくるとjQueryの問題点は自明として、
それ以下だと認識出来ないから、意外にずっと使われるのかもね。ある意味PHPもそうだし。
あれは、「サイトの数」で比較するからjQueryのシェアが高く見えるんだろうな。
実際の「Web閲覧時間」での比較が出来れば一番良いのだけど、これは直接的には無理だから、
現実的には「サイト数をPVで加重平均」したものが妥当かな？
これだと実際に見られているシェアとなり、感覚的にも一致するはずだし。
>>544
> jQueryは素晴らしくてなぁ「全くタイプの異なる要素が含まれる可能性」があっても問題ないんだよ
それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。
ま、NodeListについては、DOM自体がいまいちOOPに乗り切れてないことの問題ではあるが。
561デフォルトの名無しさん
2018/11/14(水) 22:50:55.26ID:Da4Ohzbn > それがアウトだとGitHubは判断してるわけでさ。まあ、通じないとは思うが、気になるなら読み直してみ。
また、それがどこか答えない。
同じことの繰り返しだな。
通じない？当たり前だ
お前が何も言ってないんだから
また、それがどこか答えない。
同じことの繰り返しだな。
通じない？当たり前だ
お前が何も言ってないんだから
562デフォルトの名無しさん
2018/11/14(水) 23:02:21.85ID:rJwbd1Hm563デフォルトの名無しさん
2018/11/14(水) 23:08:02.36ID:Da4Ohzbn > いやモロに書いてるがな。
いつもどおり。リンクを示せば良いものを
書いていると書くだけでおしまい。
やり口がかわらんなぁｗ
いつもどおり。リンクを示せば良いものを
書いていると書くだけでおしまい。
やり口がかわらんなぁｗ
564デフォルトの名無しさん
2018/11/14(水) 23:09:10.35ID:Da4Ohzbn 訂正
× リンクを示せば良いものを
○ 引用するなどして、具体的な箇所を示せば良いものを
× リンクを示せば良いものを
○ 引用するなどして、具体的な箇所を示せば良いものを
565デフォルトの名無しさん
2018/11/14(水) 23:16:47.50ID:rJwbd1Hm >>563
お前もいつも通り連呼リアンだよな。
普通は562は「リンクを示した」と言うぜ。
お前、煽り抜きで頭おかしいと思うぜ。マジで池沼。
同様の奴が他に2人いると書いたが、お前が一番程度が酷い。
さすがにそれだとリアルの普通の会話も成立しないだろ。
お前もいつも通り連呼リアンだよな。
普通は562は「リンクを示した」と言うぜ。
お前、煽り抜きで頭おかしいと思うぜ。マジで池沼。
同様の奴が他に2人いると書いたが、お前が一番程度が酷い。
さすがにそれだとリアルの普通の会話も成立しないだろ。
566デフォルトの名無しさん
2018/11/14(水) 23:22:14.41ID:rJwbd1Hm >>564
英語読めるつもりなんだろ？自分で読めよ。
というか、あれ、脱jQueryが気になる奴は、読む価値はあると思うぜ。
お前は読んでも全部読むうちに忘れちゃうんだろうけどさ。
それでもお前の頭は交換不可能で、お前自身で鍛えるしかないんだから、
無い頭使って一生懸命読めよ。
それを繰り返してたら、お前のその頭も少しはましになるよ。
英語読めるつもりなんだろ？自分で読めよ。
というか、あれ、脱jQueryが気になる奴は、読む価値はあると思うぜ。
お前は読んでも全部読むうちに忘れちゃうんだろうけどさ。
それでもお前の頭は交換不可能で、お前自身で鍛えるしかないんだから、
無い頭使って一生懸命読めよ。
それを繰り返してたら、お前のその頭も少しはましになるよ。
567デフォルトの名無しさん
2018/11/14(水) 23:27:59.81ID:rJwbd1Hm なお、GitHubの公式声明の内容は割と普通のことなので、
普通に脱jQueryを実行出来る人は特に読む意味はありません。
何故脱jQueryなのか？に疑問を持つ人は、読む価値があると思います。
普通に脱jQueryを実行出来る人は特に読む意味はありません。
何故脱jQueryなのか？に疑問を持つ人は、読む価値があると思います。
568デフォルトの名無しさん
2018/11/14(水) 23:32:34.35ID:Da4Ohzbn だから、GitHubの声明には本来書いてあるはずのjQueryをなくして
その結果、何が得られたかが「書いてない」ってのが、注目する点なんだってばｗ
その結果、何が得られたかが「書いてない」ってのが、注目する点なんだってばｗ
569デフォルトの名無しさん
2018/11/14(水) 23:49:27.00ID:rJwbd1Hm570デフォルトの名無しさん
2018/11/15(木) 00:17:06.64ID:gWaB1LhD はい、想定通りのレスきました
571デフォルトの名無しさん
2018/11/15(木) 00:22:47.33ID:labK41wt572デフォルトの名無しさん
2018/11/15(木) 00:29:18.03ID:labK41wt573デフォルトの名無しさん
2018/11/15(木) 00:47:30.01ID:O4sg2hqu いつものインタビュー貼っておきますね
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
574デフォルトの名無しさん
2018/11/15(木) 00:58:36.39ID:g74yzjtM >>553-557
自分のPC にサーバーを立てて、サーバー経由でアクセスしないと、
ブラウザからでは、CORS でアクセスできない
例えば、自分のPC 内のHTML ファイルを、ブラウザで起動して、
そのページから、5ch へアクセスできない。
iframe 内に読み込んでも、iframe 内外が、別ドメインだからアクセスできない
ruby -run -e httpd . -p 8080
1-liner で、Web サーバーを起動して、そのindex.html からは、別ドメインにもアクセスできる
自分のPC にサーバーを立てて、サーバー経由でアクセスしないと、
ブラウザからでは、CORS でアクセスできない
例えば、自分のPC 内のHTML ファイルを、ブラウザで起動して、
そのページから、5ch へアクセスできない。
iframe 内に読み込んでも、iframe 内外が、別ドメインだからアクセスできない
ruby -run -e httpd . -p 8080
1-liner で、Web サーバーを起動して、そのindex.html からは、別ドメインにもアクセスできる
575デフォルトの名無しさん
2018/11/15(木) 01:02:00.51ID:gWaB1LhD576デフォルトの名無しさん
2018/11/15(木) 01:03:57.60ID:gWaB1LhD >>574
オリジンが違うんだから出来ねーよ
オリジンが違うんだから出来ねーよ
577デフォルトの名無しさん
2018/11/15(木) 15:35:01.66ID:kH0mg7oG オリジンが違ってもアクセスはできるだろ
取得した中身が読み取れないだけ
取得した中身が読み取れないだけ
578デフォルトの名無しさん
2018/11/15(木) 17:42:32.99ID:bhNItiA3 アクセス拒否されるし取得できない。
何いってんだコイツ
何いってんだコイツ
579デフォルトの名無しさん
2018/11/15(木) 20:16:01.66ID:gy9NL/ik 何いってんだコイツはお前だアホ
await fetch('https://developer.mozilla.org/',{mode:'no-cors'})
アクセスしてるだろうが
もし拒否されるのならServiceWorker導入ページでどうやって
外部リソースをリクエストしたりキャッシュしたりするつもりなんだ？
人様にケチ付ける前に自分が無知であることを知れよ
await fetch('https://developer.mozilla.org/',{mode:'no-cors'})
アクセスしてるだろうが
もし拒否されるのならServiceWorker導入ページでどうやって
外部リソースをリクエストしたりキャッシュしたりするつもりなんだ？
人様にケチ付ける前に自分が無知であることを知れよ
580デフォルトの名無しさん
2018/11/15(木) 21:17:25.79ID:lEvW1moB 元々の文脈考えたらアクセスできない、で良くね？
オリジン違えば非同期通信でAPIのレスポンスは取ってこれない
jsonp対応してれば行けるだろうがそれはまた別の話だ
オリジン違えば非同期通信でAPIのレスポンスは取ってこれない
jsonp対応してれば行けるだろうがそれはまた別の話だ
581デフォルトの名無しさん
2018/11/16(金) 01:36:26.11ID:RoXRfHM0582デフォルトの名無しさん
2018/11/16(金) 03:07:01.97ID:J23WDvJz > 人様にケチ付ける前に自分が無知であることを知れよ
で自分を人様って言ってるのも色々アレ
で自分を人様って言ってるのも色々アレ
583デフォルトの名無しさん
2018/11/16(金) 03:15:01.26ID:RoXRfHM0 まあそれは煽りでよく見る
584デフォルトの名無しさん
2018/11/16(金) 05:29:59.60ID:Fm6aQCaV585デフォルトの名無しさん
2018/11/18(日) 22:16:13.60ID:0UFE24fl JAVAscriptと書くのは普通ですか？
ネットで見たのですが
ネットで見たのですが
586デフォルトの名無しさん
2018/11/18(日) 23:02:17.55ID:nb8ry1fv 好きに書けばいいんです
587デフォルトの名無しさん
2018/11/19(月) 08:23:17.32ID:xSgeYMFO JaVa$cRiPt
588デフォルトの名無しさん
2018/11/29(木) 23:02:47.57ID:vNMQ8ba8 勉強にのためにライブラリのjplayerを解読しようとしてるが
難しすぎる。
おまえら、javascript勉強してるってこは
ライブリとかもすらすら読んでわかるの？
難しすぎる。
おまえら、javascript勉強してるってこは
ライブリとかもすらすら読んでわかるの？
589デフォルトの名無しさん
2018/11/29(木) 23:33:09.60ID:fezToc6/ >>588
前提でJQueryとかの知識がいるからじゃない？
こういうやつとか初心者が試行錯誤でやったやつの方がわけわからん
https://qiita.com/ryuichi1208/items/f9e6ac2b99bbe4fc82d3
前提でJQueryとかの知識がいるからじゃない？
こういうやつとか初心者が試行錯誤でやったやつの方がわけわからん
https://qiita.com/ryuichi1208/items/f9e6ac2b99bbe4fc82d3
590デフォルトの名無しさん
2018/11/29(木) 23:41:56.52ID:lCOis1qI jQuery使わなかったらもっと難解になるんだよな
591デフォルトの名無しさん
2018/11/30(金) 00:00:53.52ID:2ubbGZPs >>588
覚えればすむものは楽なんだよ。
単に覚えればいいだけ理解すればそれで終わりなんだから。
大変なのは>>589みたいなもの。ありえないほど短いコードで
実現しているから凄いといわれるけど一般的にはクソコードと言われる類。
なぜかというと、コードというのは簡単に読めるものじゃないといけない
もちろん知識をつけたもの、能力がある人にとってね。
知識があって能力がある人でも読むのに時間がかかるような
無駄な処理ばかりで何をやってるか分からないようなものは大変
それが「解読」という作業。これはコードに問題がある。
知識がなくてわからないのは解読じゃなくて単に読めないだけ
読んでる人に問題がある
覚えればすむものは楽なんだよ。
単に覚えればいいだけ理解すればそれで終わりなんだから。
大変なのは>>589みたいなもの。ありえないほど短いコードで
実現しているから凄いといわれるけど一般的にはクソコードと言われる類。
なぜかというと、コードというのは簡単に読めるものじゃないといけない
もちろん知識をつけたもの、能力がある人にとってね。
知識があって能力がある人でも読むのに時間がかかるような
無駄な処理ばかりで何をやってるか分からないようなものは大変
それが「解読」という作業。これはコードに問題がある。
知識がなくてわからないのは解読じゃなくて単に読めないだけ
読んでる人に問題がある
592デフォルトの名無しさん
2018/11/30(金) 08:44:57.62ID:VjmtC3o0 7行テトリスは、まるで暗号
jQuery のCSS セレクターを学べば？
基本的には、# . > など、Emmet と同じ
Ruby のNokogiri でもよい
jQuery のCSS セレクターを学べば？
基本的には、# . > など、Emmet と同じ
Ruby のNokogiri でもよい
593デフォルトの名無しさん
2018/12/02(日) 13:56:14.24ID:LBfjyA1g やっぱ、オレの勉強不足だな。
もっとjavascript勉強しよ。
日経ソフトウェア読んでると、javascriptに
Reactという仮想DOMとか出てきてるし
どんどん新しい技術出てきてる
もっとjavascript勉強しよ。
日経ソフトウェア読んでると、javascriptに
Reactという仮想DOMとか出てきてるし
どんどん新しい技術出てきてる
594デフォルトの名無しさん
2018/12/02(日) 16:53:20.50ID:2mHq7Ydm 仮想DOMは、なんでDOMを全部再構築するというアイデアが
出発点になってるのかわからない。
jQueryがやってるように普通に必要なところだけDOMを更新すればいいだろう
出発点になってるのかわからない。
jQueryがやってるように普通に必要なところだけDOMを更新すればいいだろう
595デフォルトの名無しさん
2018/12/02(日) 16:55:13.96ID:d6QByty/ なるだけ参照透明にしたいからじゃない？
596デフォルトの名無しさん
2018/12/02(日) 17:19:20.90ID:3j0ioh6B 部分更新も、複数回のDOM操作がinnerHTML差し替え1回で済ませられたらメリットはあるんじゃね。
597デフォルトの名無しさん
2018/12/02(日) 17:22:34.32ID:Bx+z5yQP598デフォルトの名無しさん
2018/12/02(日) 17:53:11.92ID:9iYB1akb 複雑になってくると毎回全部再構築した方が楽だと思うけど
昔はDOMが遅くて実現が難しいとかじゃなかったっけ
昔はDOMが遅くて実現が難しいとかじゃなかったっけ
599デフォルトの名無しさん
2018/12/02(日) 17:59:05.26ID:Bx+z5yQP >>598
jQuery死ね
jQuery死ね
600デフォルトの名無しさん
2018/12/02(日) 20:39:03.60ID:uIlAasYL 推薦書
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
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
601デフォルトの名無しさん
2018/12/02(日) 20:50:24.13ID:qYaSLKlW VueはVue.js入門が出たから猫の方はいらんよ
602デフォルトの名無しさん
2018/12/03(月) 08:37:17.60ID:qqs2cxrp >>598
> 複雑になってくると毎回全部再構築した方が楽だと思うけど
> 昔はDOMが遅くて実現が難しいとかじゃなかったっけ
つまりマッチポンプってこと？
1. jQueryなどを使って必要な部分だけ構築する・・・一番速い
2. （アホな）アイデア思いついた！全部再構築したほうがいいんじゃね？・・・遅い
3. VirtualDOM使えば（jQueryほど速くないけど）全部再構築しても遅くならない！
VirtualDOMって遅くならないだけなんだよね
決してjQueryよりは速くはならない
> 複雑になってくると毎回全部再構築した方が楽だと思うけど
> 昔はDOMが遅くて実現が難しいとかじゃなかったっけ
つまりマッチポンプってこと？
1. jQueryなどを使って必要な部分だけ構築する・・・一番速い
2. （アホな）アイデア思いついた！全部再構築したほうがいいんじゃね？・・・遅い
3. VirtualDOM使えば（jQueryほど速くないけど）全部再構築しても遅くならない！
VirtualDOMって遅くならないだけなんだよね
決してjQueryよりは速くはならない
603デフォルトの名無しさん
2018/12/03(月) 08:40:10.65ID:qqs2cxrp >>594
そもそも遅延描画する必要がないですよね
仮想DOM使っても結局変更部分はDOM操作をするんだから
仮想DOMを使わずに、変更部分をDOM操作すればもっと速いですよね
なんで仮想DOMは速いって嘘をつくんだろう？
遅くならないって言えばいいのに
そもそも遅延描画する必要がないですよね
仮想DOM使っても結局変更部分はDOM操作をするんだから
仮想DOMを使わずに、変更部分をDOM操作すればもっと速いですよね
なんで仮想DOMは速いって嘘をつくんだろう？
遅くならないって言えばいいのに
604デフォルトの名無しさん
2018/12/03(月) 08:55:08.53ID:oKREYEfs そもそも、仮想DOMの方が常にjQueryより速いと主張する奴がいるという思い込みじゃね？
605デフォルトの名無しさん
2018/12/03(月) 09:07:38.44ID:qqs2cxrp 例えば>>597にも書いてますね。
> VirtualDOMの仕事ってなに？(Reactの表示速度がはやい理由)
「Reactの表示速度が遅くならない理由」と書けばいいのに
もともとDOM全部再構築なんて遅くなるような馬鹿げたことはやってないんですよ
逆にどうやってjQueryでDOM全部再構築をやれと？
めんどくさくてやってられないし遅いのでやらない
遅くなるDOM全再構築なんて馬鹿げたことをやって
遅いだろう？でもこれだと遅くないんだぜってっていうのが
マッチポンプなんですよ
> VirtualDOMの仕事ってなに？(Reactの表示速度がはやい理由)
「Reactの表示速度が遅くならない理由」と書けばいいのに
もともとDOM全部再構築なんて遅くなるような馬鹿げたことはやってないんですよ
逆にどうやってjQueryでDOM全部再構築をやれと？
めんどくさくてやってられないし遅いのでやらない
遅くなるDOM全再構築なんて馬鹿げたことをやって
遅いだろう？でもこれだと遅くないんだぜってっていうのが
マッチポンプなんですよ
606デフォルトの名無しさん
2018/12/03(月) 09:08:21.84ID:+OGeTNm4 まぁ藁人形論法だね。
その他によく知らない初心者が勘違いしたまま質の悪いウソ情報をネットに垂れ流してるというのもある。
その他によく知らない初心者が勘違いしたまま質の悪いウソ情報をネットに垂れ流してるというのもある。
607デフォルトの名無しさん
2018/12/03(月) 09:11:08.96ID:+OGeTNm4 >>597は典型的な勘違いして垂れ流してる初心者だなｗ
こんなのよりReact登場初期の、初心者が知ったかでイキってられない時期に書かれた記事読んだ方がいい。
こんなのよりReact登場初期の、初心者が知ったかでイキってられない時期に書かれた記事読んだ方がいい。
608デフォルトの名無しさん
2018/12/03(月) 09:19:09.58ID:qqs2cxrp 「今までは、基本的に受け取った情報を元にDOMを
一から作成してブラウザに描画することが多かった」
こんなことやってませんからね
サーバーを介さないクライアントだけで処理できるもの、
例えばボタンがクリックされた時に何かを行う処理は
必要最小限のDOMしか変更しないんので速い
「受け取った情報を元に」と書いてあるからAjax前提の話か
ページ遷移の時の話だろうけど、ページ全体を読み込むよりかは
一部分のほうが早いのは当然として、それはAjaxを使えばいい。
Ajaxを使って、必要最小限のところだけ書き換えるのが普通
DOMを一から作成してブラウザに描画とかしないから
一から作成してブラウザに描画することが多かった」
こんなことやってませんからね
サーバーを介さないクライアントだけで処理できるもの、
例えばボタンがクリックされた時に何かを行う処理は
必要最小限のDOMしか変更しないんので速い
「受け取った情報を元に」と書いてあるからAjax前提の話か
ページ遷移の時の話だろうけど、ページ全体を読み込むよりかは
一部分のほうが早いのは当然として、それはAjaxを使えばいい。
Ajaxを使って、必要最小限のところだけ書き換えるのが普通
DOMを一から作成してブラウザに描画とかしないから
609デフォルトの名無しさん
2018/12/03(月) 12:37:01.63ID:xsY8Ca3Y SPAだと自前でページ遷移作ることになるやろ
610デフォルトの名無しさん
2018/12/03(月) 15:23:56.50ID:y4vgdg4E SPAにページ遷移という概念が存在するとは限らない
SPAはアプリケーションなのだから
ただ単純に実際のページ遷移を伴わない技術はpjaxと言ったほうが良い
SPAはアプリケーションなのだから
ただ単純に実際のページ遷移を伴わない技術はpjaxと言ったほうが良い
611デフォルトの名無しさん
2018/12/03(月) 21:51:55.26ID:r8O+Z3hZ あれ？いつもの奴ではない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のアップデート共に改善されて最終的には限界まで端折ることになる。
この辺の、改善を外部のアップデートに期待出来ることも、フレームワーク等を導入するメリットでもあるだろ。
が、まあいい。
そもそも素人向けの解説は当然色々端折るので厳密にはそれなりに間違いを含む。
これは至極当然だ。それに対して発狂しても意味がない。
それらは、「このレベル向けの解説ならこの程度で妥当か？」で判定されるべきだ。
この点、俺は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のアップデート共に改善されて最終的には限界まで端折ることになる。
この辺の、改善を外部のアップデートに期待出来ることも、フレームワーク等を導入するメリットでもあるだろ。
612デフォルトの名無しさん
2018/12/03(月) 21:52:51.04ID:r8O+Z3hZ その記事内にもあるが、
> ウェブ開発者が文句をいう DOM の遅さは大半がレンダリング由来だったりする。
これは全くその通りで、レンダリングさえしなければDOMは遅くない。
(jQuery廚が居るから一応言っておくが、クエリもそれなりに遅い。
ただ、Reactとか使う人はクエリはほぼ全くしないはず。というかこの構成だと禁止かも？）
つまり、document.create等は十分速く（＝仮想DOM構築も速い）、レンダリングだけが遅いから、
どうにかしてレンダリングを止めさせよう（少なくしよう）というのが遅延描画だ。
それが必要かどうかは場合による。
描画しなくて済む範囲が多ければ、当然ぶっちぎりで速い。
jQueryは生JavaScriptよりも本質的に遅いから、遅延描画が効くようなら、
生JavaScriptで遅延描画>フレームワークで遅延描画>>>生JavaScriptで描画>jQueryで描画
となる。
ただし遅延描画の肝心要のoffsetTop等がこれまた致命的に遅いので、（レンダリングを要する為）
単純に遅延描画にすれば（体感的に）速くなる訳でもない。
jQueryを使ってて許されてるのなら、そのサイトはスピード狂ではないので、
遅延描画を要求されることもないのではないかな？
ただそもそも、遅延描画が効くサイト構成の所も少ないかも。
例えばアマゾン、商品一覧はいちいち「次のページ」を押して遷移するようになっている。
SPAでページ毎に商品表示部分を全面描画してる。
（ページ全体の全面描画ではなく、商品部分の全面描画。念のため）
ページ内商品点数は36なので、この程度では遅延描画はあまり効果がない。
（というか下手にやると余計に遅くなる。少なくともPC環境ではそう。モバイルだと違うかも）
俺はこういうのは無限スクロールでぐりぐりやってればいくらでも見える方が好きなのだけど、
そういうサイトは確かに少ない。
(とりあえず150点くらい表示出来るオプション付けてくれ、と思うが、そういうところもない)
> ウェブ開発者が文句をいう DOM の遅さは大半がレンダリング由来だったりする。
これは全くその通りで、レンダリングさえしなければDOMは遅くない。
(jQuery廚が居るから一応言っておくが、クエリもそれなりに遅い。
ただ、Reactとか使う人はクエリはほぼ全くしないはず。というかこの構成だと禁止かも？）
つまり、document.create等は十分速く（＝仮想DOM構築も速い）、レンダリングだけが遅いから、
どうにかしてレンダリングを止めさせよう（少なくしよう）というのが遅延描画だ。
それが必要かどうかは場合による。
描画しなくて済む範囲が多ければ、当然ぶっちぎりで速い。
jQueryは生JavaScriptよりも本質的に遅いから、遅延描画が効くようなら、
生JavaScriptで遅延描画>フレームワークで遅延描画>>>生JavaScriptで描画>jQueryで描画
となる。
ただし遅延描画の肝心要のoffsetTop等がこれまた致命的に遅いので、（レンダリングを要する為）
単純に遅延描画にすれば（体感的に）速くなる訳でもない。
jQueryを使ってて許されてるのなら、そのサイトはスピード狂ではないので、
遅延描画を要求されることもないのではないかな？
ただそもそも、遅延描画が効くサイト構成の所も少ないかも。
例えばアマゾン、商品一覧はいちいち「次のページ」を押して遷移するようになっている。
SPAでページ毎に商品表示部分を全面描画してる。
（ページ全体の全面描画ではなく、商品部分の全面描画。念のため）
ページ内商品点数は36なので、この程度では遅延描画はあまり効果がない。
（というか下手にやると余計に遅くなる。少なくともPC環境ではそう。モバイルだと違うかも）
俺はこういうのは無限スクロールでぐりぐりやってればいくらでも見える方が好きなのだけど、
そういうサイトは確かに少ない。
(とりあえず150点くらい表示出来るオプション付けてくれ、と思うが、そういうところもない)
613デフォルトの名無しさん
2018/12/03(月) 21:54:09.89ID:r8O+Z3hZ 2つ目の記事ではサーチのサジェストが例に挙げられている。
この場合、エレメントが選択的に削除されるので、確かにVirtualDOMの出番ではある。
jQueryでよくやるように、宣言的に記述する場合、
サーチサジェスト部分,innerHTML= となるが、生DOMでは全面書き換えとなる。
VirtualDOMなら同じ記述でも自動的に選択的に描画してくれる為、（一般的には）速くなる。
なお、やれば分かるが、この場合の選択的描画を自前でやると結構ウザイコードになる。
自動でやってくれるのならその方が断然楽だ。
とはいえ、俺はVirtualDOMは流行らないと思う。理由は、
・そもそも遅延/選択的描画が効く構成の所が少ない
・遅延/選択的描画するにしても再描画区画は確定的であり、フレームワークを導入するまでもない
・APIが超絶イマイチ
仮想DOMなんてユーザーに意識させてる時点でアウト。
あれはcssプロパティ draw:lazy ならブラウザが自動的に対処してくれる、程度でなきゃ駄目なのさ。
実験としては面白いと思うし、今のJavaScriptで動かすなら今の実装で致し方ないが。
しかしまあそれを言ったら、jQueryが流行った理由は
・時代がそれを必要としていた
・馬鹿には丁度いい頃合いだった
であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
発狂するくらいならフレームワークとか見た方がいいと思うぜ。
使う必要はないが、何故そんなフレームワークが出てきたのか、には意味があるから。
この場合、エレメントが選択的に削除されるので、確かにVirtualDOMの出番ではある。
jQueryでよくやるように、宣言的に記述する場合、
サーチサジェスト部分,innerHTML= となるが、生DOMでは全面書き換えとなる。
VirtualDOMなら同じ記述でも自動的に選択的に描画してくれる為、（一般的には）速くなる。
なお、やれば分かるが、この場合の選択的描画を自前でやると結構ウザイコードになる。
自動でやってくれるのならその方が断然楽だ。
とはいえ、俺はVirtualDOMは流行らないと思う。理由は、
・そもそも遅延/選択的描画が効く構成の所が少ない
・遅延/選択的描画するにしても再描画区画は確定的であり、フレームワークを導入するまでもない
・APIが超絶イマイチ
仮想DOMなんてユーザーに意識させてる時点でアウト。
あれはcssプロパティ draw:lazy ならブラウザが自動的に対処してくれる、程度でなきゃ駄目なのさ。
実験としては面白いと思うし、今のJavaScriptで動かすなら今の実装で致し方ないが。
しかしまあそれを言ったら、jQueryが流行った理由は
・時代がそれを必要としていた
・馬鹿には丁度いい頃合いだった
であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
発狂するくらいならフレームワークとか見た方がいいと思うぜ。
使う必要はないが、何故そんなフレームワークが出てきたのか、には意味があるから。
614デフォルトの名無しさん
2018/12/04(火) 00:09:05.94ID:bTQB60BC > であって、上側が無くなったから馬鹿以外は移行しつつあるわけでさ。
そんなデータどこにもないですよね？
そんなデータどこにもないですよね？
615デフォルトの名無しさん
2018/12/04(火) 00:10:53.45ID:bTQB60BC >>611
> jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
> やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。
なんで遅延描画をしなければならないって
危機的状況に陥ってるの？w
まずそんなものは不要ですって認めるところから始めようか
> jQuery厨は遅延描画を実装する腕前がないから話が通じてない。
> やれば分かるが、遅延描画を実装すると、仮想DOMみたいな作りにならざるを得ない。
なんで遅延描画をしなければならないって
危機的状況に陥ってるの？w
まずそんなものは不要ですって認めるところから始めようか
616デフォルトの名無しさん
2018/12/04(火) 01:15:34.56ID:V/vZILhe 君が現実に目を瞑るのは自由だが、
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ロック状態はあまりよろしくはないと思うぜ。それもまた自由だが。
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ロック状態はあまりよろしくはないと思うぜ。それもまた自由だが。
617デフォルトの名無しさん
2018/12/04(火) 04:16:52.76ID:tEZcZBkn いちいち長すぎだろ…要点まとめるぐらいできないのか
618デフォルトの名無しさん
2018/12/04(火) 06:15:12.11ID:Jf/aCYja >>616
お前うざいよ
お前うざいよ
619デフォルトの名無しさん
2018/12/04(火) 06:51:59.52ID:xAx9wf3n ブラウザにやらせるべきって言ってもブラウザ側にも限界があるし
PauseFrameとかその時その時のベストプラクティスを徹底するのも難しい
その辺りをケアしてくれるのがフレームワークのメリットなのだから
PauseFrameとかその時その時のベストプラクティスを徹底するのも難しい
その辺りをケアしてくれるのがフレームワークのメリットなのだから
620デフォルトの名無しさん
2018/12/04(火) 08:59:31.22ID:V/vZILhe >>619
現状のフレームワーク等はいい実験をしているとは思う。
ただ、描画に関してはブラウザの方が主管なので、本来は丸投げ出来るべきだ。
現行のAPIを組み合わせてもこれは無理だから現状は致し方ないとしても。
> PauseFrame
使いどころは、
A. ajaxで将来的に書き換えると分かっているframeを停止する
B. 画面外のframeを停止する
として、AはJS側でいいが、Bはブラウザが勝手にやるべきだ。
根本的な問題は、CSSが全く拡張不能なこと。CSSで
・pause: auto ならオフスクリーンの場合はpause『してもよい』
という拡張が出来れば、これが一番自然だ。仮想DOMについては、
・draw: lazy でオフスクリーンなら描画『しなくてもいい』
となる。ここら辺まで出来れば、
フレームワーク導入コストはほぼ０となり、もっと面白くなるのだけどね。
現状のフレームワーク等はいい実験をしているとは思う。
ただ、描画に関してはブラウザの方が主管なので、本来は丸投げ出来るべきだ。
現行のAPIを組み合わせてもこれは無理だから現状は致し方ないとしても。
> PauseFrame
使いどころは、
A. ajaxで将来的に書き換えると分かっているframeを停止する
B. 画面外のframeを停止する
として、AはJS側でいいが、Bはブラウザが勝手にやるべきだ。
根本的な問題は、CSSが全く拡張不能なこと。CSSで
・pause: auto ならオフスクリーンの場合はpause『してもよい』
という拡張が出来れば、これが一番自然だ。仮想DOMについては、
・draw: lazy でオフスクリーンなら描画『しなくてもいい』
となる。ここら辺まで出来れば、
フレームワーク導入コストはほぼ０となり、もっと面白くなるのだけどね。
621デフォルトの名無しさん
2018/12/04(火) 13:03:13.41ID:2JUdQ9PA >>620 俺の考えとしては
ブラウザは勿論最大限努力すべきだけど、プログラマがどんな書き方をしていても理論上最善に近いパフォーマンスをしてくれというのは明らかに無理があるし、
一方ある程度はブラウザ側がパフォーマンスのための機構を提示して、プログラマ側の努力を求める事も仕方ないと思う
また別の話として、CSSも数年前からJITが入ったり、ブラウザがよしなにやってくれる感は確かに高まっているけど、それと同時にHoudiniだったり従来よりローレベルな環境が提示されるようになってきておりプログラマの責任も高まってる
ブラウザは勿論最大限努力すべきだけど、プログラマがどんな書き方をしていても理論上最善に近いパフォーマンスをしてくれというのは明らかに無理があるし、
一方ある程度はブラウザ側がパフォーマンスのための機構を提示して、プログラマ側の努力を求める事も仕方ないと思う
また別の話として、CSSも数年前からJITが入ったり、ブラウザがよしなにやってくれる感は確かに高まっているけど、それと同時にHoudiniだったり従来よりローレベルな環境が提示されるようになってきておりプログラマの責任も高まってる
622デフォルトの名無しさん
2018/12/04(火) 17:16:44.38ID:bTQB60BC で、結局のところ、重要なのはJavaScriptでいろいろ解決しましょうじゃなくて
根本的な設計を改善するほうがいい。
つまり静的なページで作れば問題は解決すると言うこと
JavaScriptを使って動きをつけなきゃいけないことなんてほとんどないでしょ？
根本的な設計を改善するほうがいい。
つまり静的なページで作れば問題は解決すると言うこと
JavaScriptを使って動きをつけなきゃいけないことなんてほとんどないでしょ？
623デフォルトの名無しさん
2018/12/04(火) 18:43:50.06ID:T1qfCjQk >>622
は？
は？
624デフォルトの名無しさん
2018/12/04(火) 18:58:48.70ID:bTQB60BC625デフォルトの名無しさん
2018/12/04(火) 19:03:04.87ID:E1VClVEB >>624
は？
は？
626デフォルトの名無しさん
2018/12/04(火) 19:17:23.97ID:V/vZILhe >>621
考え方は間違っていないと思うけど、ちょっと混線してるかな？
自前で遅延/選択的描画を実装すると糞コードになるのは、
OOPで言うと、本来はオブジェクトA（ブラウザ）で完結する処理をオブジェクトB(JS)で無理に行っているからであって、
俺はそこを何とかして欲しいんだよね。
フレームワークに押し込んで隠蔽する、というのも一つの手ではあるけれど。
そちらのレスについては、単純には、
・馬鹿な書き方でもそこそこ速い
・チューニングしまくれば超速い
が通常目指すべきゴールだ。ここまではいいよな？
どちらを目指すべきかだが、両方追っかけているC++が若干迷走気味なので、
本当はどちらかに絞った方がいいんだよ。
Houdiniってことはゲーム畑に近いと思うけど、それなら当然後者を目指すべきと考え、
レンダリング制御関連のAPIがほぼ無いから困っているとは思う。
しかしそれは、APIさえ有れば十分に制御が出来る腕前があるからであって、
実際のWeb系はそこまで到達してない奴の方が多いと思う。
jQuery廚がよく言う「jQueryは簡単！」（＝馬鹿でも問題ない）というのは実は偉大なことであって、
これ自体は素晴らしい。
(jQuery廚の問題は、結局そこに乗っかってしまっていて、結果、馬鹿なままな点であって)
俺個人としては、手を抜けるところは抜きたいので、前者に寄って欲しいんだけどね。
実際は後者に寄っている気はする。
というか、前者を実装するにしてもAPIが必要だし、普通はまず後者を実装するしかないからね。
ゴリゴリの制御が要求されたとしても超高速化したいのなら、技術的にはC++側にコードを注入出来ればいい。
昔で言うアドオンをサイトから毎回ダウンロードして使う、というイメージだ。
アドオン自体はサンドボックス上ではなかったので排除されてしまったが、サンドボックス上にすれば行けるはず。
WebAssemblyが近いが、あれはJS側上のサンドボックスのはずだから、あれのC++側版だね。
考え方は間違っていないと思うけど、ちょっと混線してるかな？
自前で遅延/選択的描画を実装すると糞コードになるのは、
OOPで言うと、本来はオブジェクトA（ブラウザ）で完結する処理をオブジェクトB(JS)で無理に行っているからであって、
俺はそこを何とかして欲しいんだよね。
フレームワークに押し込んで隠蔽する、というのも一つの手ではあるけれど。
そちらのレスについては、単純には、
・馬鹿な書き方でもそこそこ速い
・チューニングしまくれば超速い
が通常目指すべきゴールだ。ここまではいいよな？
どちらを目指すべきかだが、両方追っかけているC++が若干迷走気味なので、
本当はどちらかに絞った方がいいんだよ。
Houdiniってことはゲーム畑に近いと思うけど、それなら当然後者を目指すべきと考え、
レンダリング制御関連のAPIがほぼ無いから困っているとは思う。
しかしそれは、APIさえ有れば十分に制御が出来る腕前があるからであって、
実際のWeb系はそこまで到達してない奴の方が多いと思う。
jQuery廚がよく言う「jQueryは簡単！」（＝馬鹿でも問題ない）というのは実は偉大なことであって、
これ自体は素晴らしい。
(jQuery廚の問題は、結局そこに乗っかってしまっていて、結果、馬鹿なままな点であって)
俺個人としては、手を抜けるところは抜きたいので、前者に寄って欲しいんだけどね。
実際は後者に寄っている気はする。
というか、前者を実装するにしてもAPIが必要だし、普通はまず後者を実装するしかないからね。
ゴリゴリの制御が要求されたとしても超高速化したいのなら、技術的にはC++側にコードを注入出来ればいい。
昔で言うアドオンをサイトから毎回ダウンロードして使う、というイメージだ。
アドオン自体はサンドボックス上ではなかったので排除されてしまったが、サンドボックス上にすれば行けるはず。
WebAssemblyが近いが、あれはJS側上のサンドボックスのはずだから、あれのC++側版だね。
627デフォルトの名無しさん
2018/12/04(火) 19:25:43.01ID:VeulgD+K 3DグラフィックスのHoudiniと勘違いしてない？
CSS拡張APIのHoudiniだよ？
CSS拡張APIのHoudiniだよ？
628デフォルトの名無しさん
2018/12/04(火) 19:27:12.66ID:T1qfCjQk >>624
あのさ、お前のようなヴァカの主義なんか興味ないんだよ、クソ間抜け。
あのさ、お前のようなヴァカの主義なんか興味ないんだよ、クソ間抜け。
629デフォルトの名無しさん
2018/12/04(火) 19:38:52.76ID:V/vZILhe >>622
君が静的なサイトしか作れないからといって、そうだと思いこむのはさすがに不味いと思うぞ。
>>624
というか、前から疑問なのだが、君は普段どんなサイトを見てるんだ？
純粋に静的なページって、今時、あまり見ないだろ。
例えば、動的な順で並べると以下か？
Amazon等ECサイト…大体SPA
2ch等掲示板…2chは糞だが、本来はDBに格納してPHP等でhtmlを生成して配信。
Yahoo等のニュースサイト…同上。更新頻度がやや低いだけ。
MDN/MSDN等…同上。さらに更新頻度は低い。でも更新機能があるからDBがあった方が楽。
ブログ…この辺から直接html配信でも行けるはずだが、実際はDB使っている方が多いのでは？
他に何がある？
DBも使わずhtmlを直接書いて配信してるサイトなんて、普段ほぼ見なくね？
零細サイトはほぼこれだから、サイト数（=仕事）だけは多いのかもしれんが。
君が静的なサイトしか作れないからといって、そうだと思いこむのはさすがに不味いと思うぞ。
>>624
というか、前から疑問なのだが、君は普段どんなサイトを見てるんだ？
純粋に静的なページって、今時、あまり見ないだろ。
例えば、動的な順で並べると以下か？
Amazon等ECサイト…大体SPA
2ch等掲示板…2chは糞だが、本来はDBに格納してPHP等でhtmlを生成して配信。
Yahoo等のニュースサイト…同上。更新頻度がやや低いだけ。
MDN/MSDN等…同上。さらに更新頻度は低い。でも更新機能があるからDBがあった方が楽。
ブログ…この辺から直接html配信でも行けるはずだが、実際はDB使っている方が多いのでは？
他に何がある？
DBも使わずhtmlを直接書いて配信してるサイトなんて、普段ほぼ見なくね？
零細サイトはほぼこれだから、サイト数（=仕事）だけは多いのかもしれんが。
630デフォルトの名無しさん
2018/12/04(火) 20:11:14.45ID:V/vZILhe >>627
してる。というか、ググったらそれが出てきて、Web系の会社も記事を出してて、
OpenCVでキャンバスに描くぜ！なノリだったからそれだと思った。
そして改めてググり直した。
https://developers.google.com/web/updates/2016/05/houdini?hl=ja
う〜ん。最初はこんなもんかもしれんが、
これは pause: auto や draw: lazy が効率よく出来るタイプの物ではないな。
初期のJavaScriptはこんな感じでちょこっと動きを付けていたのかも？
そしてそれをCSS側に移動しただけのような。
今のところCSSはプログラム出来ない（しない）で来ていて、それによる良さもあると思うのだけど。
勿論これが出来れば便利ではあるが、グダグダなのが増えて管理コストが増加してポシャる気が。
なんであれ「出来ることはいいことだ」という考え方もありだけど、
俺自身は「出来ることと出来ないことがはっきりしていて、使い分ける」方が管理が楽だと思っている。
なんというか、この中途半端に出来る感が、凄くJSっぽくはあるが。
とはいえ、JSは駄目だがCSSはあり、というサイトも多いはずなので、無駄に広まりそうだが。
してる。というか、ググったらそれが出てきて、Web系の会社も記事を出してて、
OpenCVでキャンバスに描くぜ！なノリだったからそれだと思った。
そして改めてググり直した。
https://developers.google.com/web/updates/2016/05/houdini?hl=ja
う〜ん。最初はこんなもんかもしれんが、
これは pause: auto や draw: lazy が効率よく出来るタイプの物ではないな。
初期のJavaScriptはこんな感じでちょこっと動きを付けていたのかも？
そしてそれをCSS側に移動しただけのような。
今のところCSSはプログラム出来ない（しない）で来ていて、それによる良さもあると思うのだけど。
勿論これが出来れば便利ではあるが、グダグダなのが増えて管理コストが増加してポシャる気が。
なんであれ「出来ることはいいことだ」という考え方もありだけど、
俺自身は「出来ることと出来ないことがはっきりしていて、使い分ける」方が管理が楽だと思っている。
なんというか、この中途半端に出来る感が、凄くJSっぽくはあるが。
とはいえ、JSは駄目だがCSSはあり、というサイトも多いはずなので、無駄に広まりそうだが。
631デフォルトの名無しさん
2018/12/04(火) 21:28:10.23ID:xAx9wf3n >>630
HoudiniはCSSの枠組みで標準化されているが、実際にはCSSというスタイルシートの仕様の延長上のものと捉えるのは間違っている
もちろん単純なCSSの拡張、柔軟化の仕様も含むが、それ以上に重大な仕様が含まれている
Houdiniとは、スタイルシートのパースから、レイアウト・ペイント・将来的には文字描画も含む
要するにブラウザのDOMレンダリングシステムをローレベルでほぼ丸ごと露出させるという
Extensible Webの精神に乗っ取ったけして中途半端ではない非常に深く広くしっかりとしたAPIだと捉えるのが正しい
pause: auto だの draw: lazy だのも素直に実現できる
>>グダグダなのが増えて管理コストが増加してポシャる
その考え方が本当に間違っている
Extensible Webは皆低レイヤーを触ろうと言ってるんじゃない
皆が求める機能を標準に追加していくのは難しいところがあるから
なんでも作れるAPIを提供してライブラリに任せましょう
そこで本当に便利なものができたら標準に組み込んでも良いねという精神だ
逆に新しい高レイヤーの機能入れたいねとなったときには、
必ずそれを構築できる低レイヤーのAPIを提供することになっている
それが最近よく聞くLayered APIと呼ばれる取り組みだ
つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
HoudiniはCSSの枠組みで標準化されているが、実際にはCSSというスタイルシートの仕様の延長上のものと捉えるのは間違っている
もちろん単純なCSSの拡張、柔軟化の仕様も含むが、それ以上に重大な仕様が含まれている
Houdiniとは、スタイルシートのパースから、レイアウト・ペイント・将来的には文字描画も含む
要するにブラウザのDOMレンダリングシステムをローレベルでほぼ丸ごと露出させるという
Extensible Webの精神に乗っ取ったけして中途半端ではない非常に深く広くしっかりとしたAPIだと捉えるのが正しい
pause: auto だの draw: lazy だのも素直に実現できる
>>グダグダなのが増えて管理コストが増加してポシャる
その考え方が本当に間違っている
Extensible Webは皆低レイヤーを触ろうと言ってるんじゃない
皆が求める機能を標準に追加していくのは難しいところがあるから
なんでも作れるAPIを提供してライブラリに任せましょう
そこで本当に便利なものができたら標準に組み込んでも良いねという精神だ
逆に新しい高レイヤーの機能入れたいねとなったときには、
必ずそれを構築できる低レイヤーのAPIを提供することになっている
それが最近よく聞くLayered APIと呼ばれる取り組みだ
つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
632デフォルトの名無しさん
2018/12/04(火) 22:12:04.80ID:WEhkJbZf この静的って、DOMを弄らないって意味ではないの？
昔ながらのPOSTで全画面更新で充分だって主張に読めたけど。
流石にバックエンド無しと取るのはちょっと変な気がする。
昔ながらのPOSTで全画面更新で充分だって主張に読めたけど。
流石にバックエンド無しと取るのはちょっと変な気がする。
633デフォルトの名無しさん
2018/12/04(火) 22:34:21.67ID:ZSkJl4U8 いやでもapacheの説明書とかではjsもhtmlやcssと同じくスタティックコンテンツやけども…
634デフォルトの名無しさん
2018/12/04(火) 23:57:54.73ID:V/vZILhe >>631
まあ言っていることは分かるし、その通りだが…
> pause: auto だの draw: lazy だのも素直に実現できる
表現は出来るが、これだと実際やるのはJSだろ。
つまり、今JSで実装しているReactのコードをCSSに持っていくだけであり、速度上のメリットは無い。
それでも外部APIが素晴らしく改善されるので効果はあるが、俺が欲しいのはコレジャナイ。
JSで実装する遅延描画がイマイチなのは、offsetTop等が糞遅いからで、
これは『正しい』offsetTopを要求するAPIしかないからだ。
だから、offsetTopの度にリフローを行い、未描画のDOMがないか全チェックする為、遅くなる。（多分）
ただ、遅延描画に必要なのは「そのページ以上の所まで描画済みか？」であり、
offsetTopの精度が悪くてもいい。（未描画DOMが残ってても問題ない）
そしてこの「精度の悪いoffsetTop」をAPIとして定義しろ、なんていちいちやっていてもキリがないから、
レンダラに介入させろ、というわけだ。
レンダラ内でラスタライズしている時、アドレスからおおよそのoffsetTopなんて一瞬で出せる。
当然高速化するし、きめ細かく制御出来るから、限界まで高速化出来る。
(ただしGPUにやらせようぜなんて話が出てたからそうなると一筋縄ではいかないが）
まあ言っていることは分かるし、その通りだが…
> pause: auto だの draw: lazy だのも素直に実現できる
表現は出来るが、これだと実際やるのはJSだろ。
つまり、今JSで実装しているReactのコードをCSSに持っていくだけであり、速度上のメリットは無い。
それでも外部APIが素晴らしく改善されるので効果はあるが、俺が欲しいのはコレジャナイ。
JSで実装する遅延描画がイマイチなのは、offsetTop等が糞遅いからで、
これは『正しい』offsetTopを要求するAPIしかないからだ。
だから、offsetTopの度にリフローを行い、未描画のDOMがないか全チェックする為、遅くなる。（多分）
ただ、遅延描画に必要なのは「そのページ以上の所まで描画済みか？」であり、
offsetTopの精度が悪くてもいい。（未描画DOMが残ってても問題ない）
そしてこの「精度の悪いoffsetTop」をAPIとして定義しろ、なんていちいちやっていてもキリがないから、
レンダラに介入させろ、というわけだ。
レンダラ内でラスタライズしている時、アドレスからおおよそのoffsetTopなんて一瞬で出せる。
当然高速化するし、きめ細かく制御出来るから、限界まで高速化出来る。
(ただしGPUにやらせようぜなんて話が出てたからそうなると一筋縄ではいかないが）
635デフォルトの名無しさん
2018/12/04(火) 23:58:28.93ID:V/vZILhe >>631（続き）
> つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
言っていることは分かるし、確かにこれ以外に現実的路線はないが、果たして上手く行くかね？
今以上にフレームワークが乱立して、なんだかな、な状態になりそうな気がするが。
それも含めてWebだというのならそうだが、
今フレームワークを乱立させてる連中をどうにかして一ヶ所に集中させ、一ついい物を作る方が、
皆にとって幸せだと思うがな。
現状のフレームワークなんて全部死に体だし、あれでは浮かばれんだろ。
> 今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
これがかなり無理があるんだよ。
JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが、
実際はC++ヘビーでレンダラやDOMが実行時間の大半を占めてるだろ。
JS側には改善予算（改善しろ）がないんだよ。
かといって、C++側にAPIやフックを用意させるのもかなり無理な話ではあるが、
しかしJSがパフォーマンスの全責任を負うのはそれ以上に『原理的に』無理だ。
強いて言うなら、現状のブラウザは十分高速で、１ページ程度ならレンダリングは一瞬だ。
遅いのは無駄に10ページ分レンダリングしてたりするか、無駄に遅いJSを実行しているからであり、
ここら辺を遅延描画で改善してやれば可能だが、
今はこれを実装する為の「速い（が精度の悪い）offsetTop」がないんだよ。
> それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
現実的にはこの路線しかないからな。これは認める。
> つまり、その世界では小さなポリフィルやライブラリを階層状に無数に組み合わせた状態が理想と言える
言っていることは分かるし、確かにこれ以外に現実的路線はないが、果たして上手く行くかね？
今以上にフレームワークが乱立して、なんだかな、な状態になりそうな気がするが。
それも含めてWebだというのならそうだが、
今フレームワークを乱立させてる連中をどうにかして一ヶ所に集中させ、一ついい物を作る方が、
皆にとって幸せだと思うがな。
現状のフレームワークなんて全部死に体だし、あれでは浮かばれんだろ。
> 今からの世界では、パフォーマンスを含む機能の責任はJSサイドが取る
これがかなり無理があるんだよ。
JSヘビーでJSエンジンが実行時間の大半を占めるのならこれは可能だが、
実際はC++ヘビーでレンダラやDOMが実行時間の大半を占めてるだろ。
JS側には改善予算（改善しろ）がないんだよ。
かといって、C++側にAPIやフックを用意させるのもかなり無理な話ではあるが、
しかしJSがパフォーマンスの全責任を負うのはそれ以上に『原理的に』無理だ。
強いて言うなら、現状のブラウザは十分高速で、１ページ程度ならレンダリングは一瞬だ。
遅いのは無駄に10ページ分レンダリングしてたりするか、無駄に遅いJSを実行しているからであり、
ここら辺を遅延描画で改善してやれば可能だが、
今はこれを実装する為の「速い（が精度の悪い）offsetTop」がないんだよ。
> それ嫌だとしても、そういうことにしていきましょうということに、もうなっている
現実的にはこの路線しかないからな。これは認める。
636デフォルトの名無しさん
2018/12/05(水) 00:18:53.86ID:HfjLZhFv きたないコード書いてそうだなあ
637デフォルトの名無しさん
2018/12/05(水) 00:27:04.77ID:n6GZlX92 >>632
すまん、それはちょっと俺が先走った。
普通の「静的ページ」は君の定義で正しいだろう。
俺は616に書いたとおり、jQueryが活躍するサイトはHTMLがグダグダな場合で、
それはhtmlを自動生成してない場合と認識しているから、
彼はjQuery廚なのもあり、先走ってしまった。
さて、実際yahooニュースをJS無しで確認してみると、
<noscript>が大量に使われているものの、どうでもいい場所ばかりだ。
これなら変にアドブロックするより、JSを切った方がいいのでは…とも思える。
SPAでもないし、ポップアップもない。リンクはいちいちページ遷移する。
これは「静的ページ」だ。
もうちょっとましな作りかと思っていたのだが、
確かにこれで大して問題ないのも事実だな。
もっとも、鯖側で動的にhtmlを生成する場合、
当然画一的なhtmlとなり、IDやclassをきっちり振ることも簡単だから、
jQueryを使う意味はほぼ無いと思う、という主張はそのままだが。
(yahooはjQuery使っているが)
すまん、それはちょっと俺が先走った。
普通の「静的ページ」は君の定義で正しいだろう。
俺は616に書いたとおり、jQueryが活躍するサイトはHTMLがグダグダな場合で、
それはhtmlを自動生成してない場合と認識しているから、
彼はjQuery廚なのもあり、先走ってしまった。
さて、実際yahooニュースをJS無しで確認してみると、
<noscript>が大量に使われているものの、どうでもいい場所ばかりだ。
これなら変にアドブロックするより、JSを切った方がいいのでは…とも思える。
SPAでもないし、ポップアップもない。リンクはいちいちページ遷移する。
これは「静的ページ」だ。
もうちょっとましな作りかと思っていたのだが、
確かにこれで大して問題ないのも事実だな。
もっとも、鯖側で動的にhtmlを生成する場合、
当然画一的なhtmlとなり、IDやclassをきっちり振ることも簡単だから、
jQueryを使う意味はほぼ無いと思う、という主張はそのままだが。
(yahooはjQuery使っているが)
■ このスレッドは過去ログ倉庫に格納されています
