+ 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/09(金) 21:15:44.51

> そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、

あ、コレ言うやつよくいるよなｗ
糖衣構文"でしかない" というやつ

俺は、糖衣構文という素晴らしいものという立場だからな

なぜ他のやり方でもできることなのに、わざわざ糖衣構文があるのか？
それは、糖衣構文があれば簡潔に正確に意味と意図を表現できるから
数式と一緒

**デフォルトの名無しさん** · 2018/11/09(金) 21:19:21.42

あとPHPのはないウザい。関係ない話だろ。
自分が嫌いなものは嫌いって言って全部一緒くたにしてる証拠
客観的に物事を見れてない

**デフォルトの名無しさん** · 2018/11/09(金) 21:28:50.89

あとjQueryのはないウザい。関係ない話だろ。
言語(Javascript)とその言語で書かれたライブラリ(jQuery)一緒くたにしてる証拠
客観的に物事を見れてない

**デフォルトの名無しさん** · 2018/11/09(金) 22:20:39.53

jQueryはJavaScript用のライブラリなので関係あり

**デフォルトの名無しさん** · 2018/11/09(金) 22:33:34.25

jQueryはJavaScript用のライブラリなので、jQueryの質問はjQueryの仕様による。JavaScriptの仕様から求まるものではない。
↓の専用スレに行け。なんで行かないの？
+ JavaScript & jQuery 質問用スレッド vol.8 +
https://mevius.5ch.net/test/read.cgi/hp/1510321470/

**デフォルトの名無しさん** · 2018/11/09(金) 22:49:20.88

>>367

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

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

>>362
> 適切な構造でHTMLを書いて、それに合うようにCSSでデザインするだけの話
> 最後にCSSでもできないことがあれば、JavaScriptを使う
これが違うんだよ。

君が言っているのはHTMLベースだ。(HTMLがマスタデータ)
それだと、どうしても開発効率が上がらないんだよ。
理由は簡単で、変更の多いHTMLおよびCSSが上流に来ているから。
HTML/CSSを変更するたびにJavaScriptまで変更/検証する必要があり、ループが大きいんだよ。

CSSベースってのは、CSSクラスをまず設計して(マスタはCSSクラス)、それに対してJavaScriptを書き、
そこに合うようにHTMLを書いて、最後に再びCSSで装飾を付けるんだよ。
まともなサイトはほぼ全てこれだから、見てみればいい。

君は旧式の開発方式しか知らないんだよ。だから俺が何を言っているか理解出来ないだけ。

ただ、旧方式が一概に悪いってわけではない。
アプリや毎日更新のサイトとかだとHTMLベースはかなり無理だが、
年に一度しか更新せず、ちょろっと動きを付けるだけ、ならいけるんだよ。
デタラメなHTMLでも何とでも出来るし、開発者のスキルが比較的不必要というメリットもある。
だからそういうところはHTMLベースにこだわり続けるだろう。今の君のように。
とはいえ、それは馬鹿にされるだろうなあ、ってだけの話で。（現時点でもそういう奴が散見されるだろ）

まあとにかく、君がjQueryを使い続けるのは君の自由だし、
jQueryが死ぬかどうかは待ってれば結果は出るんだし、それでいいだろ。
君の予想は「jQueryは永遠に不滅です」で、
俺の予想は「jQueryは次第に（10年かけて）衰退する」だね。

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

> 君が言っているのはHTMLベースだ。(HTMLがマスタデータ)
> それだと、どうしても開発効率が上がらないんだよ。

？？？

え、なんで？

例えばHTMLに「こんにちは」って書く場合
HTML以外の何を使ったら、どう開発効率が上がるんだ？

もう少し、○○という理由で、開発効率が上がるって書いてくんない？
根拠が待った書いてないからさ

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

> 理由は簡単で、変更の多いHTMLおよびCSSが上流に来ているから。
> HTML/CSSを変更するたびにJavaScriptまで変更/検証する必要があり、ループが大きいんだよ。

おまえ、下手なんじゃね？

JavaScriptはHTMLの変更に影響をつけないように作れよ

ほんと、下手

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

訂正　影響をうけないように作れよ

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

HTMLは文章は変わるが、HTMLの構造は一旦決めたら変わらないんだぜ

トップページ、一覧ページ、詳細ページ
これぐらいの区別があるだけ、ページごとにHTMLの
構造が変わっていたら、見づらいだろ

そしてJavaScriptは、特定のクラスに対して処理しますって書くだけ
ウェブデザイナさんに、こういうクラスつけておいてくださいね。
そのクラスつけておいたところは、こうなりますから～って伝えるだけ

クラス設計？そんな大げさなものじゃない。
１つ（ないし数個）クラスを作って伝えるだけ

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

> CSSベースってのは、CSSクラスをまず設計して(マスタはCSSクラス)、それに対してJavaScriptを書き、
> そこに合うようにHTMLを書いて、最後に再びCSSで装飾を付けるんだよ。
> まともなサイトはほぼ全てこれだから、見てみればいい。

つまりCSSクラスを最初に設計して、JavaScriptを書くから、
jQueryが適してるって話にしかなってないんだが？

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

jQueryとCSSは非常に相性がいい。

.foo { color: red }
$('.foo').css({ color: 'red' })

書き方が違う程度で非常に近い書き方ができる。
セレクタに対して何かを適用するという考え、
セレクタベースだからだ

querySelectorAllだとこうは書けない。
単にセレクタで検索するだけだから、
その後ループして処理するという発想になる

CSSベースの開発ではjQueryを使うのが相性がいいし
そこがDOM APIでは越えられない壁。

あとどうも俺をHTMLベースとか言ってるようだが、
HTMLベースとCSSベースを分けて考えるなら、
俺はCSSベースだなｗ

繰り返すがCSSベースはjQueryと非常に相性がいい

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

>>329を見ればわかるが

> 世界の大半を占めるウェブサイトは
> 「まず最初にHTML+CSSを書く」ということを
> しっかりと認識するようにな

最初に書くのは「HTML+CSS」だ
俺はHTMLを書いて、それに対してjQueryで処理しろとかいう話はしてない
何故か勝手に俺がHTMLベースだと決めつけられたｗ

jQueryはCSSベースになるし、CSSベースはjQueryと相性がいい

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

まあ、君は、他のサイトをよく見て学べばいいと思うよ。多分それで解決する。
今のままなら、「jQueryおじさん」だな。

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

バカかなこいつ。jsで書かれたライブラリなんだからjsでできることをまとめた関数以上でも以下でもない。
jQuery内部ではquerySelectorを使える環境ではquerySelectorを使うようになっている。
わざわざSizzleというセレクタライブラリを内包しているのになぜ？
それは遅いからｗｗｗｗｗ

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

自分が依存してるホスト言語様にケンカ売るとかｗｗｗ何様のつもりだよ替えのきくライブラリのクセにｗｗｗｗ

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

>>378

> わざわざSizzleというセレクタライブラリを内包しているのになぜ？

1. 昔はブラウザにquerySelectorが搭載されていなかった
2. ブラウザ間で対応しているセレクタの違いに対応するため
3: :has擬似クラスのような今のブラウザ使えないが、標準化される見通しのセレクタに対応している
4. :inputセレクタのようなjQueryによって拡張された便利なセレクタが使える
5. セレクタの拡張機能を使って独自のセレクタを作成可能
6. 特定ブラウザのセレクタバグの回避

こんなところかな

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

>>378
> jsでできることをまとめた関数以上でも以下でもない。

焦点は同じことをいかに楽にできるかどうかだよ

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

>>377
> まあ、君は、他のサイトをよく見て学べばいいと思うよ。多分それで解決する。

どのサイトでもjQueryが使われてる
それを見てよく学んだｗ

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

JQueryはWeb業界のCOBOLとして残るやろ
どんなに新しくて思想が素晴らし技術でもも土方が使いこなして
コピペ量産できるレベルじゃないのと流行らず終わってしまう

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

COBOLとの違いはDOMよりも優れているってことかな

jQueryはDOM APIと違ってCSSベースだからね

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

>>383
COBOLは神格化しすぎだろw

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

jqueryはEventEmitter的なやつが入ってるも便利なんだよなあ

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

ブラウザ非互換の対応をしようとすると結局ライブラリ作る羽目になるんじゃないの。
おれも極力素のJSで軽量に済ませるようにしてるけど、やっぱそういう下らない作業からは解放されたいな。

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

.ready()みたいなやつを自分で書くのが地味に面倒

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

自分とこはもう全部type=moduleでやってて
どうしても必要なとこではnomodule使うけど
基本的にIEとかではJS働かせてないな
もう確認もしてないし
あとはCanvasを積極的に使うのが互換性対処の肝かな
そうすればあってもちょっとした条件分岐くらいで
ライブラリ規模のをつくることはまず無くなる

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

とまあ、ウェブサイトではまず使わないCanvasとか言ってる時点で
ウェブでは例外にあたるサイトの話なわけでｗ
どうせゲームだろうな

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

>>383
COBOLは基幹システムに入っているから、更新間隔が標準で10年、実情は10-20年だからだよ。
Webの場合はもっと更新されるから、世代交代は早いよ。

>>384
だからお前はHTMLベースだし、大半のjQuery使用者もHTMLベースなんだよ。
HTMLに対して何かをする、という書き方でしかやってないだろ。
とにかくお前は他サイトを見て学べ。お前とは違うclassの使い方をしてるから。

そりゃjQueryを使っているサイトを見れば、当然お前と同じ程度の奴が同じ事をやってるだろう。
ただ、そんなの見ても意味無いだろ。
脱jQueryをやったサイトを確認して、(最近ならGitubか？）
何故彼等はそういう判断をしたのか、結果、どう変わったのか、
或いはそもそもjQuery使ってないサイトを見て、
お前にとって不可欠なjQueryをどうして彼等は使わないで出来るのか、それを見ないと。
その上で、自分がどうするかを判断する話であって。

お前はjQueryを使っている人がいる限りjQueryに引きこもるタイプだろうよ。(ラガード)
そういうのも一定数居るし、それが悪いことでもないが、
布教ってのは通常は新しい方向に対して行うべき物であって、
「旧来のままでいろ」ってのは普通はデフォだから必要ないんだよ。
布教に対するカウンターだってのは一理あるが、
現実として、でかいところも脱jQueryしてるんだから、脱jQuery派にも一定の妥当性はある。
そこは認めないと。

https://marketingis.jp/wiki/イノベーター理論
現実は、イノベーター共は最初からjQueryを使ってないから、
アーリーアダプターが脱jQueryを初めて、まだキャズムを越えてないから大騒ぎしてる、ってとこか？

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

ゲームだけでは無いよ
vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
まあそれがjQueryの代わりっちゃ代わりのようなもんか
イベントバブリングやアニメーションも対応してるし、
操作対象をDOMにしたり、混合させて利用する事もできる
普通じゃないって言うけど、HTML5以降Webって言うのは
アプリケーションプラットフォームになったという認識で作ってる

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

>>391
> だからお前はHTMLベースだし、大半のjQuery使用者もHTMLベースなんだよ。

CSSベースだってｗ
jQueryがCSSと相性がいいのわかってるだろ？

それにDOM APIはHTMLベースってことになるのわかっていってるのか？

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

>>391
> 脱jQueryをやったサイトを確認して、(最近ならGitubか？）
> 何故彼等はそういう判断をしたのか、結果、どう変わったのか、

どう変わったのか言ってみ？
俺、変わった所、全然わからない。

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

>>392

> アプリケーションプラットフォームになったという認識で作ってる

アプリケーションプラットフォームとしても使えるようになったからって
俺もアプリ作るぞーってなると思う？ｗ

上の方でも言ったけど、ウェブがアプリケーションプラットフォームとなって
変わるのは、ウェブサイトじゃない。

デスクトップや家庭用ゲーム機やスマホアプリの世界から
人が去っていくことになるだけだよ。変わるのはそこ

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

ウェブサイトは今のままウェブサイト
ウェブサイトがアプリになるわけがない

だからWebAssemblyとか、jQueryの代替じゃないんだよ。
jQueryをやめて使うものじゃない。

WebAssemblyとかは.NET FrameworkやDirectXや
OpenGLやUnityをやめて使うものなんだよ

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

>>393
その意図的な誤用は止めろ。
「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。

HTMLベース：HTMLがマスタ
CSSベース：CSSクラスがマスタ

> それにDOM APIはHTMLベースってことになるのわかっていってるのか？
そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。

とにかくお前は他人がどういう作りにしているか、学んだ方がいいと思うぞ。

>>394
GitHubについてはスゲー変わったけどな。
分からないのなら、それでいいと思うよ。

ただ、変わった原因はjQueryでもないとも思うが。
GitHubは元々がポンコツすぎた。

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

いい加減誰が何主張してるのか追う気も無くなってきたけど、結局どうしろと言ってるの。
自分の書いたサイトのURL貼って説明してみてよ。

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

> 「CSSベース」ってのがどうも気に入って自分の側に取り込みたいようだが、jQueryはそうじゃない。

そうじゃない理由をいうかと言えば、何も言えないｗｗｗ

> GitHubについてはスゲー変わったけどな。

変わった点を言うかと思えば何も言わないｗｗｗ

ホント説得力皆無やでｗ

> そうだ。だから、CSSベースならクエリ自体やらないんだよ。これも前から言ってるだろ。
jQueryはセレクタを書くだけでクエリはやりませんねｗ

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

>>392
> vDom的にJSOMベースでレイアウト記述するフレームワークを持ってる
これだよね。
フレームワークが流行らない一つの原因は、自前で用意しても出来てしまうこと。

> アプリケーションプラットフォームになったという認識で作ってる
プログラマはその認識で正しいと思うぜ。

ある意味、ドキュメントも、
・マークダウン等でHTMLを直接記述（少なくともHTML生成までは面倒を見る）…旧来手法
・テキストだけ書いて、ドキュメントアプリに流し込めばWebページ完成…アプリ的手法
があって、後者はブログなり静的HPフレームワークになるわけだが、
記事書きたい奴はhtmlを書きたいわけではないから、自然と後者によってくると俺は見ている。
とはいえ、そういう時代になっても、
とりあえず1回書けばいいだけなら、HTMLじか打ちの方が楽だし、旧来手法もある程度は残るだろうね。

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

jQueryはCSSベースなのでCSSと相性がいい。

例えば、jQueryでCSSと同じように色を付ける場合、
CSSで書いたのと同じように "セレクタ" に "色を指定" する
まあCSSの範囲はCSSでやればいいんだが、

jQueryはデザインじゃなくて、イベントに関しても
CSSと似たような形で、 "セレクタ" に "イベントをバインド" する

CSSは要素がなくてもエラーにならないが、jQueryも同じように
要素がなくてもエラーにならない。CSSと非常によく似ている。

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

HTMLベースとかCSSベースってのもどういった概念を指してるのかわからないけど、セレクタで抽出したエレメントを操作するのがHTMLベースで、CSSクラスの定義を操作するのがCSSベースってこと？

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

アプリケーション開発のプラットフォームは
jQueryの代替にはなりえない。

重要な点の一つだね。

みんながみんなアプリケーションを開発しているわけじゃない
ウェブの殆どはサイト

みんなが見てるのは、ウェブサイト

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

>>402
jQueryはCSSでも使われるセレクタに対して処理を適用する

だから最初にCSSのクラス設計を行う必要がある。

だからCSSベースらしいｗ

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

>>399
jQueryおじさんは、違いの分からない男であったか…
（もっとも、このスレにはこれが分かるおっさんの方が少数派の気もするが)

つか、あれで分からないのなら、感度がないんだよ。
こちらの環境では、遅いわ固まるわ落ちるわでまともに使えなかったからね。

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

>>405
いや、お前がやるべきはぐちじゃなくて
俺が言っていることへの指摘だろう？

結局何も言えない。

githubもjQueryやめた効果を何も書いていないｗ

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