+ 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(土) 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

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

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

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