+ 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(火) 02:33:15.33

いちゃもんおじさんが来ないので、jQueryとCSSの相性と
コンポーネントの再利用についてのサンプル https://jsfiddle.net/rueg1xv2/

要件：フォームコントロールにフォーカスがあたったら背景色を変えたい。
ただし全てではなく指定した要素のみ色などはCSSで指定したい。
（CSSの:focus擬似クラスでできるがあえてjQueryでｗ）

設計：CSSベースで設計する。対象としたい要素のクラスにtargetを指定する
フォーカスがあたっている場合のクラスをfocusとし、jQueryからはクラス名を
変えるだけで、具体的なデザインはCSSで行えるようにする

実装：
[CSS]
.target.focus {
　　background-color: #eee;
}
[jQuery]
$(document).on({
　　focusin: event => $(event.target).addClass('focus'),
　　focusout: event => $(event.target).removeClass('focus')
}, '.target');

解説：構造（といっても今回のは要素だけのフラットなものだが）を
CSSで最初に決めるて処理を適用している。HTMLの構造には依存しないので
HTMLに変更があったとしてもjQueryのコードに変更は必要ない

HTMLとCSSの基本であるデザインをCSSに分離しており、CSSを変えるだけでデザインを変えられる

jQueryで必要なのは適用する要素のセレクタとクラス名だけなので、それを変数で
変えられるようにすれば再利用が可能だし、社内共通名として定義できるなら決めうちでも良い
複数の要素に対応していながら、コードにはループはなく、宣言的に記述している。
DOMを直接変更するなとか変な制限があるフレームークを使っていなければ、今すぐ導入が可能

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

全部nanoやumbrellaで出来るな。
jQueryより軽いし。
所詮ライブラリだからおんなじことできるのにデブ使う必要もない。
どれでも好きな娘選んでエッチしていいよって言われたら一番かわいい娘選ぶだろ？
そういうこと。

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

>>500
> 全部nanoやumbrellaで出来るな。

みたいね。ここに書いて

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

なんだnanoもumbrellaもjQueryライクなライブラリか
設計思想が同じならjQueryの代替にならないわけじゃないな
ただクローンはオリジナルを超えられないものだけど

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

>>497
>>103
同じ事を俺だけでも何回も指摘済みだが。

>>499
間違いを垂れ流すのは止めろ。

お前自身が馬鹿なのが初心者にも分かるだろうから、お前では布教は無理だよ。
というか、何故お前は頑なに学習を拒む？
他の『快適な』サイトがどういう作りになってるか見ればすぐに分かるはずなのだが。

そもそもjQueryを使っただけで、「遅くなり、jQueryに依存する」というデメリットが付いてくる。
『今も』それを越えるメリットがあると思えば使えばいいし、
それは看過出来ないと思う奴らはjQueryを既に捨ててる。それだけの話だ。

jQueryの最大のメリットは、お前みたいな馬鹿でも、どんなグダグダなHTMLでも、何とかなってしまうことだ。
だから（今のお前もやっているように）HTMLベースで組むのは最初は悪いことではないし、妥当だ。
しかし、他の連中は色々学んで、それ以上の道を模索してる。
それがフレームワークであったり、脱jQueryであったり、素で書け、みたいなことだったりする。

フレームワークの使い方を覚えても「プログミングの本質的な腕前」には関係ないが、
各フレームワークがどこに問題を見いだし、どう解決しようとしたかを見ることは、
「プログミングの本質的な腕前」の上達に繋がる。
フレームワークを模索している連中は、その過程で、どんどん前に進んでいく。
お前はjQueryにこだわって、置き去りにされてるだけだ。（というよりそれをお前自身が望んでいる）
他の人とお前が話が通じてないのはそのためだ。君が分かってなさすぎる。
ただそれ以前に、君は日本語が怪しいから、そこをまず詰めた方がいいが。

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

>>498
最初はReactとかSPAの話だったんでその話しかしてないんだが、なんでWordPressとか持ち出すかね。
意図的に話をずらそうとしているのか「フレームワーク」で似たようなものだと区別ついてないのか。
「混ぜる」のミスリードも相変わらずだね。1ページ内で混在する話なんかしてないっつーの。

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

>>499
というか、お前は初心者の発想から抜け出せていない。
話が通じないのは、これが原因かもしれん。

本来は、ライブラリ/フレームワークは「きちんと選んで使うもの」だ。
基準は彼等がよく言う、「どうせ同じようなコードを書くことになる」が分かりやすくていい。
だから本来は、「それがなかったら同じようなコードを書く奴だけが使え」というのも正しくて、偶にこれを言ってる奴もいるだろ。
現実はそうも行かず、全く意味分からない初心者も含めて使え、ということになっているが。

実際、「どうせ同じようなコードを書くことになる」は事実だ。
大規模化したコードの生産性を上げる為には、何らかのプチライブラリ/フレームワークが内部的に必要になる。
（敢えてそれをしない、というスタイルの奴も偶にいるが）

SPA向けのフレームワークは、SPAで典型的に必要になる制御に対し、枠組みを提供するものだ。
当然、無ければ無いで書けるが、彼等の指摘通り、「どうせ同じようなコードを書くことになる」。
なら、ジャストフィットする物があれば、使った方が楽だ。

jQueryも同じで、「どうせ同じようなコードを書くことになる」のなら、使うのは正しい。
つまり、ブラウザの差異を吸収する為に、或いはCSSセレクタを使う為に、jQueryと同じようなコードがどうせ必要な場合だ。
ところが、これらは環境の整備がすすみ、なくなってしまった。
なら、もう要らなくね？というのも自然な発想だ。
彼等は原点を忘れてなかったんだよ。

君にはライブラリを選定する立場になったことがなく、
「○○は使うもの。だって○○さんが決めたから」という感覚しかないから話が通じない。
そして、自分がそうであるから、頭ごなしに「jQueryを使え」と布教しているわけだが、
本来は、どのライブラリ/フレームワークを使うかは、
各自が、「どうせ同じようなコードを書くことになる」かどうかで判断することなんだよ。
そして、jQueryには、もう、「どうせ同じようなコードを書くことになる」理由がなくなってしまっている。
だから脱jQueryも自然な流れであってさ。あれは、意識高い系が、って話ではないんだよ。

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

いちいち長いからコードで端的に示してよ

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

■ >>503 全行解説 (1/2)
> 同じ事を俺だけでも何回も指摘済みだが。
それがどれかを書かない

> 間違いを垂れ流すのは止めろ。
どれが間違いなのか言わない

> お前自身が馬鹿なのが初心者にも分かるだろうからお前では布教は無理だよ。
初心者でもわかるってことにしたい。無理と思い込みたい

> というか、何故お前は頑なに学習を拒む？
拒んでいない

> 他の『快適な』サイトがどういう作りになってるか見ればすぐに分かるはずなのだが。
快適なサイトがどれか書かない。見ればすぐに分かるってことにしたい

> そもそもjQueryを使っただけで、「遅くなり、jQueryに依存する」というデメリットが付いてくる。
速度は速ければ速いほど良いと思っている。問題があるそうかどうかという観点が抜けている。
依存するのは他のフレームワークの方がもっとひどい

> 『今も』それを越えるメリットがあると思えば使えばいいし、
だから3年たった今もみんな使っている

> それは看過出来ないと思う奴らはjQueryを既に捨ててる。それだけの話だ。
データには現れていない。むしろReactを捨ててる方が多かった。

> jQueryの最大のメリットは、お前みたいな馬鹿でも、どんなグダグダなHTMLでも、何とかなってしまうことだ。
どれをを使っても同じ。jQueryの技術から、利用者の能力へと話のすり替え

> だから（今のお前もやっているように）HTMLベースで組むのは最初は悪いことではないし、妥当だ。
最初と明言することで、それは最初だけなんだと思わせようとしている（実際にはプロはjQueryを使ってる。CSSベースで）

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

■ >>503 全行解説 (2/2)
> しかし、他の連中は色々学んで、それ以上の道を模索してる。
その他の連中が誰かを言わない。模索した結果がjQueryの利用者数に影響はなし

> それがフレームワークであったり、脱jQueryであったり、素で書け、みたいなことだったりする。
やっぱりjQueryでいいよねもその一つ

> フレームワークの使い方を覚えても「プログミングの本質的な腕前」には関係ないが、
> 各フレームワークがどこに問題を見いだし、どう解決しようとしたかを見ることは、
> 「プログミングの本質的な腕前」の上達に繋がる。
それと実際に使うかどうかは別の話

> フレームワークを模索している連中は、その過程で、どんどん前に進んでいく。
その結果が、Angular1からAngular2への作り直し、React止めたFacebook、Airbnb等。3歩進んで2歩下がる。

> お前はjQueryにこだわって、置き去りにされてるだけだ。（というよりそれをお前自身が望んでいる）
将来性不明ですぐ消える技術に振り回される連中を見て思う、Backboneに手を出さなくてよかった。Reactもかな？

> 他の人とお前が話が通じてないのはそのためだ。君が分かってなさすぎる。
どこがわかってないかの指摘がない。そういうことにしたいという希望

> ただそれ以前に、君は日本語が怪しいから、そこをまず詰めた方がいいが。
同上

まとめ
・新しいもの、新しいもの、と言ういうだけで成果がない
・技術に対して客観的な意見を言わない（速ければ良いわけじゃないってわかってるだろうにｗ）
・俺への指摘は、どれも根拠がない。（単なる個人攻撃）

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

■ >>499 全行解説 (1/3)
> というか、お前は初心者の発想から抜け出せていない。
どこがという指摘がまた書いていない

> 話が通じないのは、これが原因かもしれん。
そういうことにしたいという希望

> 本来は、ライブラリ/フレームワークは「きちんと選んで使うもの」だ。
その結果jQueryになっただけの話

> 基準は彼等がよく言う、「どうせ同じようなコードを書くことになる」が分かりやすくていい。
「どうせ同じようなコードを（また別のフレームワークで）書くことになる」

> だから本来は、「それがなかったら同じようなコードを書く奴だけが使え」というのも正しくて、偶にこれを言ってる奴もいるだろ。
一体何の話を始めたのか？

> 現実はそうも行かず、全く意味分からない初心者も含めて使え、ということになっているが。
なっていることにしたいという願望

> 実際、「どうせ同じようなコードを書くことになる」は事実だ。
実際に書いてある。Backboneで書いてたら死んだ。Angular1で書いてたら、全く違うAngular2がでてきて作り直し

> 大規模化したコードの生産性を上げる為には、何らかのプチライブラリ/フレームワークが内部的に必要になる。
jQueryでいいじゃん。

> （敢えてそれをしない、というスタイルの奴も偶にいるが）
だからなんなんだろう？

> SPA向けのフレームワークは、SPAで典型的に必要になる制御に対し、枠組みを提供するものだ。
> 当然、無ければ無いで書けるが、彼等の指摘通り、「どうせ同じようなコードを書くことになる」。
また開発工数という概念が抜けてるのかな？時間が無限にあれば、誰でもなくてかける。

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

■ >>499 全行解説 (2/3)
> なら、ジャストフィットする物があれば、使った方が楽だ。
大部分のウェブサイトにはSPA向けのフレームワークはフィットしない。ジャストフィットするjQueryを使ったほうが楽だ

> jQueryも同じで、「どうせ同じようなコードを書くことになる」のなら、使うのは正しい。
10年前のコードが今も同じように動く

> つまり、ブラウザの差異を吸収する為に、或いはCSSセレクタを使う為に、jQueryと同じようなコードがどうせ必要な場合だ。
ブラウザの差異を吸収する時代は終わってる。今は純粋なDOM操作ライブラリだ

> ところが、これらは環境の整備がすすみ、なくなってしまった。
> なら、もう要らなくね？というのも自然な発想だ。
「当然、無ければ無いで書けるが、」といったのは誰だったか。確か開発工数という概念が抜けてる人だったか

> 彼等は原点を忘れてなかったんだよ。
原点はDOM。それを便利に操作するライブラリ

> 君にはライブラリを選定する立場になったことがなく、
・俺への指摘は、どれも根拠がない。

> 「○○は使うもの。だって○○さんが決めたから」という感覚しかないから話が通じない。
・俺への指摘は、どれも根拠がない。

> そして、自分がそうであるから、頭ごなしに「jQueryを使え」と布教しているわけだが、
>>499で動くコードも書いている。お前はなにか書いたか？「頭ごなしにjQueryを使うな」だろ

> 本来は、どのライブラリ/フレームワークを使うかは、
> 各自が、「どうせ同じようなコードを書くことになる」かどうかで判断することなんだよ。
許容範囲のデメリット中で、どれだけ楽になるかだろ

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

■ >>499 全行解説 (3/3)

> そして、jQueryには、もう、「どうせ同じようなコードを書くことになる」理由がなくなってしまっている。
大規模化してて書くことがたくさんあるんでしょ？その書いてる「同じようなコードを簡潔に書ける」のが理由なんだけど？
もう何も書かないで動くって話？CSSでできるならそりゃCSSでやるけど？

> だから脱jQueryも自然な流れであってさ。あれは、意識高い系が、って話ではないんだよ。
わざわざ言うのは、意識高い系がって思ってる証拠だな

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

これは「反論」ではなく「解説」であることに注意なｗ

みんなも解説を見ながら、やつが言ってることを聞きましょう。

**デフォルトの名無しさん** · 2018/11/13(火) 12:27:14.40

別にjQuery信者がどう考えてどう主張してどう使おうがどうでもいいじゃん
今あるものを大切に使って最低限の努力で目的を達成しようとするのも良いことだし

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

糖質？

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

高い品質を求め続けて死んでいった日本の製造業みたいな考え方

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

晩年は品質もそんなよくなかったのかなけどな。

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

予測変換クソやな

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

>>507-512
お前にはそう読めるのだろうが、普通の人ならそうは読めない。
例えば、

> > 同じ事を俺だけでも何回も指摘済みだが。
> それがどれかを書かない

直前の行に書いてるだろ。再掲すると、

> >>497
> >>103
> 同じ事を俺だけでも何回も指摘済みだが。

103に決まってるだろ。

いまいちお前の頭がどういう風に障害持ちなのか分からないが、
どうやら君は非常に断片的にしか読めなくて、
これまでは2行単位でしか読んでなかったが、今はもう1行単位でしか読めなくなってる。
そして直前の行すら無視するのだから、話が通じるはずがない。

それでは一般の文章、例えば公式の紹介文も読めないと思うが。

ただお前のタイプ、リアルで遭遇するのは（俺には)ないが、ここ(2ch)で遭遇するのは3人目だ。
(お前が前から居るのは認識していたが)
何か2chにそういうのを集める理由があるのだろう。
もう少し軽度な奴、4レス前までしか追えない奴もJavaScriptスレの周りにいる。
ただこいつは4『レス』だから『忘れっぽい奴』位で対応出来るが、
さすがに直前の行も読めないようでは話は無理だ。空回りしすぎる。

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

>>513
多分、俺達が古いものをいつまでも使っていたらウェブが発展しない！
俺たちがウェブを変えていくんだ！とかいう謎の使命感（笑）に燃えてるんだと思うｗ
新しいものと速いことに執着しているのがその証

こっちは適切なタイミングで適切な道具を使うだけなのにね。

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

>>518
なんか本気で勘違いしているみたいだから、訂正してあげるね
あんたが出してきたのは以下の 1) と 2.1) のみ、もともと 1) の話はしてないし、
肝心の 2.2) の話はどこ言ったの？

1) Usage of client-side programming languages for websites （JavaScript言語の使用率）
https://w3techs.com/technologies/overview/client_side_language/all
JavaScript 95.0%、Flash 4.1%、Silverlight 0.1%

2) Usage of JavaScript libraries for websites （JavaScriptライブラリの使用率）
https://w3techs.com/technologies/overview/javascript_library/all

　2.1) Historical trends in the usage of JavaScript libraries for websites
　https://w3techs.com/technologies/history_overview/javascript_library/all
　jQueryは73.5%、未使用は24.4%

　2.2) Market share trends for JavaScript libraries for websites
　https://w3techs.com/technologies/history_overview/javascript_library
　jQueryは97.2% （未使用を含めない場合、だから書いていない）

まとめると、ウェブサイトでJavaScript言語を使用しているのは95%で
（言語の使用率とは関係なく）
ウェブサイトでJavaScriptライブラリの使用率はjQueryが73.5%
・jQuery 2015年：61.5%↑、2016年：68.3%↑、2017年：71.9%↑、2018年：73.1%↑、現在：73.5%↑
・未使用 2015年：35.0%↓、2016年：28.7%↓、2017年：25.5%↓、2018年：24.0%↓、現在：24.4%↑
JavaScriptライブラリの中でのjQueryの使用率は97.2%
・jQuery 2015年：94.5%↑、2016年：95.8%↑、2017年：96.4%↑、2018年：96.2%↓、現在：97.2%↑

矢印は前年から上がってるか下がってるか

**デフォルトの名無しさん** · 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が遅くて実現が難しいとかじゃなかったっけ