+ JavaScript の質問用スレッド vol.130 + [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-6のテンプレを読んだ上で質問してください。次スレは>>950が>>2のテンプレ案(本スレで改善案があれば考慮)を元に立ててください
■規則/推奨ルール
・メール欄を空欄にし、名前にレス番を入れることを強く推奨(なりすまし防止)
・質問内容は具体的に。言葉だけでなく、出来る限り再現性を確認したサンプルコードの掲示。
・質問テンプレートの利用推奨。
・質問への「答え」だけでなく「意見」を出しても良い。
■禁止行為
・丸投げ質問
・迷惑スクリプトの質問
・オレオレ用語の使用(一般的な用語を使用する事)
・煽り、批判等の他人を不快にさせる行為(批判の代わりに「AよりBが良い」のような代案を出す事)
・回答者同士のレスは原則禁止(>>6を参照)
・ライブラリの話題の投稿(>>6を参照)
■質問テンプレート
【環境】OS, ブラウザをバージョンと共に記入してください。(ex: IE8, Firefox4)
【何をしたのか】何をしたら問題の現象が発生するのか。再現手順を具体的に書いてください。
【エラーメッセージ】エラーメッセージがあれば正確に書き写してください。(Windows なら「コピット」を活用)
【期待する結果】最終的にどういう結果を望んでいるのか、を書いてください。
【サンプルコード】現象を再現可能な最小限のコードを書いてください。
1レスに収まらないならコード投稿サイトを利用してください。
http://jsdo.it/ http://jsbin.com/ http://jsfiddle.net/ http://ideone.com/ > でいいのに何で冗長な書き方するかね
test.textContext = 'hello world';
$('#test').text('hello world');
jQuery使ったほうが短いっていうねw
なんで冗長な書き方するかね? EdgeだとうごかないやんXMLHttpRrequest
node.jsってインストールとか言ってるけどなにこれJavaScriptファイルじゃないの? node.jsはサーバー側アプリを作るものだから関係ない
まあ正確に言えばブラウザ用のJavaScriptファイルを
"ビルドして" 作ることも有るからサーバー用限定ではないが、
少なくともブラウザで直接動かすためのものじゃない >>625
> 関数の戻り値がまた別の関数になってる
> カリー化ともいう
それはカリー化ではない。
カリー化は、引数を取る普通の関数を
特殊な形式の関数に変換すること
foo(a,b,c) という使い方をするfoo関数を
foo2(a)(b)(c) という使い方ができる別の関数に変換すること
>>623は関数を返す関数ってだけなのでカリー化ではない
JavaScriptでカリー化をする必要はないっていうのは理解できるが、
関数を返す関数はときたま使う
ある関数に同じ引数を何度も渡すのであれば、
部分適用を行って何度も渡さないようにできるし、
別のもう少し具体的な例をだすと
[{a: 1, b: 2}, {a: 11, b: 22}, {a: 111, b: 222}] みたいなデータが有って
aの項目でソートするか、bの項目でソートするか、選べるようにしたい時
aでソートする関数、bでソートする関数の2つを作る代わりに、
ソートする項目名を引数にして「ソートする関数」を返す関数
なんてのを作る時に使う >>623
> (n) => (e) =>っていう2個書く書き方をよく知らないんですがなんですかこれは?
アロー関数が2つくっついたってだけなだな。
function(n) {
return n+1;
}
という関数を(thisの扱い以外)同等のアロー関数で書くと
(n) => {
return n + 1;
}
一行で書いて
(n) => { return n + 1; }
{}とreturnを省略して
(n) => n + 1
n+1の部分が (e) => { console.log(n, e) } だったら?
(n) => (e) => { console.log(n, e) } react学ぼうと思うんですがオススメの書籍教えてください >>634
あーごめん、変な間違いしてしまった
関数を返す関数は高階関数の範疇やね >>637
また間違えた
いや、確かに関数を返す関数は高階関数の範疇なんだけど、今回のケースは特に部分適用って言った方がいいな
厳密に参照透明にこだわりたいなら使うのも良いと思うけど、ほとんどクロージャで対応しちゃうなあ
>>623なら
const n = 1;
o.addEventListener('click', e => console.log(n, e), false);
で済むし、ソートする場合も
xs => _sort(xs, 'a')
みたいな無名関数で対応してることが多い
JavaScriptの部分適用は何か無理やり感があって個人的に苦手だ そんな貴方にこの仕様がオススメ
https://github.com/rbuckton/proposal-partial-application
今のままだと身になる可能性は5割程度
議論に参加し支援してStageを上げよう! jQuery を使っていないと、各ブラウザに対応できないから、
自分で各ブラウザの違いを調べて、コーディングしなければならないから、無理
>>636
入門 React ――コンポーネントベースのWebフロントエンド開発、2015
WEB+DB vol.97 の特集が、React
WEB+DB vol.94 の特集が、Kotlin, Electron 各ブラウザの違いというけど今のモダンブラウザに違いは殆どないよ
逆に残っている違いってjQueryでも同じく対処が難しいなものばかり
(例えばfile選択キャンセルの監視とか)
あとはIEに対応するかどうかだけど、他にもAPIのポリフィル噛ますのと
同じようにIEにもポリフィル用意するほうが良いと思う o.addEventListener('click', function(e) {}, false);
ってするとダメで
const f = (e){}
o.addEventListener('click', f, false);
がメモリにいいとか無駄に関数が作られないとか何とか昔呼んだ気がするけど
理由はよく知りません >>641
> 各ブラウザの違いというけど今のモダンブラウザに違いは殆どないよ
そう思うならjQueryのソースコード見てみれば?
特定のブラウザ(機種)用のワークアラウンドがいくつも有る
仕様において違いはなくても、バグがあったりするわけ
特定の環境のみで起こるバグだから見つけるのは大変 >>643
そもそも全く同一に動かそうというのが間違いなのでは?
しかも普通その必要があればオーサリングツール使うよね ゲームのBGMで繋ぎ目が分からないシームレスなループ再生をしたいのですが一般的にはどんな方法がありますか?
Web Audio APIにはloopStartやloopEndがあるので可能ですがこれは短い音声の再生用でBGMには向かないとか・・・ 普通にaudio要素のloop属性や秒数指定で十分じゃないかと思うけど
本当に完璧に無くしたいんならAudioWorklet使うしか無いんじゃね >>647,648
ああその用途ならこれ、といったものは無さそう?
もう少し調べてなんとかしてみます ありがとうございました >>645
あんたが言ってるのは、同一じゃなくても(違いがあっても)
動いてるなら良いじゃないって話でしょ?
俺が言ってるのは、特定のブラウザだけバグや仕様の違いで
動かないって話だよ。
https://code.jquery.com/jquery-3.2.1.js
例えばms-プレフィックスがついて動かないとか
// Support: IE <=9 - 11, Edge 12 - 13
// Microsoft forgot to hump their vendor prefix (#9572)
セレクタのバグに対応する
// Support: IE8, Opera 11-12.16
// Nothing should be selected when empty strings follow ^= or $= or *=
// The test attribute must be unknown in Opera but "safe" for WinRT
// https://msdn.microsoft.com/en-us/library/ie/hh465388.aspx#attribute_section
とか
// Support: Chrome<29, Android<4.4, Safari<7.0+, iOS<7.0+, PhantomJS<1.9.8+
とか
// Webkit/Opera - :checked should return selected option elements
// http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#checked
// IE8 throws error here and will not see later tests
とか
// Support: Safari 8+, iOS 8+
// https://bugs.webkit.org/show_bug.cgi?id=136851
// In-page `selector#id sibling-combinator selector` fails
とか 古いブラウザが大半だろうから、サポートしませんって言っても良いのかもしれないけどさ
jQuery使っておいたほうが安全だろ?
// Support: real iOS 8.2 only (not reproducible in simulator)
// `in` check used to prevent JIT error (gh-2145)
// hasOwn isn't used here due to false negatives
// regarding Nodelist length in IE
// Support: Firefox<24
// Workaround erroneous numeric interpretation of +"0x"
// Support: Chrome 14-35+
// Always assume duplicates if they aren't passed to the comparison function
// Support: Webkit<537.32 - Safari 6.0.3/Chrome 25 (fixed in Chrome 27)
// Detached nodes confoundingly follow *each other*
// Support: IE 9 - 11 only, iOS 7 only, Android Browser <=4.3 only
// Treat the template element as a regular one in browsers that
// don't support it.
// Support: Chrome <=35 - 45
// Webkit & Blink performance suffers when deleting properties
// from DOM nodes, so set to undefined instead
// https://bugs.chromium.org/p/chromium/issues/detail?id=378607 (bug restricted)
// Support: Firefox <=43 - 45
// Disconnected elements can have computed display: none, so first confirm that elem is
// in the document.
// Support: Windows Web Apps (WWA)
// `name` and `type` must use .setAttribute for WWA (#14901) >>651
ごめんけどあんたの気持ちは分からないや
今だってやってるプロジェクトで権利の関係でオールスクラッチで
当分Chromeでしか検証しないまま一応完成させて
その段階でFxやらEdgeやらモバイルで動かしてみたらなんの問題もなく動いたもの
仮にそこで何かに引っかかっても簡単な置換やなんかで済むだろうし
つうか長文載せないで今生きてるブサウザでの活きてる例をピックアップして挙げてよ
個人的にはIEには興味ないからそれ以外だとより説得力を感じる
特にChとFxの違いは勉強になるから教えて欲しい 長文? 文章なんて書いてないよ。
これはjQueryのソースコードの中のコメント
こういうマイナーケースで問題が有ることは明らかになってる
ユーザーが使うブラウザのバージョンなんて指定できないからね。
あとはどれだけ見れる人が多いかどうか
問題が起きた時のクレームに悩まされるかどうか
予防していればクレームは減るよ。
あとからマイナーケースに悩まされる必要はなくなるよ
> 個人的にはIEには興味ないから
あんた個人の都合で物事を決めたりはしない
客観的なデータ。ユーザー数で考えよう まぁとりあえず、さも当たり前のように初心者に
さてjQueryを使いますって勧めるのはやめなよ。
とりあえずjQueryに頼らなくてもjsが使えるようになってから選択として
jQueryなりvue.jsなりlodashなり選択使を提示すればいい。
独善的にjQueryは標準装備ですと言うのはヤメテってだけ >>653
客観的だのなんのってよくわからないそれっぽいこと言うけど、
あくまで今は俺と君とが固有の価値観をすり合わせるんでしょ、それ以上でも以下でもない
もし一般的な話をするとしたら「客を選べない」って本来良くはないことだからね
下請けとか部下の立場で言われたとおりに作るなと言ってるわけじゃないけど、
まるでそれが正義か理想かなにかと勘違いするのは辞めたほうが良いよ
というか、なんかjQuery使わないことを病的に恐れ過ぎなんじゃない?
いつかその補助輪外す勇気が出せると良いね jQueryは補助輪じゃなくて
自転車だと思いますよ。 補助輪付けてる人は少ないわけで
jQueryは世界中の多くの人が使っている以上補助輪じゃないわな
「ということにしたい!」という臭いが
プンプン感じられるレスだ 唐突な自分語りですまんが
jquery使わない俺かっけーって思ってた時期があった >>655
>>654じゃないが、基礎が何も分からないのにいきなりjQueryの記述だけ覚えたときに何も出来ないかと
>>660
そもそも単なる関数の集合体のライブラリなんだから、全て自分で出来るのを簡単に書けるようにしただけだし、
使わなくて済む、または出来るならカッコイイというか良いと思うけどね > >>654じゃないが、基礎が何も分からないのにいきなりjQueryの記述だけ覚えたときに何も出来ないかと
なんで? 基礎が何も分からないのにいきなりjQueryの記述だけ覚えたときに何も出来ない
っていうのは結局何の根拠もないんだよな。
そもそもおかしいよね。
jQuery使える人なら、jQueryがなくてもプログラムできるでしょ?
できない理由が「基礎がわからなくてもjQueryならできる」のであれば
どんだけjQueryは簡単なんだよ?って話になる。
jQueryは面倒な記述を減らしてくれるだけで、
決して基礎が知らない人でも使えるようになるライブラリじゃない
jQueryを過大評価するのはやめろよ。
アンチが過大評価してんだよ ここ最近のjQueryディス流れは親から育つ反抗期的な感を受ける jQueryはプログラム組めないけど何となく読める
くらいの知識で、落ちてるフリーのやつをちょっとだけ弄る
って感じの人に需要がある 求めてもいないjQueryを勝手に勧めて「jQueryを使うべき理由」を語り出してもなあ
いずれにしても、スレ違い >>665
それってjQuery使わなくても一緒だと思うけど、
jQuery使わないで作るのが大変だから
そういうのはめったに落ちてないって話ですか? >>666
スレ違いはごもっともだが一々反応しているのが滑稽w 何度もこういう流れがあったからテンプレ出来たのに荒らしが消したからなぁ jsからjQueryに入ったら簡単に感じる
jQueryから入って難しくてjs勉強した俺が言うんだから間違いない 全然流れわからないけど、ウェブの参考にしたり拾ってくるならjquery分からないとかなり厳しい
自分だけでやるなら本当に好きにしろ 多分某ローダッシュ君のような布教目的だと思って嫌う人がいるんだろうけど
jQuererに関しては単にjQuery使わないやり方を知らない・想像もできないだけだと思う
自分も昔そうだった
だからjQueryでこう書けばいい、程度であれば許してやって欲しい 例えるなら仕事では「スーツを着る」のが無難で常識だと思っているところに対して
生JS派が別に裸やシャツ一枚でも十分仕事はできる、むしろスーツは窮屈
と言ってるのと同じに聞こえるんだと思う jQueryが悪いとかじゃなくて、「当然手間はかかっても生jsで同じコード書けるよね?
その上で利便性や開発生産性からjQuery選んでるんだよね?」って話じゃないの DOM APIでも大昔に比べて少しマシな書き方が
できるようになったとは言えjQueryにはかなわない
jQueryでできないことも有るかもしれないけど、
そこだけDOM APIを使えばいい
こう考えるとDOM APIのメリットはライブラリが必要ないから
ダウンロード時間が不要なのと実行速度が速い
そういうメリットを言えばいいのに、jQueryやめろーとしか言わないんだよな
いや、もちろんダウンロード時間も実行速度も無視できる程度だよ。
だからjQueryを使った時の開発速度と比較すると、小さなメリットしか無いよ。
でも、メリットを言うならそこしか無いだろ?そこを言えば良いんだよ。
今は反論されて撃沈したくないから、あえてDOM APIのメリットを言わないようにしか見えないよ
結局その程度の気持ちなんだろ? jQueryをやめろーって言ってるのは
本気でDOM APIの方がいいと思ってるなら、メリットを言えるはずだ
補足 ライブラリのメリットデメリットの話なので、
jQuery以外使えない人は困るとかいう、
人間の能力の話はしないでください jqueryが初心者向けだというなら、俺はTypeScriptを薦めたい。
コッチのほうが初心者向け。
例えばdocument.まで打ち込めばquerySelectorが候補として出るし必要パラメーターと返り値の型が分かる。
null安全でもあるからちゃんとnullチェックの分岐処理を入れないとエラーになる。
だから丁寧なコードをある程度矯正できる。
という具合に相手が求めてないのに薦めてうざいと思った? > jqueryが初心者向けだというなら、俺はTypeScriptを薦めたい。
TypeScriptは否定しないけど、それは言語の話なので
TypeScript(言語)でjQuery(ライブラリ)を使うのが良いよ。
君が勘違いしてるのはjQueryでコードが短くなることのメリットは
書く量が減るというメリットじゃなくて読む量が減るというメリット
たしかにタイプ数は減るが、仮に少ないタイプ数(操作)で
何万行もコードが自動生成され、それを読まないといけないとなったらどうする?
大変だって思うだろう? コード補完されたからといって、
そこから生成されるコード量が多ければ、その分だけ読まないといけない。
書くのは一回(数回)だが読む回数はもっと多い。
バグ修正で忘れた頃に読まないといけない。他人が読まないといけない。
そういう時に読む量を減らすのが目的なんだから、候補として出るというだけじゃ
何も問題は解決してない
そして最初の話。TypeScriptでjQueryを使えば良いんだよ
> という具合に相手が求めてないのに薦めてうざいと思った?
いや別に? 内容に穴があるなぁって思ったよ。 俺も時々、型あり言語では型を書くのが面倒だが、
それは補完してくれるテキストエディタがあれば
そこまで面倒ではない。的な発言をすることがあるしね。
ここで型があったら読まなければいけない量が増えるじゃないか
っていわれそうなんで補足
俺が言ってる読まなければいけないから大変いうのは「処理」
型などの定義部分は、処理とは違って、何をやってるんだろう?と
読み解かなければいけない所ではなくって、コメントのように
あぁ、ここはこの型なのねってさらっと見ればいい部分
なので定義部分に関しては許容できる。というスタンス
だから俺にとって「冗長なコード」っていうのは、
型(定義)ありだから冗長ってことにはならないんだよね
処理しか見ないからね。
そして型(定義)部分は、たいして読まなくて良いものだから
面倒な点があるとすると(繰り返すけど定義部分は)書く時
それは補完で相殺できる。
もちろん>>677の
> 例えばdocument.まで打ち込めばquerySelectorが候補として出るし
っていうのは補完してるものが定義ではなく処理(メソッド)の一部なので
こういうのはなるべく少ない方がいい。書く時ではなくて読む時の話。 もう一つ>>677に補足しておこうか?
補完してくれるから、とかnull安全だからという理由は
初心者向けということにはならない。
だってそれらは上級者でも便利な道具なんだもの。
初心者向けというのは補助輪のように、
上級者にとっては足かせになるようなもののことだろう。
例えばScratchみたいなビジュアルプログラミング言語も
上級者にとっては足かせになるから、初心者向けだろう。
TypeScriptもjQueryも上級者が使っても便利なものは
初心者向けと呼ぶのは間違いだろう。
初心者でも上級者でも使いやすい道具という言い方なら間違いじゃないけどね。 あと俺はjQueryが初心者向けだとは言ってないよ。
初心者に上級者でも使ってる道具を薦めるのは
小さい頃から本物のピアノを薦めるのと同じようなものだろう。
本物志向w
まあjQueryは上級者でも初心者でも使いやすい道具なんだが 無関係な話は無い方が良いけど、TypeScriptやjQuery
はこのスレに関係ある内容なのでうざいとは思いませんね。
無関係な話(例えば「おまえの考えは気に食わんから書き込み禁止」的なもの)は
やめましょう。 直接DOM触らんのにeachの為にjquery入れてる
みたいな悲劇が起こらなけりゃ別に良いよ ライブラリを本来の目的と違う使い方をするのは
ライブラリの問題ではなくて、使う人の問題なので、
人の問題を理由に、ライブラリに文句をつけること自体がおかしい
それを言ったら、ブラウザで動かす必要が無いのに
(alertで)画面にメッセージ表示したいために、
JavaScriptを使うという悲劇とかいう言い方までできてしまう。
そういうのは人の問題 みんな今流行りのprototype.js使おうぜ最高にイケててナウいからモテるぞ prototype.jsは最終更新日は2年以上前だよ
最新のブラウザに対応しているのかどうかも怪しい
prototype.jsはDOM周りは、DOM APIのショートカットでしか
なかったのが良くなかった。jQueryはDOMをリストとして
扱うという考え方の変更だったけど、prototype.jsは
document.getElementByIdって入力するの長いでしょ?
短い名前の関数用意したよ。で終わってしまった。
標準オブジェクトのprototypeを変更するというのは、
そんなに悪くない発想だと思うんだけど、やっぱり標準で
同じ名前のメソッドが定義されて互換性がなくて。
なんだろうな。GoogleとかMozillaとか大手が同じことをやっていれば
このアプローチでも良かったんだと思うけど、運かなぁ。それがなかった
まあやっぱりjQueryに駆逐されたものという扱いなんだろうな >>675
問題はその理屈だと結局ありとあらゆる事をする時に色んなライブラリを提案しないといけないのか?ということになり
極論を言うと、今その問題を「a()」だけでこなせるライブラリ書いてupしたからそれを使うのが一番スマートだよとも言えてしまう
勿論もしそういう事なら皆それはおかしいと思うはずだが、jQueryで意見が別れるのはJSで一番有名なライブラリという特殊性にあると思う
jQueryを準標準だと考える人と、そうでない人との溝は深い >>1の禁止事項を読んでから書き込みしてもらえないものかね 多分jQueryを他のライブラリと同列だと考えない人にとってはその禁止事項は意味を成さないんだろうね
何でうざがられてるのかもよく分かってないようだし jQueryがオワコン気味なのは紛れもない事実
流行中はドヤってもいいけど潮目が変わればおとなしく引き下がるべし 取り敢えず使いたいやつは使えってことだろ?
俺が知りたいのは、JavaScriptを学ばずにjQueryを使うことは最適解なのかどうか。教えてくれ jQuery を使わない開発者は、ドンドン貧乏になっていく!
このブラウザでバグが出た。
このOS でも、バグが出た
新たな環境で、バグが見つかる度に、修正依頼が届くから、
結局、無料で、永遠に修正させられる
最終的には、時給が100円以下になる。
JS は、トラブルと貧乏しか生まない! とりあえずdom操作目的ならvue.jsとかreactを使うから
そのためにjquery使うのは微妙。
他に使いみちなんかあるの? なんというか、「え?プログラミングってどんなものか知りたいの?」
「じゃあ今見てるブラウザでF12押して、コンソールに1+1って入力してみて」
ってできる気軽さがJSの醍醐味なのに、初期学習者に対してjQueryを押し付けるのは無粋なんだよ
開発者としてならどんどん使ってどうぞ、でもJS初心者の学習には不要 つうかそういうようなプログラミングを勉強したいっていう層や動機無視で
すぐ業務が云々言い出す奴も無粋極まりないと思う
最初はChromeとか今使ってるブラウザで動けばいいじゃない
でもそれを公開しようとした段階で別のブラウザだと仕様が違うことを知り、
じゃあどうするのかを考えるのも勉強だと思うよ
最初からjQueryありきで進めるのはやはり良くない 基本的に俺もjqueryいきなり勧めるやつ否定派だけど
jqueryオワタ論は懐疑的。chrome-extensionで今開いているサイトの使ってるライブラリが分かるやつがあるんだけど
qiitaではreact押しでjquery否定な感じだが
現実はそこまでreact使ってるサイトはないし、jquery使ってるサイトは多い。
多分、理想と現実のギャップを目撃してるんだろうけどね。 このスレはそういう流れをもう何度も繰り返してきたんだよ
>>11にまともなテンプレが載ってるから目を通すと不毛な争いを避けられる どう考えても避けられるとは思わない
歴史の教科書や犯罪事例が合っても犯罪がなくならないのと同じ 何れにしてもライブラリの話題は他所でやれってことでしょ
jQueryなんて専用スレあるんだしそっちに誘導してやればいい >>690
> jQueryがオワコン気味なのは紛れもない事実
せめてシェアが大きく下がってから言うか、
jQueryよりも優れているというコードを書いてから言ってほしい所 >>693
> とりあえずdom操作目的ならvue.jsとかreactを使うから
現実から目をそらさないで考えてみ。
今までHTMLとCSSで書いていました!
というのをvue.jsやreactに置き換えた所あるかい?
vue.jsやreactの欠点は、既存のHTML+CSSに
JavaScriptを付け足して動作をカスタマイズするという
用途に向かないんだよ。 >>696
> qiitaではreact押しでjquery否定な感じだが
> 現実はそこまでreact使ってるサイトはないし、jquery使ってるサイトは多い。
> 多分、理想と現実のギャップを目撃してるんだろうけどね。
理由ははっきりしていて、react押しなのはもともとJavaScriptを
多用するサイトを使っていて、JavaScriptコードのメンテナンスコストが
高くなってしまってるという前提が有るからなんだよ。
残念ながら既存のウェブサイトはページの一部にJavaScriptを利用しているだけ
例えば会社の地図を表示するためにAPIを使ったりとかね
その程度なんだからreactに乗り換えるわけないよ Reactは最近むしろReact Nativeが最近勢い良いじゃん
知ってるか?WebブラウザのためのReact風にNativeアプリを作れるようにした
React NativeをWebブラウザ用に書き出すためのReact Native Webというのがあって
そこそこ使われてるんだぞ?まさに奇想天外だな >>706
> Reactは最近むしろReact Nativeが最近勢い良いじゃん
あー、それは理解できるな
Reactはアプリ用であってウェブサイト用ではない
と考えるとReact Nativeになるもんな
まあどちらにしろウェブサイト用のjQueryに変わる
ライブラリはまだ登場してないことに変わりはないが reactのjsxはキモいんだがわかるやついない? jQueryに変わるウェブサイト用のライブラリってのも必要性が分からんけどな
jQueryで何千行も書いたりしないんだろう?
実際はせいぜい十回くらい要素取るためだけに使ってるだけじゃないの?
なら別にそれ使わなくたって大した違いないじゃん
lodashに含まれる僅か数種類の機能を数カ所で使いたいからといって
わざわざlodashをライブラリに加えたりしないでしょ
逆にアプリケーションとしてフレームワークを使うってことなら
それこそ何千行の短縮になるから価値も理解できるけどさ
なんか取り敢えずちょっとはマシになるだろうから何も考えず取り敢えずちょっと使っとけ
みたいなのは容認できないわ >>709
いやねあんたの言う「大したことはない」は
「面倒だけど、それぐらい我慢できる」って意味になってるんだよ
なんでいちいち我慢しなきゃならんのかと 各ブラウザのバグ対応も有るしな
jQueryをやめると、コードは5倍ぐらいになるからな なんのメリットもないのに使わなくても我慢できるから使うな的な
理屈を言うのやめろよ。メリットを言えよ。メリットを 古いブラウザは動かなくさせられるメリットがある、とか >>712
いや、メリットは暗に言ってるだろ
管理するライブラリが減る、管理しなくて済むと
仮に倍違うとしても、ここで質問されるのはせいぜい数行のもの
その数行の節約のために質問者にjQueryのDL、もしくは管理と
勉強を強制するのはそれこそメリットよりデメリットが上回ってるでしょ
バグ対策とかいうのもここでの質問には基本的に必要ないんだよ
まあ仮に質問者が教えていただいたコード僕のIE6じゃ動きませんと言ったとしても
じゃあjQuery使うと良いよというのが良いのかどうかは分からんがな 必要に応じて適切なライブラリやフレームワークを推奨するんなら分かるけれど
何でもかんでもjQuery有りきっていうのは間違ってるってことでしょ
メリットが有るなんてどのライブラリやフレームワークだって同じだし
ならこの世の全てのライブラリやフレームワーク使うのか?って話になる >>714
> 管理するライブラリが減る、管理しなくて済むと
普通の言語だったらそうだろう
だけど、ブラウザの場合はどうしても避けられない
ブラウザの種類というものが有る。
ブラウザの種類を管理しなければいけないんだ。
jQueryを使うと管理するブラウザの種類が減る
それぞれのブラウザのバグの対応を行ってくれる
そっちのメリットのほうが大きいよ >>715
> 必要に応じて適切なライブラリやフレームワークを推奨するんなら分かるけれど
> 何でもかんでもjQuery有りきっていうのは間違ってるってことでしょ
いや、場合によってはjQueryじゃなくてlodashを勧めたりしてるよ
momentを勧めたことも有る。なんでもjQueryではなく
その他が適切な場合は別の方法を提示してるよ。
単にAngularやReactが適切な質問がないってだけ
それは俺が適切じゃないと思ってるだけで、
jQuery以外のライブラリやフレームワークが適切だと思えば
その例をサンプルコード付きで出してあげればいいじゃない >>714
> 仮に倍違うとしても、ここで質問されるのはせいぜい数行のもの
> その数行の節約のために質問者にjQueryのDL、もしくは管理と
人生で数行しかコードを書かないならそうだろうね。
でも違うからね。 >>716
だから上でも一度言ったがお前の仕事ならそうすればいいさ
俺も仕事ならそうする
でもこのとかのスレの性質上コード作成依頼は当然お断りだし、一問一答のような場合が殆ど
レベルとしては小中学校の義務教育内容なんだよ
jQueryを使ってどう書けますか?どういう道具を使えば実現できますか?という質問なら
その都度、何も考えずにこのライブラリ使えばこれで済むよ、でいいんだよ
でも質問者的にはJSを勉強しよう、理解しようという趣旨で一般的な質問してきてる場合が多い
ここは「JavaScript を自ら学ぶ人のための質問スレッド」だからね
そうじゃないと必然的にコード作成依頼に近くなってくる
その上でここなどでの回答というのは最も単純に物事を解決できるものではなくて
きちんと質問者がJSの勉強を出来るものでないといけないんだよ
誤解しないでほしいけどそれはライブラリの話するなと言うことではないよ
ただjQueryは必須だといってJSに全く向き合おうとしないのは、
何だかんだ理由つけて完全に素のJSから逃げようとするのは行き過ぎということ 質問者に決めてもらえばいい
『私は小中学生なので高校や大学で習う公式で教えないで下さい』か
『私は社会人なので率直に役立つ方法を教えて下さい』か >>719
質問者を育ててるつもりかもしれんがそれはお前のエゴ
育つやつは勝手に育つ
俺達は自由に解答すればいいだけ
それをどう捉えて活かすかは完全に質問者の責任 そんなに「JavaScriptを学ぶ」に
こだわるならDOM APIはブラウザが提供しているAPIであって
JavaScriptではないと言わないといけないな。
どうせダブルスタンダードなんだろうけどな。 ChromeでのみWebGL2のcreateVertexArrayが時々nullを返すんですけど返す条件って分かりませんか?
あとcreateVertexArrayやcreateBufferで作成したオブジェクトも参照が切れた時点でGCで回収されるので明示的にdeleteしなくても大丈夫ですよね? >>723
できれば再現するための最小コード貼ってみて
まあ経験上はタイミング的問題というかバグなのかもしれない
それと昨今のメモリリークバグはdeleteは関係ないよ
JSオブジェクトとリンクされた内部バッファの管理の問題だから
JS側では別策を取る以外何もできないというのが主流だから
とは言えChromeは1年くらい前からネイティブとJSのGCを統合する仕組み強化したから
Canaryでも使っていない限り滅多にお目にかかれないと思うけどね
(ただしBlobURLを使うと仕組み上どうしてもリークする) 取ってつけたように適当な質問しなくていいから(呆) >>722
それは流石にない
まずは銃に頼らず筋肉を付けろと言ってるところに
じゃあ人間の本質は脳だから手足を無くせと言うようなもの >>726
例えが的外れ。
まずjQueryはJavaScriptで使うライブラリなのだから
使う言語はJavaScriptだ。jQueryを使っていても
JavaScriptを使う以上、JavaScriptの勉強になる。
DOM APIはJavaScriptではない。これはJavaScriptの仕様書に
DOM APIがのってないことからも明らか
つまり、おまえはJavaScriptとDOM APIを混同している。 > まずは銃に頼らず筋肉を付けろと言ってるところに
これを「道具に頼らず筋肉をつけろ」と言い換えれば
DOM APIの立場ってのがよく分かるだろう。
jQueryは道具。DOM APIは筋肉。普段の生活で何を使っている?
朝起きてシャワー浴びて着替えて電車に乗って
パソコンを使って仕事をして食べ物を調理して寝る
川に行って水を組んで火を起してお湯にして
何キロも歩いて紙と鉛筆で図表を作って
狩りをして火をおこして焼いて寝る
これが「道具に頼らず筋肉をつけろ」ということだ
無人島ツアーじゃあるまいし、そんなことをして遊ぶ気はない。
どうしても必要なところだけ頑張ればいい DOM APIはCで言うところのOSのAPI(の一部)みたいなもんだと思う
CとJavaScriptは単独ではコンパクトな辺りはよく似てると思う ■ このスレッドは過去ログ倉庫に格納されています