私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.130 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>668で誘導してる
>>693
> とりあえずdom操作目的ならvue.jsとかreactを使うから
現実から目をそらさないで考えてみ。
今までHTMLとCSSで書いていました!
というのをvue.jsやreactに置き換えた所あるかい?
vue.jsやreactの欠点は、既存のHTML+CSSに
JavaScriptを付け足して動作をカスタマイズするという
用途に向かないんだよ。
> とりあえず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に乗り換えるわけないよ
> qiitaではreact押しでjquery否定な感じだが
> 現実はそこまでreact使ってるサイトはないし、jquery使ってるサイトは多い。
> 多分、理想と現実のギャップを目撃してるんだろうけどね。
理由ははっきりしていて、react押しなのはもともとJavaScriptを
多用するサイトを使っていて、JavaScriptコードのメンテナンスコストが
高くなってしまってるという前提が有るからなんだよ。
残念ながら既存のウェブサイトはページの一部にJavaScriptを利用しているだけ
例えば会社の地図を表示するためにAPIを使ったりとかね
その程度なんだからreactに乗り換えるわけないよ
Reactは最近むしろReact Nativeが最近勢い良いじゃん
知ってるか?WebブラウザのためのReact風にNativeアプリを作れるようにした
React NativeをWebブラウザ用に書き出すためのReact Native Webというのがあって
そこそこ使われてるんだぞ?まさに奇想天外だな
知ってるか?WebブラウザのためのReact風にNativeアプリを作れるようにした
React NativeをWebブラウザ用に書き出すためのReact Native Webというのがあって
そこそこ使われてるんだぞ?まさに奇想天外だな
>>706
> Reactは最近むしろReact Nativeが最近勢い良いじゃん
あー、それは理解できるな
Reactはアプリ用であってウェブサイト用ではない
と考えるとReact Nativeになるもんな
まあどちらにしろウェブサイト用のjQueryに変わる
ライブラリはまだ登場してないことに変わりはないが
> Reactは最近むしろReact Nativeが最近勢い良いじゃん
あー、それは理解できるな
Reactはアプリ用であってウェブサイト用ではない
と考えるとReact Nativeになるもんな
まあどちらにしろウェブサイト用のjQueryに変わる
ライブラリはまだ登場してないことに変わりはないが
jQueryに変わるウェブサイト用のライブラリってのも必要性が分からんけどな
jQueryで何千行も書いたりしないんだろう?
実際はせいぜい十回くらい要素取るためだけに使ってるだけじゃないの?
なら別にそれ使わなくたって大した違いないじゃん
lodashに含まれる僅か数種類の機能を数カ所で使いたいからといって
わざわざlodashをライブラリに加えたりしないでしょ
逆にアプリケーションとしてフレームワークを使うってことなら
それこそ何千行の短縮になるから価値も理解できるけどさ
なんか取り敢えずちょっとはマシになるだろうから何も考えず取り敢えずちょっと使っとけ
みたいなのは容認できないわ
jQueryで何千行も書いたりしないんだろう?
実際はせいぜい十回くらい要素取るためだけに使ってるだけじゃないの?
なら別にそれ使わなくたって大した違いないじゃん
lodashに含まれる僅か数種類の機能を数カ所で使いたいからといって
わざわざlodashをライブラリに加えたりしないでしょ
逆にアプリケーションとしてフレームワークを使うってことなら
それこそ何千行の短縮になるから価値も理解できるけどさ
なんか取り敢えずちょっとはマシになるだろうから何も考えず取り敢えずちょっと使っとけ
みたいなのは容認できないわ
各ブラウザのバグ対応も有るしな
jQueryをやめると、コードは5倍ぐらいになるからな
jQueryをやめると、コードは5倍ぐらいになるからな
なんのメリットもないのに使わなくても我慢できるから使うな的な
理屈を言うのやめろよ。メリットを言えよ。メリットを
理屈を言うのやめろよ。メリットを言えよ。メリットを
>>712
いや、メリットは暗に言ってるだろ
管理するライブラリが減る、管理しなくて済むと
仮に倍違うとしても、ここで質問されるのはせいぜい数行のもの
その数行の節約のために質問者にjQueryのDL、もしくは管理と
勉強を強制するのはそれこそメリットよりデメリットが上回ってるでしょ
バグ対策とかいうのもここでの質問には基本的に必要ないんだよ
まあ仮に質問者が教えていただいたコード僕のIE6じゃ動きませんと言ったとしても
じゃあjQuery使うと良いよというのが良いのかどうかは分からんがな
いや、メリットは暗に言ってるだろ
管理するライブラリが減る、管理しなくて済むと
仮に倍違うとしても、ここで質問されるのはせいぜい数行のもの
その数行の節約のために質問者にjQueryのDL、もしくは管理と
勉強を強制するのはそれこそメリットよりデメリットが上回ってるでしょ
バグ対策とかいうのもここでの質問には基本的に必要ないんだよ
まあ仮に質問者が教えていただいたコード僕のIE6じゃ動きませんと言ったとしても
じゃあjQuery使うと良いよというのが良いのかどうかは分からんがな
必要に応じて適切なライブラリやフレームワークを推奨するんなら分かるけれど
何でもかんでもjQuery有りきっていうのは間違ってるってことでしょ
メリットが有るなんてどのライブラリやフレームワークだって同じだし
ならこの世の全てのライブラリやフレームワーク使うのか?って話になる
何でもかんでもjQuery有りきっていうのは間違ってるってことでしょ
メリットが有るなんてどのライブラリやフレームワークだって同じだし
ならこの世の全てのライブラリやフレームワーク使うのか?って話になる
>>714
> 管理するライブラリが減る、管理しなくて済むと
普通の言語だったらそうだろう
だけど、ブラウザの場合はどうしても避けられない
ブラウザの種類というものが有る。
ブラウザの種類を管理しなければいけないんだ。
jQueryを使うと管理するブラウザの種類が減る
それぞれのブラウザのバグの対応を行ってくれる
そっちのメリットのほうが大きいよ
> 管理するライブラリが減る、管理しなくて済むと
普通の言語だったらそうだろう
だけど、ブラウザの場合はどうしても避けられない
ブラウザの種類というものが有る。
ブラウザの種類を管理しなければいけないんだ。
jQueryを使うと管理するブラウザの種類が減る
それぞれのブラウザのバグの対応を行ってくれる
そっちのメリットのほうが大きいよ
>>715
> 必要に応じて適切なライブラリやフレームワークを推奨するんなら分かるけれど
> 何でもかんでもjQuery有りきっていうのは間違ってるってことでしょ
いや、場合によってはjQueryじゃなくてlodashを勧めたりしてるよ
momentを勧めたことも有る。なんでもjQueryではなく
その他が適切な場合は別の方法を提示してるよ。
単にAngularやReactが適切な質問がないってだけ
それは俺が適切じゃないと思ってるだけで、
jQuery以外のライブラリやフレームワークが適切だと思えば
その例をサンプルコード付きで出してあげればいいじゃない
> 必要に応じて適切なライブラリやフレームワークを推奨するんなら分かるけれど
> 何でもかんでもjQuery有りきっていうのは間違ってるってことでしょ
いや、場合によってはjQueryじゃなくてlodashを勧めたりしてるよ
momentを勧めたことも有る。なんでもjQueryではなく
その他が適切な場合は別の方法を提示してるよ。
単にAngularやReactが適切な質問がないってだけ
それは俺が適切じゃないと思ってるだけで、
jQuery以外のライブラリやフレームワークが適切だと思えば
その例をサンプルコード付きで出してあげればいいじゃない
>>714
> 仮に倍違うとしても、ここで質問されるのはせいぜい数行のもの
> その数行の節約のために質問者にjQueryのDL、もしくは管理と
人生で数行しかコードを書かないならそうだろうね。
でも違うからね。
> 仮に倍違うとしても、ここで質問されるのはせいぜい数行のもの
> その数行の節約のために質問者にjQueryのDL、もしくは管理と
人生で数行しかコードを書かないならそうだろうね。
でも違うからね。
>>716
だから上でも一度言ったがお前の仕事ならそうすればいいさ
俺も仕事ならそうする
でもこのとかのスレの性質上コード作成依頼は当然お断りだし、一問一答のような場合が殆ど
レベルとしては小中学校の義務教育内容なんだよ
jQueryを使ってどう書けますか?どういう道具を使えば実現できますか?という質問なら
その都度、何も考えずにこのライブラリ使えばこれで済むよ、でいいんだよ
でも質問者的にはJSを勉強しよう、理解しようという趣旨で一般的な質問してきてる場合が多い
ここは「JavaScript を自ら学ぶ人のための質問スレッド」だからね
そうじゃないと必然的にコード作成依頼に近くなってくる
その上でここなどでの回答というのは最も単純に物事を解決できるものではなくて
きちんと質問者がJSの勉強を出来るものでないといけないんだよ
誤解しないでほしいけどそれはライブラリの話するなと言うことではないよ
ただjQueryは必須だといってJSに全く向き合おうとしないのは、
何だかんだ理由つけて完全に素のJSから逃げようとするのは行き過ぎということ
だから上でも一度言ったがお前の仕事ならそうすればいいさ
俺も仕事ならそうする
でもこのとかのスレの性質上コード作成依頼は当然お断りだし、一問一答のような場合が殆ど
レベルとしては小中学校の義務教育内容なんだよ
jQueryを使ってどう書けますか?どういう道具を使えば実現できますか?という質問なら
その都度、何も考えずにこのライブラリ使えばこれで済むよ、でいいんだよ
でも質問者的にはJSを勉強しよう、理解しようという趣旨で一般的な質問してきてる場合が多い
ここは「JavaScript を自ら学ぶ人のための質問スレッド」だからね
そうじゃないと必然的にコード作成依頼に近くなってくる
その上でここなどでの回答というのは最も単純に物事を解決できるものではなくて
きちんと質問者がJSの勉強を出来るものでないといけないんだよ
誤解しないでほしいけどそれはライブラリの話するなと言うことではないよ
ただjQueryは必須だといってJSに全く向き合おうとしないのは、
何だかんだ理由つけて完全に素のJSから逃げようとするのは行き過ぎということ
質問者に決めてもらえばいい
『私は小中学生なので高校や大学で習う公式で教えないで下さい』か
『私は社会人なので率直に役立つ方法を教えて下さい』か
『私は小中学生なので高校や大学で習う公式で教えないで下さい』か
『私は社会人なので率直に役立つ方法を教えて下さい』か
そんなに「JavaScriptを学ぶ」に
こだわるならDOM APIはブラウザが提供しているAPIであって
JavaScriptではないと言わないといけないな。
どうせダブルスタンダードなんだろうけどな。
こだわるならDOM APIはブラウザが提供しているAPIであって
JavaScriptではないと言わないといけないな。
どうせダブルスタンダードなんだろうけどな。
ChromeでのみWebGL2のcreateVertexArrayが時々nullを返すんですけど返す条件って分かりませんか?
あとcreateVertexArrayやcreateBufferで作成したオブジェクトも参照が切れた時点でGCで回収されるので明示的にdeleteしなくても大丈夫ですよね?
あとcreateVertexArrayやcreateBufferで作成したオブジェクトも参照が切れた時点でGCで回収されるので明示的にdeleteしなくても大丈夫ですよね?
>>723
できれば再現するための最小コード貼ってみて
まあ経験上はタイミング的問題というかバグなのかもしれない
それと昨今のメモリリークバグはdeleteは関係ないよ
JSオブジェクトとリンクされた内部バッファの管理の問題だから
JS側では別策を取る以外何もできないというのが主流だから
とは言えChromeは1年くらい前からネイティブとJSのGCを統合する仕組み強化したから
Canaryでも使っていない限り滅多にお目にかかれないと思うけどね
(ただしBlobURLを使うと仕組み上どうしてもリークする)
できれば再現するための最小コード貼ってみて
まあ経験上はタイミング的問題というかバグなのかもしれない
それと昨今のメモリリークバグはdeleteは関係ないよ
JSオブジェクトとリンクされた内部バッファの管理の問題だから
JS側では別策を取る以外何もできないというのが主流だから
とは言えChromeは1年くらい前からネイティブとJSのGCを統合する仕組み強化したから
Canaryでも使っていない限り滅多にお目にかかれないと思うけどね
(ただしBlobURLを使うと仕組み上どうしてもリークする)
>>726
例えが的外れ。
まずjQueryはJavaScriptで使うライブラリなのだから
使う言語はJavaScriptだ。jQueryを使っていても
JavaScriptを使う以上、JavaScriptの勉強になる。
DOM APIはJavaScriptではない。これはJavaScriptの仕様書に
DOM APIがのってないことからも明らか
つまり、おまえはJavaScriptとDOM APIを混同している。
例えが的外れ。
まずjQueryはJavaScriptで使うライブラリなのだから
使う言語はJavaScriptだ。jQueryを使っていても
JavaScriptを使う以上、JavaScriptの勉強になる。
DOM APIはJavaScriptではない。これはJavaScriptの仕様書に
DOM APIがのってないことからも明らか
つまり、おまえはJavaScriptとDOM APIを混同している。
> まずは銃に頼らず筋肉を付けろと言ってるところに
これを「道具に頼らず筋肉をつけろ」と言い換えれば
DOM APIの立場ってのがよく分かるだろう。
jQueryは道具。DOM APIは筋肉。普段の生活で何を使っている?
朝起きてシャワー浴びて着替えて電車に乗って
パソコンを使って仕事をして食べ物を調理して寝る
川に行って水を組んで火を起してお湯にして
何キロも歩いて紙と鉛筆で図表を作って
狩りをして火をおこして焼いて寝る
これが「道具に頼らず筋肉をつけろ」ということだ
無人島ツアーじゃあるまいし、そんなことをして遊ぶ気はない。
どうしても必要なところだけ頑張ればいい
これを「道具に頼らず筋肉をつけろ」と言い換えれば
DOM APIの立場ってのがよく分かるだろう。
jQueryは道具。DOM APIは筋肉。普段の生活で何を使っている?
朝起きてシャワー浴びて着替えて電車に乗って
パソコンを使って仕事をして食べ物を調理して寝る
川に行って水を組んで火を起してお湯にして
何キロも歩いて紙と鉛筆で図表を作って
狩りをして火をおこして焼いて寝る
これが「道具に頼らず筋肉をつけろ」ということだ
無人島ツアーじゃあるまいし、そんなことをして遊ぶ気はない。
どうしても必要なところだけ頑張ればいい
DOM APIはCで言うところのOSのAPI(の一部)みたいなもんだと思う
CとJavaScriptは単独ではコンパクトな辺りはよく似てると思う
CとJavaScriptは単独ではコンパクトな辺りはよく似てると思う
OS、例えばWindowsだと、Win32APIを持ってきて、
これが基礎だと騒がれる気持ちがわかるだろう?
これが基礎だと騒がれる気持ちがわかるだろう?
ぶっちゃけjQueryが一番息が長くて
これからもほとんど変わらず生き残り続ける
ライブラリだよ。
AngularとかReactとか1年後に今の知識が
使えるかどうか怪しい
これからもほとんど変わらず生き残り続ける
ライブラリだよ。
AngularとかReactとか1年後に今の知識が
使えるかどうか怪しい
オワコン云々よりjQueryに変わるような優れたライブラリがないだろ?w
まあbootstrapがjQueryに依存してるからなあ
生き残ってる理由はそれが大きいな
生き残ってる理由はそれが大きいな
>>730
数年前ならWin32APIだったと思うが今なら(ネイティブではないが).NETくらいには感じてるよ
数年前ならWin32APIだったと思うが今なら(ネイティブではないが).NETくらいには感じてるよ
>>737
これが嫌でblumaに乗り換えた
これが嫌でblumaに乗り換えた
それは仕様の違いであってメモリリークとは言わない
もしかしたら生子要素を再利用する場面もあるかもしれないし
もしかしたら生子要素を再利用する場面もあるかもしれないし
>>727
> DOM APIはJavaScriptではない。これはJavaScriptの仕様書に
> DOM APIがのってないことからも明らか
JavaScript APIという用語を知らないのか
それから、JavaScriptという仕様書はないぞ
君が「JavaScriot = ECMAScript」と曲解してるだけ
> DOM APIはJavaScriptではない。これはJavaScriptの仕様書に
> DOM APIがのってないことからも明らか
JavaScript APIという用語を知らないのか
それから、JavaScriptという仕様書はないぞ
君が「JavaScriot = ECMAScript」と曲解してるだけ
そんな文句を付けて何か意味があるのかは知らんが
取り敢えずJavaScriptという仕様書はかつてあったけどな
__defineGetter__やらESの仕様にないがブラウザが実装しているものについて
WHATWGが定義していたが拡張も概ねES仕様書に乗るようになったので削除された
取り敢えずJavaScriptという仕様書はかつてあったけどな
__defineGetter__やらESの仕様にないがブラウザが実装しているものについて
WHATWGが定義していたが拡張も概ねES仕様書に乗るようになったので削除された
>>743
jQueryもJavaScript APIだよ
jQueryもJavaScript APIだよ
JavaScript APIとはなにか?
http://www.google.co.jp/search?q="JavaScript+API"&oq="JavaScript+API"&sourceid=chrome&ie=UTF-8
Maps JavaScript API - Google Developers
JavaScript API for Office - MSDN - Microsoft
JavaScript API の例 - IBM
Garoon JavaScript API - cybozu developer network
http://www.google.co.jp/search?q="JavaScript+API"&oq="JavaScript+API"&sourceid=chrome&ie=UTF-8
Maps JavaScript API - Google Developers
JavaScript API for Office - MSDN - Microsoft
JavaScript API の例 - IBM
Garoon JavaScript API - cybozu developer network
JavaScript APIって呼び方意味分からんわ
JavaにJSの環境を公開するAPIならそう呼ぶのはわかるが
ライブラリはあくまでライブラリでしょ
jQueryくらい薄いラッパーではAPIと名乗ることすらおこがましい
JavaにJSの環境を公開するAPIならそう呼ぶのはわかるが
ライブラリはあくまでライブラリでしょ
jQueryくらい薄いラッパーではAPIと名乗ることすらおこがましい
>>744
「JavaScript, aka.」の事だとしたら、相互運用性の為に非推奨機能をまとめただけの補完的仕様で「JavaScriptの仕様」と呼べるものでもなかったと思う
「JavaScript, aka.」の事だとしたら、相互運用性の為に非推奨機能をまとめただけの補完的仕様で「JavaScriptの仕様」と呼べるものでもなかったと思う
JavaScriptによるAPIなのか
JavaScriptのためのAPIなのか
コンテキストによるだろ
JavaScriptのためのAPIなのか
コンテキストによるだろ
それ単体で「JavaScriptの仕様」と呼べるものでもなかったと思う
に訂正しておく
に訂正しておく
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.130 + (974) - [100%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.110 + (1001) - [97%] - 2013/10/13 14:01
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.100 + (1001) - [97%] - 2012/6/13 22:46
- + JavaScript の質問用スレッド vol.113 + (1001) - [95%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.118 + (1002) - [95%] - 2014/8/29 22:30
トップメニューへ / →のくす牧場書庫について