+ JavaScript の質問用スレッド vol.125 +
■ このスレッドは過去ログ倉庫に格納されています
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です） さて、むそろそろ俺の登場かな？
この問題はね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にはならないんだけどね。
でも検索エンジンには関係ない話 SPAを作る時にページが存在しない場合にをどうやって404を返せばいいんでしょうか？
現状
https://support.google.com/webmasters/answer/181708?hl=ja
に示すみたいにソフト404エラーみたいになってるんですが
SPAでステータスコードを返す方法がよくわからないんです。 補足
「その与えられた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を返すことができる。 クローラーについて
今、話をしてるのはクローラーの話だって分かってない？
クローラーはクッキーやローカルストレージは使わない
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のどちらかに決定することが可能
（まあ他にもリダイレクトとかあるだろうけどいずれにしろどれかに決定できる）
クローラーがブラウザと同じようにクライアントサイドだけでアプリを動かしているかもしれないじゃないか
とか頓珍漢なこと言うなよ？ それなにもクロールしてないからｗ クローラーの使命を果たしていない ターニングポイント
ん？ もしかして>>834もそうなのかもしれないが、他のやつも
404が「サーバーから返すもの」
つまり HTTPというプロトコルを使ってクライアントから
サーバーにアクセスした時に、サーバーからクライアントへ
返すものだって分かってないのか？
404はHTTPプロトコルレベルの話なんだから、
仮にHTMLとJavaScriptだけで動くものがって
一切サーバーとアクセスしない=HTTPプロトコルを使わない場合
には、当然HTTPプロトコルレベルの話であるHTTPステータスコード404（200も）はでてこない。
これは常識だよね？
ここまではいいよね？ すいません。404の件で質問したものですけどスレが切り替わった後でも
議論していただいていてありがとうございます。
その後facebookでもソフト404を許容していることがわかったりとか
サービスによってまちまちであることがわかったので、
他のサービスとの比較もしてみて、どうしても必要だったら
リダイレクトで404ページに飛ばすという簡易戦略で検証を進めてみます。
ありがとうございました。 >>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ステータスコードの話 === じゃあ、ブラウザの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を返すだけでいいんだよ。 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が返せるし、パフォーマンスアップにもつながる この検証からfacebookは（調べた範囲では）ソフト404を使ってないことになるね。
クローラーはURLを直接入力したときと同じように取得するわけだから
facebookで存在しないページをクロールしてしまうことはない。
（GoogleBotはJavaScriptを実行するとかSPAだからとかいうのは全く関係ない話） > 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通信を回避することが可能です。 同時リクエスト数制限の話はもうやめようぜ
HTTP2だってあるし、ブラウザもESMの導入で依存関係が1000を超えるようなケースが出てきてるので
パッケージング仕様標準化も含め最適化に乗り出してるしさ
そもそもSPAならServiceWorkerでCache使うだろうと 案の定SSR無しとかいろんな前提を捨ててHTTPがどうの言ってたのか。
化石は化石として、現場を荒らすような真似はせずシーラカンスのように漂っててほしいな。 だからSSR（サーバサイドレンダリング）無しの前提で話をしてますよｗ
ちゃんと書いてあるでしょ
レスだけして、反論の一つもないってどういうことだよｗ
悔しかったからレスしたが、言い返せるものは何もなかったって
言ってるようなもんだよ 前スレ眺めてたけど明らかに勘違いをごまかしてるのはレスポンスコードにこだわってる方だろ このスレにでてきた例はTwitterじゃなくてFacebookだけど、こっちはSPA とあるサービスを作っています。
chrome-extensionと連携するサービスですがその中でお金のかかるapiを使おうとしています。(例えばGoogleTranslateAPI等)
自作のchrome-extensionユーザーには
(私が自腹を切るので)無料で使ってもらおうと思っているのですが、
chrome-extension以外のユーザーからは使ってもらいたくありません。
その場合どうやって制約をかければいいでしょうか？
一応考えているのはproxyとなるapiサーバを作って
ユーザー認証を行いそこから使ってもらおうと考えているのですか
トークンはsessionStorageに配置しているのでそれを取られると
結局無断で使われてしまいます。 ページと言う概念で見てるのかそうじゃないのかがまずでかいんじゃないの？ というか、404は何がnot foundの時の
エラーなのかってことだな 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 electronアプリに適したデザインガイドラインは何でしょうか？ Array.mapの中でawait使いたかったんでcallbackをasyncにしたら処理順序が不定になってしまった。
await使いながらループ順を維持したいなら昔ながらのforを使うしかないんだろうか。 >>29
それって処理順序が不定じゃなくて
処理終了するタイミングの違いだろ。
処理終了を順序良くしたいなら同期処理するしかないのでは？
というか非同期にする意味がない。 >>29
あとasync-awaitでmap使うんだったらPromise.allを使ったほうがいいのでは？
Promise.allをmapっていってるとか？
参考:
https://qiita.com/m0a/items/6b3965295df92d7bb28d result = ary.map( v => f( v ) )
↓
result = await Promise.all( ary.map( async v = await f( v ) ) ) >>30
理由は書いたとおり、awaitが使いたかったから。
同期的にやりたいのは山々なんだけど、非同期な関数が混ざってるから仕方なく。
Promise.allはもちろん使ってる。そうしないとPromise[]しか返ってこないし。
やっぱりforしかないのかな。 １個ずつ順番に待って実行したいってことか
それなら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 >>36
なるほど、reduceは思いつかなかった。
もしかしてこれ、await sを後に持ってくると順序が変わってしまったりする？
どっちにしても試してみる。ありがとう。 初歩的な質問ですみません
要素数の決まっている配列の中身をそれぞれ別の配列(やオブジェクト)で初期化したいとき(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 で無関係な値で埋め立てないといけないのが冗長な感じがします 最後丸括弧抜けてますね
const ary = arrayInit(6, () => { return new Array() }) const ary = [...'.'.repeat(6)].map(_=>[]); const ary = Array.from(Array(6),_=>[]); const ary = [...Array(6)].map(_=>[]); 今では立ち消えになったTypedObject提案にこの手の構造化の仕組みがあったから
それを真似してライブラリを作っても良いかもしれない >>45
と言ってもいろいろあるわけで。どれのこと ブラウザにデータを保存するlocalStorage（ローカルストレージ）の使い方 >>47
サイズ５MBしかないし単純のkey-value型でしょ
indexdbのほうが良い気がする。 >>49
手軽さはlocalStorageとsessionStorageのほうがはるかに上
要は適材適所 jQueryでa要素のリンクをクリックされた時の処理を
ハンドリングするにはどうすればいいでしょうか？
キーボードで選択&エンターされる場合もあるので
onclickは適当ではないと思います >>52の件ですが
キーボードでフォーカス＆enterした場合にもclickが発火するんですね jQuery の質問は、web制作管理板のjQueryのスレへ
JavaScript・ブラウザ関連の質問も、web制作管理板へ書き込む方が良い >>54
そうだよ。jQueryの機能ではなくDOM API自体がそうなってる セレクトボックスのようなUI部品を表示し、
他の部分をクリックした時にそのUI部品を閉じる、
というような処理をする時は
UI表示時にclickなどのハンドラをセットして
自分以外の部分がクリックされていたら自分を消してハンドラを削除する、
というようなやり方をするのでしょうか？ 閲覧環境がクリックという概念を発生させやすいデバイスとは限らない
そのために各環境向けに調整することを許された標準要素がある
それらを再実装することは最もやってはいけないこと
標準要素に出来る限り頼って軽くスタイルをあてるだけが良い >>57
documentレベルにハンドラ追加して
バブルアップしてきたイベントで対応 >>59
そういうのはサポート環境決まった上で
きちんと検証してユーザーからのフィードバックもしてるからね
個人ではそれは無理 > （ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです）
多数の意見？ ブラウザ内座標をpx基準で(x,y)にある要素をクリックすることはできますか？ document.elementFromPoint(x, y).click();
上は試しました。
初歩的な質問なのかもしれませんが、ブラウザ上のpixel座標と全く違う箇所をクリックしてしまいます。
どうしたらいけますでしょうか？ >>58
セレクトボックスを再実装すべきではないということですが、
セレクトボックスは
通常CSSで実装されるドロップダウンメニューの
メインメニューが一つになったものと考えられるので、そこまで難解ではないのでは？
select要素だと項目の最大の文字数によってサイズが規定されますが
それを避けたいので、再実装しています
>>60
デレゲーションですね
考えてみればいちいちハンドラの付け外しをする必要なかったです
ありがとうございました >>65
例えばスマホでは画面が小さいのでselect要素が選択された時、文字が拡大表示される
これからはスマートウォッチのような超小型デバイスで見られるかもしれないし、
標準要素を使えば操作に関してもデバイスや閲覧者のハンデに応じた補正が入る
それらを全て再実装することは不可能なのですべきではないということ
もしそれっぽくデザインしてもそれが別の環境では改悪になることもある
Webっていうのは様々なデバイスで様々に見られる柔軟性が良いのであって
Flashが廃れてHTML5が栄えた理由の一つもFlashがスマホという新しい環境に適応できなかったから
だから自分の好きなデザインで固定化するという悪歴史の繰り返しは避けないといけない
それがサイトの構成上本当にどうしても必要なものであれば良い
でもデザイン上自作したほうが良いように思えるという理由ならやめとけ セマンティクス的な意味でもそのままの要素を使う方が望ましいのは当然ですが
そうはいかない場合もありますよね
なんとか元のタグを生かそうとしたのですが機能上不可能だったので自分で実装しました これ以上アドバイスしようがない
人の忠告を聞く気がないなら初めから自分で好きにやればいい ちょっと抽象的な質問で恐縮なのですが、ハロワの要求する経験欄に、
JavaScriptに精通している事、とあるのですが、どのレベルまで行っていれば
その条件を満たしていると考えてよいでしょうか？
具体例などを挙げて頂けると幸いです。 >>70
会社によっても違うかと。
teratailでスコアをある程度jsで取れてる？
qiitaに、記事を書いてる？ 答えてくれた方、ありがとうございます。
>>71
検討してみます。
>>72
いえ、teratailやqiitaにはノータッチです…。 generatorの中でawait使いたくなって混乱した。
処理を細切れにasync即時関数にするくらいしかないのかな。
yield (async () => {
})();
もうちょっと目に優しい方法があると良いが。 もうChromeとかではasync generatorが使える ググってもよくわからんかったが、そのasync generatorてのを使った記述ってどんな感じなの？
あと、ESで言うとどのバージョンに含まれる仕様なんだろうか。 ある配列から別の配列に存在する要素を削除する
一番いい方法はどういったものですか？ >>77
lodashの_.differenceメソッドを使用する
https://lodash.com/docs/4.17.5#difference
_.difference([2, 1], [2, 3]);
// => [1] >>78
これはいいですね
ありがとうございました >>77
バニラならfilterで
var foo = [1,2,3,4,5]
var bar = [2,4,6]
foo.filter(x => !bar.includes(x))
//=> [1,3,5] >>80
いいね、今は一行で書けるんだな。
こんだけのことのためにlodash導入とかご苦労なこってｗｗｗ >83
_.difference(foo, foo);
foo.filter(x => !bar.includes(x))
_ difference foo foo ・・・4ワード
foo filter x => ! bar includes x ・・・8ワード
二倍違ってるし、バニラだと
「filterでincludeしてないのを除く」ということの
意味を考えないといけない
さらにlodashは古いブラウザでも動く >>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解くのにどれだけ演算・容量コスト掛けてんだ無能。
「自分で実装したくありません。何かよいライブラリありませんか」って質問ならライブラリスレで聞けや。 differenceを定義しとけば3wordで済むね
l o d a s h 完 敗 なんか屁理屈いってんなーｗ
問題は自分の作業がどれだけ減るかだろ。テストも含めて
lodashのdifferenceはすでに十分テストされてる
それからお前のコードは配列の差集合をもとめることだけなのか？
実際に仕事してりゃもっとたくさんのことやるだろ。
それがlodash使うことで大幅に減るんだよ mdnでdifference検索したけど出てきませんでした。ブラウザでもnot definedとかでてきてエラーになります。
javascriptではないのですか？
一方>>80はコンソールでそのまま実行できました！
これはjavascriptなんですね？ありがとうございます！ このように無知な人に下手に自力で書くように進めると
何でもかんでも自分で書くようになって
下手なコードた大量に生産されます。
初心者「こんなにたくさん書いたんだぜ時間もかかったすごいだろ！」 >>88
differenceはjavascriptのAPIではないよ。
外部のライブラリだから別途ロードしないといけないし、リファレンスもjavascriptのじゃなくてそのライブラリのを調べないといけない。
君のプロジェクトが他のライブラリ採用してたら全く役に立たないね。
>>80はfilterもincludesも標準javascript APIだから外部ライブラリのロードなしに使えるし、javascriptのリファレンスにも載ってるよ。 >>87
ここはお仕事相談所ではありません
JavaScript を自ら学ぶ人のための質問スレッドです
とにかく楽がしたい人はお呼びではありません JavaScriptほど広く多くの人に使われてるスクリプト言語はないのにね 今のjavascript系ライブラリ乱立地獄はこういう奴らのせい Extensible Web的にはライブラリが乱立するのが正しい
問題はjQueryというライブラリでもフレームワークでもない
独自世界を提供する強すぎる存在がいてバランスを崩していること
まだ標準と対立することで標準側にいい影響を与えてくれるなら良いのだが
jQueryの開発者もそうだし、特にその利用者なんて全くその気がないのが問題
昔っから『JSをJavaと呼ぶ』問題があるが、それ以上に『jQueryとJSの関係性が分からない』問題が酷い
ここでも良く、便利だから、簡潔だから初学者にはとりあえずjQuery使って教えれば良いんだよ
という論調の奴が度々湧くがそれは大変危険
なぜならjQueryはWeb APIとの親和性が極めて中途半端で、水と油のように馴染めない存在だから
極論を言えば同じJSでもjQuery中心で始めるかどうかで、それぞれ別言語を習ってると言っても良い
jQueryと非jQuery派にはシナジーがほとんど無くただ食い合ってるだけっていうのが本当に深刻な問題
これからのExtensible Web精神やそれに基づいて生まれてくるだろう大量のライブラリとも強く反発する 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みたいに反論してくるやつがいるが、文章をよく見てみよう。
理由、根拠が何一つ書いていないのがわかるはずだ。
俺はこのレスに理由、根拠をちゃんと書いている jQueryそのものは確かにあなたの言う通りExtancible Webのを阻害するものだけど、ライブラリの乱立や混沌や対立、深刻な問題を引き起こしてるのは
間違いなくgoogleやappleやfacebookやらの連中だよ
そいつらが2000年前後に無責任なhackを推し進めたことで生まれた問題だ
jQuery が原因ではない、採用した奴らが悪い
「IEが糞、IEは時代遅れ、IEは解釈を誤っている、IEは...」とか言ってブラウザ主導で機能拡張しまくった奴らも同罪
HTMLはただの「ドキュメント」だ「文章」が正しく表示されればその役割を果たしたと言える
それをHTMLを「アプリケーションプラットホーム」と勘違いしてる一部の狂信者たちがバカみたいに機能拡張しまくるからこんなことになる おいおいｗ 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 > といったところが代表的でしょう。例えば、セレクタを用いたDOM操作は
> jQuery で実践的に有効性が示され、querySelectorとして標準化されました。
> これにより、jQueryのパフォーマンスは向上し、さらに Zepto.js のような
> 軽量化ライブラリが登場・・・といったWebの好循環を起こしました。 Object.observeは無かったことリスト入りしたぞｗｗｗ ■ このスレッドは過去ログ倉庫に格納されています
