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です）
+ JavaScript の質問用スレッド vol.126 +
■ このスレッドは過去ログ倉庫に格納されています
2018/06/02(土) 14:31:23.04ID:B1JKBGEy
262デフォルトの名無しさん
2018/11/06(火) 01:27:51.27ID:bRR/Nar/ >>261
仕様ならMDNなり仕様書なりに載ってるはずだから、とりあえず探してみれば？
それ以前にまともな奴ならそんな物使わないが。
nameは重複許可だから、それは仕様バグであり、使い物にならない。
仮に仕様であったとしても、削除/変更されるのは時間の問題だ。地雷臭が酷すぎる。
お前も含めてJavaScripterは全員馬鹿だからここら辺を理解出来ないようだけど。
仕様ならMDNなり仕様書なりに載ってるはずだから、とりあえず探してみれば？
それ以前にまともな奴ならそんな物使わないが。
nameは重複許可だから、それは仕様バグであり、使い物にならない。
仮に仕様であったとしても、削除/変更されるのは時間の問題だ。地雷臭が酷すぎる。
お前も含めてJavaScripterは全員馬鹿だからここら辺を理解出来ないようだけど。
263デフォルトの名無しさん
2018/11/06(火) 07:04:44.97ID:A8Uqo2gA nameが何にためにあるのかを知っていれば
重複可なのが当たり前でそのformを１つだけ参照するものがあっても
常識の範囲で有意義に使えることが分かる
まあ馬鹿にはわからないだろうが
重複可なのが当たり前でそのformを１つだけ参照するものがあっても
常識の範囲で有意義に使えることが分かる
まあ馬鹿にはわからないだろうが
264デフォルトの名無しさん
2018/11/06(火) 09:04:41.69ID:9jHKU1L0 同じ名前の人が二人いるとかおかしいじゃないですか
265デフォルトの名無しさん
2018/11/06(火) 09:46:57.23ID:bRR/Nar/ >>263
唯一性をユーザー側で保証出来るのならid使え、ってことになってるだろ。
旧API（のつもり？)を使用し続けるのなら、それが今どういう状況になっているのか、自分で把握しておく必要がある。
そんな質問している時点でアウトでしょ。
とりあえず仕様書やMDNを漁って、「今でも使えるものか」確認しないと駄目だと思うよ。
ただそれ以前に、それが仕様であったとしても、動かないんなら意味無いけど。
（お前が「仕様だ！俺は悪くない！」とごねたところでコードが動くようにはならない）
大体、document.forms.xxx ならさておき、ドキュメント直下 document.xxx は不味いとすぐ分かるだろ。
それが仕様であったなら、早々に非推奨になって削除されるべきだし、実際多分そうなんだろ。
仕様がどんどん改訂されるプラットフォームなのだから、良くも悪くもトレンドに沿ってないと駄目なんだよ。
それだって、idで参照するようにしていれば、最初からそんな疑問すらわかないわけでさ。
仕様だから使える！と思ってる時点で馬鹿確定なんだよ。
お前も含めて、JavaSripterはコードを書き捨てばかりしているから、大局観が全く育ってない。
動かないから書き直す、ではなく、
何故書き直す羽目になったのか、どう書いていれば書き直さずに済んだのか、それを考える癖を付けた方がいい。
繰り返すが、それ、id/classで参照する今風のコードなら、問題すら発生しなかったわけでしょ。
お前ら、マッチポンプをしていることにすら気づいてないだろ。
唯一性をユーザー側で保証出来るのならid使え、ってことになってるだろ。
旧API（のつもり？)を使用し続けるのなら、それが今どういう状況になっているのか、自分で把握しておく必要がある。
そんな質問している時点でアウトでしょ。
とりあえず仕様書やMDNを漁って、「今でも使えるものか」確認しないと駄目だと思うよ。
ただそれ以前に、それが仕様であったとしても、動かないんなら意味無いけど。
（お前が「仕様だ！俺は悪くない！」とごねたところでコードが動くようにはならない）
大体、document.forms.xxx ならさておき、ドキュメント直下 document.xxx は不味いとすぐ分かるだろ。
それが仕様であったなら、早々に非推奨になって削除されるべきだし、実際多分そうなんだろ。
仕様がどんどん改訂されるプラットフォームなのだから、良くも悪くもトレンドに沿ってないと駄目なんだよ。
それだって、idで参照するようにしていれば、最初からそんな疑問すらわかないわけでさ。
仕様だから使える！と思ってる時点で馬鹿確定なんだよ。
お前も含めて、JavaSripterはコードを書き捨てばかりしているから、大局観が全く育ってない。
動かないから書き直す、ではなく、
何故書き直す羽目になったのか、どう書いていれば書き直さずに済んだのか、それを考える癖を付けた方がいい。
繰り返すが、それ、id/classで参照する今風のコードなら、問題すら発生しなかったわけでしょ。
お前ら、マッチポンプをしていることにすら気づいてないだろ。
266デフォルトの名無しさん
2018/11/06(火) 09:47:16.32ID:WbDKfplt267257
2018/11/06(火) 10:49:05.82ID:2Hp5KyS3 >>266
英語読みきれてなかったらスマンだけど、それはアプリケーションサーバの設定の問題でローカル開発環境では form の name が出力されてなかったってことかな？
であればちょっと違うかも。
>>265
言わんとしてることはよく分かるよ。
でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
どうやってもその書き方じゃ動かないという話なら、機能として削除されたんだろうとも思うわけ。
>>257 の例だと、コールバックじゃないところでの例えば smtForm1内での document.form1 は問題無いし、それどころか同じものを別サーバへ設置するとコールバックの中でも動いたりする。
同じブラウザで。サーバはどっちも同じ apache で。ブラウザに渡ってる HTML も全く同一で。
しかしブラウザ依存でもないようで、動かない時はどのブラウザでも同じように動かない。
だからクロスドメイン周りの設定に差があるのかとサーバからの HTTPヘッダを比較してもこれと言った差も無いようで、よくわからんって話さ。
ただこのページに仕込んである他のJSの挙動が置くサーバによって違ってるのかもしれない。ページが安定した後の document に影響があるようなことは無いだろうと思って言わなくて悪かったけど。
ちなみに他のJSってアクセス解析の類い。
んじゃそれ外して試せばいいじゃんとなるだろうけど、いつか確かめるけど事情により今すぐは難しい。
といった感じで実用面では他のより良い手段でやればいいことなので問題があるわけじゃないんだけど、理由は知っておきたいという話。
どこでハマるか分からんし。
英語読みきれてなかったらスマンだけど、それはアプリケーションサーバの設定の問題でローカル開発環境では form の name が出力されてなかったってことかな？
であればちょっと違うかも。
>>265
言わんとしてることはよく分かるよ。
でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
どうやってもその書き方じゃ動かないという話なら、機能として削除されたんだろうとも思うわけ。
>>257 の例だと、コールバックじゃないところでの例えば smtForm1内での document.form1 は問題無いし、それどころか同じものを別サーバへ設置するとコールバックの中でも動いたりする。
同じブラウザで。サーバはどっちも同じ apache で。ブラウザに渡ってる HTML も全く同一で。
しかしブラウザ依存でもないようで、動かない時はどのブラウザでも同じように動かない。
だからクロスドメイン周りの設定に差があるのかとサーバからの HTTPヘッダを比較してもこれと言った差も無いようで、よくわからんって話さ。
ただこのページに仕込んである他のJSの挙動が置くサーバによって違ってるのかもしれない。ページが安定した後の document に影響があるようなことは無いだろうと思って言わなくて悪かったけど。
ちなみに他のJSってアクセス解析の類い。
んじゃそれ外して試せばいいじゃんとなるだろうけど、いつか確かめるけど事情により今すぐは難しい。
といった感じで実用面では他のより良い手段でやればいいことなので問題があるわけじゃないんだけど、理由は知っておきたいという話。
どこでハマるか分からんし。
268デフォルトの名無しさん
2018/11/06(火) 11:11:11.71ID:9jHKU1L0 > どこでハマるか分からんし。
だからみんなjQuery使うんだよ
だからみんなjQuery使うんだよ
269デフォルトの名無しさん
2018/11/06(火) 11:21:39.49ID:4sD8op2P もう誰もjQueryなんて使ってない
270デフォルトの名無しさん
2018/11/06(火) 11:53:23.90ID:bRR/Nar/ >>267
> 同じコードが動いたり動かなかったりするからなんでって聞いてるの
それはそうだから、でしかないだろ。
まず、今現在「仕様」かどうか確認しろよ。
それで「仕様」でないのなら、それは偶々動いていただけであって、それだけでしかない。
ブラウザは大幅に更新されてる。
元々それを動かすコードをブラウザが持っていたとして、
仕様から外れた時点でそれをどこで落とすかはブラウザ開発者の自由だし、
結果的に一部残っていて動いたり動かなかったりするのも問題なしだ。
そしてそうなってるだけだろ。
「仕様」でなければ何の不思議もないし、「仕様」であればバグ報告すればいいだけだろ。
そしてその範囲を知る意味もない。
ありがちなパターンとしては、「古いコードもある程度までは動くようにする」為に、
初期構築（最初の構築)だけはそのコードを通し（つまり旧来方法でのアクセスも可能）、
追加で動的構築したDOMについては追跡してない(つまり旧来方法でのアクセスは不可能)といったところか。
ただこれを知ったところで、いつ変更されるかも分からんし、意味無いだろ。
> どこでハマるか分からんし。
「仕様」かどうかはさておき、「みんな」が「今」使ってない方法を使ったら駄目、ってことでしかないだろ。
そういったコードは、必要に応じて書き換えて「今」のトレンドに乗るようにするか、
jQueryみたいに「バージョン○○では…」と自前で管理しきるしかない。
どっちもする気がないのなら、それはお前の問題だ。
初心者にありがちな、全て「仕様」で確定している、という勘違いなら、頭を切り換えた方がいい。
厳密に仕様準拠なら、「必ずundefinedが返る」のが正しいが、
JavaScript界隈はそういう厳密さより、上記のように旧来コードも動くような曖昧さを残した方が好まれる。
結果、今の君のように、「ある日突然コードが動かなくなって？？？、環境依存？？？」な事も発生し、
それが長期的に生産性を下げる要因になっているのも事実だが。
> 同じコードが動いたり動かなかったりするからなんでって聞いてるの
それはそうだから、でしかないだろ。
まず、今現在「仕様」かどうか確認しろよ。
それで「仕様」でないのなら、それは偶々動いていただけであって、それだけでしかない。
ブラウザは大幅に更新されてる。
元々それを動かすコードをブラウザが持っていたとして、
仕様から外れた時点でそれをどこで落とすかはブラウザ開発者の自由だし、
結果的に一部残っていて動いたり動かなかったりするのも問題なしだ。
そしてそうなってるだけだろ。
「仕様」でなければ何の不思議もないし、「仕様」であればバグ報告すればいいだけだろ。
そしてその範囲を知る意味もない。
ありがちなパターンとしては、「古いコードもある程度までは動くようにする」為に、
初期構築（最初の構築)だけはそのコードを通し（つまり旧来方法でのアクセスも可能）、
追加で動的構築したDOMについては追跡してない(つまり旧来方法でのアクセスは不可能)といったところか。
ただこれを知ったところで、いつ変更されるかも分からんし、意味無いだろ。
> どこでハマるか分からんし。
「仕様」かどうかはさておき、「みんな」が「今」使ってない方法を使ったら駄目、ってことでしかないだろ。
そういったコードは、必要に応じて書き換えて「今」のトレンドに乗るようにするか、
jQueryみたいに「バージョン○○では…」と自前で管理しきるしかない。
どっちもする気がないのなら、それはお前の問題だ。
初心者にありがちな、全て「仕様」で確定している、という勘違いなら、頭を切り換えた方がいい。
厳密に仕様準拠なら、「必ずundefinedが返る」のが正しいが、
JavaScript界隈はそういう厳密さより、上記のように旧来コードも動くような曖昧さを残した方が好まれる。
結果、今の君のように、「ある日突然コードが動かなくなって？？？、環境依存？？？」な事も発生し、
それが長期的に生産性を下げる要因になっているのも事実だが。
271デフォルトの名無しさん
2018/11/06(火) 12:09:12.29ID:5TKL1Nze >>267
> でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
グローバル変数に関する規定はあるが、documentは分からん
納得できるまで、自分で調べてくれ
https://momdo.github.io/html/window-object.html#named-access-on-the-window-object
https://momdo.github.io/html/dom.html#the-document-object
あと、それを使うと決めたあなたの判断基準が分からん
> でもそういう話じゃなく、同じコードが動いたり動かなかったりするからなんでって聞いてるの。
グローバル変数に関する規定はあるが、documentは分からん
納得できるまで、自分で調べてくれ
https://momdo.github.io/html/window-object.html#named-access-on-the-window-object
https://momdo.github.io/html/dom.html#the-document-object
あと、それを使うと決めたあなたの判断基準が分からん
272デフォルトの名無しさん
2018/11/06(火) 13:49:56.96ID:9jHKU1L0 >>269
> もう誰もjQueryなんて使ってない
いちいち嘘つくなよ。どうせ俺がバラすんだから逆効果にしかならんぞｗ
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年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか？この先の動向が注目される
> もう誰もjQueryなんて使ってない
いちいち嘘つくなよ。どうせ俺がバラすんだから逆効果にしかならんぞｗ
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年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか？この先の動向が注目される
273デフォルトの名無しさん
2018/11/06(火) 14:36:25.99ID:Fd8yf0Li 前線の開発者が新規にwebアプリ作る時はもう使わんというだけで
全体から見たらそんなのごくごく希少さね
全体から見たらそんなのごくごく希少さね
274デフォルトの名無しさん
2018/11/06(火) 14:42:55.62ID:9jHKU1L0 Angularが減ったのはまだ誤差の範囲内だと思うけど
Reactがこんなに減ったのはなんでだろうな
Reactがこんなに減ったのはなんでだろうな
275デフォルトの名無しさん
2018/11/06(火) 14:44:59.13ID:4sD8op2P 保守ではjQueryあるけど新規は全くない
俺なところはほぼAngular
最近はJAVA有料化の流れのおかげでnodejsも上げてきてる
俺なところはほぼAngular
最近はJAVA有料化の流れのおかげでnodejsも上げてきてる
276デフォルトの名無しさん
2018/11/06(火) 14:56:30.64ID:9jHKU1L0 そもそも新規の仕事ってのがないってだけなので、
jQueryがまったくないという言い方はおかしい
同様にAngularやReactを使うこともないんだから
新規の仕事が無いのでね
たいていは過去やったことの続きか、
別の客に同じようなものを提供するので
そこで使われてるjQueryがそのまま使われる
jQueryがまったくないという言い方はおかしい
同様にAngularやReactを使うこともないんだから
新規の仕事が無いのでね
たいていは過去やったことの続きか、
別の客に同じようなものを提供するので
そこで使われてるjQueryがそのまま使われる
277デフォルトの名無しさん
2018/11/06(火) 20:15:00.55ID:ObpCKggA >>264
全国の鈴木一郎に謝れ！
全国の鈴木一郎に謝れ！
278デフォルトの名無しさん
2018/11/06(火) 20:34:37.04ID:A8Uqo2gA ここまで探せば１分で見つかる仕様提示 無し
https://html.spec.whatwg.org/multipage/dom.html#dom-document-nameditem
https://html.spec.whatwg.org/multipage/dom.html#dom-document-nameditem
279デフォルトの名無しさん
2018/11/06(火) 22:25:14.22ID:8rUvp8iU280デフォルトの名無しさん
2018/11/06(火) 22:53:30.78ID:9jHKU1L0 とりあえずバグなんで、ブラウザの対応待ちですわ
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど
281デフォルトの名無しさん
2018/11/06(火) 23:01:46.77ID:bRR/Nar/282デフォルトの名無しさん
2018/11/06(火) 23:08:25.32ID:9jHKU1L0 自演ではないね。
そういう事がありましたってことだよ
起こったことはちゃんと書かないとｗ
そういう事がありましたってことだよ
起こったことはちゃんと書かないとｗ
283デフォルトの名無しさん
2018/11/06(火) 23:13:35.68ID:bRR/Nar/284デフォルトの名無しさん
2018/11/06(火) 23:29:44.69ID:9jHKU1L0285デフォルトの名無しさん
2018/11/06(火) 23:44:03.25ID:bRR/Nar/286デフォルトの名無しさん
2018/11/07(水) 00:45:22.01ID:UCphLCxy >>285
流行り通じてねぇｗ
「
とりあえずバグなんで、ブラウザの対応待ちですわ
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど
」
ということが、起こったんですよ。彼の現場ではね！
って話だろうがｗ
流行り通じてねぇｗ
「
とりあえずバグなんで、ブラウザの対応待ちですわ
客にも、ブラウザが悪いんで、直るまで待ってくださいって言った
なぜか逆ギレされたけど
」
ということが、起こったんですよ。彼の現場ではね！
って話だろうがｗ
287デフォルトの名無しさん
2018/11/07(水) 00:45:39.54ID:UCphLCxy × 流行り通じてねぇｗ
○ はやり通じてねぇｗ
○ はやり通じてねぇｗ
288デフォルトの名無しさん
2018/11/07(水) 05:11:53.04ID:tcZfPZ7D +new Date()の+って何ですか？
289デフォルトの名無しさん
2018/11/07(水) 06:48:51.19ID:2P8ub5kW >>280
ブラウザはOSやグラフィックドライバなどのバグにきちんと対処してるぞ
ブラウザはOSやグラフィックドライバなどのバグにきちんと対処してるぞ
290デフォルトの名無しさん
2018/11/07(水) 06:50:32.64ID:2P8ub5kW >>288
+-のプラス 単項演算子
+-のプラス 単項演算子
291デフォルトの名無しさん
2018/11/07(水) 07:32:08.33ID:+978RLDn >>267
>別サーバへ設置するとコールバックの中でも動いたりする
実行環境が異なると、使っているライブラリも変わる
それと一般的には、動いたり動かなかったりするのは、非同期処理を勘違いしているとか。
promise とかで、ちゃんと解決してない
処理A, B の順番では動くけど、B, A の順番では動かないとか
1回目は、ファイルの読み込みに時間が掛かるから、エラーになっても、
2回目は、キャッシュから読み込むから、エラーにならないとか
ちゃんと非同期処理をやっていないのに、タイミング次第で動いているアプリは多い。
その特徴はエラーになったり、動いたりすること
ログを見れば、わかる
>別サーバへ設置するとコールバックの中でも動いたりする
実行環境が異なると、使っているライブラリも変わる
それと一般的には、動いたり動かなかったりするのは、非同期処理を勘違いしているとか。
promise とかで、ちゃんと解決してない
処理A, B の順番では動くけど、B, A の順番では動かないとか
1回目は、ファイルの読み込みに時間が掛かるから、エラーになっても、
2回目は、キャッシュから読み込むから、エラーにならないとか
ちゃんと非同期処理をやっていないのに、タイミング次第で動いているアプリは多い。
その特徴はエラーになったり、動いたりすること
ログを見れば、わかる
292デフォルトの名無しさん
2018/11/07(水) 07:44:13.90ID:Ahw1ICjC293デフォルトの名無しさん
2018/11/07(水) 09:25:05.22ID:avMw4Nf2 >>291
概ね同意だ。
善し悪しはさておき、WHATWGにあるのなら、今現在も仕様としてブラウザ開発者側に認識されているだろう。
なら、既に実装されて十分動いていたコードが意図的に落とされることはない。となると、
1. そもそも257のコードに問題があって、それが何らかの理由で顕在化しただけ
2. 元々ブラウザにバグがあって、それが検出されずにずっと残っていただけ
3. ブラウザのコードの更新時に、レグレッションテストに引っかからずバグを挿入してしまっただけ
のどれかだが、可能性が一番高いのは 1. だね。
俺自身はブラウザなんてバグだらけで全く信用ならないプラットフォームだと認識しているから、
こなれてない書き方は出来るだけしないようにしている。
そこではまっても本当に時間の無駄でしかないから。
だからそんなコードはさっさと書き直せ、という立場だ。
ただ、ブラウザのバグだという立場なら、バグ報告をするにしてもコードを切り分けていかないといけないし、
仮に 1. なら、idで書き直しても動かないケースが発生するはずだから、
どのみちそのコードに関しては詳細検討が必要になってしまったね。まあ頑張れ。
ある意味、「仕様外」だったほうが楽だったのではないかな？
もっとも、バグ報告したとしても、直すのも開発者側の自由だから、このまま放置される可能性もあるが。
JavaScripterは全般的にそうだが、最近の初心者は、仕様の隅を使いたがる傾向がある。
仕様を隅々まで知って、それを『使い切る』事がいいことだ/上級テクニックだと勘違いしている。
そういうところでしか差別化出来ないから、そういう小手先テクニックに異常にこだわるわけだ。
ただ、それが仕様内でも、それを動かすのは人間が作ったソフトウェアであって、
そこにバグがある可能性があり、実際、ブラウザなんてバグだらけだ。
こなれてない書き方をするのなら、それなりの覚悟と能力が必要だって事だ。
勿論それをやるのも自由だけど。
(もっとも、257がこなれてないか、と言われれば、こなれているが古い書き方、かな？)
概ね同意だ。
善し悪しはさておき、WHATWGにあるのなら、今現在も仕様としてブラウザ開発者側に認識されているだろう。
なら、既に実装されて十分動いていたコードが意図的に落とされることはない。となると、
1. そもそも257のコードに問題があって、それが何らかの理由で顕在化しただけ
2. 元々ブラウザにバグがあって、それが検出されずにずっと残っていただけ
3. ブラウザのコードの更新時に、レグレッションテストに引っかからずバグを挿入してしまっただけ
のどれかだが、可能性が一番高いのは 1. だね。
俺自身はブラウザなんてバグだらけで全く信用ならないプラットフォームだと認識しているから、
こなれてない書き方は出来るだけしないようにしている。
そこではまっても本当に時間の無駄でしかないから。
だからそんなコードはさっさと書き直せ、という立場だ。
ただ、ブラウザのバグだという立場なら、バグ報告をするにしてもコードを切り分けていかないといけないし、
仮に 1. なら、idで書き直しても動かないケースが発生するはずだから、
どのみちそのコードに関しては詳細検討が必要になってしまったね。まあ頑張れ。
ある意味、「仕様外」だったほうが楽だったのではないかな？
もっとも、バグ報告したとしても、直すのも開発者側の自由だから、このまま放置される可能性もあるが。
JavaScripterは全般的にそうだが、最近の初心者は、仕様の隅を使いたがる傾向がある。
仕様を隅々まで知って、それを『使い切る』事がいいことだ/上級テクニックだと勘違いしている。
そういうところでしか差別化出来ないから、そういう小手先テクニックに異常にこだわるわけだ。
ただ、それが仕様内でも、それを動かすのは人間が作ったソフトウェアであって、
そこにバグがある可能性があり、実際、ブラウザなんてバグだらけだ。
こなれてない書き方をするのなら、それなりの覚悟と能力が必要だって事だ。
勿論それをやるのも自由だけど。
(もっとも、257がこなれてないか、と言われれば、こなれているが古い書き方、かな？)
294デフォルトの名無しさん
2018/11/07(水) 11:04:13.33ID:PR5Ic2pS 最近の初心者が仕様の隅まで知りたがる？ｗ嘘つけｗｗｗ
仕様の隅まで知りたがるのはCおじさんとか古い人たちだろ。あの年代はCの仕様を勘違いしてたことがバレようものなら翌日から同僚に蔑まれてえんがちょされるような世代。
最近の特にWeb系のやつらなんか、必要になったらググって出てきたコードコピペする世代じゃんｗｗｗｗｗ
仕様の隅まで知りたがるのはCおじさんとか古い人たちだろ。あの年代はCの仕様を勘違いしてたことがバレようものなら翌日から同僚に蔑まれてえんがちょされるような世代。
最近の特にWeb系のやつらなんか、必要になったらググって出てきたコードコピペする世代じゃんｗｗｗｗｗ
295257
2018/11/07(水) 11:27:49.74ID:9inYuNmK いろいろありがとう。
>>267 で言ったアクセス解析のJS（これまた別のドメイン extdomain2 にある）を外したら動くようになった。
このJSはページロード初期に動いて終わりだと思ったら、タイマーで定期的に動き続けてるようだ。
ビーコン的に外と通信してるわけでもなさそうだから何やってるのかは分からないし、>>257 の smtFrom1 と smtForm1Callback の間でその JS の処理は割り込んでないようだけど、
少なくとも初期に DOM をいじってるようだからその影響なんだと思う。
それでも smtForm1 では document.form1 を参照できてるから、関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど、現状の詳細を伏せたままここで話を深められるほど単純なことでもなさそうだから、ちょっと引きこもります。
ありがとう。
>>267 で言ったアクセス解析のJS（これまた別のドメイン extdomain2 にある）を外したら動くようになった。
このJSはページロード初期に動いて終わりだと思ったら、タイマーで定期的に動き続けてるようだ。
ビーコン的に外と通信してるわけでもなさそうだから何やってるのかは分からないし、>>257 の smtFrom1 と smtForm1Callback の間でその JS の処理は割り込んでないようだけど、
少なくとも初期に DOM をいじってるようだからその影響なんだと思う。
それでも smtForm1 では document.form1 を参照できてるから、関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど、現状の詳細を伏せたままここで話を深められるほど単純なことでもなさそうだから、ちょっと引きこもります。
ありがとう。
296デフォルトの名無しさん
2018/11/07(水) 12:50:29.23ID:avMw4Nf2 >>295
> 具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど
そのスタンスなら君は君なりに整合性が取れていると思うよ。まあ頑張れ。
言うなれば俺はそういうのから逃げてる。
俺は思うように動かしたいだけであって、
JavaScript自身や環境のデバッグをしたいわけではない、というスタンスだからだ。
> 関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
知っているような気がするが、仕様上は document は複数存在しえる。
ただし、通常はそのようにコードが作られておらず、結果、まともに動かないから妥協されてる。
以下から辿れる。
> Node.ownerDocument 問題の詳細については W3C DOM FAQ を参照してください。
>
> Firefox では現在このルールを強制していません。
> Firefox 3 の開発中には強制していた時期もありましたが、
> このルールを強制すると多くのサイトが機能しなくなってしまうため取りやめになりました。
> 将来的な互換性を高めるため、Web 開発者にはこのルールに従ってコードを修正することを推奨します。
https://developer.mozilla.org/ja/docs/Web/API/Document/importNode
なにか、2-3年前にJavaScriptのスレ（ここだったかWeb板だったかは不明）で
同じようなことを言っていた奴が居たような気もしたが…。(あまり自信ない)
一応複数 document については、実装はされてるっぽい。
例えば、ChromeのDevTools(F12の奴）のTimelineでJSHeapの使用量グラフを出せるが、
そこに document が何個かのグラフも出る。
ただし俺にはあの document の数が何に一致するのかいまいち分からないが。
（具体的に外部documentを取り込むときに増えるのは分かるが、よく分からん時に増えるときもある）
> 具体的に何が原因かを再現するミニマムなコードを見つけたいからもうちょっとやってみるけど
そのスタンスなら君は君なりに整合性が取れていると思うよ。まあ頑張れ。
言うなれば俺はそういうのから逃げてる。
俺は思うように動かしたいだけであって、
JavaScript自身や環境のデバッグをしたいわけではない、というスタンスだからだ。
> 関数コール元の由来によって document が何通りか存在してるのかも、なんて思い当たった。
知っているような気がするが、仕様上は document は複数存在しえる。
ただし、通常はそのようにコードが作られておらず、結果、まともに動かないから妥協されてる。
以下から辿れる。
> Node.ownerDocument 問題の詳細については W3C DOM FAQ を参照してください。
>
> Firefox では現在このルールを強制していません。
> Firefox 3 の開発中には強制していた時期もありましたが、
> このルールを強制すると多くのサイトが機能しなくなってしまうため取りやめになりました。
> 将来的な互換性を高めるため、Web 開発者にはこのルールに従ってコードを修正することを推奨します。
https://developer.mozilla.org/ja/docs/Web/API/Document/importNode
なにか、2-3年前にJavaScriptのスレ（ここだったかWeb板だったかは不明）で
同じようなことを言っていた奴が居たような気もしたが…。(あまり自信ない)
一応複数 document については、実装はされてるっぽい。
例えば、ChromeのDevTools(F12の奴）のTimelineでJSHeapの使用量グラフを出せるが、
そこに document が何個かのグラフも出る。
ただし俺にはあの document の数が何に一致するのかいまいち分からないが。
（具体的に外部documentを取り込むときに増えるのは分かるが、よく分からん時に増えるときもある）
297デフォルトの名無しさん
2018/11/07(水) 12:52:09.02ID:lrycyXQF 仕様の隅とかカッコつけなくて良いから
ただ「俺はそんな仕様知らないし勉強する気もない」だけでしょ
自分の意見を表明するだけで良いところを
ひたすら他人を絡めようとする奴は程度が知れてる
ただ「俺はそんな仕様知らないし勉強する気もない」だけでしょ
自分の意見を表明するだけで良いところを
ひたすら他人を絡めようとする奴は程度が知れてる
298デフォルトの名無しさん
2018/11/07(水) 12:55:39.20ID:oTVd6hn3 防衛機制の一種だろうな。
誰でも自分が無能と認めるわけにはいかないのさ。
誰でも自分が無能と認めるわけにはいかないのさ。
299デフォルトの名無しさん
2018/11/07(水) 13:32:20.41ID:avMw4Nf2 >>297-298
それが俺の自説を補強することにしかなってないことに気づけないのが、
お前らが馬鹿たる所以だよ。
マジでJavaScripterは馬鹿しかいない。これは断言出来る。
他言語と比べても相当酷い。
それが俺の自説を補強することにしかなってないことに気づけないのが、
お前らが馬鹿たる所以だよ。
マジでJavaScripterは馬鹿しかいない。これは断言出来る。
他言語と比べても相当酷い。
300デフォルトの名無しさん
2018/11/07(水) 15:22:39.79ID:PR5Ic2pS ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
Ｖ
＿＿＿ ＿
／ ＿＿＿＿ヽ ／ ￣ ￣ ＼
| | /, −､, -､ｌ /､ ヽ きみ頭だいじょうぶ？
| _| -|○ | ○|| |･ |―-､ |
, ―-､ (6 ＿ｰ つ-´､} ｑ -´ 二 ヽ |
| -⊂) ＼ ヽ_ ￣￣ﾉﾉ ﾉ＿ ー | |
|￣￣|／ （_ ∪￣ / ､ ＼ ＼.￣｀ | /
ヽ ｀ ,.| ￣ | | O＝＝＝＝＝ |
｀− ´ | | ＿| / |
Ｖ
＿＿＿ ＿
／ ＿＿＿＿ヽ ／ ￣ ￣ ＼
| | /, −､, -､ｌ /､ ヽ きみ頭だいじょうぶ？
| _| -|○ | ○|| |･ |―-､ |
, ―-､ (6 ＿ｰ つ-´､} ｑ -´ 二 ヽ |
| -⊂) ＼ ヽ_ ￣￣ﾉﾉ ﾉ＿ ー | |
|￣￣|／ （_ ∪￣ / ､ ＼ ＼.￣｀ | /
ヽ ｀ ,.| ￣ | | O＝＝＝＝＝ |
｀− ´ | | ＿| / |
301デフォルトの名無しさん
2018/11/07(水) 18:00:52.56ID:avMw4Nf2 >>295
あと、実は、2.もあるかもね。
まともな奴（＝バグ報告出来るレベルの奴)はそんな設計しないから、
バグ報告すら上がってきてない可能性もある。
1a. id
1b. document.forms[name]
1c. document[name]
でどれも動くとしても、まともな奴ならaかbだ。
「非推奨」なんて言われなくとも、推奨はaに決まっている。
そして、
2a. ノードそのものを渡す
2b. 名前を渡して、document[name]でアクセスしてもらう
ここもおかしいだろ。普通はaだ。
(決め打ち出来る状況だからだろうが、普通はその手の場合は決め打ちは無理だし）
おかしなコードが何故動かないか調査するのに精を出すよりも、
おかしなコードを修正する方に精を出す方が有意義だと思うが、まあこれは個人の自由だ。
ただ、俺は「仕様内」でもブラウザで動くかは信用ならんと実感しているから、
俺ならさっさと修正して終わりにするが。
(ブラウザのバグだとか言いだしたら長くcloseしない案件になってしまう。
ブラウザのバグ取りが目的ではないし)
あと、実は、2.もあるかもね。
まともな奴（＝バグ報告出来るレベルの奴)はそんな設計しないから、
バグ報告すら上がってきてない可能性もある。
1a. id
1b. document.forms[name]
1c. document[name]
でどれも動くとしても、まともな奴ならaかbだ。
「非推奨」なんて言われなくとも、推奨はaに決まっている。
そして、
2a. ノードそのものを渡す
2b. 名前を渡して、document[name]でアクセスしてもらう
ここもおかしいだろ。普通はaだ。
(決め打ち出来る状況だからだろうが、普通はその手の場合は決め打ちは無理だし）
おかしなコードが何故動かないか調査するのに精を出すよりも、
おかしなコードを修正する方に精を出す方が有意義だと思うが、まあこれは個人の自由だ。
ただ、俺は「仕様内」でもブラウザで動くかは信用ならんと実感しているから、
俺ならさっさと修正して終わりにするが。
(ブラウザのバグだとか言いだしたら長くcloseしない案件になってしまう。
ブラウザのバグ取りが目的ではないし)
302デフォルトの名無しさん
2018/11/07(水) 19:49:33.17ID:qlBNSZgc303デフォルトの名無しさん
2018/11/07(水) 21:46:32.86ID:2P8ub5kW >>302
まずDocumentクラスの仕様を見るでしょ？
https://html.spec.whatwg.org/multipage/dom.html#the-document-object
// DOM tree accessors の getter object (DOMString name); を見つけるでしょ
その説明を見て終わり
まずDocumentクラスの仕様を見るでしょ？
https://html.spec.whatwg.org/multipage/dom.html#the-document-object
// DOM tree accessors の getter object (DOMString name); を見つけるでしょ
その説明を見て終わり
304デフォルトの名無しさん
2018/11/07(水) 22:16:45.82ID:+978RLDn VSCode の拡張機能、ESLint には、package manager のyarn の、インストールが必要。
yarnには、node.js のインストールが必要
yarnは、npm でインストールしなかった。
Windows10 に直接インストールした
yarnは、数MB のJavaScript で作られているのか。
Ruby のBundler, npm の影響を受けている
where node
C:\Program Files\nodejs\node.exe
where yarn
C:\Program Files (x86)\Yarn\bin\yarn
C:\Program Files (x86)\Yarn\bin\yarn.cmd
C:\Program Files (x86)\Yarn\bin\yarn.js
yarnには、node.js のインストールが必要
yarnは、npm でインストールしなかった。
Windows10 に直接インストールした
yarnは、数MB のJavaScript で作られているのか。
Ruby のBundler, npm の影響を受けている
where node
C:\Program Files\nodejs\node.exe
where yarn
C:\Program Files (x86)\Yarn\bin\yarn
C:\Program Files (x86)\Yarn\bin\yarn.cmd
C:\Program Files (x86)\Yarn\bin\yarn.js
305デフォルトの名無しさん
2018/11/07(水) 22:29:07.63ID:/kHK9X1+ 「Ruby」でNG登録するのがお手軽・簡単です。
306デフォルトの名無しさん
2018/11/07(水) 23:00:35.11ID:avMw4Nf2 >>294
コピペプログラマが無自覚で結果的に仕様の隅をつついたコードになっていることはあり得る。
彼等は書かないのだから、どういうコードが標準なのか当然知らないから。
ただ、本質的な問題はそこじゃない。
コピペプログラマがコピペしてきた元コードが糞だって事なんだよ。
コピペ自体が褒められるべき事ではないにしても、元コードがまともなら局所的にはまともなコードになる。
今回で言えば、誰かが最初に
document.name
の糞コードを書いた、ということなんだよ。
これがコピペであれば、どこかの馬鹿がドヤ顔で「こんな書き方も出来る(ｷﾘｯ」した結果、ということだ。
正直、JavaScript界隈はこれが多すぎる。
糞コードが糞コードを再生産してて、しかもみんなそれに気づいてない。
JavaScript界隈はバージョン管理を止めてしまった。
結果、猶予期間中にアップデートして新しい書き方に変更していかないといけない状況になってる。
旧来の、バージョン○○では動きます、みたいな管理方法が出来なくなっている。
だからそもそも257流の管理方法は不適だ。
古い書き方のままでどこまで動かせるか厳密に言える状況ではなく、適宜書き換えていくしかなくなってる。
だから、本来は古いwebサイトは閉鎖されるべきなんだよ。
今 document.name なんて書いているまともなサイトがあるとは思えないから、
おそらくはかなり古いサイトを参考にしたか、どこかの馬鹿がドヤ顔したかだが、
正直、前者もかなりある。
コピペプログラマが無自覚で結果的に仕様の隅をつついたコードになっていることはあり得る。
彼等は書かないのだから、どういうコードが標準なのか当然知らないから。
ただ、本質的な問題はそこじゃない。
コピペプログラマがコピペしてきた元コードが糞だって事なんだよ。
コピペ自体が褒められるべき事ではないにしても、元コードがまともなら局所的にはまともなコードになる。
今回で言えば、誰かが最初に
document.name
の糞コードを書いた、ということなんだよ。
これがコピペであれば、どこかの馬鹿がドヤ顔で「こんな書き方も出来る(ｷﾘｯ」した結果、ということだ。
正直、JavaScript界隈はこれが多すぎる。
糞コードが糞コードを再生産してて、しかもみんなそれに気づいてない。
JavaScript界隈はバージョン管理を止めてしまった。
結果、猶予期間中にアップデートして新しい書き方に変更していかないといけない状況になってる。
旧来の、バージョン○○では動きます、みたいな管理方法が出来なくなっている。
だからそもそも257流の管理方法は不適だ。
古い書き方のままでどこまで動かせるか厳密に言える状況ではなく、適宜書き換えていくしかなくなってる。
だから、本来は古いwebサイトは閉鎖されるべきなんだよ。
今 document.name なんて書いているまともなサイトがあるとは思えないから、
おそらくはかなり古いサイトを参考にしたか、どこかの馬鹿がドヤ顔したかだが、
正直、前者もかなりある。
307デフォルトの名無しさん
2018/11/07(水) 23:16:45.49ID:TSvBneKa ダラダラ長い。仕事できなさそう。
308デフォルトの名無しさん
2018/11/08(木) 06:09:34.45ID:+uMbCCJQ 質問です。
Parentを親に持つクラス Child には、自身のインスタンスを生成する関数があります。
（この書き方で良いのかは分かりませんが）
//基本クラス
class Parent{
}
//派生クラス
class Child extends Parent{
//自身のインスタンスを生成する
static CreateInstance(){ return new Child(); }
}
このとき、CreateInstance関数を
Parent側で用意するにはどう書くのが良いでしょうか。
Parentを親に持つクラス Child には、自身のインスタンスを生成する関数があります。
（この書き方で良いのかは分かりませんが）
//基本クラス
class Parent{
}
//派生クラス
class Child extends Parent{
//自身のインスタンスを生成する
static CreateInstance(){ return new Child(); }
}
このとき、CreateInstance関数を
Parent側で用意するにはどう書くのが良いでしょうか。
309デフォルトの名無しさん
2018/11/08(木) 06:35:07.12ID:RRHAcNkK new this()
310デフォルトの名無しさん
2018/11/08(木) 07:23:26.56ID:QHwNiY6E グローバルスコープの変数は、id だけの方がよい
311デフォルトの名無しさん
2018/11/08(木) 08:28:22.04ID:+uMbCCJQ312デフォルトの名無しさん
2018/11/08(木) 12:26:51.19ID:P9fHG5v1 まずWebの仕様とJSを一括にするのは違和感あるけど、まあそれはいいとして
今はWHATWGなどに立派な仕様があるんだからさ
それが元々どこかのブラウザの独自実装だろうが、デファクトだろうが、
ブラウザのお偉いさんが話し合って決めたことだろうが、
メーリングリストで決まったことだろうが、
なにがどうだって仕様は仕様なんだからさ、それを素直に参照すればいいじゃん
まあ色々言いたいことあるけど長くなるから取り敢えず１つだけにすると
Webって言うのは皆の合意、というより総意で決まって来たものだからさ
中央集権的な所が丸ごと決めきってから出す物と比べたら、
そりゃ良いところもあるし、同じだけ悪いところもある
でもその悪いとこだけを引き合いに出すのはおかしいと思うね
それはWebがWebの道を選んだ時点でどうしても付いてくる「特徴」だもの
それを改めようと思ったらWebがWebじゃ無くなっちゃう
WebはWebらしくて、他は他らしい、で良いじゃん
別にWebの特徴が嫌いなら他所へ行けばいいじゃん?
それをせずにそんな批判ばかりしたって、俺からすると、
「WebやWebの人間はこんな悪いとこがあるのに注目されて盛り上がっちゃって俺まで付き合わされておかしいだろ!」っていう妬みにしか聞こえないよ
でもたまたまラッキーでWebが発展できたわけじゃないからね
Webやコミュニティがこの形だったからこのよう発展できたわけ
それは事実として認めないとね
今はWHATWGなどに立派な仕様があるんだからさ
それが元々どこかのブラウザの独自実装だろうが、デファクトだろうが、
ブラウザのお偉いさんが話し合って決めたことだろうが、
メーリングリストで決まったことだろうが、
なにがどうだって仕様は仕様なんだからさ、それを素直に参照すればいいじゃん
まあ色々言いたいことあるけど長くなるから取り敢えず１つだけにすると
Webって言うのは皆の合意、というより総意で決まって来たものだからさ
中央集権的な所が丸ごと決めきってから出す物と比べたら、
そりゃ良いところもあるし、同じだけ悪いところもある
でもその悪いとこだけを引き合いに出すのはおかしいと思うね
それはWebがWebの道を選んだ時点でどうしても付いてくる「特徴」だもの
それを改めようと思ったらWebがWebじゃ無くなっちゃう
WebはWebらしくて、他は他らしい、で良いじゃん
別にWebの特徴が嫌いなら他所へ行けばいいじゃん?
それをせずにそんな批判ばかりしたって、俺からすると、
「WebやWebの人間はこんな悪いとこがあるのに注目されて盛り上がっちゃって俺まで付き合わされておかしいだろ!」っていう妬みにしか聞こえないよ
でもたまたまラッキーでWebが発展できたわけじゃないからね
Webやコミュニティがこの形だったからこのよう発展できたわけ
それは事実として認めないとね
313デフォルトの名無しさん
2018/11/08(木) 14:39:53.97ID:L3KEyImk > まあ色々言いたいことあるけど長くなるから取り敢えず１つだけにすると
うんとっても短いね棒
うんとっても短いね棒
314デフォルトの名無しさん
2018/11/08(木) 17:24:06.77ID:MPerk9aH >>312
コピペか？ポエムか？
意味不明すぎ。
流れ上俺への批判だろうが、該当する箇所がどこだかさっぱり分からない。
お前も「JavaScripterは馬鹿しかいない」という俺の自説を補強したいのか？
他言語スレでは馬鹿が噛みついて来るにしても、少なくともどこに噛みつかれたかは分かるぜ。
お前らではまともに会話が成立しないではないか。
コピペか？ポエムか？
意味不明すぎ。
流れ上俺への批判だろうが、該当する箇所がどこだかさっぱり分からない。
お前も「JavaScripterは馬鹿しかいない」という俺の自説を補強したいのか？
他言語スレでは馬鹿が噛みついて来るにしても、少なくともどこに噛みつかれたかは分かるぜ。
お前らではまともに会話が成立しないではないか。
315デフォルトの名無しさん
2018/11/08(木) 19:25:14.84ID:Kp/pDH8+ 下記のjsonをJavaScriptの多元連想配列に格納する方法を教えてください。
{
"name1": {
"key1": "value1",
"key2": "value2"
}
}
$.getJSON(url) で取得はできますが、
どのようなアクセスでvalue1等に辿れますでしょうか？
json['name1']['key1'] == 'value1' を期待していますが違うようです。
{
"name1": {
"key1": "value1",
"key2": "value2"
}
}
$.getJSON(url) で取得はできますが、
どのようなアクセスでvalue1等に辿れますでしょうか？
json['name1']['key1'] == 'value1' を期待していますが違うようです。
316デフォルトの名無しさん
2018/11/08(木) 20:03:52.85ID:dNW1RU/q >>315
$.getJSON( url, function( json ) {
console.log( json['name1']['key1'] );
});
俺ならawait fetch使うがjQueryがいいってんだからしょうがないね
$.getJSON( url, function( json ) {
console.log( json['name1']['key1'] );
});
俺ならawait fetch使うがjQueryがいいってんだからしょうがないね
317デフォルトの名無しさん
2018/11/08(木) 20:07:48.28ID:Kp/pDH8+ ありがとうございました。死ね。
318デフォルトの名無しさん
2018/11/08(木) 20:14:54.95ID:dNW1RU/q お前が死ね
319デフォルトの名無しさん
2018/11/08(木) 20:21:16.21ID:Kp/pDH8+ 人間のクズw
320デフォルトの名無しさん
2018/11/08(木) 20:34:29.34ID:IPM45bBP ここはひどいインターネットですね
321デフォルトの名無しさん
2018/11/08(木) 21:03:58.59ID:hMdcDcbr322デフォルトの名無しさん
2018/11/08(木) 22:52:35.10ID:EWHrduHm 今どきjQueryでって頭が湧いてるとしか思えんな
323デフォルトの名無しさん
2018/11/08(木) 23:00:42.87ID:QHwNiY6E 荒らしと会話するな。質問に答えるな。
荒らしと会話するものも、荒らしと同じ
このスレで質問しないように！
JavaScript, jQuery のスレは、web制作管理板にあるので、そこへ書き込め
この板には、荒らしが多いから、書き込まないように！
他の質問スレにも、よくいる。
質問に答えると、お前に聞いていないとか、馬鹿とか、荒らしてくる奴が多い
荒らしと会話するものも、荒らしと同じ
このスレで質問しないように！
JavaScript, jQuery のスレは、web制作管理板にあるので、そこへ書き込め
この板には、荒らしが多いから、書き込まないように！
他の質問スレにも、よくいる。
質問に答えると、お前に聞いていないとか、馬鹿とか、荒らしてくる奴が多い
324デフォルトの名無しさん
2018/11/08(木) 23:09:47.02ID:MPerk9aH325デフォルトの名無しさん
2018/11/08(木) 23:36:30.84ID:rJTiWJ81 ほんと、jQueryの話題がでると、頭フットーするやつがいるなぁｗ
>>322
> 今どきjQueryでって頭が湧いてるとしか思えんな
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年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか？この先の動向が注目される
>>322
> 今どきjQueryでって頭が湧いてるとしか思えんな
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年まで減り続けていたがこの一年ではほとんど変化はない。
この状況が大きく変化するときは来るのだろうか？この先の動向が注目される
326デフォルトの名無しさん
2018/11/08(木) 23:51:10.14ID:a5prroZo 近年jQueryは余計な機能減らしてきててDOM操作ライブラリへの回帰を目指している。
jQuery.slimには$.ajaxや$.getJSONは入っていない。
jQuery.slimには$.ajaxや$.getJSONは入っていない。
327デフォルトの名無しさん
2018/11/08(木) 23:54:50.59ID:MPerk9aH >>325
> jQueryの話題がでると、頭フットーするやつがいるなぁｗ
お前もな。
好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
急速に衰退するかは微妙だが、引き金になるとしたらWebAssemblyが成功したら、かな？
そう簡単に行くとも思えんが、あれはゲームチェンジャーになり得る。
> jQueryの話題がでると、頭フットーするやつがいるなぁｗ
お前もな。
好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
急速に衰退するかは微妙だが、引き金になるとしたらWebAssemblyが成功したら、かな？
そう簡単に行くとも思えんが、あれはゲームチェンジャーになり得る。
328デフォルトの名無しさん
2018/11/09(金) 01:16:54.01ID:UVRb8J0Z >>327
> 好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
> それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
逆逆ｗ 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どう考えても終わりません。不安を煽って間違ってる方向へ変えようと、
明らかにずれてる方向が正しいんだと、布教してるやつがいるから事実を伝えてるだけ
jQueryの代替なんてまだ登場してないんだよ。React？Angular？ WebAssembly？
それらはjQueryの代替ではなく大規模なウェブアプリを作るためのもの。
ウェブサイトに適してるのは昔も今もjQueryだ。
jQueryが終わるとしたらWeb componentsが完成して、
使えるコンポーネントが "出揃った時" だろう
つまりウェブサイトを作ってる連中が「JavaScriptなんて全く使わねぇ。
誰かが作ったコンポーネントを使ったHTMLを書くだけで終わり」と
言い出すまでってことだ
そうなれば本来あるべき完全分業の世界に行くことができる。
HTMLのパーツを作るのはプログラマ。それを使うのはウェブデザイナー。
今はウェブデザイナーが書いたHTMLにJavaScript（jQuery）で動きをつけるという形で分業している。
jQueryを使うのはJavaScriptよりも圧倒的に楽だから。セレクタを使うからウェブデザインとの相性も良い。
React、Angular、WebAssembly などはウェブデザイナーの仕事であるデザインの作成を
プログラマの領域に吸収するやり方なので、世界の大半を占めるウェブサイトには全く適していない
> 好き嫌いはともかく、jQueryが先細りなのは事実だと思うぞ。
> それを自覚しているからこそ、お前もいちいち布教してるわけだろ。
逆逆ｗ 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どう考えても終わりません。不安を煽って間違ってる方向へ変えようと、
明らかにずれてる方向が正しいんだと、布教してるやつがいるから事実を伝えてるだけ
jQueryの代替なんてまだ登場してないんだよ。React？Angular？ WebAssembly？
それらはjQueryの代替ではなく大規模なウェブアプリを作るためのもの。
ウェブサイトに適してるのは昔も今もjQueryだ。
jQueryが終わるとしたらWeb componentsが完成して、
使えるコンポーネントが "出揃った時" だろう
つまりウェブサイトを作ってる連中が「JavaScriptなんて全く使わねぇ。
誰かが作ったコンポーネントを使ったHTMLを書くだけで終わり」と
言い出すまでってことだ
そうなれば本来あるべき完全分業の世界に行くことができる。
HTMLのパーツを作るのはプログラマ。それを使うのはウェブデザイナー。
今はウェブデザイナーが書いたHTMLにJavaScript（jQuery）で動きをつけるという形で分業している。
jQueryを使うのはJavaScriptよりも圧倒的に楽だから。セレクタを使うからウェブデザインとの相性も良い。
React、Angular、WebAssembly などはウェブデザイナーの仕事であるデザインの作成を
プログラマの領域に吸収するやり方なので、世界の大半を占めるウェブサイトには全く適していない
329デフォルトの名無しさん
2018/11/09(金) 01:18:44.17ID:UVRb8J0Z 世界の大半を占めるウェブサイトは
「まず最初にHTML+CSSを書く」ということを
しっかりと認識するようにな
まず最初にビルド環境を整えましょうじゃないんだよｗ
「まず最初にHTML+CSSを書く」ということを
しっかりと認識するようにな
まず最初にビルド環境を整えましょうじゃないんだよｗ
330デフォルトの名無しさん
2018/11/09(金) 01:31:54.32ID:aKlbQf3w IE11のことを考えないコードを指摘するのは人間のクズ
JQの時点でお察ししろクソ野郎
ちなみに、あたしはクソ女だからな！
女の言う事は従えよ？
JQの時点でお察ししろクソ野郎
ちなみに、あたしはクソ女だからな！
女の言う事は従えよ？
331デフォルトの名無しさん
2018/11/09(金) 03:02:19.99ID:OgIaPmrY >>328
> 逆逆ｗ 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どっちが先とかはどうでもよくて、お前も必死過ぎなのは事実だよ。
どうしても、jQueryは不滅です、ってことにしたいんだろ。それもまた、不安だからだよ。
> 今はウェブデザイナーが書いたHTMLにJavaScript（jQuery）で動きをつけるという形で分業している。
> ウェブデザイナーの仕事であるデザインの作成を
> プログラマの領域に吸収するやり方なので
この、君の現状認識については同意出来る。
> 「まず最初にHTML+CSSを書く」ということを
これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
CSSの恩恵を正しく受ける為にはクラス設計が必要となる。
そしてそれは工程が逆転する、つまりプログラマが上流、デザイナが下流になるから、
Webデザイナが牛耳っている職場ではかなり無理がある。変化するにしても時間はかかるだろう。
それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
どっちに賭けるかも含めて、個人の自由だ。
> jQueryの代替なんてまだ登場してないんだよ。
jQueryの売りはCSSセレクタで、それは標準に入ってしまった。
大体それ以前に、まともにクラス設計されてたら getElementsByClassName だけで済んでしまって、
querySelectorすら必要ない。（アプリならqueryすらしないし）
その他諸々jQueryが色々便利に出来ていることは認めるが、
最早、無ければ無いでいいや、程度でしか無いと思うが？
まあこれについては水掛け論だからもういいが、
少なくとも、俺と同じ「もう要らないんじゃね？」と思う奴が一定数居るからこそ「不要論」が出るわけで、
そこは君も認めないと駄目だと思うぜ。
> 逆逆ｗ 先に始めたのは、jQueryが終わるとか反布教しだしたやつ
どっちが先とかはどうでもよくて、お前も必死過ぎなのは事実だよ。
どうしても、jQueryは不滅です、ってことにしたいんだろ。それもまた、不安だからだよ。
> 今はウェブデザイナーが書いたHTMLにJavaScript（jQuery）で動きをつけるという形で分業している。
> ウェブデザイナーの仕事であるデザインの作成を
> プログラマの領域に吸収するやり方なので
この、君の現状認識については同意出来る。
> 「まず最初にHTML+CSSを書く」ということを
これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
CSSの恩恵を正しく受ける為にはクラス設計が必要となる。
そしてそれは工程が逆転する、つまりプログラマが上流、デザイナが下流になるから、
Webデザイナが牛耳っている職場ではかなり無理がある。変化するにしても時間はかかるだろう。
それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
どっちに賭けるかも含めて、個人の自由だ。
> jQueryの代替なんてまだ登場してないんだよ。
jQueryの売りはCSSセレクタで、それは標準に入ってしまった。
大体それ以前に、まともにクラス設計されてたら getElementsByClassName だけで済んでしまって、
querySelectorすら必要ない。（アプリならqueryすらしないし）
その他諸々jQueryが色々便利に出来ていることは認めるが、
最早、無ければ無いでいいや、程度でしか無いと思うが？
まあこれについては水掛け論だからもういいが、
少なくとも、俺と同じ「もう要らないんじゃね？」と思う奴が一定数居るからこそ「不要論」が出るわけで、
そこは君も認めないと駄目だと思うぜ。
332デフォルトの名無しさん
2018/11/09(金) 03:02:58.94ID:OgIaPmrY jQueryはHTMLベースになる点が本質的に筋が悪いんだよ。(逆に、それが取っつきやすい点でもあるが)
だから頻繁にリニューアルするサイトならCSSベースの方が効率がいい。
文書を流し込んで出来上がり、だからだ。
（そしてその場合は、CSSクラスをがっちり組んでしまう為、jQueryの恩恵がない）
その点、おそらくWordPress等もそこを目指しているはずだが、
いまいちjQueryが死にきってないところをみると、
WordPressではJavaScriptをある程度書かないと駄目なのかな？
まあそれはさておき、
> 世界の大半を占めるウェブサイト
はつまりほぼ静的なサイトであり、お約束的動きしか必要ないのだから、（ハンバーガーメニューとか）
最終的には静的ページ用のフレームワークで全て終了するようになるはずだが。
Hugoとか、どこまで出来るのか知らんが、出てきてるだろ。
他サイトでやってない動きが必要なら自前で書くしかないけど、ほぼ静的サイトでそれは不要だろ。
デザイナがJavaScriptを書かなければならないのは、環境が整備されてないからだよ。
そしてプログラマにとってはjQueryはもうどっちでもいい存在になってる。
或いはここは君も同意してくれるのかな？
> jQueryが終わるとしたらWeb componentsが完成して、
> 使えるコンポーネントが "出揃った時" だろう
確認してみたが、この意見にも同意出来る。
ただ、若干大がかりすぎるとは思うが。俺は静的HP用フレームワークでいいと思うぜ。
shadowDOMなんてここで持ち出す必要なんて無いと思うのだが。
あと、デザイナはどうしても独自の動きを付けたいのかね？
だとすると、永久に「出揃う」事はないが。
とまあ、つらつら書いてみたが、俺と君の認識は似ている、というかほぼ同じだろう。
WebAssemblyについては、俺は「プログラマがjQuery禁止にされる理由」になり得ると見ている。
今現在jQueryを使って悪い点は、第一に速度面だろ。だから。
だから頻繁にリニューアルするサイトならCSSベースの方が効率がいい。
文書を流し込んで出来上がり、だからだ。
（そしてその場合は、CSSクラスをがっちり組んでしまう為、jQueryの恩恵がない）
その点、おそらくWordPress等もそこを目指しているはずだが、
いまいちjQueryが死にきってないところをみると、
WordPressではJavaScriptをある程度書かないと駄目なのかな？
まあそれはさておき、
> 世界の大半を占めるウェブサイト
はつまりほぼ静的なサイトであり、お約束的動きしか必要ないのだから、（ハンバーガーメニューとか）
最終的には静的ページ用のフレームワークで全て終了するようになるはずだが。
Hugoとか、どこまで出来るのか知らんが、出てきてるだろ。
他サイトでやってない動きが必要なら自前で書くしかないけど、ほぼ静的サイトでそれは不要だろ。
デザイナがJavaScriptを書かなければならないのは、環境が整備されてないからだよ。
そしてプログラマにとってはjQueryはもうどっちでもいい存在になってる。
或いはここは君も同意してくれるのかな？
> jQueryが終わるとしたらWeb componentsが完成して、
> 使えるコンポーネントが "出揃った時" だろう
確認してみたが、この意見にも同意出来る。
ただ、若干大がかりすぎるとは思うが。俺は静的HP用フレームワークでいいと思うぜ。
shadowDOMなんてここで持ち出す必要なんて無いと思うのだが。
あと、デザイナはどうしても独自の動きを付けたいのかね？
だとすると、永久に「出揃う」事はないが。
とまあ、つらつら書いてみたが、俺と君の認識は似ている、というかほぼ同じだろう。
WebAssemblyについては、俺は「プログラマがjQuery禁止にされる理由」になり得ると見ている。
今現在jQueryを使って悪い点は、第一に速度面だろ。だから。
333デフォルトの名無しさん
2018/11/09(金) 03:17:04.51ID:ToatAuO8 馬鹿って変なところにこだわって前へ進めないままなんだよなあ
そういうの捨てれば楽になるのに
そういうの捨てれば楽になるのに
334デフォルトの名無しさん
2018/11/09(金) 06:28:59.39ID:n9QnyFxx jQueryの遅さは機能性から来るそのDOMAPI利用の冗長さにあって
WebAssemblyでDOMAPIを叩ける用になっても同じことをすれば速度は変わらないだろ
こいつホント中身スッカスカの思考しかできない、文字通りのカス
WebAssemblyでDOMAPIを叩ける用になっても同じことをすれば速度は変わらないだろ
こいつホント中身スッカスカの思考しかできない、文字通りのカス
335デフォルトの名無しさん
2018/11/09(金) 07:09:53.79ID:yToTdWux ブラウザもPCもどんどこ高性能になってるよ。
そんなに言うほど遅くない。
慣れている物で素早く開発し、ちゃんと制御することも大事じゃん。
そんなに言うほど遅くない。
慣れている物で素早く開発し、ちゃんと制御することも大事じゃん。
336デフォルトの名無しさん
2018/11/09(金) 07:39:35.28ID:UVRb8J0Z >>331
> > 「まず最初にHTML+CSSを書く」ということを
> これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
中途半端に引用するな
ほんとな。わざと１行で書いて、都合よく引用させないように
徹底しないといけないよな
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」ということを
ってかいただろ
プログラマ的に間違ってるとか、大半を占めるウェブサイトになんの関係があるんですか？
上で、ゲームチェンジャーになりうるとか言ったが、なんのゲームを変えるのかを
明確に言ったらどうだ？それは「プログラマ的なゲーム」だろう
チェンジするのはウェブサイトの世界じゃない。デスクトップやスマホアプリ・ゲームの世界だ
デスクトップやスマホと言ったウェブでない世界を壊してウェブに来るだけの話
その場合になくなるのはjQueryじゃなくて.NET FrameworkやUnityだよ
> > 「まず最初にHTML+CSSを書く」ということを
> これがプログラマ的には間違ってるのさ。理由は効率が悪いからだ。
中途半端に引用するな
ほんとな。わざと１行で書いて、都合よく引用させないように
徹底しないといけないよな
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」ということを
ってかいただろ
プログラマ的に間違ってるとか、大半を占めるウェブサイトになんの関係があるんですか？
上で、ゲームチェンジャーになりうるとか言ったが、なんのゲームを変えるのかを
明確に言ったらどうだ？それは「プログラマ的なゲーム」だろう
チェンジするのはウェブサイトの世界じゃない。デスクトップやスマホアプリ・ゲームの世界だ
デスクトップやスマホと言ったウェブでない世界を壊してウェブに来るだけの話
その場合になくなるのはjQueryじゃなくて.NET FrameworkやUnityだよ
337デフォルトの名無しさん
2018/11/09(金) 07:45:53.68ID:UVRb8J0Z WebAssemblyとか語るやつは、新しく何ができるかしか言わない。
何がどう楽になるのかをけっして言わない。
なぜか？それを言ってしまうと「あぁうちには関係ありませんね」って
言われるのが目に見えてるからだ
WebAssemblyで楽にならないわけがない。では何が楽になるのか？
マルチプラットフォームのアプリをウェブアプリにするのが楽になるんだよ。
いまウェブの大半を占めるウェブサイトの制作が楽になることはない
新しいことができるようになったら、みんな新しいことをするはずだとか
思ってるのかもしれないが、大半は新しいことなんてしようと思っていない
今の仕事が楽にしようと思っている。
だからWebAssemblyもそうだし、JavaScriptフレームワークの導入も大変だし、
jQuery捨ててDOM APIを使うのも、大変になるだけなので使おうと思わない。
そしてjQueryのスピードにも全く困っていないというのも重要な所だな
何がどう楽になるのかをけっして言わない。
なぜか？それを言ってしまうと「あぁうちには関係ありませんね」って
言われるのが目に見えてるからだ
WebAssemblyで楽にならないわけがない。では何が楽になるのか？
マルチプラットフォームのアプリをウェブアプリにするのが楽になるんだよ。
いまウェブの大半を占めるウェブサイトの制作が楽になることはない
新しいことができるようになったら、みんな新しいことをするはずだとか
思ってるのかもしれないが、大半は新しいことなんてしようと思っていない
今の仕事が楽にしようと思っている。
だからWebAssemblyもそうだし、JavaScriptフレームワークの導入も大変だし、
jQuery捨ててDOM APIを使うのも、大変になるだけなので使おうと思わない。
そしてjQueryのスピードにも全く困っていないというのも重要な所だな
338デフォルトの名無しさん
2018/11/09(金) 07:53:41.77ID:UVRb8J0Z >>331
> それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
いつまで待てばいいの？ｗ
このスレ立ててからもうすぐ2年になる
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/
You-Dont-Need-jQueryができてからは3年ぐらい立つか？
もうそろそろ結論出たってことでいいと思うんだけど？
あと3年？ 5年？ 10年？ まだまだかかりそうだねぇｗ
> それが「staticおじさん」のように「jQueryおじさん」として馬鹿にされるようになるかは、結果を待てばいい。
いつまで待てばいいの？ｗ
このスレ立ててからもうすぐ2年になる
2017年 JavaScript★71.9%ものサイトがjQueryを利用 [無断転載禁止]©2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1485008061/
You-Dont-Need-jQueryができてからは3年ぐらい立つか？
もうそろそろ結論出たってことでいいと思うんだけど？
あと3年？ 5年？ 10年？ まだまだかかりそうだねぇｗ
339デフォルトの名無しさん
2018/11/09(金) 08:05:03.76ID:J9ZYW49D jQueryは蔓延りすぎて機能拡張しまくったせいで害悪化してしまったのがな
そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
だから新規で作るものはjQueryを見送ってるし
保守してる人間たちはこれから廃れていくjQueryにしがみつくしかない
JAVAと同じだな
そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
だから新規で作るものはjQueryを見送ってるし
保守してる人間たちはこれから廃れていくjQueryにしがみつくしかない
JAVAと同じだな
340デフォルトの名無しさん
2018/11/09(金) 08:11:32.70ID:UVRb8J0Z > jQueryは蔓延りすぎて機能拡張しまくったせいで害悪化してしまったのがな
1.7（2011年11月）ぐらいから殆ど変わってないんだが？
もう7年も前だぜ・・・
> そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
ESとは対象分野が違う、ESにDOM操作の命令はない
そういう基本的なところを分ってないやつが
> だから新規で作るものはjQueryを見送ってるし
とかいっても、説得力ゼロだよｗ
1.7（2011年11月）ぐらいから殆ど変わってないんだが？
もう7年も前だぜ・・・
> そんな折にesの更改が進み始めてesのほうが今は便利になってきてる
ESとは対象分野が違う、ESにDOM操作の命令はない
そういう基本的なところを分ってないやつが
> だから新規で作るものはjQueryを見送ってるし
とかいっても、説得力ゼロだよｗ
341デフォルトの名無しさん
2018/11/09(金) 08:14:08.68ID:J9ZYW49D 老害
342デフォルトの名無しさん
2018/11/09(金) 08:55:33.36ID:UVRb8J0Z 俺が老害かどうかじゃなくて、現実を見たほうが良くね？ｗ
老害と言われた俺が言ってることが、現実となってるとしたら、
それはどういうことなんだろうね
React、0.6%から0.1%にシェア減っちゃいましたよ？
老害と言われた俺が言ってることが、現実となってるとしたら、
それはどういうことなんだろうね
React、0.6%から0.1%にシェア減っちゃいましたよ？
343デフォルトの名無しさん
2018/11/09(金) 09:11:07.67ID:Ijfza7/E344デフォルトの名無しさん
2018/11/09(金) 10:08:49.86ID:OgIaPmrY >>336
意図的におかしな引用をしたつもりはないが、そう取れたのならすまんかった。
現状認識において、俺と君には大差ない。再度確認するなら、
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」
そうだ。正確に言えば、そうだった。これが変わりつつある。
> いまウェブの大半を占めるウェブサイトの制作が楽になることはない
これが違う。静的HP用のフレームワークを使えば、楽になる。
本来はWordPress等もここを目指しているはずだが、
JavaScriptをいちいち書かないといけないのなら、それは上手く行ってないだけだね。
> そしてjQueryのスピードにも全く困っていないというのも重要な所だな
これはそうだとも言えるが、そうでも無いとも言える。
そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
それがJQueryかどうかは別だが、
フレームワークもjQueryも無しなら（いろんな意味で）遅いサイトになりにくいのも事実だ。
結果、素で書け、と言われるのもまた然り。
意図的におかしな引用をしたつもりはないが、そう取れたのならすまんかった。
現状認識において、俺と君には大差ない。再度確認するなら、
> 世界の大半を占めるウェブサイトは「まず最初にHTML+CSSを書く」
そうだ。正確に言えば、そうだった。これが変わりつつある。
> いまウェブの大半を占めるウェブサイトの制作が楽になることはない
これが違う。静的HP用のフレームワークを使えば、楽になる。
本来はWordPress等もここを目指しているはずだが、
JavaScriptをいちいち書かないといけないのなら、それは上手く行ってないだけだね。
> そしてjQueryのスピードにも全く困っていないというのも重要な所だな
これはそうだとも言えるが、そうでも無いとも言える。
そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
それがJQueryかどうかは別だが、
フレームワークもjQueryも無しなら（いろんな意味で）遅いサイトになりにくいのも事実だ。
結果、素で書け、と言われるのもまた然り。
345デフォルトの名無しさん
2018/11/09(金) 10:09:17.53ID:OgIaPmrY が、話が広がりすぎるので絞ると、
・デザイナ（またはその下請けが）JavaScriptを書かなくてよくなったときにjQueryは終わる
というのは俺も君も共通見解だ。これはいいな？なら、逆説的に、君も
・プログラマにはもう既にjQueryは無用の長物となっている
事を認めることになるが、ここまでもいいよな？
そしてデザイナがいつJavaScriptを書かなくて良くなるかは、
・Web componentsが完成して、使えるコンポーネントが "出揃った時" （君）
・静的HP用フレームワークが整備され、普及したとき(俺）
と詳細な意見は異なるが、まあこれは誤差の範囲だろ。
> いつまで待てばいいの？ｗ
「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
なら、10年後くらいではないかな。
今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。
そしてその彼等が主力、具体的には30代前半にさしかかり、
「jQueryなんて要りません」派が現場での主流派になったときに牙をむくってだけの話さ。
が、正直なところ、俺と君には議論になるほどの意見の相違はないぞ。
別段、君の現状認識に間違いがあるとも思えないし、jQueryが死ぬにしても時間はかかるよ。
もし頓死する可能性があるとしたら、WebAssemblyの出現によって次の次元のスピード競争に巻き込まれたら、って話さ。
ただ、正直、俺にはWebAssemblyがどこを目指しているのかよく分からんし、そもそも立ち上がるかも微妙だとは思う。
だからって、jQueryが安泰で未来永劫使われる、ってことも無いよ。繰り返すが、
今から始める人にとっては、「重複機能ばっかり…」なのも事実だろ。
・デザイナ（またはその下請けが）JavaScriptを書かなくてよくなったときにjQueryは終わる
というのは俺も君も共通見解だ。これはいいな？なら、逆説的に、君も
・プログラマにはもう既にjQueryは無用の長物となっている
事を認めることになるが、ここまでもいいよな？
そしてデザイナがいつJavaScriptを書かなくて良くなるかは、
・Web componentsが完成して、使えるコンポーネントが "出揃った時" （君）
・静的HP用フレームワークが整備され、普及したとき(俺）
と詳細な意見は異なるが、まあこれは誤差の範囲だろ。
> いつまで待てばいいの？ｗ
「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
なら、10年後くらいではないかな。
今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。
そしてその彼等が主力、具体的には30代前半にさしかかり、
「jQueryなんて要りません」派が現場での主流派になったときに牙をむくってだけの話さ。
が、正直なところ、俺と君には議論になるほどの意見の相違はないぞ。
別段、君の現状認識に間違いがあるとも思えないし、jQueryが死ぬにしても時間はかかるよ。
もし頓死する可能性があるとしたら、WebAssemblyの出現によって次の次元のスピード競争に巻き込まれたら、って話さ。
ただ、正直、俺にはWebAssemblyがどこを目指しているのかよく分からんし、そもそも立ち上がるかも微妙だとは思う。
だからって、jQueryが安泰で未来永劫使われる、ってことも無いよ。繰り返すが、
今から始める人にとっては、「重複機能ばっかり…」なのも事実だろ。
346デフォルトの名無しさん
2018/11/09(金) 10:41:19.41ID:UVRb8J0Z347デフォルトの名無しさん
2018/11/09(金) 10:43:55.06ID:UVRb8J0Z >>345
> そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
> それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
> それがJQueryかどうかは別だが、
> フレームワークもjQueryも無しなら（いろんな意味で）遅いサイトになりにくいのも事実だ。
> 結果、素で書け、と言われるのもまた然り。
やっぱり、実行速度しか目に入ってないんだなｗ
かわいそうに。
ほとんどの人は、楽になる方法しか求めてないよ
jQueryをやめて楽になるか？ 何一つ楽にならない
速いとか遅いとか言ってる限り、現状のjQueryのシェアが
落ちてない事実は理解できないだろうよ
> そもそもJavaScriptは現状でも十分速い。単純なGUIだけなら十分だ。
> それでも事実としてもっさりページは存在するから、相当な糞コードが書かれているのは間違いない。
> それがJQueryかどうかは別だが、
> フレームワークもjQueryも無しなら（いろんな意味で）遅いサイトになりにくいのも事実だ。
> 結果、素で書け、と言われるのもまた然り。
やっぱり、実行速度しか目に入ってないんだなｗ
かわいそうに。
ほとんどの人は、楽になる方法しか求めてないよ
jQueryをやめて楽になるか？ 何一つ楽にならない
速いとか遅いとか言ってる限り、現状のjQueryのシェアが
落ちてない事実は理解できないだろうよ
348デフォルトの名無しさん
2018/11/09(金) 10:44:48.91ID:UVRb8J0Z > 今からJavaScriptを始める奴がjQueryを見て、「重複機能ばっかり…」としか思えないのも事実だろ。
同じことをこんなに簡単にできるなんて！
としか思わないよｗ
楽になるかどうかだからね。
同じことをこんなに簡単にできるなんて！
としか思わないよｗ
楽になるかどうかだからね。
349デフォルトの名無しさん
2018/11/09(金) 10:46:26.82ID:UVRb8J0Z document.querySelectorAll() を
$() とかけるだけで、素晴らしいって思うだろうねｗ
$() とかけるだけで、素晴らしいって思うだろうねｗ
350デフォルトの名無しさん
2018/11/09(金) 10:53:28.88ID:UVRb8J0Z >>345
> 「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
> なら、10年後くらいではないかな。
「staticおじさん」なる言葉が発生したときには、staticばかり使ってる人はすでにいなかったわけだが、
jQueryの場合、使っている所が大半を締めてる。状況はぜんぜん違うんだが何と何を比べてるんだ？
> 「staticおじさん」なる言葉がいつ発生したかだよ。ググる限り2010年、となるとJava誕生より15年後だ。
> なら、10年後くらいではないかな。
「staticおじさん」なる言葉が発生したときには、staticばかり使ってる人はすでにいなかったわけだが、
jQueryの場合、使っている所が大半を締めてる。状況はぜんぜん違うんだが何と何を比べてるんだ？
351デフォルトの名無しさん
2018/11/09(金) 11:16:21.71ID:9aipcx/m >>343
NGしとくといいよ。
NGしとくといいよ。
352デフォルトの名無しさん
2018/11/09(金) 12:31:06.18ID:ZgQBCm2t まあ、適材適所っしょ。
React信者は自分のスキルセットを至高で唯一の物だと思いがち。
jQueryで十分なものもあれば、Vueで十分なものもあるし、Reactが適してるものもある。
React信者は自分のスキルセットを至高で唯一の物だと思いがち。
jQueryで十分なものもあれば、Vueで十分なものもあるし、Reactが適してるものもある。
353デフォルトの名無しさん
2018/11/09(金) 14:21:08.83ID:OgIaPmrY >>349
> document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねｗ
なるほど君はデザイナ側か。
なら話は平行線だろうし、君はjQueryと心中して問題ないと思うよ。
プログラマにとってはそれはコストではないんだよ。
タイピングも速いし、それ以前に「デバッグ」のコストが大半だから。
色を付けるだけならスモークテスト＝最終テストで、君はその発想しか出来てない。
実際、DOMクエリは100倍くらい遅くて、地道に削除するだけでもかなり高速化する。
だから、 document.getElementsByClassName みたいな糞長ったらしいメソッドで、
書きたくなくさせるのも、効果があるといえばあるのさ。
「高価な操作はソースコード上でもそう見えるようにしろ、そうしないとメンテの時に障害になる」
ってのはC++の思想だが、これも一理あるわけでさ。
(デザイナにとっては色が付けば良しなのだろうが、プログラマにとっては実行速度も管理対象であって）
jQueryが不味いのは、その手の操作がお手軽にできるから、そういった書き方になってしまいがちなこと。
これはjQueryそのものが遅いのではなくて、使う人が悪いのだけど、
これも含めてjQueryが悪いことにされてて、君のようにムキになる人が出てくるのも自然な成り行きではある。
ただ、既に書いたように、jQueryはHTMLベースになる点（なりがちな点）が本質的に筋が悪いんだよ。
ただそれは上記の通り、使う人の問題だが、
CSSクラスベースに移行したらクエリそのものが単純になる/必要なくなるのも事実でさ。
結果、CSSにすら移行出来ないサイトだけがjQueryを使い続けることになり、それは馬鹿にされるのも当然だよ。
そして今の君のような人に対する反動として、10年後に噴出する、というわけさ。
>>350
『今から』10年後な。
jQueryが必要ではなくなってから15年後、ってことだよ。
「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
> document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねｗ
なるほど君はデザイナ側か。
なら話は平行線だろうし、君はjQueryと心中して問題ないと思うよ。
プログラマにとってはそれはコストではないんだよ。
タイピングも速いし、それ以前に「デバッグ」のコストが大半だから。
色を付けるだけならスモークテスト＝最終テストで、君はその発想しか出来てない。
実際、DOMクエリは100倍くらい遅くて、地道に削除するだけでもかなり高速化する。
だから、 document.getElementsByClassName みたいな糞長ったらしいメソッドで、
書きたくなくさせるのも、効果があるといえばあるのさ。
「高価な操作はソースコード上でもそう見えるようにしろ、そうしないとメンテの時に障害になる」
ってのはC++の思想だが、これも一理あるわけでさ。
(デザイナにとっては色が付けば良しなのだろうが、プログラマにとっては実行速度も管理対象であって）
jQueryが不味いのは、その手の操作がお手軽にできるから、そういった書き方になってしまいがちなこと。
これはjQueryそのものが遅いのではなくて、使う人が悪いのだけど、
これも含めてjQueryが悪いことにされてて、君のようにムキになる人が出てくるのも自然な成り行きではある。
ただ、既に書いたように、jQueryはHTMLベースになる点（なりがちな点）が本質的に筋が悪いんだよ。
ただそれは上記の通り、使う人の問題だが、
CSSクラスベースに移行したらクエリそのものが単純になる/必要なくなるのも事実でさ。
結果、CSSにすら移行出来ないサイトだけがjQueryを使い続けることになり、それは馬鹿にされるのも当然だよ。
そして今の君のような人に対する反動として、10年後に噴出する、というわけさ。
>>350
『今から』10年後な。
jQueryが必要ではなくなってから15年後、ってことだよ。
「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
354デフォルトの名無しさん
2018/11/09(金) 15:32:39.21ID:YLhQ0tUv いちいちなげーんだよ
ここ質問スレだよな？よそ行ってやってくれんか
ここ質問スレだよな？よそ行ってやってくれんか
355デフォルトの名無しさん
2018/11/09(金) 18:34:41.79ID:ya9Twat2 >>349
> document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねｗ
document.querySelectorAll()を$()と書けるようにする方法
方法１：
var $ = document.querySelectorAll.bind(document)
（48文字、minifyで46文字）
方法２：
jQueryのロード
（minify + gzipで約30,000文字ｗ）
ブラウザがgzip解凍後の約85,000文字のjsで書かれたjQueryコードをパース、コンパイルｗｗｗ
結構な時間です
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization/#parsecompile
> document.querySelectorAll() を
> $() とかけるだけで、素晴らしいって思うだろうねｗ
document.querySelectorAll()を$()と書けるようにする方法
方法１：
var $ = document.querySelectorAll.bind(document)
（48文字、minifyで46文字）
方法２：
jQueryのロード
（minify + gzipで約30,000文字ｗ）
ブラウザがgzip解凍後の約85,000文字のjsで書かれたjQueryコードをパース、コンパイルｗｗｗ
結構な時間です
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization/#parsecompile
356デフォルトの名無しさん
2018/11/09(金) 19:52:57.84ID:UVRb8J0Z >>353
やっぱり、実行速度しか頭にないのなｗ
視野狭過ぎでワロタｗ
実行速度も何が何でも速いと思ってる。
そんなに実行速度が重要ならブラウザ使うの止めたほうが良い
速度は許容範囲かどうかで決めるものだ
今jQueryを使ってるサイトは、jQueryの速度が許容範囲ってことだ
なにせ一回読み込めばキャッシュが効くからな
遅いのは最初の一回だけという
> ただ、既に書いたように、jQueryはHTMLベースになる点（なりがちな点）が本質的に筋が悪いんだよ。
ウェブはHTMLベースで書くのだから仕方ないな。むしろHTMLベースで使いにくいものはだめだろう
> 『今から』10年後な。
「jQueryはオワコン（10年後にな！）」
もうこれ完全に不安煽ってるもの以外の何物でしか無いわｗ
> 「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
暗記済みの状態で楽なのはjQuery。覚えるのが嫌いな人っているよね
覚える苦労をして、後の開発を楽にする
VS
覚えるのが嫌だから、開発で大変な思いをしてまで、今楽をしたい
> 君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
切れないが？ ソフトウェア開発において覚えることこそが技術力だし。そうやって覚えてしまうことで
読まなくて良いコードを増やしていくことで、開発速度はあげられる。
もっとも何でも覚えられるわけがないので、より汎用性があって世間でよく使われてるものに限ったほうが良い
つまり、オレオレライブラリなんか覚える価値がないってことな
やっぱり、実行速度しか頭にないのなｗ
視野狭過ぎでワロタｗ
実行速度も何が何でも速いと思ってる。
そんなに実行速度が重要ならブラウザ使うの止めたほうが良い
速度は許容範囲かどうかで決めるものだ
今jQueryを使ってるサイトは、jQueryの速度が許容範囲ってことだ
なにせ一回読み込めばキャッシュが効くからな
遅いのは最初の一回だけという
> ただ、既に書いたように、jQueryはHTMLベースになる点（なりがちな点）が本質的に筋が悪いんだよ。
ウェブはHTMLベースで書くのだから仕方ないな。むしろHTMLベースで使いにくいものはだめだろう
> 『今から』10年後な。
「jQueryはオワコン（10年後にな！）」
もうこれ完全に不安煽ってるもの以外の何物でしか無いわｗ
> 「楽だ」と思えるのは君が既にjQueryを暗記済みだからさ。
暗記済みの状態で楽なのはjQuery。覚えるのが嫌いな人っているよね
覚える苦労をして、後の開発を楽にする
VS
覚えるのが嫌だから、開発で大変な思いをしてまで、今楽をしたい
> 君だって、JavaScriptにPython流、C++流、Java流の糖衣構文が大量に導入されたとして、いちいち全部覚えろ、と言われたら切れるだろ。
切れないが？ ソフトウェア開発において覚えることこそが技術力だし。そうやって覚えてしまうことで
読まなくて良いコードを増やしていくことで、開発速度はあげられる。
もっとも何でも覚えられるわけがないので、より汎用性があって世間でよく使われてるものに限ったほうが良い
つまり、オレオレライブラリなんか覚える価値がないってことな
357デフォルトの名無しさん
2018/11/09(金) 19:54:07.17ID:UVRb8J0Z358デフォルトの名無しさん
2018/11/09(金) 20:07:12.39ID:62z6ttwQ 実行速度と通信量は重要な要素なわけだよ
昨今は多言語対応も要求されるだけに余計にな
昨今は多言語対応も要求されるだけに余計にな
359デフォルトの名無しさん
2018/11/09(金) 20:25:53.76ID:ya9Twat2 >>349
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js";></script>
jQueryおじさん「ワアッ！短い！たった88文字！どーだ参ったか！」
var $=document.querySelectorAll.bind(document)
（46文字）
document.querySelectorAll() を
$() と書けるようにしたいだけで88文字かけて85,000文字のコードをロード、パース、コンパイルさせるjQueryおじさん仕事できなさそうｗｗｗｗｗ
ゴキブリ倒すのに戦車持ってくるみたいなｗｗｗｗｗ
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js";></script>
jQueryおじさん「ワアッ！短い！たった88文字！どーだ参ったか！」
var $=document.querySelectorAll.bind(document)
（46文字）
document.querySelectorAll() を
$() と書けるようにしたいだけで88文字かけて85,000文字のコードをロード、パース、コンパイルさせるjQueryおじさん仕事できなさそうｗｗｗｗｗ
ゴキブリ倒すのに戦車持ってくるみたいなｗｗｗｗｗ
360デフォルトの名無しさん
2018/11/09(金) 20:45:00.11ID:OgIaPmrY >>356
> ソフトウェア開発において覚えることこそが技術力だし。
これは違う。やはり君はプログラマではない。だから分かる必要もないんだが、
ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
ただ、HTMLベースでやると、君みたいに暗記主体の積み上げ方式で出来るのも事実なんだよ。
だから、君のタイプは今後ともjQueryを使い続けた方が効率はいいし、おそらく君はそうするだろう。
一方、ある程度の能力を備えたプログラマにとっては、抽象化が使えるCSSベースの方が効率がいい。
そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、
強烈に嫌う奴も出てくるわけでさ。
同様のことはPHPにも言える。
PHPも仕様が糞すぎて、いちいち場合分けが必要になり、プログラミング上級者でも綺麗に書けなかったりする。
だから、上級者こそPHPを目の敵にする。
ところが、初心者〜中級者成り立ての程度なら、あれくらいのベタさ加減が丁度いい。
そして、自分達よりも綺麗に書ける上級者が存在しないから、彼等にとってはそれなりに快適な状況になってる。
ただ、上質なコードがその世界に存在しないことは本当に問題で、
結果、上質なコードを見たことがないから、PHPerは自分達のコードがトンデモだ、ということに気づけないでいる。
それがPHPerがやたら叩かれている理由だよ。
彼等の自己評価と、外部から見た客観評価に、ズレが有りすぎるのさ。
ま、これは正直、俺はJavaScripterにも当てはまると思っているけどね。
分かるか？両者が矛盾しているわけではないんだよ。
jQueryを使った方が効率がいいタイプもいれば、jQueryを捨てた方が効率がいいタイプもいる。
暗記ベースなら前者で、抽象化ベースなら後者だ。そして一般のプログラマは後者なんだよ。
だから今後ともjQuery不要論はずっと水掛け論になるんだよ。
言ってしまえばお互いポジショントークをしているにすぎないから。
ただ、HTMLベースとCSSベースでは実際に効率が違いすぎるから、
CSSで行ける奴、或いは両方とも出来る奴は、CSSベースを選択することになる。
結果、HTMLベースの奴は取り残され、馬鹿にされるポジションになる、というのが俺の見立てであってさ。
> ソフトウェア開発において覚えることこそが技術力だし。
これは違う。やはり君はプログラマではない。だから分かる必要もないんだが、
ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
ただ、HTMLベースでやると、君みたいに暗記主体の積み上げ方式で出来るのも事実なんだよ。
だから、君のタイプは今後ともjQueryを使い続けた方が効率はいいし、おそらく君はそうするだろう。
一方、ある程度の能力を備えたプログラマにとっては、抽象化が使えるCSSベースの方が効率がいい。
そしてjQueryは最早「ちょっと短く書ける分、もっさりするだけの糖衣構文ライブラリ」でしかないから、
強烈に嫌う奴も出てくるわけでさ。
同様のことはPHPにも言える。
PHPも仕様が糞すぎて、いちいち場合分けが必要になり、プログラミング上級者でも綺麗に書けなかったりする。
だから、上級者こそPHPを目の敵にする。
ところが、初心者〜中級者成り立ての程度なら、あれくらいのベタさ加減が丁度いい。
そして、自分達よりも綺麗に書ける上級者が存在しないから、彼等にとってはそれなりに快適な状況になってる。
ただ、上質なコードがその世界に存在しないことは本当に問題で、
結果、上質なコードを見たことがないから、PHPerは自分達のコードがトンデモだ、ということに気づけないでいる。
それがPHPerがやたら叩かれている理由だよ。
彼等の自己評価と、外部から見た客観評価に、ズレが有りすぎるのさ。
ま、これは正直、俺はJavaScripterにも当てはまると思っているけどね。
分かるか？両者が矛盾しているわけではないんだよ。
jQueryを使った方が効率がいいタイプもいれば、jQueryを捨てた方が効率がいいタイプもいる。
暗記ベースなら前者で、抽象化ベースなら後者だ。そして一般のプログラマは後者なんだよ。
だから今後ともjQuery不要論はずっと水掛け論になるんだよ。
言ってしまえばお互いポジショントークをしているにすぎないから。
ただ、HTMLベースとCSSベースでは実際に効率が違いすぎるから、
CSSで行ける奴、或いは両方とも出来る奴は、CSSベースを選択することになる。
結果、HTMLベースの奴は取り残され、馬鹿にされるポジションになる、というのが俺の見立てであってさ。
361デフォルトの名無しさん
2018/11/09(金) 21:09:46.39ID:UVRb8J0Z >>360
> ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
お前、論理的な思考が出来てないなｗ
俺は覚えることが重要だと言ったが、抽象化能力とその応用力が不要などとは一言も言ってない
また暗記とは言ってない。細かい違いだが、どんな機能があるか覚えていればいいだけ
暗記（何も見ないでかけるようにしろ）とまでは言ってない
覚えることが重要だと言ったが、お前は覚えることは重要ではないと言うわけか？
少ない語群だと、文章を適切に伝えられないぞ
数学で数式を使うのは、短い文章（数式）で正確に意味を伝えるためだ。
数式を覚えてないなら、長い文章を読み書きしなければいけなくなる
それをソフトウェアでは「冗長」という。
「冗長」はバグを増やしテスト時間を増やすことにつながる
jQueryはその「冗長」を減らしてくれる。
> ソフトウェアにおいて重要なのは暗記ではない。抽象化能力と、その応用力だよ。
お前、論理的な思考が出来てないなｗ
俺は覚えることが重要だと言ったが、抽象化能力とその応用力が不要などとは一言も言ってない
また暗記とは言ってない。細かい違いだが、どんな機能があるか覚えていればいいだけ
暗記（何も見ないでかけるようにしろ）とまでは言ってない
覚えることが重要だと言ったが、お前は覚えることは重要ではないと言うわけか？
少ない語群だと、文章を適切に伝えられないぞ
数学で数式を使うのは、短い文章（数式）で正確に意味を伝えるためだ。
数式を覚えてないなら、長い文章を読み書きしなければいけなくなる
それをソフトウェアでは「冗長」という。
「冗長」はバグを増やしテスト時間を増やすことにつながる
jQueryはその「冗長」を減らしてくれる。
■ このスレッドは過去ログ倉庫に格納されています
