+ JavaScript の質問用スレッド vol.125 +

**デフォルトの名無しさん** · 2018/02/18(日) 16:48:01.14

JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。

■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
　　(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
　　具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
　　わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
　　※必ず「問題の事象が再現されること」を確認してください。
　　　必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。

前スレ
+ JavaScript の質問用スレッド vol.124 + [転載禁止](c)2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1427008785/

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

**デフォルトの名無しさん** · 2018/02/18(日) 16:49:02.27

さて、むそろそろ俺の登場かな？
この問題はねSPAだからといってパフォーマンスさげないよね？
無駄なことはしないよね？という話で解決するんだよ。

例えば、http://example.com/foo/1 とかにアクセスした時、
index.html に30x のリダイレクトしたりはしない
なぜかって？リダイレクトしたらパフォーマンス落ちるでしょ？

つまりね。PATH_INFO（でいいかな？）の情報を持った状態で
サーバーサイドアプリが呼び出されるんだよ
そこでサーバーサイド側の仕組みを使って404を返せばいい

SPAの話なのに何を言ってるのと思うかもしれないけど、
ちゃんとしたSPAっていうのはF5を押しても同じ画面が表示されるし
URLも http://example.com/foo/1 のままになるもの

SPAは/foo/1のデータをAjaxで読み込むものだと思ってるかもしれないけど、
それは他のページから辿った場合で、直接 http://example.com/foo/1 に
アクセスした場合は、JavaScriptで取ってくるそのデータを最初からHTMLに埋め込むものなんだよ。
なぜかって？ページアクセスして表示されてからデータを取りに行くとパフォーマンスさがるだろ？
だからSPAは基本Ajaxでデータを取るのは間違ってないんだけど、最初のページに限っては
最初からHTMLに埋め込んでおく。埋め込むことができるってことは、
データが見つからない時に404を返すことも容易

そして検索エンジンとかは、基本的にAjaxを使ってデータを読んだりしない。
読むことも有るかもしれないけど、Ajaxリクエスト（Content-Type: application/json）として
そのページを読み込むことはないだろう。だからいま問題にしているどうやって404を返すか？という
話は実は当てはまらない。検索エンジンは http://example.com/foo/1 を直接読み込むのだから

Ajaxによるリクエスト、つまり別ページを読み込んでからSPAの処理としてページを読み込む場合は
そのリクエストを404にすればよい。たしかにページ自体は404にはならないんだけどね。
でも検索エンジンには関係ない話

**デフォルトの名無しさん** · 2018/02/18(日) 16:49:33.38

SPAを作る時にページが存在しない場合にをどうやって404を返せばいいんでしょうか？

現状
https://support.google.com/webmasters/answer/181708?hl=ja
に示すみたいにソフト404エラーみたいになってるんですが
SPAでステータスコードを返す方法がよくわからないんです。

**デフォルトの名無しさん** · 2018/02/18(日) 16:50:02.42

質問と回答が逆になった。>>3が質問で>>2が答

**デフォルトの名無しさん** · 2018/02/18(日) 16:51:04.80

補足

「その与えられたURIだけでルータが割り振ったあとコントロールのJS内で画面と内容をレンダリング」
という処理をするためには、

1. URIからサーバーにリクエストを投げる
2. サーバーからindex.html/js相当を貰う
3. クライアントのJSでURIから画面と内容を表示するのデータを貰うためにサーバーにリクエストを投げる
4. サーバーから画面と内容を表示するためのデータを貰う
5. そのデータを使って画面と内容をレンダリングする

の3～4のサーバーへのリクエストの処理について考察できてないんでしょ？

そしてSPAでは2回サーバーにリクエストを投げるのが当たり前で解決できない問題だと思い込んじゃってる。
まともなSPAだとここを1回にする。理由は2回リクエストを投げるとパフォーマンスが落ちるから。

2回サーバーにリクエストを投げる方法だと2の時点で200が返ってきてしまい、4の時点で404を返すことになるが、
リクエストを1回にした場合は、2の段階でindex.html/js相当＋画面と内容を表示するためのデータを貰うことになるので
この時点で404を返すことができる。

**デフォルトの名無しさん** · 2018/02/18(日) 16:51:34.30

クローラーについて

今、話をしてるのはクローラーの話だって分かってない？

クローラーはクッキーやローカルストレージは使わない
https://www.suzukikenichi.com/blog/googlebot-uses-a-web-rendering-service-that-is-based-on-chrome-41/
ページレンダリング中に一時的に使ってるかもしれないが読み込み時に毎回クリアされる

クローラーっていうのは、HTMLを取得（ページをレンダリング）する処理と、URLをかき集める処理が別れている
そしてクローラーは自分が知ってるURLに対してGETリクエストを送る
だから一回もリクエストを送らないということはありえないんだよ。

クローラーはブラウザじゃない。ブラウザのように前の状態というのを持たない。
だからアプリの作りが例えサーバーと通信しない作りであっても
知ってるURLに対して初回アクセスと同じようにかならずGETリクエストを送ってくる
そしてクッキーやローカルストレージは持たない

クローラーは必ずSPAのアプリケーションの特定のURLに対して直接GETでアクセスしてきており
（アクセスしない＝最新の情報がわからないのだからクロールされてるページ内容の更新を行わない）
なおかつ初回アクセスと同じようにデータは空なのだから、状態は200か404のどちらかに決定することが可能
（まあ他にもリダイレクトとかあるだろうけどいずれにしろどれかに決定できる）

クローラーがブラウザと同じようにクライアントサイドだけでアプリを動かしているかもしれないじゃないか
とか頓珍漢なこと言うなよ？それなにもクロールしてないからｗクローラーの使命を果たしていない

**デフォルトの名無しさん** · 2018/02/18(日) 16:55:51.36

ターニングポイント

ん？もしかして>>834もそうなのかもしれないが、他のやつも
404が「サーバーから返すもの」
つまり HTTPというプロトコルを使ってクライアントから
サーバーにアクセスした時に、サーバーからクライアントへ
返すものだって分かってないのか？

404はHTTPプロトコルレベルの話なんだから、

仮にHTMLとJavaScriptだけで動くものがって
一切サーバーとアクセスしない=HTTPプロトコルを使わない場合
には、当然HTTPプロトコルレベルの話であるHTTPステータスコード404（200も）はでてこない。

これは常識だよね？
ここまではいいよね？

**デフォルトの名無しさん** · 2018/02/18(日) 22:24:06.39

すいません。404の件で質問したものですけどスレが切り替わった後でも
議論していただいていてありがとうございます。
その後facebookでもソフト404を許容していることがわかったりとか
サービスによってまちまちであることがわかったので、
他のサービスとの比較もしてみて、どうしても必要だったら
リダイレクトで404ページに飛ばすという簡易戦略で検証を進めてみます。
ありがとうございました。

**デフォルトの名無しさん** · 2018/02/19(月) 02:01:33.45

>>8
そういわれるとちょっと違うと言わざるをえないんだよね。

仕方ないんで、facebookで再現する方法を探してきたよ

まず以下のABC News（でいいのかな？）のページを開く
https://www.facebook.com/abc/

その左側の「ページ情報」と「投稿」のリンクをクリックして
ページを行き来してみると（ブラウザのURLが変わることに注意）
Ajax（xhr）での通信が行われており、これがSPAであることがわかる
（Chromeのデベロッパーツールなんかで確認してね）

（ページ上の「メールアドレスまたは電話番号」とかいう文字を適当な文字列に変えておけば
SPAから抜け出してしまった時にすぐに気付ける）

=== ここまではfacebookでSPAで動作していることの確認 ===

で、Chromeのデベロッパーツールなどで左側の「ページ情報」のリンクを以下のように書き換えてみる
<a class="_2yau" data-endpoint="/abc/about/?ref=page_internal" aria-current="page" href="/abc/about/?ref=page_internal">
↓
<a class="_2yau" data-endpoint="/abc/about/aa?ref=page_internal" aria-current="page" href="/abc/about/aa?ref=page_internal">
（「abount/」を「about/aa」に変えた）

この状態で「ページ情報」をクリックした時 URLが https://www.facebook.com/abc/about/aa になる
HTTPステータスコードは404。（もちろんSPA状態から抜け出てはいない）
abount/aaなんてページは存在しないので画面は正しく表示されない
facebookは画面が変わらないようだが、ソフト404としてエラー画面にしようと思えばできるだろう

=== ここまではSPAとしてこのURLを開いた時のHTTPステータスコードの話 ===

**デフォルトの名無しさん** · 2018/02/19(月) 02:02:45.81

じゃあ、ブラウザのURLに https://www.facebook.com/abc/about/aa を直接入力して開くと
facebookの画面がでてくるのか？というともちろんそうじゃない。

HTTPステータスコードは404だし、「このページはご利用いただけません
リンクに問題があるか、ページが削除された可能性があります。」の画面がでてくる

つまりまとめると、

https://www.facebook.com/abc/about/aa というURLで示される存在しないリソースを要求したときは404になる。
SPA状態でアクセスされているときは、内部的に404になっているとしても画面上はそれが出てこない。

最初から言っているとおりだが、SPAで404を返したいという質問が意味不明で、単にサーバーにアクセスされて
レスポンスを返す時に、そのリソースが存在しないときは404を返すだけでいいんだよ。

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

SPAだからどうしても200になってしまうっていうのは間違いで、
200になってしまうのは>>5でも書いたけど

1. URIからサーバーにリクエストを投げる
2. サーバーからindex.html/js相当を貰う
3. クライアントのJSでURIから画面と内容を表示するのデータを貰うためにサーバーにリクエストを投げる
4. サーバーから画面と内容を表示するためのデータを貰う
5. そのデータを使って画面と内容をレンダリングする

この状態になってるからだよ

SPAのためのindex.htm/jsの読み込みと（そのURLで示される）データの読み込みを
二段階に分けてしまうからそうなる

SPAでデータがない時に404を返したければ、リクエストを2回に分けるのではなく
2. と 4. の内容をまとめて1回で行うようにする。
そうすれば404が返せるし、パフォーマンスアップにもつながる

**デフォルトの名無しさん** · 2018/02/19(月) 02:23:50.84

この検証からfacebookは（調べた範囲では）ソフト404を使ってないことになるね。

クローラーはURLを直接入力したときと同じように取得するわけだから
facebookで存在しないページをクロールしてしまうことはない。
（GoogleBotはJavaScriptを実行するとかSPAだからとかいうのは全く関係ない話）

**デフォルトの名無しさん** · 2018/02/19(月) 02:46:19.97

> SPAでデータがない時に404を返したければ、リクエストを2回に分けるのではなく
> 2. と 4. の内容をまとめて1回で行うようにする。

補足 ↑言っておくけど、これはサーバーサイドでレンダリングするって話じゃない
HTMLにJSONを埋め込めばいいだけ

っていうのは前スレのこれを呼んでいればわかるはずだが

https://mevius.5ch.net/test/read.cgi/tech/1427008785/889

https://qiita.com/takeshy/items/b7e1b6bd30d12ecb02c6
> 1.データを別々にAjaxで取得
> 各CollectionやModelがRESTを使ってデータをAjaxで取得するので、
> リクエスト数が多くて遅くなる上に、ブラウザの同じサイトに対しての同時リクエスト数制限にひっかかります。

> 1.に関しては、初期画面のHTMLにAjaxで取得予定のデータを予め埋め込んでしまい、
> 初期データとして使うことで初期画面表示時のAjax呼び出しをなくしました。

https://qiita.com/takeshy/items/ba8b3ee4606993c1c5b8

> 初期表示時にサーバとの通信を極力行わない
> SPAで作成する場合、各モデルごとにサーバとデータを同期する必要がありますが、
> データを初期のHTMLにJSONデータとして埋め込んでしまうことで、Ajax通信を回避することが可能です。

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

同時リクエスト数制限の話はもうやめようぜ
HTTP2だってあるし、ブラウザもESMの導入で依存関係が1000を超えるようなケースが出てきてるので
パッケージング仕様標準化も含め最適化に乗り出してるしさ
そもそもSPAならServiceWorkerでCache使うだろうと

**デフォルトの名無しさん** · 2018/02/20(火) 21:10:35.89

案の定SSR無しとかいろんな前提を捨ててHTTPがどうの言ってたのか。
化石は化石として、現場を荒らすような真似はせずシーラカンスのように漂っててほしいな。

**デフォルトの名無しさん** · 2018/02/20(火) 23:03:06.66

だからSSR（サーバサイドレンダリング）無しの前提で話をしてますよｗ
ちゃんと書いてあるでしょ

レスだけして、反論の一つもないってどういうことだよｗ
悔しかったからレスしたが、言い返せるものは何もなかったって
言ってるようなもんだよ

**デフォルトの名無しさん** · 2018/02/21(水) 01:49:20.69

前スレ眺めてたけど明らかに勘違いをごまかしてるのはレスポンスコードにこだわってる方だろ

**デフォルトの名無しさん** · 2018/02/21(水) 02:06:56.65

ということにしたいんだねｗ

**デフォルトの名無しさん** · 2018/02/21(水) 08:22:42.51

TwitterはSPAじゃないしな。

**デフォルトの名無しさん** · 2018/02/21(水) 09:22:27.13

このスレにでてきた例はTwitterじゃなくてFacebookだけど、こっちはSPA

**デフォルトの名無しさん** · 2018/02/21(水) 11:15:18.06

とあるサービスを作っています。
chrome-extensionと連携するサービスですがその中でお金のかかるapiを使おうとしています。(例えばGoogleTranslateAPI等)
自作のchrome-extensionユーザーには
(私が自腹を切るので)無料で使ってもらおうと思っているのですが、
chrome-extension以外のユーザーからは使ってもらいたくありません。
その場合どうやって制約をかければいいでしょうか？

一応考えているのはproxyとなるapiサーバを作って
ユーザー認証を行いそこから使ってもらおうと考えているのですか
トークンはsessionStorageに配置しているのでそれを取られると
結局無断で使われてしまいます。

**デフォルトの名無しさん** · 2018/02/21(水) 12:11:20.96

https://support.google.com/cloud/answer/6310037?hl=ja

**デフォルトの名無しさん** · 2018/02/21(水) 12:40:06.03

ページと言う概念で見てるのかそうじゃないのかがまずでかいんじゃないの？

**デフォルトの名無しさん** · 2018/02/22(木) 09:48:47.81

というか、404は何がnot foundの時の
エラーなのかってことだな

**デフォルトの名無しさん** · 2018/02/22(木) 09:51:09.56

そして誰に何のために404を返すのかってことだな

**デフォルトの名無しさん** · 2018/02/25(日) 17:41:41.99

Apache24を起動すると以下のような文章が表示され、
localホストと入力してもIt Works!が出なくなってしまいました。
サクラエディタを使用してコードを書いていますが、実行結果が表示されません。
知り合いが言うにはデフォルトで表示する文書の内容替えたか、
デフォルトの文章内容いじったのでは？と言われましたが心当たりがありません。
Apache自体は動いてるようなのですが、どのようにしたらよろしいでしょうか？

AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name,
using fe80::f862:7a8d:c09a:60b8. Set the 'ServerName' directive globally to suppress this message

**デフォルトの名無しさん** · 2018/02/25(日) 19:53:49.44

なんでここで聞いたの？

**デフォルトの名無しさん** · 2018/02/26(月) 20:37:45.85

electronアプリに適したデザインガイドラインは何でしょうか？

**デフォルトの名無しさん** · 2018/02/26(月) 23:16:35.28

Array.mapの中でawait使いたかったんでcallbackをasyncにしたら処理順序が不定になってしまった。
await使いながらループ順を維持したいなら昔ながらのforを使うしかないんだろうか。

**デフォルトの名無しさん** · 2018/02/27(火) 00:05:06.34

>>29
それって処理順序が不定じゃなくて
処理終了するタイミングの違いだろ。
処理終了を順序良くしたいなら同期処理するしかないのでは？
というか非同期にする意味がない。

**デフォルトの名無しさん** · 2018/02/27(火) 00:08:03.88

>>29
あとasync-awaitでmap使うんだったらPromise.allを使ったほうがいいのでは？
Promise.allをmapっていってるとか？
参考:
https://qiita.com/m0a/items/6b3965295df92d7bb28d

**デフォルトの名無しさん** · 2018/02/27(火) 05:34:51.61

result = ary.map( v => f( v ) )
↓
result = await Promise.all( ary.map( async v = await f( v ) ) )

**デフォルトの名無しさん** · 2018/02/27(火) 05:35:42.97

誤字は誤愛嬌

**デフォルトの名無しさん** · 2018/02/27(火) 07:49:39.49

>>30
理由は書いたとおり、awaitが使いたかったから。
同期的にやりたいのは山々なんだけど、非同期な関数が混ざってるから仕方なく。
Promise.allはもちろん使ってる。そうしないとPromise[]しか返ってこないし。
やっぱりforしかないのかな。

**デフォルトの名無しさん** · 2018/02/27(火) 08:59:02.40

>>34
Promise-Iteration を使うとか
https://qiita.com/toniov/items/127267fb64a960e8166e

**デフォルトの名無しさん** · 2018/02/27(火) 09:45:08.41

１個ずつ順番に待って実行したいってことか
それならreduce使えば良いんじゃない？
ary = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
delay = v => new Promise( ok => setTimeout( ( ) => ok( v ), 100 ) )

sum = ary.reduce( ( s, n ) => s + n ) //55
↓
sum = await ary.reduce( async ( s, n ) => await s + await delay( n ) ) //55

**デフォルトの名無しさん** · 2018/02/27(火) 20:40:08.66

>>36
なるほど、reduceは思いつかなかった。
もしかしてこれ、await sを後に持ってくると順序が変わってしまったりする？
どっちにしても試してみる。ありがとう。

**デフォルトの名無しさん** · 2018/02/27(火) 20:56:23.98

for-await-ofの実装が待たれる

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

初歩的な質問ですみません

要素数の決まっている配列の中身をそれぞれ別の配列(やオブジェクト)で初期化したいとき(Ruby の Array.new(6){ Array.new } がやりたい時)、
何か簡単に書けるやり方はあるでしょうか。
これぐらいでいちいち for ループ書いてを回すのもコードが長くなってなんだかなあという感じで、今は

function arrayInit(length, cb) {
return new Array(length).fill(null).map(cb)
}

const ary = arrayInit(6, () => { return new Array })

こういう感じで処理していますが、一旦 fill で無関係な値で埋め立てないといけないのが冗長な感じがします

**デフォルトの名無しさん** · 2018/02/28(水) 11:03:03.13

最後丸括弧抜けてますね

const ary = arrayInit(6, () => { return new Array() })

**デフォルトの名無しさん** · 2018/02/28(水) 13:29:39.43

const ary = [...'.'.repeat(6)].map(_=>[]);

**デフォルトの名無しさん** · 2018/02/28(水) 13:43:58.24

const ary = Array.from(Array(6),_=>[]);

**デフォルトの名無しさん** · 2018/02/28(水) 13:44:58.59

const ary = [...Array(6)].map(_=>[]);

**デフォルトの名無しさん** · 2018/02/28(水) 14:48:53.13

今では立ち消えになったTypedObject提案にこの手の構造化の仕組みがあったから
それを真似してライブラリを作っても良いかもしれない

**デフォルトの名無しさん** · 2018/03/02(金) 02:41:28.45

今更だけどローカルストレージ便利ンゴねえ

**デフォルトの名無しさん** · 2018/03/02(金) 04:04:31.26

>>45
と言ってもいろいろあるわけで。どれのこと

**デフォルトの名無しさん** · 2018/03/02(金) 08:41:19.91

>>46
これ
https://www.granfairs.com/blog/staff/local-storage-01

**デフォルトの名無しさん** · 2018/03/02(金) 08:41:51.52

ブラウザにデータを保存するlocalStorage（ローカルストレージ）の使い方

**デフォルトの名無しさん** · 2018/03/02(金) 11:56:05.82

>>47
サイズ５MBしかないし単純のkey-value型でしょ
indexdbのほうが良い気がする。

**デフォルトの名無しさん** · 2018/03/02(金) 20:28:07.04

そんなんあるんやね

**デフォルトの名無しさん** · 2018/03/02(金) 21:29:53.20

>>49
手軽さはlocalStorageとsessionStorageのほうがはるかに上
要は適材適所

**デフォルトの名無しさん** · 2018/03/04(日) 08:29:39.81

jQueryでa要素のリンクをクリックされた時の処理を
ハンドリングするにはどうすればいいでしょうか？
キーボードで選択&エンターされる場合もあるので
onclickは適当ではないと思います

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

ここjsスレです

**デフォルトの名無しさん** · 2018/03/04(日) 09:14:20.34

>>52の件ですが
キーボードでフォーカス＆enterした場合にもclickが発火するんですね

**デフォルトの名無しさん** · 2018/03/04(日) 14:48:23.17

jQuery の質問は、web制作管理板のjQueryのスレへ

JavaScript・ブラウザ関連の質問も、web制作管理板へ書き込む方が良い

**デフォルトの名無しさん** · 2018/03/04(日) 15:09:05.19

>>54
そうだよ。jQueryの機能ではなくDOM API自体がそうなってる

**デフォルトの名無しさん** · 2018/03/06(火) 17:08:15.28

セレクトボックスのようなUI部品を表示し、
他の部分をクリックした時にそのUI部品を閉じる、
というような処理をする時は
UI表示時にclickなどのハンドラをセットして
自分以外の部分がクリックされていたら自分を消してハンドラを削除する、
というようなやり方をするのでしょうか？

**デフォルトの名無しさん** · 2018/03/06(火) 20:51:41.15

閲覧環境がクリックという概念を発生させやすいデバイスとは限らない
そのために各環境向けに調整することを許された標準要素がある
それらを再実装することは最もやってはいけないこと
標準要素に出来る限り頼って軽くスタイルをあてるだけが良い

**デフォルトの名無しさん** · 2018/03/06(火) 21:42:29.28

>>58
bootstrapは再実装してるよ

**デフォルトの名無しさん** · 2018/03/06(火) 22:32:23.80

>>57
documentレベルにハンドラ追加して
バブルアップしてきたイベントで対応

**デフォルトの名無しさん** · 2018/03/07(水) 06:13:15.60

>>59
そういうのはサポート環境決まった上で
きちんと検証してユーザーからのフィードバックもしてるからね
個人ではそれは無理

**デフォルトの名無しさん** · 2018/03/07(水) 08:42:02.75

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

**デフォルトの名無しさん** · 2018/03/07(水) 10:53:50.71

ブラウザ内座標をpx基準で(x,y)にある要素をクリックすることはできますか？

**デフォルトの名無しさん** · 2018/03/07(水) 10:58:43.99

document.elementFromPoint(x, y).click();

上は試しました。
初歩的な質問なのかもしれませんが、ブラウザ上のpixel座標と全く違う箇所をクリックしてしまいます。
どうしたらいけますでしょうか？

**デフォルトの名無しさん** · 2018/03/07(水) 11:00:34.27

>>58
セレクトボックスを再実装すべきではないということですが、
セレクトボックスは
通常CSSで実装されるドロップダウンメニューの
メインメニューが一つになったものと考えられるので、そこまで難解ではないのでは？
select要素だと項目の最大の文字数によってサイズが規定されますが
それを避けたいので、再実装しています

>>60
デレゲーションですね
考えてみればいちいちハンドラの付け外しをする必要なかったです
ありがとうございました

**デフォルトの名無しさん** · 2018/03/07(水) 18:22:22.46

>>65
例えばスマホでは画面が小さいのでselect要素が選択された時、文字が拡大表示される
これからはスマートウォッチのような超小型デバイスで見られるかもしれないし、
標準要素を使えば操作に関してもデバイスや閲覧者のハンデに応じた補正が入る
それらを全て再実装することは不可能なのですべきではないということ

もしそれっぽくデザインしてもそれが別の環境では改悪になることもある
Webっていうのは様々なデバイスで様々に見られる柔軟性が良いのであって
Flashが廃れてHTML5が栄えた理由の一つもFlashがスマホという新しい環境に適応できなかったから
だから自分の好きなデザインで固定化するという悪歴史の繰り返しは避けないといけない

それがサイトの構成上本当にどうしても必要なものであれば良い
でもデザイン上自作したほうが良いように思えるという理由ならやめとけ

**デフォルトの名無しさん** · 2018/03/07(水) 21:19:03.68

セマンティクス的な意味でもそのままの要素を使う方が望ましいのは当然ですが
そうはいかない場合もありますよね
なんとか元のタグを生かそうとしたのですが機能上不可能だったので自分で実装しました

**デフォルトの名無しさん** · 2018/03/08(木) 02:00:43.54

そこに現れたJSオフユーザー

**デフォルトの名無しさん** · 2018/03/08(木) 06:41:02.68

これ以上アドバイスしようがない
人の忠告を聞く気がないなら初めから自分で好きにやればいい

**デフォルトの名無しさん** · 2018/03/08(木) 17:54:27.13

ちょっと抽象的な質問で恐縮なのですが、ハロワの要求する経験欄に、
JavaScriptに精通している事、とあるのですが、どのレベルまで行っていれば
その条件を満たしていると考えてよいでしょうか？
具体例などを挙げて頂けると幸いです。

**デフォルトの名無しさん** · 2018/03/08(木) 19:12:11.83

電話して聞けよ。

**デフォルトの名無しさん** · 2018/03/08(木) 21:31:21.97

>>70
会社によっても違うかと。
teratailでスコアをある程度jsで取れてる？
qiitaに、記事を書いてる？

70 · 2018/03/08(木) 23:21:20.53

答えてくれた方、ありがとうございます。

>>71
検討してみます。

>>72
いえ、teratailやqiitaにはノータッチです…。

**デフォルトの名無しさん** · 2018/03/09(金) 08:07:45.79

generatorの中でawait使いたくなって混乱した。
処理を細切れにasync即時関数にするくらいしかないのかな。

yield (async () => {
})();

もうちょっと目に優しい方法があると良いが。

**デフォルトの名無しさん** · 2018/03/09(金) 20:58:40.68

もうChromeとかではasync generatorが使える

**デフォルトの名無しさん** · 2018/03/09(金) 21:56:48.81

ググってもよくわからんかったが、そのasync generatorてのを使った記述ってどんな感じなの？
あと、ESで言うとどのバージョンに含まれる仕様なんだろうか。

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

ある配列から別の配列に存在する要素を削除する
一番いい方法はどういったものですか？

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

>>77
lodashの_.differenceメソッドを使用する

https://lodash.com/docs/4.17.5#difference

_.difference([2, 1], [2, 3]);
// => [1]

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

>>78
これはいいですね
ありがとうございました

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

>>77
バニラならfilterで

var foo = [1,2,3,4,5]
var bar = [2,4,6]
foo.filter(x => !bar.includes(x))
//=> [1,3,5]

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

>>80
バーニラバニラバーニラ

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

高・収・入～！

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

>>80
いいね、今は一行で書けるんだな。
こんだけのことのためにlodash導入とかご苦労なこってｗｗｗ

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

>83
_.difference(foo, foo);
foo.filter(x => !bar.includes(x))

_ difference foo foo ・・・4ワード
foo filter x => ! bar includes x ・・・8ワード

二倍違ってるし、バニラだと
「filterでincludeしてないのを除く」ということの
意味を考えないといけない
さらにlodashは古いブラウザでも動く

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

>>84
バカが。lodashロードするのに1行必要だ。

javascriptのレベルで考えるなら数十行の追加に等しい。
以下lodashのdifference実装だが
さらにbaseDifference, baseFlatten, isArrayLikeObjectも読み込んでる。

function difference(array, ...values) {
return isArrayLikeObject(array)
? baseDifference(array, baseFlatten(values, 1, isArrayLikeObject, true))
: []
}
https://github.com/lodash/lodash/blob/master/difference.js

8ワードどころじゃ済まないなｗ
高々>>78解くのにどれだけ演算・容量コスト掛けてんだ無能。
「自分で実装したくありません。何かよいライブラリありませんか」って質問ならライブラリスレで聞けや。

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

differenceを定義しとけば3wordで済むね
l o d a s h 完　敗

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

なんか屁理屈いってんなーｗ

問題は自分の作業がどれだけ減るかだろ。テストも含めて
lodashのdifferenceはすでに十分テストされてる

それからお前のコードは配列の差集合をもとめることだけなのか？
実際に仕事してりゃもっとたくさんのことやるだろ。
それがlodash使うことで大幅に減るんだよ

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

mdnでdifference検索したけど出てきませんでした。ブラウザでもnot definedとかでてきてエラーになります。
javascriptではないのですか？
一方>>80はコンソールでそのまま実行できました！
これはjavascriptなんですね？ありがとうございます！

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

このように無知な人に下手に自力で書くように進めると
何でもかんでも自分で書くようになって
下手なコードた大量に生産されます。

初心者「こんなにたくさん書いたんだぜ時間もかかったすごいだろ！」

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

>>88
differenceはjavascriptのAPIではないよ。
外部のライブラリだから別途ロードしないといけないし、リファレンスもjavascriptのじゃなくてそのライブラリのを調べないといけない。
君のプロジェクトが他のライブラリ採用してたら全く役に立たないね。
>>80はfilterもincludesも標準javascript APIだから外部ライブラリのロードなしに使えるし、javascriptのリファレンスにも載ってるよ。

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

>>87
ここはお仕事相談所ではありません
JavaScript を自ら学ぶ人のための質問スレッドです
とにかく楽がしたい人はお呼びではありません

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

JavaScriptほど広く多くの人に使われてるスクリプト言語はないのにね

**デフォルトの名無しさん** · 2018/03/12(月) 07:23:07.30

今のjavascript系ライブラリ乱立地獄はこういう奴らのせい

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

Extensible Web的にはライブラリが乱立するのが正しい
問題はjQueryというライブラリでもフレームワークでもない
独自世界を提供する強すぎる存在がいてバランスを崩していること

まだ標準と対立することで標準側にいい影響を与えてくれるなら良いのだが
jQueryの開発者もそうだし、特にその利用者なんて全くその気がないのが問題

昔っから『JSをJavaと呼ぶ』問題があるが、それ以上に『jQueryとJSの関係性が分からない』問題が酷い
ここでも良く、便利だから、簡潔だから初学者にはとりあえずjQuery使って教えれば良いんだよ
という論調の奴が度々湧くがそれは大変危険

なぜならjQueryはWeb APIとの親和性が極めて中途半端で、水と油のように馴染めない存在だから
極論を言えば同じJSでもjQuery中心で始めるかどうかで、それぞれ別言語を習ってると言っても良い
jQueryと非jQuery派にはシナジーがほとんど無くただ食い合ってるだけっていうのが本当に深刻な問題
これからのExtensible Web精神やそれに基づいて生まれてくるだろう大量のライブラリとも強く反発する

**デフォルトの名無しさん** · 2018/03/12(月) 22:13:42.58

jQueryはライブラリだよ

https://jquery.com/
> jQuery is a fast, small, and feature-rich JavaScript library.
ここに書いてあるとおり

jQueryの成果はDOM API標準にも大きな影響を与え
セレクタによるDOM要素抽出、classList、dataset、CSSのanimationなど
jQueryを参考にしたであろうAPIがいくつか有る

またDOM APIとの互換性も考えられており、イベントに関しては
DOM APIのイベントハンドラがそのまま使える場合も有るぐらい

jQueryのEventオブジェクトはW3C standardsに準拠している
https://api.jquery.com/category/events/event-object/
> jQuery's event system normalizes the event object according to W3C standards.

たまに>>94みたいに反論してくるやつがいるが、文章をよく見てみよう。
理由、根拠が何一つ書いていないのがわかるはずだ。
俺はこのレスに理由、根拠をちゃんと書いている

**デフォルトの名無しさん** · 2018/03/12(月) 22:18:02.24

jQueryそのものは確かにあなたの言う通りExtancible Webのを阻害するものだけど、ライブラリの乱立や混沌や対立、深刻な問題を引き起こしてるのは
間違いなくgoogleやappleやfacebookやらの連中だよ
そいつらが2000年前後に無責任なhackを推し進めたことで生まれた問題だ
jQuery が原因ではない、採用した奴らが悪い

「IEが糞、IEは時代遅れ、IEは解釈を誤っている、IEは...」とか言ってブラウザ主導で機能拡張しまくった奴らも同罪

HTMLはただの「ドキュメント」だ「文章」が正しく表示されればその役割を果たしたと言える
それをHTMLを「アプリケーションプラットホーム」と勘違いしてる一部の狂信者たちがバカみたいに機能拡張しまくるからこんなことになる

**デフォルトの名無しさん** · 2018/03/12(月) 22:20:08.11

>>94
何が乱立するのが正しい、だ
くたばれ

**デフォルトの名無しさん** · 2018/03/12(月) 22:21:06.57

おいおいｗ Extensible Webでぐぐったら
上の方にこんな記事見つかったぜ

見事にjQueryがExtensible Webにいい影響を与えたって例に出てるぜ？
根拠なくjQueryが阻害してるとかいうのやめてもらおうか？

Extensible Web
https://html5experts.jp/iwase/10825/

> しかし近年、Webの開発者が先導して、ブラウザの新機能へ影響を与えるケースが
> 出てきています。例えば、querySelector や、Object.observe が具体例です。
> これらの例は、以下のフィードバックループによって生まれてきています：

> Webに本当に必要な機能を生み出すためには、上記のように、
> ユースケースに沿った実践的なフィードバックループを回すことが重要です。
>
> 既にこのプロセスはWeb標準化にも取り込まれています。例をあげると、
>
> ライブラリ例標準化された例
> jQuery querySelector
> Ember, AngularJS Object.observe
> Sass, Less CSS Variables

**デフォルトの名無しさん** · 2018/03/12(月) 22:21:48.60

> といったところが代表的でしょう。例えば、セレクタを用いたDOM操作は
> jQuery で実践的に有効性が示され、querySelectorとして標準化されました。
> これにより、jQueryのパフォーマンスは向上し、さらに Zepto.js のような
> 軽量化ライブラリが登場・・・といったWebの好循環を起こしました。

**デフォルトの名無しさん** · 2018/03/12(月) 22:28:08.51

Object.observeは無かったことリスト入りしたぞｗｗｗ

**デフォルトの名無しさん** · 2018/03/13(火) 01:09:29.98

TypeScript使うとJqueryオブジェクトとDOM APIの混乱が減ると思うからオススメ。

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

>>95,98
俺はシナジーは「ほとんど」無いと言った
逆に言うと数個はあったと認めてる
それ以上に害が大きいということ

なぜならjQueryなどを参考にした機能が標準にも入ったことで
似てるがやや違う機能というのが多くなってしまったというのも事実だから
つまり標準を補うものではなく、ただ「中途半端」に対立している別世界の存在になってしまっている

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

「Webの発展に貢献すること」と「初心者の理解を阻害すること」に因果関係はない
最も、「初心者の理解を阻害すること」については同意するが

**デフォルトの名無しさん** · 2018/03/13(火) 20:35:49.76

>>103
その２つには因果関係は無いかもしれないが、
jQueryのあり方とその２つは因果関係がある

jQueryっていうのは、つまらん標準のフォローと、それだけではなく
実装の混乱からWeb技術者を守るために生まれた
その当時の存在っていうのは大変素晴らしいものであった

大きい存在が居ることは良いことにもなり得る
実際jQueryはWebに良い影響も与えた
でも現在は大袈裟に言うとユーザーを二分してしまっている

別にjQueryが悪いんじゃない、むしろ最初覚えるのがライブラリからと
思わせてるっていうのは、標準や環境が悪いのだろうよ
でもそれを初学者に頑なに勧める回答者も悪いよ

Webっていうのは先にどんどん進んでいくものだし、先に勧めていかないといけないからね
今この瞬間この場で適当な回答ができれば良いんじゃない
教えた初学者がそのうち自分たちと共にWebを作っていくようになるんだから

IEだって見方によってはActiveXObjectだったり、いろいろ協力で素晴らしい技術を提供していた
でもそれを悪だと言わないといけないし、現状どうしても無視できない存在でも
あえて切るべきと唱え続けなければいけないときっていうのがある
jQueryも今からそういう立場になっていくってことだよ

**デフォルトの名無しさん** · 2018/03/13(火) 21:20:57.71

>>102
それであんたの言いたい害ってなに？

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

> つまり標準を補うものではなく、ただ「中途半端」に対立している別世界の存在になってしまっている
別世界でも何でもないなｗ

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

>>104を呼んでも心に響かないのは単なる根性論になってるからだよ。
そうあってほしい。でも理由はなにもない。

だから俺が理由を書いてあげよう。
AngularやReactがなぜ普及しないのか？
それはJavaScriptの世界を作ろうとしているから
残念ながらウェブのほとんどはJavaScriptを必要としない世界

そもそもHTMLが文書を書くために作られたもので、
世の中の大半は静的な文書で成り立ってる　例 Wikipedia、ブログ
もちろん一部にJavaScriptを使っているわけだが、一部なんだよ、一部。

AngularやReactなどのフレームワークはほぼ全てにJavaScriptを
導入しようとしている。そんなもん望んでないのにね。

よく知られた事実として、jQueryのシェアは伸び続けている
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/
このスレにも書いてあるが、2017年で71.9%のシェアだったjQueryは
1年後の2018年で1.4%も増えて73.2%になっている
Angularやreactなんて1%にも満たない

なぜか？それはjQueryがウェブの大部分にマッチしたライブラリだからなんだよ。
技術ができればそれが使われる。なんて考えるのは素人。使う理由がなければ使われない。
人々が求めているのは仕事が楽になる方法であって新しい技術じゃないんだよ

欲しいのは今やっていること（＝73.2%はjQuery）の延長技術であって
そうでないものは欲しいと思ってない。それが現実なんだよね。

**デフォルトの名無しさん** · 2018/03/14(水) 01:10:40.81

>>104
つまり、おまえさんの言いたいことはこういうことか？
「これから廃れる運命にあるjQueryを今更、勧めるな」
では、これから発展する仮想DOM系は初心者に進めて良いと？(そういう問題でもないと思うのだが)

てっきり、おまえさんの主張は「なぜならjQueryはWeb APIとの親和性が極めて中途半端で、水と油のように馴染めない存在だから」関係だと思ったんだがな
俺が初心者にjQueryを勧めるべきではないと思う理由は、初心者にとって、jQueryオブジェクトにラップされたコードを理解するのは困難だからだ
初心者がjQueryから学習を始めると、
・これってjQueryでどう書きますか？(明らかにESの範疇)
・～はjQueryでないと出来ないんですね(ピュアJSで出来ないと思ってる)
のように、jQueryで出来ることと出来ないことの区別が全く出来ず、見当違いの方向に理解を進める
jQueryに限った問題ではないが、jQueryはよく分からなくても書けてしまう(サンプルコードが多い)が為にそういう傾向が強い

**デフォルトの名無しさん** · 2018/03/14(水) 01:27:53.11

js質問スレでjqが喧嘩吹っ掛けるスレがあると聞いて

**デフォルトの名無しさん** · 2018/03/14(水) 01:49:28.16

jqに喧嘩ふっかけてこてんぱんにされてるっていうのが正しい

**デフォルトの名無しさん** · 2018/03/14(水) 01:50:43.59

>>108
> 見当違いの方向に理解を進める

じゃあその見当違いにならないように説明すればおしまい

**デフォルトの名無しさん** · 2018/03/14(水) 02:52:03.27

まとまりのない長文を書くやつは
コードもわかりやすく簡潔に書けない
主張は3行以内で明確に

**デフォルトの名無しさん** · 2018/03/14(水) 06:17:15.57

>>108
ちょっと言いたいことが違うかな
どちらかと言うとIEガーと言ってほしくない
それでブラウザ互換をどうこうでjQueryを「必須のように」言ってほしくない
そういう一部の仕事の実情がJavaScriptという世界の全てだと考えてほしくない
それは世界の中心かもしれないが、巨大な世界からしてみれば小さいコアでしかない

そしてやっぱり最初は「義務教育の学校」のように「綺麗事」でシンプルに教えていくべきで
血汗涙にまみれた現場で生き残っていくための「今」役に立つ「生の」実践テクニックは
初学者を卒業して応用が効くようになって、「今」実務コードが書ける用になった時「専門学校」で習うべきことだと思う

別にjQueryの質問をしてくる初心者がどうのこうのは関係がない
本当に未熟な初学者にjQueryが必須のように教えるのは良くないと言うだけ
そして実際に教えていることというよりも、そういうスタンスだということが何度も表明されているので反発してるだけ

**デフォルトの名無しさん** · 2018/03/14(水) 06:28:09.46

>>108
あとは他のフレームワークでも同じだよ
それがベースで依存するような学ばせ方をしてはいけない

でも、いつもかつもなんでもかんでも１つのフレームワークに依存するようなことなんて無いし、
ライブラリだって拡張として小さく必要のために使ってるのなら問題ないんだよ
jQueryはその常識から外れた大きすぎる存在だから特に注意ってだけ
麻薬のようなもの

**デフォルトの名無しさん** · 2018/03/14(水) 09:54:54.70

フレームワークは開発者の作ったコードを呼び出す側
だから複数のフレームワークを同時に使うことが難しい
フレームワークの導入や変更は大変な作業になる

だけどjQueryはライブラリなので、コードの一部だけ
使ったり使わなかったりできる。
仮に必要なくなったら徐々に減らすこともできるし
徐々にjQuery使うようにもできる

>>114が勘違いしているのはjQueryはウェブアプリでは
多くの場面に使えるから使用してる量が増えているだけのことを
まるでjQueryに依存してしまう（逃れられない）と思っていること

jQueryはDOM APIを混ぜても便利に使える。
その証拠が$関数を始めとしてjQueryの多くのAPIは
DOM要素を引数にすることができるし、イベントハンドラのthisもDOM要素

フレームワークは導入するのは大変な作業になるが
jQueryは使うのをやめるのも簡単なので安心して気軽に導入できる

**デフォルトの名無しさん** · 2018/03/14(水) 12:53:19.28

違う、JavaScriptのJの字しか知らないような奴に、標準DOM APIなんて使えたもんじゃない、覚える必要も無いと言うことを思わすなということ
それからよくjQueryは上手く扱えるという奴が居るが、それは経験あるお前だから、そしてJS波乱期からライブラリの発展をそれなりに体験している俺たちだから言えること

自分が言ってるのは赤ちゃんにスマホを持たせて、鉛筆で字を書かせたり本を読んだり砂場で遊んだり、何かを為すため体を使い苦労して作った経験が極めて少ない事になると
実際基本的に普段それをする必要が無いとしても、不便である素な経験がない事で困ることは出てくるし、広い意味でその子がスマホ以外の素の実世界の発展のために活躍できにくくなるということ

**デフォルトの名無しさん** · 2018/03/14(水) 20:42:10.78

>>116
> 違う、JavaScriptのJの字しか知らないような奴に、標準DOM APIなんて使えたもんじゃない、覚える必要も無いと言うことを思わすなということ

出だしから間違えてるよね？

誰が「標準DOM APIなんて使えたもんじゃない、覚える必要もない」などと言った？
俺は言ってない。じゃあ誰か？

お前だよ。何者でもないお前が「標準DOM APIなんて使えたもんじゃない、覚える必要もない」って
言ってるんだよ。

もう一つの間違いは「JavaScriptのJの字しか知らないような奴」
JavaScriptのJの字しか知らないような奴だと誰が証明した？
本人がそう名乗っているわけじゃない。他人がわかるはずがない。
つまり、これもお前なんだよ。何者でもないお前がそう言ってるんだよ。

ようするにな、お前は自分が作り出した敵と戦ってるだけだ

**デフォルトの名無しさん** · 2018/03/14(水) 21:04:00.18

それから言いたいのは他人の発言を遮るんじゃなくて自分の考えを発言しろ

他人の発言遮るっていうのはjQueryの話をするなだけじゃなくて
そいつは低レベルだから（思い込み）高度な話はするなと遮ることも含まれる

こいつは赤ちゃんだからといってレスの内容を変えるのは
傲慢な考え以外の何物でもない

自分の考えを発言しろというのは、誰かがjQueryを使った解答をしたら
それを遮るんじゃなくて、自分の考え、つまりDOM APIを使った解答をしろということ

他人の足を引っ張るな。自分の考えを発言しろ。

**デフォルトの名無しさん** · 2018/03/14(水) 21:48:29.45

今から始めるフロントの「初学者」はもうjQuery やんないんじゃないの？
なんも知らない人がググるであろう「js ライブラリ　フレームワーク」
とか検索するとjQueryやめとけ系の記事いっぱいでてくるぞ

**デフォルトの名無しさん** · 2018/03/14(水) 21:52:40.61

でもjQueryは使われてますからね。

2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/

jQueryを使わない = DOM操作をしない = DOM APIも使わない
これなら理屈にあってるんですよ。
今のフレームワークはDOM APIを使わないですからね。

**デフォルトの名無しさん** · 2018/03/14(水) 21:55:02.15

フレームワークを使う話ならもちろんフレームワークを使った回答をしますね。
でもjQueryで解決できることなら、そりゃ当然jQueryで回答しますわ

なぜjQueryで回答できるような質問ばかりなのでしょうか？
それこそが結論ですよ。JavaScriptのフレームワークはほとんど使われてない証拠です。

**デフォルトの名無しさん** · 2018/03/14(水) 23:08:25.55

アラム語のスレの質問に英語の文法では～とか答えるようなもの。どんなに英語が支配してようが関係ないだろ。アラム語のスレだというのに

**デフォルトの名無しさん** · 2018/03/14(水) 23:12:57.10

jQueryはJavaScriptのライブラリなので例えがおかしい
英語のスレで英語のスラングで答えるようなもんだから何の問題もない

**デフォルトの名無しさん** · 2018/03/14(水) 23:14:16.72

実際に質問者がjQueryの回答をみて、解决したって言ったんだから
間違った答えを言ってないことは確定なんだよ

**デフォルトの名無しさん** · 2018/03/15(木) 06:13:05.13

>>117
ここまでずっと１スレに１回は議論のなかでそういう論がでている
一部のjQueryニキの潜在意識にあるのは確実

JavaScriptのJの字しか知らないような奴でないと誰が証明した？
そうかもしれない奴にjQueryを勧誘するなということ

**デフォルトの名無しさん** · 2018/03/15(木) 06:39:18.96

>>118
勘違いしてほしくないが自分はjQueryの回答をするなというつもりはない

個々の質問への回答としてライブラリを使う例があれば勿論そのほうが良い
だが、具体的な例で言うと
誰かがライブラリ使わずに回答したらやれ互換性だのコードの短さだの主張して
ライブラリを使うべきという論争が始まるだろ
自分からすると、それこそ足を引っ張るなと言いたいね

俺たちはそういうライブラリの長所は視野が狭く誇張されたものだと思ってるし、
実際は何も使わなく書くことが無いとしても、
一般例として教え習うときはそういう「特殊な」ライブラリを使わないほうがいいと考えてるんだよ
そして「全体として」過度にライブラリを推すのは自重すべきだと感じてる

反ライブラリ派の多くは、結局そういうライブラリ使いの
短絡的なドヤ思想が嫌いなんだよ
こっちは地道に初心者を育てようとしてるんだから足を引っ張らないで欲しい

**デフォルトの名無しさん** · 2018/03/15(木) 06:49:48.66

例えるならあれだな
一生懸命近所の子供に筆算のやり方教えようとしてたら
変なおっさんが、そんな物、非効率だし不確かだから、電卓を使う法が良い
と言ったような感じを自分たちはいつも感じてる
本人に変な気がなくとも実際妨害されるし、
それによって子どもたちが筆算の必要性軽視してしまったらショックだろ？

何事も最初から楽するなと言いたい
そして何が普通か分からないうちの奴は、「騙して」でも
きついことさせて鍛えさせるんだよ
そうしないと極論育ったときに使い捨てになるだけ

自分はせっかくここであえて回答させてもらう関係になったのだから
この一瞬の経験で今後も良い影響を与えたいし、
立派な子に育って欲しいと思ってるんだよ
これはエゴだが、自分は5chのJS質問スレ2,30くらいからずっといる身として
ここは淡白なその場よければ終わりの一問一答スレになるべきではないと思ってる

**デフォルトの名無しさん** · 2018/03/15(木) 08:22:10.49

SPAも勘違いしてた彼はいつも暴走してんのか。
無駄な指摘だったな。

**デフォルトの名無しさん** · 2018/03/15(木) 15:53:53.33

>>127
また質問者を子供扱いですか？
それが傲慢だっての

**デフォルトの名無しさん** · 2018/03/15(木) 20:18:47.79

相変わらずjQuery厨は懲りないな。
とはいえ双方の言い分は分かるが、俺は ID:oazhajsT を支持する。

>>127
> 楽するな
この言い方は角が立つから「ずっとブラックボックス扱いではいけない」と言った方がいい。
中で何が行われているか理解した上で手抜きするのと、
なんだか分からないがこうすれば出来るからいい、ではその後の理解が違ってくる。
そして前者はつぶしが利くが、後者は環境（フレームワーク等）を変えたら全部覚え直しだ。
プログラマとしてやっていくつもりなら、前者でなくては話にならない。

例えて言うなら、連立方程式を逆行列の暗記で解くな、ということではないかな。
あれは「等式を並べて引いても『当然』等号は成立する」事を理解して
式変形していくことが「数学的に」重要なのであって、
「プログラミング的に」は2x2行列なら確定的に求まる逆行列で実装するが、
暗記しているだけだと、知らないと全く何も出来ないことになる。
実際、大体のBigNumは筆算をプログラムでやっているだけだし、
中身を知らないとちょっとでも外れたら対応ができなくなってしまう。

とはいえ、中学の時点では「とにかく並べて引け」であってその意味を理解しているわけではないから、
初心者にも「全て理解して挑め」ってのも無理はある。
また、現実問題、jQuery厨が言っていることも一理ある。
現実はWebの大半はドキュメントであり、アプリではない。
だから実は「jQueryのシェアはー」ってのも都合のいい誇張で、
フレームワークのシェアを問うなら、「アプリ」のところだけでjQueryの比率を見なければならない。
当然これはだだ下がりのはずだ。

**デフォルトの名無しさん** · 2018/03/15(木) 20:19:13.39

結局は、その本人がどこを目指すか、ではないかな。
デザイナならjQuery程度でもあり、というのも一理ある。
そしてこれが今のJavaScriptの酷さに繋がっており、頭に来ているというのも分かる。
プログラマとしてのJavaScripterの多くは全く成長していない。
理由はクソデザイナ/クソPHPerの下請けだから、というのが多分大きい。
元々与えられたHTMLがクソすぎてJavaScriptだけでは効率を上げられないから、
初学者のJavaScripterはそんなものだと勘違いしてしまうし、クソなコードしか書けない馬鹿も淘汰できない。
そしてクソコードが再生産され、また初学者はそれを見て学ぶ、という悪循環となっている。

俺はWeb系ではないが、全くjQueryを使ってないし、今後とも使うつもりもない。その理由は、
・jQueryは実はフレームワーク化しており、jQueryで生成したDOMはjQuery経由で消去しないとリークする。
・jQueryは「HTMLノードベース」のコードになってしまうことが最悪。
　というか、そもそもHTMLにちゃんとクラス付けされてれば、DOMのquery自体ほぼしないしjQueryのメリットはなくなる。
標準のDOMガーって言うのは、
逆に言えば、あれで十分だと判断されているからそれ以上増えないのであって、実際そう。
だから標準だけで苦労するというのなら、それはそもそもコード（というかHTML)の構造がまずいだけ。
（なおこれはlodashにも当てはまる。必要ないから標準に取り込まれないだけ。)
ただ、「クラスベースのCSSは難しい」「SPAは難しい」とされる馬鹿ばかりのJavaScriptの世界では、
この真実を言うとおそらく袋だたきにされ、そして世界は歪んだまま、ということになっているように見える。
正しいプログラミングを出来る奴が切れるのも分かる。
というか、俺も今のJavaScripterは全員死なねーかな、と思っているし。

**デフォルトの名無しさん** · 2018/03/15(木) 20:19:56.14

棲み分けをするなら、少なくともこのスレはjQuery禁止が妥当のように思える。
・プログラマとしてやっていくつもりなら、jQuery依存になるのは不味い。（使うのはかまわないにしても）
　そしてこの板はプログラム技術板だ。理解をすっ飛ばしてちゃっちゃとやりたいだけならWeb板でいい。
・今お前が使っているブラウザですら動く物が作れない奴に、各種ブラウザ対応を説く必要はない。
　というか、そいつらが独り立ちできる頃には解決されているかもしれんし、駄目ならそのときに教えればいい。
・実際、jQueryは上記のように「ちゃんとした」状況では使いどころがない。
　だからプログラマとして「ちゃんとした」JavaScriptを学ぶつもりなら、除外しろ、と言うのも分からなくもない。
　そして、実際、今後は「アプリ」のサイトでは次第に使われなくなっていくのも自明だ。使う理由がないから。
・jQueryは抽象レベルも中途半端。というかこれは使う側の問題だが、
　DOM+「ちょっと」をワンライナーであちこちに書きまくるのは実はまずい。
　それは関数として呼ばれるべき物であって。
　だから何を関数化すべきか分からない初心者にとっては標準DOMの煩雑さの方がいいコードになりやすい。
　（こういう教条的なのは俺は嫌いなのだが、初心者的に「1行ならインラインで、5行以上は関数で」とかだと、
　なまじ1行であれこれ書けるが故に悲惨なことになる。
　余談だがPHPも状況は似ていて、あれは標準自体がクソだから上達を阻害している。
Goもクソだが、Go/JavaScript/PHPしか知らない意識高いWeb系がGoに傾倒するのも分からなくもない)

**デフォルトの名無しさん** · 2018/03/15(木) 20:21:18.27

まあ、一言で言うと、「jQueryによってお手軽に実現できること自体が成長を阻んでいる」ってのも事実。
彼らはその先の、正しくクラス等を構成したときのJavaScriptの速さ、CSSのメンテのしやすさ等を知ることがない。
ただ、これを知らなくてもいい連中(=デザイナ)も大量に混ざっているのも事実。
だからデザイナはWeb板で、プログラマはこの板で、と棲み分け、方向性もそう絞ればいいと思う。

jQueryは、60点のコードをお手軽に目指す為のものであって、実はどうやっても100点のコードにはならない。
（正確に言うと、100点のコードではjQueryが活躍する場所がほとんど無い）
これを分かった上で使い捨てのコードと割り切ってjQueryを使うのはありだが、
100点のコードをそもそも書けない（書く気がない）のはプログラマとしてはまずい。

ちなみに乱立については、JavaScriptはWeb的民主主義(気に入らないならforkしろ）で行くことにしているようだから、
これは民主主義のコストでしかない。
もちろん君たちが学んだことがフレームワーク等の頓死で全部無駄になるのも、当然として受け入れるしかない。
それが嫌なら全部標準でいけ、ということになる。実際、それでも大して苦労しないし。

事実としてjQueryは役に立つから広く使われており、これがJavaScriptを牽引したのも事実だろうが、
今後役割を縮小して行くのもまた事実だろう。
必要な機能は既に標準に取り込まれた。逆に言えば残りの機能はいらないって事だ。
そしてjQueryを学んだコストが全く無駄になる日もいつか来るし、受け入れるしかないんだよ。

**デフォルトの名無しさん** · 2018/03/15(木) 21:12:53.19

↑長文で読みにくいなｗってか読まなくていいよｗ

いくら根拠のない決めつけ、思い込みで語ってもデータがなければ信頼性はゼロだしね

2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/

2018年の今は73.2%がjQueryを使ってる。未だに増え続けている。
しかも他のフレームワークよりも伸びは大きい

さて結局jQueryは使うのだから、残る問題勉強する順番なわけだがこれを読むと良いよ

挫折する学生が続出したゲーム制作、「学習の優先順位」を変えてみたら見違えるようにモチベが改善した話「ゲーム以外でも大事」
https://togetter.com/li/1202257

> 「Unityでゲーム作るならC言語から」という話題があるようですが、
> Unityを導入するのにあわせて、言語等の必須知識の学習を後回しにすることで、
> 学生のモチベが劇的に改善したらしい専門学校様のスライドがこちら。

言いたいことはこれのまんまだが、言語の勉強したいのでなければ、
つまり解决したい問題があるなら、その解決方法を提示するこそが初学者には重要
成果が見えるとモチベーションにつながる。
DOM APIを勉強するなとはいってない。jQueryの後で良いということ。

俺偉いよな。思い込みじゃなくてデータを示している。

**デフォルトの名無しさん** · 2018/03/15(木) 21:21:37.40

>>134のリンク先を読んでいて、遅延評価勉強法という造語を見つけた

ハッカーと遅延評価勉強法
http://d.hatena.ne.jp/LukeSilvia/20080402/1207149044

> 日本の（というかはてな界隈）ハッカーはほぼ「遅延評価勉強法」をしている気がします。

> ここから遅延評価勉強法とは、「その知識が必要になった時に初めて勉強する方法」です。
> もっと言えば、「○○を学んだから××をやってみる」ではなく、
> 「××をやりたいから○○を勉強する」と定義できます。

> 具体的遅延評価勉強法
> ここからは憶測ですが、遅延評価勉強法を具体的にやるとすれば、それは、「Webのソースを読む」、
> 「Webからコードを持ってきてごにょごにょいじってみる」ということになるのかなと思います。
>
> ハッカーに「良いプログラマーになるためにやることは？」と聞くと、「ソースを読む」ということが
> 必ずといって良いほどでてきます。逆に、「ソース読んでいない人はだめだ」という表現もよく言われていると思います。
>
> この「ソースを読む」とは、そもそも「これどうやって動いているんだ？」と思って
> 初めて実行するものだと思うのです。つまり、遅延評価勉強法です。

**デフォルトの名無しさん** · 2018/03/15(木) 21:22:40.03

wizのスレで延々とffの素晴らしさを説くようなもの。シンプルにスレ違いなだけだ。ffのスレがあるというのに。

**デフォルトの名無しさん** · 2018/03/15(木) 21:26:42.33

http://www.swatz.net/entry/2013/01/13/220400

> 学習効率を落とす「プロセス思考型」に陥っていないか
> 今日とある尊敬している起業家の人にグサリとささるご指摘をいただいた。
>
> 「プロセス思考型」に陥っていないか？

> 「プロセス思考型」とは
> プロセス、つまり過程であり、やり方や方法論をまず考える思考。それがプロセス思考型というらしい。
>
>
> そして、これは非常に学習効率が悪いと教えていたいただいた。

> このプロセス思考の最大の欠点は、非常にシンプルなものだった。
> 考えすぎて、行動を起こさない
>
> その通りすぎて、泣きそうになる。いやマジで。当たり前のことだが、目からウロコだった。
>
> 逆に学習効率の高いのは、これまたシンプルで、
>
> ひたすら行動を起こすこと

俺の行動にも当てはまるな。いろいろ言う前にjQueryでさっさっと答を書く（行動を起こす）
一方いろいろ言ってくるやつは、俺をどうやって追い出そうかの話ばかり考えて
行動（質問者にレスを返すこと）を起こさない

**デフォルトの名無しさん** · 2018/03/15(木) 21:27:44.57

>>136
jQueryはJavaScriptのライブラリなのでスレ違いじゃないよ

**デフォルトの名無しさん** · 2018/03/15(木) 21:49:04.26

>>138
そうは言ってもアセンブリのスレでエクセルマクロの話するやつはえんがちょやろ

**デフォルトの名無しさん** · 2018/03/15(木) 22:07:33.30

JavaScript初心者にはjQuery、DOMは中級者になってから覚えればいい
質問するような人は初心者だからjQueryで答えればいい

**デフォルトの名無しさん** · 2018/03/15(木) 22:07:54.13

>>138
実際君だけがjQuery派で、完全に四面楚歌だろ。
理由は簡単で、君以外には自明だからだよ。

jQueryは書く量を減らすことは出来るが、その程度でしかない。
HTMLが正しくクラス構成されていれば、そもそも書かずに済むんだよ。それを君は分かってない。
とはいえ、君は多分見たことがないだけだろうから、適当に探し出して試しに機能追加してみればいい。
あれ？っと思うほど簡単に機能追加できたりするから。

**デフォルトの名無しさん** · 2018/03/15(木) 22:10:19.08

>>140
jQueryで答えて欲しいのならjQueryスレで質問しろ、ってことだろ。

**デフォルトの名無しさん** · 2018/03/15(木) 22:21:57.05

>>139
> そうは言ってもアセンブリのスレでエクセルマクロの話するやつはえんがちょやろ
アセンブリのスレでアセンブリ用のライブラリはOKですね。
そういやアセンブリ用のライブラリはマクロ、通称マクロライブラリって言われてたね

**デフォルトの名無しさん** · 2018/03/15(木) 22:23:20.07

>>141
> jQueryは書く量を減らすことは出来るが、その程度でしかない。

アセンブリ言語に比べれば、高級言語なんて全部
書く量を減らすことができる程度よ。

それが重要なんだけどな。
時間が減る、すなわちコストが減るという言い方にすれば
わかりやすいと思うが

**デフォルトの名無しさん** · 2018/03/15(木) 22:40:35.07

>>144
だからそれが違うんだよ。
騙されたと思ってclassとID振りまくっているサイトのコードとか見てみろよ。

例えて言うなら、
jQuery：ゴミゴミした町でも、地図やナビがあれば問題なし
正しいHTML：いやそもそも区画整理して、地図なんか無くても迷わないようにしろ
なんだよ。

jQueryは汚い構成をごまかすのに便利だが、最初から美しく構成されてれば使いどころがないんだよ。
そしてその「美しく構成すること」に手間をかけろ、というのが正しいプログラミング道だ。
ただ、JavaScriptの問題は、上流行程のデザイナとPHPerがゴミばかりで、ゴミ処理ばっかさせられる点だ。
そしてそれが日常化しているから、問題だと気づけない。
(だからこれに関してはjQueryの責任ではないんだが…)

**デフォルトの名無しさん** · 2018/03/15(木) 22:54:11.13

>>145
何が言いたいのか分からんが、
jQueryが要らなくなるならばDOM APIも要らなくなる
HTMLが汚いなら、DOM APIを使っていても、同じHTMLなんだから汚い
jQueryの話をまったくしてないよお前

**デフォルトの名無しさん** · 2018/03/15(木) 22:55:08.98

それからjQueryが一番有効的に働くのは
綺麗なHTMLとCSSを正しく使われている場合
相性が良いんだよ。

**デフォルトの名無しさん** · 2018/03/15(木) 23:07:56.93

>>147
水掛け論だからもういいけど、俺はjQueryは今後廃れる方向だと確信している。
理由はこれまで書いたとおり。
君がそう思わないのは君の自由。
どちらが正しいかは歴史が証明してくれるし、それを待つしかない。

**デフォルトの名無しさん** · 2018/03/15(木) 23:16:46.21

>>145が「美しく構成する」とか「正しいプログラミング道」とか言ってるけど
根拠書いてないから説得力に書けるだろう？　説明できないのさ。
だから代わって俺が説明するよ。具体的にね

良いプログラミングに必要なことに「宣言型」というのがある

「ﾌﾟﾘﾝｼﾌﾟﾙｵﾌﾞﾌﾟﾛｸﾞﾗﾐﾝｸﾞ3年目までに身につけたい一生役立つ101の原理原則」の77ページ
https://books.google.co.jp/books?id=biseDAAAQBAJ&;pg=PA77&lpg=PA77

> 宣言型でプログラミング

> 命令形のプログラミングは「問題の解法」、すなわちデータ構造とアルゴリズムを記述します。
> 一方、宣言型のプログラミングは「問題の定義」、すなわち説くべき問題の性質や、
> その際にに満たすべき成約を記述します。

> フローがないと読みやすい

> 宣言型のコードは、順序や条件分岐がありません。純然たる事実が宣言的に書かれているため、
> コードが読みやすくなります。
> 一方、命令形のコードは、常に「状態」と「制御」と「データのフロー」を頭に描かないと、
> 事実を正確に理解できません。そのため、流れを追いながら読まなければならなくなります。

> 宣言型を取り入れる

> 例えば、宣言型の汎用プログラミング言語の代表的なカテゴリに、関数型言語があります。
> また、汎用言語ではありませんが、HTMLやCSS、SQLも宣言型です。

> 一方、プログラミングのパラダイムが命令形の言語を仕様スr場合でも、
> 宣言型の表現を部分的に取り入れ、宣言型の利点を享受しましょう。

**デフォルトの名無しさん** · 2018/03/15(木) 23:17:41.01

さて、なんでここで俺が宣言型の話を始めたかと言うと、
察しがいい人と、その話をされたら困る辞めてくれって思ってる人（笑）は
気づいていると思うけど、jQueryは宣言的であるということ

JavaScriptは本来命令型だが、jQueryを使うとHTMLやCSSと同じく
宣言型に書くことができるようになる。

例えばCSSで

.klass { color: red }

みたいなものはjQueryで

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

と書くことができる。似てるだろう？文法が違うだけといえる。
つまりjQueryで書くと処理が含まれずに宣言的になってる。

>>145がいう「美しく構成する」とか「正しいプログラミング道」というのは
まさにjQueryのことなんだよ。

もちろんjQueryを使ってもDOM APIの癖で命令型で書いてしまうやつがいる。
それはそいつの問題であって、そんなやつがこんな所に出てきたら
俺が矯正してあげているわけだがｗ

JavaScriptの問題点を解决している物の一つがjQueryなんだよ。

**デフォルトの名無しさん** · 2018/03/15(木) 23:18:54.67

>>148
> 水掛け論だからもういいけど、俺はjQueryは今後廃れる方向だと確信している。

あんたの確信なんかどうでもいいんだわ
データが去年からの1年間で増えているってことのほうが
よっぽど信頼性が有る

2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/

2018年の今は73.2%がjQueryを使ってる。未だに増え続けている。
しかも他のフレームワークよりも伸びは大きい

**デフォルトの名無しさん** · 2018/03/16(金) 00:05:29.96

>>149
君がそう思うのは自由なんだが、宣言型だけでは遅延描画が出来ないんだよ。
(正確に言うと、状態を持たないコードだけでは遅延描画は出来ない)
だから糞遅いコードになってしまう。
というか、当初俺は何でこんな遅いコードを何の恥じらいもなくこいつらは書くのか疑問だったんだが、
それが関数型()の洗脳の結果なんだよ。
実際、関数型()は何も成果を出せてないだろ。大騒ぎした割には、何も物にならなかった。

宣言的に書いて問題ないところは宣言的に書くべきだ。これは事実だが、
全部宣言的に書いていいわけではないんだよ。この点を関数型()の奴らは間違っている。
何事も適材適所はあるわけでね。

とはいえ、面倒だから全部ブラウザがやれ、JavaScriptは宣言型でしか書かない(ｷﾘｯ
ってのも最終的にはありだと思う。これはVirtualDOMとして動いてるんだろ。
ブラウザに内蔵されて全自動になれば俺は使うし、コードも変更するが、
それはそのときの話。まだまだ先だよ。

というかね、糞重いサイトとか大体コードが糞なわけで、
関数型()の奴らは命令型で書けないことを隠す為に「宣言的に書く」と言い訳しているだけ。
それが最適なら命令型で書くべきであってね。
動けばいいのなら何でもいいんだが、実際はそうじゃないだろ。JavaScriptはサクサク感が勝負であってさ。

そもそも○○であればいい！ってのは馬鹿であって、何事も適材適所なんだよ。
単純に宣言型にすれば見やすいとか見にくいとか、そういう話でもない。
そしてその辺を振り回して意味無い議論に終始するのがライブラリ厨が嫌われる理由だよ。
jQueryを使うことを必死で正当化しているだけだろ。
実際、ブラウザ間の差異は減ってきているし、jQueryが役に立つ局面は減る一方だ。これは事実だよ。
その上で、使った方が捗るというのなら使えばいい。
俺はメリット無いから使わないってだけ。

**デフォルトの名無しさん** · 2018/03/16(金) 00:11:47.64

> 君がそう思うのは自由なんだが、宣言型だけでは遅延描画が出来ないんだよ。

ほんと呆れたｗ

理由がさ、いきなり技術的な話
だからダメなんだよ。

ユースケース考えろ。誰が今jQueryを使っているか
そのjQueryを使っている人たちが、遅延描画できないって
騒いてるか？問題にすらしてないだろ

ほんと自分が言ってることが理由になってないのが
分かってないんだろうな。

**デフォルトの名無しさん** · 2018/03/16(金) 00:19:00.42

**デフォルトの名無しさん** · 2018/03/16(金) 00:48:27.24

>>153
> 騒いてるか？問題にすらしてないだろ
その結果、サイトがもっさりしてる。
でも技術力が無く改善できないから「問題ない」「こんな物です」と言い張っている。
勿論遅い理由はjQueryを使っていることで、だからこそjQueryを使わない事を肯定されたら困る。
それがお前が必死に抵抗している理由だろ。

jQuery使っている限り生JavaScriptの速度に勝てるはずもなく、
それ以前にjQuery厨は馬鹿だから速度チューニングもマトモに出来ない。
だから世界全体がとろいままでいてくれないと困る。

俺はそんなのにはつきあわない。サクサク感が勝負だ。
そして速いJavaScriptのコードをリリースすることによってjQueryの問題点を露呈させ、
jQueryしか使えない馬鹿共を淘汰することを目指す。

繰り返すが、問題ない部分は何やってもいいんだよ。
それこそjQueryでもフレームワークでも使えばいい。書きたいように書けばいい。
ただな、もっさり感に直結するところは速いコードが必要なんだよ。
それもしないjQeury厨はユーザを無視している。

**デフォルトの名無しさん** · 2018/03/16(金) 00:49:00.42

思うんだけど、これからjQueryは廃れていくと言うけれど
今が廃れた結果なんだと思う

backbone.jsがでた当たり、5年以上前から必要な人は
どんどん脱jQueryをした。そしてほぼ全員が移行してしまった。

今残ってる70%以上のユーザーはそもそもJavaScriptのフレームワークを必要としない人たち。
必要な人達は移行済みなんだからこれ以上jQueryの利用者は減らない。

これからじゃない。もう（移行は）終わってしまったんだよ。

**デフォルトの名無しさん** · 2018/03/16(金) 00:49:51.98

>>155
> その結果、サイトがもっさりしてる。

？ jQueryの方が軽いんやで？

Virtual DOMが速いのはウソだった。仮想DOMは遅い。
https://mevius.5ch.net/test/read.cgi/hp/1519842565/

**デフォルトの名無しさん** · 2018/03/16(金) 00:52:40.79

jQueryはフレームワークと違ってライブラリだから
遅いところだけ局所的にチューニングすることが可能

**デフォルトの名無しさん** · 2018/03/16(金) 00:56:36.18

>>156
> 今残ってる70%以上のユーザーはそもそもJavaScriptのフレームワークを必要としない人たち。
これは当たっている。
ただそれ以前に、HTMLが正しく作られていれば、生JavaScriptでも大して苦労しない。
jQueryは所詮糖衣構文を提供している程度であってね。
だから積極的に使う理由はないんだよ。

>>157
今俺は使ってない。jQueryによって速くなることもない。
てかお前もう話について来れてないな？

>>158
だからそれは駄目だと>>131で言ったろ。
jQueryを使うのなら全面jQeuryじゃないとまずいんだよ。

**デフォルトの名無しさん** · 2018/03/16(金) 00:58:33.61

> jQueryは所詮糖衣構文を提供している程度であってね。
> だから積極的に使う理由はないんだよ。

糖衣構文というのは、それが必要だと強く求められたから
使わないでできるのも限らず、採用されたんだよ。

その経緯を知ってるなら、糖衣構文だからこそ積極的に
使うべしってなるはずなんだが。

**デフォルトの名無しさん** · 2018/03/16(金) 01:00:44.98

>>159
> 今俺は使ってない。jQueryによって速くなることもない。
> てかお前もう話について来れてないな？

ついてくると言うか、お前が明後日の方向にとんでいってるのを
眺めてる状態なんだがｗ

誰も速度なんて求めてない。
わかる？

> jQueryを使うのなら全面jQeuryじゃないとまずいんだよ。
全然まずくないよ。

問題点があるならば、問題点を修正するべきだが、
問題点として考えたれてない部分のパフォーマンスを上げることに意味はない。

最初に考えるべきは、それが問題かどうか
問題かどうかを検証する前に対処するな
具体的に言うならば、50msを5msにしてくれなんて誰も思ってない

**デフォルトの名無しさん** · 2018/03/16(金) 01:02:00.48

>>160
だからそれが単なる糖衣じゃないのが問題なんだよ。
テキストベースでやってるから無駄にパースする必要があり、それも遅い理由だろ。

**デフォルトの名無しさん** · 2018/03/16(金) 01:03:34.01

>>161
なるほどお前がやっているのはその程度なのだろう。それなら問題ない。

**デフォルトの名無しさん** · 2018/03/16(金) 01:06:10.23

>>162
> テキストベースでやってるから無駄にパースする必要があり、それも遅い理由だろ。

テキストベースでなんてやってないけど？
そもそも遅くないし。

**デフォルトの名無しさん** · 2018/03/16(金) 01:06:21.04

>>161
おい、全面jQuery化が必要なのは速度ではなくリークの問題だぞ。よく読め。

**デフォルトの名無しさん** · 2018/03/16(金) 01:06:56.80

>>164
jQueryのインタフェースがテキストベースだろ。お前は何を言っているんだ？

**デフォルトの名無しさん** · 2018/03/16(金) 01:07:09.26

>>163
> なるほどお前がやっているのはその程度なのだろう。それなら問題ない。

俺だけじゃないね。世界の7割以上がその程度なんだよ。

**デフォルトの名無しさん** · 2018/03/16(金) 01:07:38.20

>>165
> おい、全面jQuery化が必要なのは速度ではなくリークの問題だぞ。よく読め。
jQuery使わなかったらリークするんだねｗ

**デフォルトの名無しさん** · 2018/03/16(金) 01:08:34.91

>>166
> jQueryのインタフェースがテキストベースだろ。お前は何を言っているんだ？

何を言ってるんだよはお前だろｗ．

document.querySelector('#foo\bar');
DOM API自体がテキストベースだろｗ

**デフォルトの名無しさん** · 2018/03/16(金) 01:11:22.52

>>168
マジで読め。

>>169
なるほどお前はjQueryもブラックボックスで中で何をやっているのか理解してないんだな。

まあいいよ、俺はこれまでもjQueryを使ってないし、今後も使うことはない。
君が使い続けるのは君の自由。
で、これ以上続ける理由無いよな？

**デフォルトの名無しさん** · 2018/03/16(金) 01:12:48.86

>>170
> なるほどお前はjQueryもブラックボックスで中で何をやっているのか理解してないんだな。

知ってるが？今はブラウザがquerySelectorAllをサポートしていれば、
それに丸投げしてる。だからjQueryのインターフェースがテキストベースって
いうのが意味不明なんだが、お前はjQueryのソースコードが見れるのに
ブラックボックスって思っちゃってるんだなｗ

**デフォルトの名無しさん** · 2018/03/16(金) 01:14:32.67

>>170
これ以上続ける理由がないというのなら
質問者にDOM API使って回答しろよｗ
俺は最初から質問者にjQueryを使って回答している

こんなくだらない話をやめるなら、
俺にかまってちゃんしてないで
俺みたく質問者に回答しろ

今度俺が質問者と話をしてる間に
よこから話しかけて来んなよ？

**デフォルトの名無しさん** · 2018/03/16(金) 01:17:27.75

>>171
だってお前コード読んでないじゃん。例えば、

>>149
> フローがないと読みやすい

> 宣言型のコードは、順序や条件分岐がありません。純然たる事実が宣言的に書かれているため、
> コードが読みやすくなります。
> 一方、命令形のコードは、常に「状態」と「制御」と「データのフロー」を頭に描かないと、
> 事実を正確に理解できません。そのため、流れを追いながら読まなければならなくなります。

これ、間違いなんだよね。というかここだけ見ると間違いではないのだけど、
実際の所、こんな局所区画で読める読めない、という話にはならないんだよ。
だからこれドヤ顔で持ってくること自体が初心者の証。
といっても君には通じないだろうけどね。

**デフォルトの名無しさん** · 2018/03/16(金) 01:18:18.82

>>172
> 今度俺が質問者と話をしてる間に
> よこから話しかけて来んなよ？
お前は誰と戦っているんだ？それは俺ではないぞ多分。

**デフォルトの名無しさん** · 2018/03/16(金) 01:19:18.81

はい、みなさん、コレですよコレ

> これ、間違いなんだよね。というかここだけ見ると間違いではないのだけど、
> 実際の所、こんな局所区画で読める読めない、という話にはならないんだよ。

間違いと言うだけで、それがどう間違いなのか理由がない。

よーくみてください。理由がまったく書いてない
反論できないはずなのに、反論した気になってる
そういうレスなのです。

生暖かく見てあげましょうｗ

**デフォルトの名無しさん** · 2018/03/16(金) 01:23:17.62

>>175
まあ俺はそういう煽って情報を出させようとする奴には情報をやらないことにしている。
というか、割と自明だから、どちらが正しいかは分かる奴には分かるし、それで十分だ。

**デフォルトの名無しさん** · 2018/03/16(金) 01:26:54.80

さっきから情報出してあげるの俺だけどなｗ
お前は情報がないんだから出さなくていい

**デフォルトの名無しさん** · 2018/03/16(金) 01:28:04.46

>>175
つうかね、多分君は数行のコードしか読んだこと無いんだよ。だからそういう発想になる。
数千行のコードを試しに読んでみろ。どこで引っかかるか分かるから。

**デフォルトの名無しさん** · 2018/03/16(金) 01:28:44.89

数千行で多いとか思ってんのか？

**デフォルトの名無しさん** · 2018/03/16(金) 01:33:31.31

>>179
jQueryみたいに数行の個別関数の固まりだと何万行あっても所詮数行の技術レベルで読めるんだよ。
そうではなく、一つのサイトのコードを読んでみろ。その場合は数千行で十分だ。
そうすれば、俺が何を言っているか分かるだろう。

俺は前から言っているが、お前にはこれが全く足りてないんだよ。
だからおかしな方向に走ってしまっている。

**デフォルトの名無しさん** · 2018/03/16(金) 01:35:37.00

> そうではなく、一つのサイトのコードを読んでみろ。その場合は数千行で十分だ。
> そうすれば、俺が何を言っているか分かるだろう。

読んだ。わからなかった。以上。お前のターン。はい答えろ
（つきあってられるか）

**デフォルトの名無しさん** · 2018/03/16(金) 01:39:01.53

>>181
じゃあ諦めろ。
というかマジで１回数千行のコード読んでみろ。色々違った物が見えるようになると思うよ。

**デフォルトの名無しさん** · 2018/03/16(金) 01:44:20.17

>>171
ちなこっちについては教えておいてやる。
(つっても俺は使ってないから確認に時間がかかった)
https://qiita.com/kazu56/items/8e92d08fd1bba0a2d771

jQueryってDOMの生成とクエリを同じインタフェースにしてるだろ。
だから先頭に<があるかどうか確認しないといけない。これで無駄に遅くなる。
(しかもタグの書き方に自由度があり、これでも無駄に遅くなる)
というかその他諸々色々被せてあったと思うが。
まあ便利ではあるんだろうけど、動作速度はその分遅くなってるよ。
傍目からみてちょっとやりすぎ。無駄が多すぎ。

**デフォルトの名無しさん** · 2018/03/16(金) 01:48:39.43

で？ 1ns遅くなるから、それがどうしたっていうの？

**デフォルトの名無しさん** · 2018/03/16(金) 01:50:36.00

速度も計測しないでパフォーマンスを語るな

**デフォルトの名無しさん** · 2018/03/16(金) 01:54:10.20

ライブラリの話はライブラリのスレでやれよ。jQueryはライブラリ。ほんと頭おかしい。

**デフォルトの名無しさん** · 2018/03/16(金) 01:56:43.28

>>184
まあ君の問題はそこだよね。自分が問題ないと信じることは問題ないと言い張るだけ。

ただjQuery厨の問題はそこではなく、既に書いたとおり、
問題になっていたとしても絶対に宣言型で糞遅いコードを書くことだね。
そしてjQueryを使ったらjQueryロックされてしまうから生で書きまくるわけにも行かんし。
結果、逃げ場がなくなるという。（対策が出来なくなる）

まあ、jQueryが嫌われているのも理由があるって事だよ。君は認めないのだろうけど。

**デフォルトの名無しさん** · 2018/03/16(金) 02:11:12.60

だからjQueryの速度で問題になってないって言ってるだろ
なんでその議論を無視して問題が有ることにしてるだか

こうやってお前の卑怯な手を俺がバラしてるから
続けても意味ないぞｗ

**デフォルトの名無しさん** · 2018/03/16(金) 02:14:16.16

jQueryは只のライブラリなので、一行ぐらいの単位で
DOM APIを使ったコードと混ぜることができる。

jQueryを使って取得したものに対して、DOM APIで処理したり
逆にDOM APIで取得したものをjQueryで処理したりできる。

**デフォルトの名無しさん** · 2018/03/16(金) 02:20:00.48

jQueryとDOM APIが混ぜて使えることの例を出そうか？

DOM APIで取得したDOM要素に対して、jQueryのcssメソッドで色をつける例

$(document.querySelectorAll('li')).css('color', 'red');

jQueryで取得したものに対して、DOM APIのstyleで色をつける例

$('li').each(function() {
　this.style.color = 'red';
});

同様にJavaScriptのmapメソッドを使って色をつける例

$('li').get().map(function(el) {
　el.style.color = 'red';
});

**デフォルトの名無しさん** · 2018/03/16(金) 02:24:42.26

DOM API と jQuery で同じイベントハンドラを共通で使える例

var btn = document.getElementById('button')
btn.addEventListener('click', handler, false);

$('#button').on('click', handler);

function handler(e) {
　alert(e.target.textContent);
}

**デフォルトの名無しさん** · 2018/03/16(金) 02:27:53.77

>>188
だからそれは問題になるときもあるんだよ。
君がやっているコードの規模ではそうならないだけで。

ああそれと、俺は君を飼い慣らしてやろうと思っている奴だから、
他の連中よりは比較的風当たりはマシなはずだぜ。
(追い出すのではなく、有効活用しようとしている）
君がコードを書いて回答すること自体は俺は評価している。
ただなあ、ちょっとピントがずれてるんだよ。
だから君をちょっと教育して、もうちょっとマシな回答が出るようにしたい。
前から思っているけど、君には明らかに「大規模コード」の経験が足りてないんだよ。
だからそれをやれと本当に何度も言っている。

君は数行のコードにフォーカスしていて、それは十分出来ている。
だけどそれがプログラミング上問題になることはないんだよ。その辺を理解できていない。
数行のコードを綺麗に書く技術と、数千行のコードを纏める技術は別物なんだよ。
君には後者の視点が全くない。だから回答がちぐはぐになっている。

だから、騙されたと思って、マジでちょっとでかいの書いてみ？多分世界が広がるから。
そしたら今の君がずいぶんトンチンカンだったことも分かるだろうし。

**デフォルトの名無しさん** · 2018/03/16(金) 02:30:26.59

>>192
> だからそれは問題になるときもあるんだよ。
> 君がやっているコードの規模ではそうならないだけで。

俺だけじゃない。世界の大部分が問題にならないっていったろ
大部分っていうのは全部じゃない。
俺と同じことを言うな。

お前が言ったことじゃない。俺が言ったことだ
大部分は問題にならないと

**デフォルトの名無しさん** · 2018/03/16(金) 02:31:33.13

>>192
> 前から思っているけど、君には明らかに「大規模コード」の経験が足りてないんだよ。
> だからそれをやれと本当に何度も言っている。

説得力がない。まず行動を起こせ
俺に経験が足りないと口先だけでごまかすことは行動じゃない
まずお前がコードを書け
大規模経験者ならではだとわかるコードをな

**デフォルトの名無しさん** · 2018/03/16(金) 02:33:06.37

>>192
> 数行のコードを綺麗に書く技術と、数千行のコードを纏める技術は別物なんだよ。
> 君には後者の視点が全くない。だから回答がちぐはぐになっている。

なんだ、大規模なコードを書いたことがないのはお前じゃないかｗ
関数一つやファイル一つで、数千行書くのは大規模なコードとは言わない
大変なだけなコードだ

大規模コードの開発者は、数行のコードの集まりで
数千行のコードを作るんだよ。

そんな事も知らないのか？

**デフォルトの名無しさん** · 2018/03/16(金) 02:36:27.96

例えばjQueryのコードだって、1万行を超えている
https://code.jquery.com/jquery-3.3.1.js

お前の定義では大規模なコードになるだろうが、
ソースコードを見てみろ
https://github.com/jquery/jquery/tree/master/src
それぞれが数十～数百程度の短いコードのファイルがたくさんある
関数一つで見れば殆どが数行から数十行だ
それらをビルドでくっつけることで1万行を超えるコードにしてるんだよ。

数行のコードと数千行のコードで書き方が違うって
それはお前が大規模なコードの経験がないだけだ

**デフォルトの名無しさん** · 2018/03/16(金) 02:44:10.09

つーか、自分が思う大規模なコードのプロジェクトの一つでもあげたら？
どれも数行のコードの集まりでできてるだろうさ

俺から大規模なコードのプロジェクトを一つだしてあげよう
JavaScriptではなくRubyだが
https://github.com/gitlabhq/gitlabhq

gitlabは大規模なコード中でもコードの品質が高いものだ
数行のコードの集まりでできてるぞ。ほとんどの関数はかなり短い

**デフォルトの名無しさん** · 2018/03/16(金) 02:59:42.90

>>196
だからそれは既に言ったが、それは初心者でも読めるコードでしかないんだよ。
それをいくら読んでも今の君以上には上達しない。

てゆうか君がどうしたいのか俺にはさっぱり分からない。
上達する気があるのなら、俺がオススメするのは「大規模コードを書くこと」であって、
それは君自身がやらなければならないことだからいくら俺を煽っても意味がない。
俺を信じないのも君の自由だ。

コードの組み方にも色々あるのだけど、ライブラリみたいに平べったいコードばかり読んでても駄目なんだ。
いや、読むこと自体は悪くはないが、同じタイプのコードを何度読んでも駄目なんだ。引き出しが増えない。
だから今の君は平べったくないコードを読まないといけないのだけど、君にはここら辺の話も通じないだろ？
まあ君が上達すれば俺が今何を言っているか分かるだろうさ。どうするかは君の自由で。

ちなみに俺はjQuery厨を追い出そうとしているのではなく、改心させようとしている。
つまり、教育することで「jQuery使えばいいってわけではないんだな」と悟らせ、
結果的にjQuery厨を除去しようとしている。どうも食いついてこないのだが。

**デフォルトの名無しさん** · 2018/03/16(金) 06:26:31.44

極論質問される度にライブラリ作って、『それは「run()」で済むよ』という回答があったとして
それは単純に考えて一番スマートな解決策とも言えるわけだけど、
こういう場で人に教えるにあたっては不味い点もあるということは分かるだろう？

**デフォルトの名無しさん** · 2018/03/16(金) 06:45:55.51

今は人の作った便利なものを使いこなす能力のほうが求められている