+ 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/10(土) 11:45:37.39

>>404
セレクタに対して処理をするんじゃなく、セレクタでセレクトされたエレメントを操作するんだよね。
んで >>397 で言ってるクエリ自体をやらないってことは、セレクタでエレメントを抽出せず操作するってことじゃないのかな。
とするとDOMは操作せずスタイルだけをいじるって趣旨なんじゃないのかな。
早い話、セレクタで操作対象のDOMエレメントを抽出した時点でHTMLベースだという主張ではないのかね。

**デフォルトの名無しさん** · 2018/11/10(土) 11:46:24.46

> こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。
なんの話？

jQueryは今も世界中で動いていますね
世界の7割を超えるサイトで使われてるので
普通にサイト見てるだけでjQueryが問題なく動くことが証明できてる

**デフォルトの名無しさん** · 2018/11/10(土) 11:54:10.09

>>407
> セレクタに対して処理をするんじゃなく、セレクタでセレクトされたエレメントを操作するんだよね。

いや、jQueryはそういう風に考えなくて良いんだよ。
考えないほうが正しいと思ったほうが良い

CSSは宣言的な言語
https://developer.mozilla.org/ja/docs/Glossary/CSS
> CSS (Cascading StyleSheets) はブラウザーで Web ページの見た目を調整する宣言型の言語です。

宣言型とはどういうことかってのはまあ検索してもらえばいろいろわかると思うが
http://www.geocities.jp/mickindex/database/db_laws.html
> セルコが正しく言い当てたように、SQLの考え方を習得するときに最大の障壁となるのが、
> 私たちが慣れ親しんだ手続き型言語の考え方です。具体的に言えば、代入・分岐・ループを
> 基本的な処理単位として、システム全体をこの基本的な処理へ分割する発想です。
>
> 　SQL の考え方は、ある意味でその対極を行きます。SQL には代入やループなどの手続きは一切現れませんし、
>データもレコードではなく、もっと複合的な集合の単位で扱われます。

その特性の一つとしてループや分岐がない

CSSにはループや分岐はないだろう？
.foo { color: red }

それと同じでjQueryも宣言的なライブラリになってるんだよ
$('.foo').css({ color: 'red' })

内部的にループしているかどうかって言う話じゃなく（それを言い出したらSQLだってループしてる）
それを使って書くプログラマが、ループや分岐を書かなくてすむ

もちろんjQueryは生JavaScriptもかけるから、下手なやつがjQueryの中でループとかしてるやつがいるが
jQuery自体は宣言型で設計されてるんだよ。

**デフォルトの名無しさん** · 2018/11/10(土) 12:14:11.57

>>407
その解釈であってるが、詳細は以下。

>>402
ああ、それは俺がここで使っている用語だからな。
ただ、一般解釈できる呼称にしているつもりだ。
要は、マスタデータをどこに持つか、ということ。

HTMLベース：HTMLがマスタ
CSSベース：CSSクラスがマスタ（この呼称が良いかはさておき、他よりは誤解がないはず）

jQueryの典型的コードは、「クエリして、その結果のDOMに○○」というものだ。
ここで毎回クエリが必要なのは、HTMLがマスタデータだからだ。
そしてそのクエリが遅いから、動作がもっさりする。

一方、マスタデータがHTMLではない場合、クエリは当然必要ない。
アプリでは内部データがマスタであり、そこから一方的にHTMLを吐き出す。
PHP鯖も、DBからマスタデータを取り寄せ、一方的にHTMLを生成するだけで、DOMクエリなんてやらない。
「DOMクエリが必要なのは、DOMがマスタデータだから」だ。
で、彼はこの抽象化能力がないから、ここが通じずに話が空回りしてる。

DOMクエリが遅いのだから、高速化にはこれを『必要ない』構造にするのが一番いい。
そして、大半のマトモなサイトはそれを既にやっていて、「いちいち何かをする前にDOMクエリ」はしない。
結果、クエリ自体しないのだから、jQueryの利点もない、というだけの話。
彼は知らないから話が通じないだけ。

ただ、これを「CSSベース」というのが分かりやすいかは微妙で、そこが君の疑問点なのは妥当だが、
では、この場合何が「マスタデータ」に当たるかといわれれば、JavaScriptでもないしHTMLではないし、
敢えていうならCSSクラスかな、というところ。

なお、HTMLベースには「マスタデータが直接見える為、ものすごくデバッグし易い」という大きな利点があって、
つまりはこれが蔓延る原因となっている。

**デフォルトの名無しさん** · 2018/11/10(土) 12:15:14.62

>>395
ちょっと考え方が違うんじゃない?
WebやHTMLは文書のための規格として始まったけど、
今ではそうじゃないじゃん?
Web3.0っていう言葉もあるけど、
まだ「インタラクティブな文書表示」とも言えたWeb2.0の段階を
だんだん超えてきてるとは思わない？

別にアプリ作れるから作るぞーって作るものとも限らないと思うよ
表現したいこと、持たせたい機能が自然と増えて高度化して行くのは確実に起きてることで、
いつの間にか作ってるものが「文書」を越えたアプリケーションになっていくって言うのが
ある意味自然な流れだと思うよ

Webサイトって言うのがもう「文書を提供する為の場所」だけではどんどんなくなってると思うけどな
別にゲーム的なものに限らなくてもね

**デフォルトの名無しさん** · 2018/11/10(土) 12:18:08.67

>>409
集合に対する処理系なのか自前でループするとかそんな話じゃなく、そのコードで言えば $('.foo') でセレクトされたエレメント（達）に対して .css({ color: 'red' }) という操作をしてるんでしょ？
それを HTMLベースと言っていて、foo のスタイルそのものを変更するアプローチが CSSベースと言ってるんじゃないのか、という確認だよ。

**デフォルトの名無しさん** · 2018/11/10(土) 12:24:49.10

>>411
> WebやHTMLは文書のための規格として始まったけど、
> 今ではそうじゃないじゃん?

なんで技術主導で考えてるんだよｗ
一番最初に来るのは「要求」何をしたいかだ。
いくら何かができるようになったとしても、
それを使ってなにかしたいという「要求」がなければ使わない

新しいことができるようになったからって
誰もが新しいことするわけじゃないんだよ。

スマホができたからって、誰もがスマホアプリ作ったりしないだろうが？

ウェブをアプリプラットフォームとして使いたいと思ってるのは
今アプリを作っている所で、ウェブサイトの世界からすればよそ者

**デフォルトの名無しさん** · 2018/11/10(土) 12:26:14.66

> 別にアプリ作れるから作るぞーって作るものとも限らないと思うよ
> 表現したいこと、持たせたい機能が自然と増えて高度化して行くのは確実に起きてることで、

起きてない。mozillaのウェブサイトだって、殆どが静的コンテンツ
ページ開くたびに音楽流すとか、アニメーション流すとか
3Dでキャラクターがグリグリとか、やらないからさｗ

**デフォルトの名無しさん** · 2018/11/10(土) 12:28:12.32

>>412
言う必要なさそうだが、その解釈であってる。

HTMLがマスタデータだから、更新時にはHTMLを更新しなければならない。
CSSクラスがマスタなら、更新時にはCSSクラスを更新(add/removeまたはスタイルリスト操作）することになる。

まあこの「CSSベース」が分かりやすい呼称かはさておき、
マスタデータが○○なら、○○ベース、と呼んでる。（今ここでは）

**デフォルトの名無しさん** · 2018/11/10(土) 12:28:25.73

>>412
> そのコードで言えば $('.foo') でセレクトされたエレメント（達）に対して .css({ color: 'red' }) という操作をしてるんでしょ？

だからjQueryはそういう発想で使うものじゃないってこと
間違った発想で使ってるやつが非常に多いのは事実だがね
だからjQueryはHTMLベースとか言い出すアホがでてくる

内部はそうなっていても、jQueryは宣言型として考えることができるようになってる。
ループも条件分岐も書かなくて良いようになってる
だから同じ宣言型のCSSと非常に相性が良い

**デフォルトの名無しさん** · 2018/11/10(土) 12:31:22.88

jQueryはCSSベースなので、具体的なHTMLタグのことは考慮しない。
できるかどうかは置いといて、jQueryはクラスベースでプログラミングする

特定の名前のクラスの要素（それがHTMLのどのタグかは意識しない）を
どのようにするかという宣言で書いていく

CSSのクラスベースなのでHTMLがどのように変わっても問題ない。
jQueryではCSSを直接変えるのは基本的にしないでCSSクラスの更新を行う
jQueryでやるのはCSSクラスの更新＝状態の変化だけだ

**デフォルトの名無しさん** · 2018/11/10(土) 12:35:11.86

>>410
CSSベースのアプローチの真髄が分からんのだけど、HTML の構造に縛られなくなっても CSS の構造に縛られるようになるんじゃないの？
改修する時にはどのみちどちらかには手が入るからJS側の調整も無くなるわけじゃないだろうし、やりたいことの全部が CSS だけでできるわけでもないだろうし。
まあエレメント抽出なんてする必要が無いと言ってるわけじゃなく、基本をどっちに置くか程度の話だと思うけど。
まあおれも何するにも $('.foo') で始めるのはどうかと思うよ。コスト的に。
でも操作対象は明確だから、書き方としては悪くないと思う。

**デフォルトの名無しさん** · 2018/11/10(土) 12:40:02.46

>>416
なんか書き方で言ってるのか動きで言ってるのかの違いっぽいのかな。
おれは書き方は結構スマートだと思うが動きを考えると使う所を選びたいといった感覚だけど。

**デフォルトの名無しさん** · 2018/11/10(土) 12:40:21.64

もう少し具体的に書くと、例えばA要素に対してhoverしたときに色を変えたい
というのをCSSで書くと

a:hover { color: red } となる

ループ的なものはなく、このように宣言するだけで、
全てのa要素に対してこの処理が適用される

これをjQueryでシミュレートするならば、まず
a.hover { color: red } とクラスに変えておいてjQueryでは以下のようにする

$('a').hover(function(event) {
　$(this).toggleClass('hover', event.type == 'mouseenter')
});

ループ的なものはなく、このように宣言するだけで、
全てのa要素に対してこの処理が適用される

条件分岐も不要で、クラスを変えることでデザインを適用する

**デフォルトの名無しさん** · 2018/11/10(土) 12:43:20.01

>>406
>>408
お前はまず全部読んでから、整理して回答する癖を付けろ

> なんの話？
GitHubの話に決まってるだろ

>>409
なるほど君は典型的なjQuery廚か。まあ、この点は分かりやすくていいね。

そうだ。それがjQueryの典型的な書き方で、結果、ものすごくもっさりするのも事実だ。
そしてjQuery厨は君のようにそれを「大正義」だと思っているらしく、
どんなにもっさりしていてもその書き方を止めない。
「宣言型」だからこの書き方の方が素晴らしい！と本気で勘違いしてる。

ただ、プログラミングってのは手段であって、目的ではない。
ユーザーは、そのサイトが快適かどうかは気にするが、中身のソースコードなんて気にしない。

宣言型の方がソースコードの管理は楽だし、HTMLベースの方がデバッグしやすいのも事実だが、
ユーザーエクスペリエンスを損ねるようでは意味がない。
ただ、CSSベースでも宣言型ではあるし、実際そんなに難しくもならないから、まともなところは既に移行済みだ。
そしてjQuery廚だけが取り残されつつある、というのが今だね。

**デフォルトの名無しさん** · 2018/11/10(土) 12:45:37.73

そういや、仮想DOMは最終的に遅いっていう話があったな
仮想lDOMはDOM全部入れ替えよりも速いというだけで
そもそもDOM全部入れ替えなんてしねーよという話

**デフォルトの名無しさん** · 2018/11/10(土) 12:46:04.24

>>421
> そうだ。それがjQueryの典型的な書き方で、結果、ものすごくもっさりするのも事実だ。

もっさいりしているという証拠は？

結局いつも出せないんだよねｗ

**デフォルトの名無しさん** · 2018/11/10(土) 12:46:39.27

> ユーザーエクスペリエンスを損ねるようでは意味がない。

はい、宣言型のjQuery使って
ユーザーエクスペリエンスを損ないません。

**デフォルトの名無しさん** · 2018/11/10(土) 13:27:52.51

>>418
指摘はその通り。一応いちいち確認しておくと、以下。

> HTML の構造に縛られなくなっても CSS の構造に縛られるようになるんじゃないの？
なる。
ただし、HTMLよりはCSSクラスの方がだいぶまし、という話。
MVCの利点は、「変更されやすいVを、変更されないMと変更に大きなコストがかかるCから分離した」事だ。
この場合、MはCSSクラス、CはJavaScript、VはHTMLとCSSデザインだ。
だから、JavaScript自体がCSSクラスに「だけ」依存するようにしておけば、
HTMLとCSSデザインの変更の影響は受けずに済む、という話。

何にも依存しないというのは無理だから、「変更され難いもの」に依存するようにしていくのが常道。
HTMLよりもCSSのクラス構成の方が本質的だから、変更されにくい。
単品のサイトだと分かりにくいから、複数サイトを同一JavaScriptでカバーすることを想定してみればいい。

> 基本をどっちに置くか程度の話だと思うけど。
そうとも言えるが、現実的にはコード構成ががらりと変わる。

各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
だから個別データはノードから動的に取得する必要があり、
単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。

結果、イベント起動部分のコードは全書き換えに近くなる。

> まあおれも何するにも $('.foo') で始めるのはどうかと思うよ。コスト的に。
> でも操作対象は明確だから、書き方としては悪くないと思う。
分かりやすいのは事実なんだよ。
その結果、もっさりするのもまた事実な訳でさ。
そしてCSSベースにしても、特段分かりにくくなるわけでもないのも事実で、
実際に軽くなるんだからまともな奴はみんなそうしてる、ってだけでさ。

**デフォルトの名無しさん** · 2018/11/10(土) 13:29:27.38

id="css1" の style の一件目が .foo { color: red; } だったとして、

$('.foo').css({ color: 'blue' }) とやったら HTMLベースと言ってるのは合ってると思うが、

document.getElementById('css1').sheet.cssRules[0].style['color'] = 'blue'; とやったら CSSベースで合ってる？

つかそれはそれとしてルールへのスマートなアクセスのやり方教えて。

**デフォルトの名無しさん** · 2018/11/10(土) 13:48:22.57

>>426
> document.getElementById('css1').sheet.cssRules[0].style['color'] = 'blue'; とやったら CSSベースで合ってる？
いや、そこは普通にクラスを足す。具体的には、

e.target.classList.add('highlight') とか。
.foo.highlight {color:blue;} は当然最初から書いておく。

つかここら辺は普通のサイトはこうしてるから、見ればいいと思うよ。
絶対にHTMLをいじらない、というわけではない。ましな方を適宜選択するだけ。

スタイルルールをいちいち書き換えるコードは、あまり使っている奴は居ないと思うぞ。
それよりは、スタイルリストごと全部入れ替えてると思う。

**デフォルトの名無しさん** · 2018/11/10(土) 13:59:17.38

>>427
となるとエレメントに対してクラスを追加するという操作をしてるんだから、HTMLベースと言ってるところと一緒に思えるが、
またCSSベースが指す概念がよくわからなくなってきたよ。
CSSの定義の方をいじっちゃえば見栄え変えるのにエレメントを抽出する必要無いじゃん、という話ではなかったっぽいな。

**デフォルトの名無しさん** · 2018/11/10(土) 14:36:49.62

>>428
そこは説明用の言葉を考えただけだから、過度に拘る必要はないが、
CSSがマスタなのは変わらないし、DOMクエリが必要ないのも変わらないだろ。

CSSは最初から .foo.highlight を持っていて、HTMLが変化しただけ。

俺がCSS「クラス」と言っているのが不味かったか？
CSSでは文法上分離してないが、あれは「構造クラス」と「デザインクラス」と分けて考えるべきで、
.foo は「構造クラス」で不変、.highlightは「デザインクラス」で適宜追加/削除するもの。
「構造クラス」はJavaScriptの「クラス」と同じで、またOOPの「クラス」とも同じ。変わることはない。
そして最初に設計されるべき物。
「デザインクラス」はただの追加アトリビュートだ。見た目を変える為に動的に追加/削除/変更される。

上記の通り、CSSクラスの使い方はOOPと同じだから、OOPを理解している奴は普通に適切に使える。
ところがJavaScripterにはOOPを理解してない奴も多いから、
（というよりはその上流のデザイナのせいか？
もっとも、上流にデザイナが居る時点で間違いだというのが俺の見解だが）
CSSもグチャグチャになってたりする。
CSSも本来は、

.構造クラス {}
.構造クラス.デザインクラス {}

の2種類だけで構成されるべきなんだよ。（基本的には）

> CSSの定義の方をいじっちゃえば見栄え変えるのにエレメントを抽出する必要無いじゃん、という話ではなかったっぽいな。
ああ、これは違う。これをやるには大量にクラスを定義しまくる必要があるだろ。
実際、何個くらいまで実用に耐えられるのかは興味はあるにしても、
他にそんなコードを見たことがないので、採用はしないね。

**デフォルトの名無しさん** · 2018/11/10(土) 14:44:43.10

>>428
というか、俺はオレオレ流の先進性がある(ｷﾘｯな方法を宣伝しているのではなく、
割とみんなやってる方法を言ってるだけだから、新しい手法か？という期待をされても無理だ。
そんなもん知ってるわ！でしか無いと思う。

**デフォルトの名無しさん** · 2018/11/10(土) 19:55:52.70

DOMを縦横無尽に弄ろうとするから複雑になる
機能が小さく閉じたコンポーネントを組み合わせて設計すればいいだけ
直接CSSを弄ろうなど、愚の骨頂

**デフォルトの名無しさん** · 2018/11/10(土) 20:28:54.94

>>431
それな。jQueryの使い方として、まずトップのクラスを一つ作る
正確には最初にCSSの設計を行って、CSSの構造でコンポーネントを定義する
この時sassを使うとネストができるのでHTMLの構造をCSSで定義しやすい
そしてjQueryはそのコンポーネントに対して処理を記述する

CSSで構造を作って、その構造通りにHTMLを書く
そしてCSSでは不可能なことが出てくればJavaScript（jQuery）の出番ってわけ
jQueryはCSSと相性がいい

**デフォルトの名無しさん** · 2018/11/10(土) 20:33:34.38

>>425
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。

jQueryはこのイベントを親で受けるっていうのがすごく書きやすい

$('.foo').on('click', ・・・) とあったら
$(document).on('click', '.foo', ・・・) と書き換えるだけ
documentでなくても、.fooの親である任意の要素でよい

ここでも「分離して動作」という処理がなくなって宣言的になる
bodyにonしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
それどころか、e.target.classList.contains を使って分離して動作させることもいらない

それでいて、共通イベントハンドラとか使わなくていいし、クロージャでそのノード個別のデータを渡すこともできる。

DOM APIを使ったときに発生する問題が全て解決されるってわけ

どや？ｗ

**デフォルトの名無しさん** · 2018/11/10(土) 20:36:59.04

DOM APIの問題をあげたようだが、
それがjQueryによって解決されてるのを見ると、
やっぱりjQuery使ったほうが良いなってなるよなｗ

**デフォルトの名無しさん** · 2018/11/10(土) 20:42:53.84

>>432
それはjQueryの使い方でも使われ方でもないな
jQueryに限らないけど君みたいな大好きマンが語ることって、
もちろんそれは君の好きにしたら良いし否定はしないけど、やっぱり例外的なんだよ
コンポーネントで組むならそれ専用のライブラリを使うほうが絶対にいいし
一部に使うにしろShadowDOM然り相性が良いとは消して言えない

気軽で便利さが取り柄のjQueryのようなライブラリで、
考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ
jQueryは正に比較的小規模なサイトでパッチを当てるような勢いで
縦横無尽にDOMを操ることに最も向いてるライブラリなんだよ

**デフォルトの名無しさん** · 2018/11/10(土) 20:47:26.06

> 気軽で便利さが取り柄のjQueryのようなライブラリで、
> 考えて素敵な使い方をしよう仕様という時点で、それは普通とは違うんだよ

はっはっは。
つまりお前は、jQueryは気軽に使うもんだ。気軽に使うから問題出るやろ
って言ってるわけか。
全てお前の使い方が悪いんじゃないか

見ての通り、お前が上げたDOM APIの問題がすべてjQueryで解決していることを示した。

>>425で（DOM APIの場合は）

> そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、
～略～
> 結果、イベント起動部分のコードは全書き換えに近くなる。

といっているが、jQueryならたったこれだけだ。

> $('.foo').on('click', ・・・) とあったら
> $(document).on('click', '.foo', ・・・) と書き換えるだけ

イベントハンドラのコードは全く変更がいらない

**デフォルトの名無しさん** · 2018/11/10(土) 20:55:48.33

イベントハンドラのコードは全く変更がいらないと書いたが、
実はDOM APIのイベントハンドラの中身を
jQueryでほぼそのまま使えるってことも重要な所だな

DOM APIからjQueryへの移植が楽になっている

$(document).on('click', '.foo', function(event) {
　　ここで扱う、thisはDOM APIの場合と同じく、イベントが発生した要素だし、
　　eventもDOM APIと互換性のあるeventオブジェクトになっている
　　これは各イベントを親で受け取る場合だが、個別の要素で受け取る場合と全く同じ書き方で良い
})

**デフォルトの名無しさん** · 2018/11/10(土) 21:08:34.79

結局さ、CSSベースでJavaScriptを素敵な使い方をしようと思えば
DOM APIを使うよりも、jQueryを使うのが良いってことなんだよなー

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

どこまで行っても所詮jsのライブラリだからな。jsでできる以上のことはできない。
jsで書いてループが必要なところは、ライブラリが内部で行っているだけ。
てかもしかして他の言語のライブラリの仕組みと勘違いしてるのかもしれんが、jsのライブラリって単なる他人の書いたコードだからなｗ
「jQuery設計した人はなぁ！すごいんだぞ！頭いいんだぞ！だから俺にひれ伏せ(?)」と主張しているにすぎない。
なぜか御主人様の自慢を始めてしまう奴隷のようだｗｗマヌケｗｗｗｗ

**デフォルトの名無しさん** · 2018/11/10(土) 21:14:39.84

> どこまで行っても所詮jsのライブラリだからな。jsでできる以上のことはできない。

それはJavaScriptでできることの限界までできるってことじゃね？

**デフォルトの名無しさん** · 2018/11/10(土) 21:17:06.38

>>439
> 「jQuery設計した人はなぁ！すごいんだぞ！頭いいんだぞ！だから俺にひれ伏せ(?)」と主張しているにすぎない。

いや、人の自慢はしてないぞｗ
（褒められたことではないが）jQueryの作者の名前知らないｗ

純粋にjQueryというライブラリ、その設計が素晴らしいと言ってるだけ
DOM APIの様々な問題（を都合よく語ってくれたのでｗ）それを解決している

**デフォルトの名無しさん** · 2018/11/10(土) 21:58:09.87

>>437その他
それは素のJavaScriptで出来ることをjQueryでやっただけで、
jQueryを使う意味が全くないだろ。
楽にもなってないし、無駄ラップしてる分遅くなってるし、jQueryに無駄に依存してる。
メリットが何もない。
当然、この状況でjQueryを使う馬鹿なんて居ない。

ただ、お前はjQueryの典型的な使い方>>409をしてるんだろ？
じゃあ437その他の書き方じゃねえだろ。

というか、お前は考え方が逆なんだよ。
409の書き方がjQuery使いに典型的な理由は、jQueryの恩恵を受けられるからなんだよ。
そしてCSSベースでがっちり組んでる奴にはjQueryのメリットなんて全くないから、
彼等はjQueryもフレームワークも大嫌いなわけでさ。

だから
> Queryは正に比較的小規模なサイトでパッチを当てるような勢いで
> 縦横無尽にDOMを操ることに最も向いてるライブラリなんだよ (>>435)
これが正鵠を射てる。
小規模のサイトで技術力が比較的ない場合、
HTMLベース+jQueryで運用するのは極めて現実的な判断だ。だから広まった。

俺は歴史はあまり知らないが、どうやらCSSはかなり初期からあったのに、
「CSSでスタイルしようぜ」なんて言いだしたのは最初からでもないだろ。（特に国内のサイトは酷かった）
そして、みんな学んできて、『技術力が比較的ない』状態を脱しつつあるから、
今脱jQueryの動きがある、ってだけでさ。
特に不思議でもなんでもないだろ。
むしろお前が無理に居残ろうとする意味が分からない。

**デフォルトの名無しさん** · 2018/11/10(土) 22:11:33.57

>>442
> それは素のJavaScriptで出来ることをjQueryでやっただけで、
> jQueryを使う意味が全くないだろ。

バカなのかな？

>>425で自分で
> そうとも言えるが、現実的にはコード構成ががらりと変わる。

とか問題があると言いながら、
jQueryで解決すると、意味がないといいはる。

発言に矛盾が生じてますねｗ

**デフォルトの名無しさん** · 2018/11/10(土) 22:16:43.94

>>443
お前はマジで日本語をもう少しちゃんとやるか、半島に帰れ。
俺は、
> 問題がある
なんて言ってない。
というか、お前が必死だったのはここを読み間違えたからか。

**デフォルトの名無しさん** · 2018/11/10(土) 22:20:32.47

> 俺は歴史はあまり知らないが、どうやらCSSはかなり初期からあったのに、
> 「CSSでスタイルしようぜ」なんて言いだしたのは最初からでもないだろ。（特に国内のサイトは酷かった）

知らないなら言わなきゃ良いのにｗ

1994年にホーコン・ウィウム・リーが初めてCSSの概念を提唱した時から
CSSでスタイルを適用するって話をしてるのに

https://www.w3.org/People/howcome/p/cascade.html
https://www.w3.org/Style/951106_Workshop/
> Style sheets have the potential of adding style to the web without sacrificing device-independence or
> document structure. Instead of adding visual tags to HTML, style sheets attach
> presentational information to the structure of SGML and HTML documents.

なにか言うたびに墓穴をほってるんだから、もう止めたら？ｗ

**デフォルトの名無しさん** · 2018/11/10(土) 22:21:59.95

>>444
ほー、ってことは

jQueryを使わないと
> そうとも言えるが、現実的にはコード構成ががらりと変わる。
が問題はない　と、そういったわけですか？

でも、jQueryを使うとがらりと変わることは無いってことには
異論はないわけですよね？

**デフォルトの名無しさん** · 2018/11/10(土) 22:23:31.80

> そしてCSSベースでがっちり組んでる奴にはjQueryのメリットなんて全くないから、
> 彼等はjQueryもフレームワークも大嫌いなわけでさ。

どこの話をしてるだろう？

現実には彼らはjQueryを使っていますが？ウェブの7割以上。JavaScriptを使ってるサイトの97%以上。
それはjQueryにメリットがある何よりの証拠じゃないんですかねｗ

**デフォルトの名無しさん** · 2018/11/10(土) 22:25:04.76

>>425

> そうとも言えるが、現実的にはコード構成ががらりと変わる。
>
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
> bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
> 共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
> だから個別データはノードから動的に取得する必要があり、
> 単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
>
> 結果、イベント起動部分のコードは全書き換えに近くなる。

それは問題はなにもないってことじゃないんですか？ｗｗｗ

**デフォルトの名無しさん** · 2018/11/10(土) 22:25:21.28

>>445
> なにか言うたびに墓穴をほってるんだから、もう止めたら？ｗ
お前がな。
https://mayonez.jp/topic/1758

使えなかった当初はさておき、海外のCSS対応に比べて国内はものすごく遅れた。
これをお前は知らないのか？
だとするとお前はそんなに年でもないはずだが、何故そこまでしてjQueryおじさんになろうとする？

**デフォルトの名無しさん** · 2018/11/10(土) 22:36:21.41

>>449
そのリンクを持ち出してきて、お前が何を言いたいのかが
まーた書かれてないんだがｗ

> だとするとお前はそんなに年でもないはずだが、何故そこまでしてjQueryおじさんになろうとする？

なろうとしてないよ？お前がなろうとしてるはずだって思いこんでるだけ

俺は今までずっとjQueryの技術について話をしているのに、
お前は、俺のことばっかりだよなｗ

jQueryそのものに対しては、遅れてるだとか誰も使ってないだとか
そんな根拠のないことしか言ってない

一つぐらいお前が>>425で書いた問題（問題じゃなかったことにしたんでしたっけ？ｗ）
についてjQueryが解決していることにコメントでもしたら？
解決してないことを探し出すんじゃなくて
jQueryが "解決していること" を無視せずにコメントしろ言ってる

**デフォルトの名無しさん** · 2018/11/10(土) 22:46:13.68

>>446
> 異論はないわけですよね？
あるぞ。というかお前自身が書き換えてるだろ。

>>448
実際は最初からそう書くから、書き換えなんてしない。
両対応なんてする意味はないし。
だから、HTMLベースで行くのか、CSSベースで行くのかは、最初に決めるし、それで確定する。
そして、今時HTMLベースを選ぶのは技術力がない連中だけだ。
そのHTMLベースにjQueryは極めてフィットし、CSSベースにおいては無用の長物だから、結果的に、
jQuery使い≒HTMLベース≒技術力がない
が成立するから、馬鹿にされる要因にもなり得るし、実際、今そういう感じだろ。

もっとも、イベントエントリ部分は書き換えるにしても大した話ではない。
だから、正しいクラスの使い方をしていれば、移行するのは面倒だが難しい話ではない。
やればいいだけの話だ。

というか、お前は本当に色々知らないから話が通じてない。
もうここら辺でいいかな？どうしてもjQueryを否定されたくないんだろ？
俺はjQueryは役割を終えたという見方だし、お前の屁理屈をいくら聞いても全く変わらない。
このスレの他の連中も、割と公平な見方してると思うぜ。

**デフォルトの名無しさん** · 2018/11/10(土) 22:48:55.83

>>450
> jQueryが "解決していること" を無視せずにコメントしろ言ってる
>>451参照してくれ。
そもそも問題がないのに、何を解決したつもりなんだ？

マジで日本語どうにかしろ

**デフォルトの名無しさん** · 2018/11/11(日) 00:01:21.30

>>452
何を解決したかって

各イベントを親で受けて、e.target.classList.contains を使って分離して動作させて
共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ないず
だから個別データはノードから動的に取得する必要があり、
単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
というコードを最初から書くんでしょう？

最初から多少煩雑になるコードを書いてるわけですよね？

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

実際に書いてみたら良いんじゃないですか？
その煩雑になるコードってやらを

**デフォルトの名無しさん** · 2018/11/11(日) 00:12:37.08

>>451
> 俺はjQueryは役割を終えたという見方だし、お前の屁理屈をいくら聞いても全く変わらない。

たしか俺が、>>338で結論出るまで、あとどれくらいか聞いた時
たしか10年って答えなかったっけ？ｗ

そうだね。結論が出るまで10年後ってレスしてるね

**デフォルトの名無しさん** · 2018/11/11(日) 00:20:37.58

>>453-455
日本語でおk

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

>>456
後で書き換えるかもしれないから、あとで書き換えなくて良いように、
必要ないかもしれないのに、煩雑になるコードを最初から書いているってさ

YAGNIな俺とは正反対だねｗ

**デフォルトの名無しさん** · 2018/11/11(日) 00:28:45.76

>>457
日本語でおk

つかマジでそんなこと言ってないだろ。
もう、空回りしてる部分についてはこちらからはフォローしない。キリがないし、意味もないから。
内容を把握出来るまで何度でも読み返し、整理してから回答しろ。

**デフォルトの名無しさん** · 2018/11/11(日) 00:31:32.66

> つかマジでそんなこと言ってないだろ。

引用しかしてませんが？もう一回引用したら良い？

>>425より
> 各イベントは親で受けて、e.target.classList.contains を使って分離して動作させることになる。
> bodyにaddEventListenerしてよければ、DOMクエリ自体が最初から最後まで全く要らない。
> 共通イベントハンドラで対処することになるから、クロージャでそのノード個別のデータを渡すことが出来ない。
> だから個別データはノードから動的に取得する必要があり、
> 単純にgetAttribute等で取れない場合は、この部分が多少煩雑になる。
>
> 結果、イベント起動部分のコードは全書き換えに近くなる。

>>451より
> 実際は最初からそう書くから、書き換えなんてしない。

全書き換えに近くなるから、書き換えしなくてすむように
最初から>>425のように書くんでしょう？

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

>>459
日本語でおk

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

自分が書いた日本語も読めなくなったのかｗ

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

いい加減Observable使おうぜ

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

フレームワークがよくわからないのですが
node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか

jQuery だけは DOM をいじるときと $.ajax ぐらいは使えるんですが
jQuery みたいな便利なライブラリ群って認識でいいんでしょうか

**デフォルトの名無しさん** · 2018/11/11(日) 19:05:55.76

>>463
公式を読むのが一番早いし誤解がない。
公式を読めない/読む気もないのならプログラマには向いてないから辞めた方がいい。
公式を読んで色々ググった上で疑問点があるときのみここに書き込め。

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

>>463
> node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか

その中でnode.jsはフレームワークじゃなくて実行環境。JavaScriptはブラウザ以外でも動く。
例えばWindowsだったらcscriptコマンドでコマンドプロンプト上でJavaScriptが動く。
node.jsも同じようにChromeで使われてるV8 JavaScriptエンジンを使ってコンソールで動く実行環境

だから本来はJavaScript本体と言ったらブラウザでしか使えないDOM APIは含まれない。
実際JavaScriptの仕様にもDOM APIは書いていない。それを区別できないやつがこんなスレタイで
ブラウザはJavaScrptの一部みたいなもんだからいいだろとか言ってるわけだが

話がそれたが、フレームワークは枠組み。全体的な仕組みは、こっちで作って呼び出してやるから
お前はその中の処理を書けばいいよ。というタイプ。ライブラリはその処理を書くときに使える便利な道具

例えば、ボタンをクリックしたらclickイベントを発生してやるから、
お前はその中身だけを書けばいいという仕組みがフレームワーク。と書くとブラウザでは
普通のことじゃね？と思うかもしれないが、その通り。ブラウザは一種のフレームワークになってる。

そこに新たにvue.jsやreact.jsというフレームワークを入れるというのはどういうことなのかというと、

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

（>>465の続き）ブラウザ標準のフレームワークを、独自の思想を持った独自のフレームワークに作り変えている。
だから原則としてDOM APIを使わない。DOM APIを使わずに作れることがメリットと言っているが
まあセールストークだね。思想が違うのでフレームワークとしての使い方が大幅に変わるし
過去の資産が使えなくなるし、何よりサイトの一部にだけに取り入れることが難しい。
（つまりブラウザ標準のフレームワークとvue.jsやreact.js混ぜて使うことが難しい）

ブラウザ標準のHTMLを書いてその要素にイベントを割り当てるのではなく
そもそもHTMLをJavaScriptから生成することになるので、ウェブサイトを作るのには適していない
JavaScriptのフレームワークを使わないと、単純なページすら作れない。

さらにこれらのフレームワークはSPA（single page application）が基本となってるから、
複数ページに見えても1ページ。なので特定のページだけ使うとかじゃなくて
サイト全体とか特定のパス以下は全てフレームワークで管理することになる。
だからウェブサイトとして使っている所には普及しない。

ここいらはブラウザ特有の事情ね

jQueryは一般的にはライブラリと言われてるし、実際にライブラリでブラウザ標準のフレームワークを
互換性を保ちながら使いやすくしている。イベントハンドラを割り当てる方法とか
DOM APIのaddEventListenerではなくon等を用いるため、jQuery独自の世界になるように見えるが、
内部では単純にDOM APIを呼び出しているだけで、フレームワークに関しては独自の思想は持っていない
互換性があるので簡単に置き換えられる。DOM APIのイベントハンドラをほとんど変えずにjQueryで使えるしね

jQueryの特徴はむしろjQueryオブジェクト（ $(セレクタ) ）の方にあって、
0個以上のDOM要素を一つのオブジェクトにラップして塊として扱えるようにするのが特徴で
これにより宣言的な記述が可能になる。CSSとも相性が良い。CSSベースで正しく設計した時のjQueryの相性は抜群
jQueryは新たなフレームワークを作り出すものではなく、jQueryオブジェクトを導入するものなのでライブラリ

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

>>463
> node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか

直接的にこの質問に答えると、所詮JavaScriptのライブラリでしか無いので
JavaScriptでできる以上のことは出来ない。

何ができるようになるかじゃなく、作り方が変わる。
vue.js react.jsは作りやすくなると自称しているが、ウェブサイトには適していない
ウェブアプリとして作りやすいようになっているフレームワーク

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

訂正
> node.js vue.js react.js とかをよくききますが何ができるようになるんでしょうか

node.jsは実行環境で、ブラウザなしにJavaScriptを動かすことができるようになる。
ブラウザではないのでDOM APIの代わりにAPIを搭載しておりローカルファイルにアクセスできたりする
（もちろんブラウザではな動かない）

vue.jsとreact.jsは所詮JavaScriptで実装されたもの（というべきだった）
だからJavaScrpitでできる以上のことは出来ないし、
ブラウザのJavaScriptで動くのだから、ブラウザのJavaScriptでできる以上のことは出来ない

ただし、React.jsはReactNativeといってブラウザ以外でもスマホアプリとして動くように
なってる。ブラウザ版とアプリ版でコードを共有したいなら使えるというメリットは有るが
AirBnb がReactNativeやめるとか言ってるし、UIにこだわるったりするなら茨の道なんだろうね。
んで、やっぱり、これはアプリの話なんだよｗ

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

>さらにこれらのフレームワークはSPA（single page application）が基本となってるから、
>複数ページに見えても1ページ。なので特定のページだけ使うとかじゃなくて
>サイト全体とか特定のパス以下は全てフレームワークで管理することになる。

細かいこと言うと、1ページでしかないから(React等を使っていない)他のページと
組み合わせて使うことは十分可能なんだよな。

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

>>469
可能か不可能かじゃなくて難しいって話をしている
例えば既存でサイトが既にあったとして
URLを変えずに1ページずつ移行していきましょうとか大変

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

prototype.jsからjQueryへの移行のときとか、
1ページ内に、prototype.jsとjQueryを両方読み込んで、
HTML（とCSS）はそのままに1関数ずつ移行とかできたしね

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

なんでいきなり移行する話になるんだか。
共存自体は別に難しくないよ。非SPAで複数ページ連携するのと変わらん。

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

463です

たくさんリプありがとうございます

まだいまいちわかってないけど
React Vue は複数ページに見えるページセットみたいなのをJSでかけて
クライアントはリンクふんだときにページ遷移にみえるように画面いれかえてくれるものってことなのかな
だからそのページセットがネイティブアプリでうごくってことなのかな

node.js は javascript で CGI サーバーサイドの物を作れるってことかな
llisten accept とかをJSでできるようになるのかな
JSで標準入出力をかくだけでCGIとして動くものなのかな

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

>>462
1ページの中にvue.jsとreact.jsを共存させるサンプル教えて
もちろんフレーム使わずに

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

>>473
釣れますか？

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

>>473
まあjQuery廚がするjQueryの話だけは鵜呑みにするなよ。
既に何度も言ったとおり、CSSベースで組んだ場合にjQueryを使うメリットは何もない。
だから、CSSベースでいける、と判断したところが脱jQueryしていってる。
そしてjQuery廚はCSSベースの意味を理解出来てないし、誤用している。

なお、話を戻すと、その手のフレームワークについては、
こういった解説を求めたり、或いはググったらQuitaとかに色々でてくるはずだが、
なんだかんだで間違いが多いから公式を読んだ方がいい。
そして、公式を読んでも意味が分からないのなら、それは君が今使うべき物ではない、ということ。

結局、ここで聞いて、俺達が何か言ったところで、君には間違いが見抜けないだろ。
なら、君自身が間違いを見抜けるようになるか、間違いがあった場合に誰かが訂正してくれる場所でないと、
質問する意味がないだろ。間違いを掴まされる可能性も普通にあるわけでさ。
そして、間違いが一番少ない場所は公式、ってことだ。通常、間違ってればすぐに訂正されるから。

最近の公式はどれもこれも布教用ページを持っているから、そこを読むのが一番いい。
そして、当然それは使用者のレベルも想定した上で書かれているから、
そこを読んで分からないのならお呼びではないって事で諦めた方がいい。つまり、

公式を読め、無理なら諦めろ、なんだが。

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

>>473
> React Vue は複数ページに見えるページセットみたいなのをJSでかけて
> クライアントはリンクふんだときにページ遷移にみえるように画面いれかえてくれるものってことなのかな

それはどちらかといえばオマケ機能。たまたま（デフォルトで）そうやってるってだけで
そうやる必要もないし、フレームワークの話とは関係ない

> だからそのページセットがネイティブアプリでうごくってことなのかな
この話とネイティブアプリで動くのとは直接の関係はない
まあ設計はしやすいんだろうけど

> node.js は javascript で CGI サーバーサイドの物を作れるってことかな
それはあっている。CGIにすることもできるが、通常はnode.jsで
動くサーバーサイドフレームワークを使う

> llisten accept とかをJSでできるようになるのかな
できる

> JSで標準入出力をかくだけでCGIとして動くものなのかな
node.jsの使い方としてはあまり一般的ではないが
標準入出力の機能もあるのでCGIとしても使える

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

>>475
釣れるようですよ

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

>>475
ちがうんですか？

基本ホームページ制作で
ウェブサーバー上に HTMl CSS JS のテキストファイルをおいて動かしたことしかないので
本気でわかってないです

ただウェブ制作だけだとこの先厳しいってきくので
サーバーサイドよりのフロントエンドに手出したいなと思ってて
募集案件で Vue React Node とか使えることみたいな募集けっこうみかけるので
ぢどういうものなのかなときいてみた次第です

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

>>476
お前が言っていることを3行でまとめてやろう

・jQueryは嫌いだ
・ここで質問するな、公式を見ろ。
・俺は参考になる話は何もしない

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

SPAと非SPAの共存の話をしているのになんで1ページの中に共存する話になるんだかw

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

>>477
Node はどちらかというと他のホスティングサーバーで動くものというよりは
サーバープログラム自体をJSで作るためのものなんですね

npmっていうインストーラーを使うためのライブラリか何かだとおもってました…

VueとReactはまだよくわかってないので公式よんでみます
丁寧にありがとうございました

**デフォルトの名無しさん** · 2018/11/12(月) 00:08:20.33

>>480
身も蓋もないが、実際、「公式を読め」がベストアンサーだろ。
日本語も論理も怪しい奴が一生懸命説明してくれたところで信じ切れないし、
ここで俺らがグダグダ説明するより数段ましな説明が公式にある。
○○ってなんですか系は、

・誤解をピンポイントで訂正していく

位しかここの使い道はないんだよ。
それで、ライブラリに無理に振ったようだから「釣りですか」なんて言われるわけでさ。

**デフォルトの名無しさん** · 2018/11/12(月) 01:17:07.58

「公式を読め」じゃ解答になっていない
公式のこういうところをこういうように読んで、
補足してこういう情報も見るとこの状況・段階では捗るよと教えてあげないと
ただ単に答えるの面倒くさいからって投げてるだけじゃん

**デフォルトの名無しさん** · 2018/11/12(月) 01:52:38.96

答えられないなら黙ってればいいのにな

**デフォルトの名無しさん** · 2018/11/12(月) 02:39:18.09

きちんと公式が整備されてるのは幸せだよね
と最近実感した

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

>>486
Yes、PHP！

**デフォルトの名無しさん** · 2018/11/12(月) 07:14:02.24

>>484-485
ならお前らがまず「ぼくがほしかったかいとうれい」を出して言え。
この点、jQuery厨はやってるだけましだし、やったからこそ文句を言う権利はあるが、
お前らやってないのに文句を言ってるだろ。
それがゆとりが駄目なところだ。

そして、お前らが一生懸命説明したとしても、公式を越えるのは容易ではない。
公式は、スキルがあり、お前ら以上に詳しい奴が、時間をかけて、しかも複数人数で書いてる。
沢山の人の目にも触れ、間違いや分かりにくい表現は修正されてる。
これらの意味が分からないのは、お前らが馬鹿だからだよ。

マジで、今後、公式も読めない奴はプログラマやっていけないよ。
公式も読んでない段階でここで質問するような馬鹿も、プログラマ辞めた方がいいと思うぜ。
それって、わざわざ誤解したがっているようなものだからな。

**デフォルトの名無しさん** · 2018/11/12(月) 07:32:44.63

> これらの意味が分からないのは、お前らが馬鹿だからだよ。

英語だからでしょ？

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

>>489
終わらせるなよｗ

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

約二名が批判しあっているが、身のある結論には行き着かない

**デフォルトの名無しさん** · 2018/11/12(月) 16:28:44.22

長文書いてるわりに中身がないからな

**デフォルトの名無しさん** · 2018/11/12(月) 16:34:07.15

まあ、何を言おうが現実はこれってことだよ。
終わったと言い始めて3年だからな

https://w3techs.com/technologies/overview/javascript_library/all

w3techsによると2017年1月の時点で71.9%のサイトがJavaScriptのライブラリとして
jQueryを使用していることが判明し、それ以降もシェアの増加が続いていたが、
2018年4月～2018年10月の約半年間で変化が見られず、ようやく73.3%～73.4%で
増加が停止したようである。

しかしながら、減少の傾向は見られず、マーケットシェア（JavaScriptを使用しているサイトでの使用率）
https://w3techs.com/technologies/history_overview/javascript_library は97.2%を
示していることから、jQueryからの移行が始まったと言うより、上げ止まりであると考えられる

jQuery以外では、この1年でBootstrapが2%程度、Underscoreが1%程度増加している以外は
ほとんど変動はなく、期待されていたAngularは過去最高の0.5%から0.1%減少した0.4%に、
Reactは過去最高の0.6%から0.5%と大きく減少し、0.1%に下がっていることが判明した。

またいずれのライブラリも使用していないサイトは24.5%で
2017年まで減り続けていたがこの一年ではほとんど変化はない。

この状況が大きく変化するときは来るのだろうか？この先の動向が注目される

**デフォルトの名無しさん** · 2018/11/12(月) 16:43:28.03

>>481
> SPAと非SPAの共存の話をしているのになんで1ページの中に共存する話になるんだかw

だってWordPressがjQueryを使ってる所に、
ReactやAngularで作られたプラグインのせるとか、
逆に将来WordPressがReactやAngularに乗り換えたとして、
jQueryで作られたプラグインのせるとか、共存できないと
移行なんて無理でしょ？全部いっぺんに変えられるわけがないんだから

フレームワークはサイト全体をそのフレームワークで構成するならいいが
パーツ単位で別のフレームワークで作られたもの混在や再利用がしづらいんだよ

そこで、ブラウザ標準のフレームワークとDOM APIを改良した
ライブラリであるjQueryが一番再利用性が高いということになる。

**デフォルトの名無しさん** · 2018/11/12(月) 22:38:28.19

別ページなんだから「全部いっぺんに」変える必要もないんだが、どうしてもそこが理解できないようだな。
SPAは別にReact難かに限らずjQuery使って作ることだってできるわけだが、あるページでjQueryを
使ったからといって他のページも全部jQuery使わなきゃならないわけじゃないと説明すればjQuery脳にも
理解できるかねぇ。

**デフォルトの名無しさん** · 2018/11/12(月) 23:41:28.73

>>493
それ何度も言ってるが、お前意図的に間違えてるだろ。
或いは、実はお前は英語が読めなくて、マジで勘違いしてるのか？

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

>>496
じゃあ、お前が本当はどうなのかを書くべきでは？

「お前は間違ってるー」「お前は間違ってるー」って
叫んでも、説得力無いんやで？

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

>>495
だからすでにあるWordPressの一部に何かのフレームワークで作ったものを混ぜたり
あるフレームワーク作ったものを、他のフレームワークで使ったりするってことだよ
コンポーネントっていうのは、そうやって他の人が作ったものを使うってこと。
混ぜて使えないなら、そのフレームワークで全てを構成しなきゃならない
ってか、混ぜて使えないから、そうやって言い訳してるわけなんだろうけどねｗ

**デフォルトの名無しさん** · 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

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