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

JavaScript覧 / PC版 /

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

701 = :

>>668で誘導してる

702 = :

>>690
> jQueryがオワコン気味なのは紛れもない事実
せめてシェアが大きく下がってから言うか、
jQueryよりも優れているというコードを書いてから言ってほしい所

703 = :

>>693
> とりあえずdom操作目的ならvue.jsとかreactを使うから

現実から目をそらさないで考えてみ。
今までHTMLとCSSで書いていました！
というのをvue.jsやreactに置き換えた所あるかい？

vue.jsやreactの欠点は、既存のHTML+CSSに
JavaScriptを付け足して動作をカスタマイズするという
用途に向かないんだよ。

704 = :

>>696
> qiitaではreact押しでjquery否定な感じだが
> 現実はそこまでreact使ってるサイトはないし、jquery使ってるサイトは多い。
> 多分、理想と現実のギャップを目撃してるんだろうけどね。

理由ははっきりしていて、react押しなのはもともとJavaScriptを
多用するサイトを使っていて、JavaScriptコードのメンテナンスコストが
高くなってしまってるという前提が有るからなんだよ。

残念ながら既存のウェブサイトはページの一部にJavaScriptを利用しているだけ
例えば会社の地図を表示するためにAPIを使ったりとかね
その程度なんだからreactに乗り換えるわけないよ

705 = :

706 = :

Reactは最近むしろReact Nativeが最近勢い良いじゃん
知ってるか？WebブラウザのためのReact風にNativeアプリを作れるようにした
React NativeをWebブラウザ用に書き出すためのReact Native Webというのがあって
そこそこ使われてるんだぞ？まさに奇想天外だな

707 = :

>>706
> Reactは最近むしろReact Nativeが最近勢い良いじゃん

あー、それは理解できるな
Reactはアプリ用であってウェブサイト用ではない
と考えるとReact Nativeになるもんな

まあどちらにしろウェブサイト用のjQueryに変わる
ライブラリはまだ登場してないことに変わりはないが

709 = :

jQueryに変わるウェブサイト用のライブラリってのも必要性が分からんけどな
jQueryで何千行も書いたりしないんだろう？
実際はせいぜい十回くらい要素取るためだけに使ってるだけじゃないの？

なら別にそれ使わなくたって大した違いないじゃん
lodashに含まれる僅か数種類の機能を数カ所で使いたいからといって
わざわざlodashをライブラリに加えたりしないでしょ

逆にアプリケーションとしてフレームワークを使うってことなら
それこそ何千行の短縮になるから価値も理解できるけどさ
なんか取り敢えずちょっとはマシになるだろうから何も考えず取り敢えずちょっと使っとけ
みたいなのは容認できないわ

710 = :

>>709
いやねあんたの言う「大したことはない」は
「面倒だけど、それぐらい我慢できる」って意味になってるんだよ

なんでいちいち我慢しなきゃならんのかと

711 = :

各ブラウザのバグ対応も有るしな
jQueryをやめると、コードは5倍ぐらいになるからな

712 = :

なんのメリットもないのに使わなくても我慢できるから使うな的な
理屈を言うのやめろよ。メリットを言えよ。メリットを

713 = :

古いブラウザは動かなくさせられるメリットがある、とか

714 = :

>>712
いや、メリットは暗に言ってるだろ
管理するライブラリが減る、管理しなくて済むと
仮に倍違うとしても、ここで質問されるのはせいぜい数行のもの
その数行の節約のために質問者にjQueryのDL、もしくは管理と
勉強を強制するのはそれこそメリットよりデメリットが上回ってるでしょ

バグ対策とかいうのもここでの質問には基本的に必要ないんだよ
まあ仮に質問者が教えていただいたコード僕のIE6じゃ動きませんと言ったとしても
じゃあjQuery使うと良いよというのが良いのかどうかは分からんがな

715 = :

必要に応じて適切なライブラリやフレームワークを推奨するんなら分かるけれど
何でもかんでもjQuery有りきっていうのは間違ってるってことでしょ
メリットが有るなんてどのライブラリやフレームワークだって同じだし
ならこの世の全てのライブラリやフレームワーク使うのか？って話になる

716 = :

>>714
> 管理するライブラリが減る、管理しなくて済むと
普通の言語だったらそうだろう

だけど、ブラウザの場合はどうしても避けられない
ブラウザの種類というものが有る。

ブラウザの種類を管理しなければいけないんだ。
jQueryを使うと管理するブラウザの種類が減る
それぞれのブラウザのバグの対応を行ってくれる

そっちのメリットのほうが大きいよ

717 = :

>>715
> 必要に応じて適切なライブラリやフレームワークを推奨するんなら分かるけれど
> 何でもかんでもjQuery有りきっていうのは間違ってるってことでしょ

いや、場合によってはjQueryじゃなくてlodashを勧めたりしてるよ
momentを勧めたことも有る。なんでもjQueryではなく
その他が適切な場合は別の方法を提示してるよ。

単にAngularやReactが適切な質問がないってだけ
それは俺が適切じゃないと思ってるだけで、
jQuery以外のライブラリやフレームワークが適切だと思えば
その例をサンプルコード付きで出してあげればいいじゃない

718 = :

>>714
> 仮に倍違うとしても、ここで質問されるのはせいぜい数行のもの
> その数行の節約のために質問者にjQueryのDL、もしくは管理と

人生で数行しかコードを書かないならそうだろうね。
でも違うからね。

719 = :

>>716
だから上でも一度言ったがお前の仕事ならそうすればいいさ
俺も仕事ならそうする
でもこのとかのスレの性質上コード作成依頼は当然お断りだし、一問一答のような場合が殆ど
レベルとしては小中学校の義務教育内容なんだよ

jQueryを使ってどう書けますか？どういう道具を使えば実現できますか？という質問なら
その都度、何も考えずにこのライブラリ使えばこれで済むよ、でいいんだよ
でも質問者的にはJSを勉強しよう、理解しようという趣旨で一般的な質問してきてる場合が多い
ここは「JavaScript を自ら学ぶ人のための質問スレッド」だからね
そうじゃないと必然的にコード作成依頼に近くなってくる

その上でここなどでの回答というのは最も単純に物事を解決できるものではなくて
きちんと質問者がJSの勉強を出来るものでないといけないんだよ
誤解しないでほしいけどそれはライブラリの話するなと言うことではないよ
ただjQueryは必須だといってJSに全く向き合おうとしないのは、
何だかんだ理由つけて完全に素のJSから逃げようとするのは行き過ぎということ

720 = :

質問者に決めてもらえばいい
『私は小中学生なので高校や大学で習う公式で教えないで下さい』か
『私は社会人なので率直に役立つ方法を教えて下さい』か

721 = :

>>719
質問者を育ててるつもりかもしれんがそれはお前のエゴ
育つやつは勝手に育つ
俺達は自由に解答すればいいだけ
それをどう捉えて活かすかは完全に質問者の責任

722 = :

そんなに「JavaScriptを学ぶ」に
こだわるならDOM APIはブラウザが提供しているAPIであって
JavaScriptではないと言わないといけないな。
どうせダブルスタンダードなんだろうけどな。

723 = :

ChromeでのみWebGL2のcreateVertexArrayが時々nullを返すんですけど返す条件って分かりませんか？

あとcreateVertexArrayやcreateBufferで作成したオブジェクトも参照が切れた時点でGCで回収されるので明示的にdeleteしなくても大丈夫ですよね？

724 = :

>>723
できれば再現するための最小コード貼ってみて
まあ経験上はタイミング的問題というかバグなのかもしれない
それと昨今のメモリリークバグはdeleteは関係ないよ
JSオブジェクトとリンクされた内部バッファの管理の問題だから
JS側では別策を取る以外何もできないというのが主流だから
とは言えChromeは１年くらい前からネイティブとJSのGCを統合する仕組み強化したから
Canaryでも使っていない限り滅多にお目にかかれないと思うけどね
（ただしBlobURLを使うと仕組み上どうしてもリークする）

725 = :

取ってつけたように適当な質問しなくていいから（呆）

726 = :

>>722
それは流石にない
まずは銃に頼らず筋肉を付けろと言ってるところに
じゃあ人間の本質は脳だから手足を無くせと言うようなもの

727 = :

>>726
例えが的外れ。

まずjQueryはJavaScriptで使うライブラリなのだから
使う言語はJavaScriptだ。jQueryを使っていても
JavaScriptを使う以上、JavaScriptの勉強になる。

DOM APIはJavaScriptではない。これはJavaScriptの仕様書に
DOM APIがのってないことからも明らか
つまり、おまえはJavaScriptとDOM APIを混同している。

728 = :

> まずは銃に頼らず筋肉を付けろと言ってるところに

これを「道具に頼らず筋肉をつけろ」と言い換えれば
DOM APIの立場ってのがよく分かるだろう。
jQueryは道具。DOM APIは筋肉。普段の生活で何を使っている？

朝起きてシャワー浴びて着替えて電車に乗って
パソコンを使って仕事をして食べ物を調理して寝る

川に行って水を組んで火を起してお湯にして
何キロも歩いて紙と鉛筆で図表を作って
狩りをして火をおこして焼いて寝る

これが「道具に頼らず筋肉をつけろ」ということだ
無人島ツアーじゃあるまいし、そんなことをして遊ぶ気はない。
どうしても必要なところだけ頑張ればいい

730 = :

OS、例えばWindowsだと、Win32APIを持ってきて、
これが基礎だと騒がれる気持ちがわかるだろう？

731 = :

たとえ合戦は不毛

732 = :

このスレはあと10年は話題に困らねえな

733 = :

ぶっちゃけjQueryが一番息が長くて
これからもほとんど変わらず生き残り続ける
ライブラリだよ。

AngularとかReactとか1年後に今の知識が
使えるかどうか怪しい

734 = :

オワコンって言ったのがよほど癪に障ったか

735 = :

オワコン云々よりjQueryに変わるような優れたライブラリがないだろ？ｗ

736 = :

まあbootstrapがjQueryに依存してるからなあ
生き残ってる理由はそれが大きいな

737 = :

>>730
数年前ならWin32APIだったと思うが今なら(ネイティブではないが).NETくらいには感じてるよ

738 = :

>>737
これが嫌でblumaに乗り換えた

739 = :

>>738
アンカミスった
>>736

740 = :

>>739
本末転倒ってやつだなｗ

○○が良いから乗り換えた・・・乗り換える理由がある。正しい
○○が嫌だから乗り換えた・・・乗り換える理由がない。間違い

742 = :

それは仕様の違いであってメモリリークとは言わない
もしかしたら生子要素を再利用する場面もあるかもしれないし

743 = :

>>727
> DOM APIはJavaScriptではない。これはJavaScriptの仕様書に
> DOM APIがのってないことからも明らか
JavaScript APIという用語を知らないのか
それから、JavaScriptという仕様書はないぞ
君が「JavaScriot = ECMAScript」と曲解してるだけ

744 = :

そんな文句を付けて何か意味があるのかは知らんが
取り敢えずJavaScriptという仕様書はかつてあったけどな
__defineGetter__やらESの仕様にないがブラウザが実装しているものについて
WHATWGが定義していたが拡張も概ねES仕様書に乗るようになったので削除された

746 = :

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

747 = :

JavaScript APIって呼び方意味分からんわ
JavaにJSの環境を公開するAPIならそう呼ぶのはわかるが
ライブラリはあくまでライブラリでしょ
jQueryくらい薄いラッパーではAPIと名乗ることすらおこがましい

748 = :

>>744
「JavaScript, aka.」の事だとしたら、相互運用性の為に非推奨機能をまとめただけの補完的仕様で「JavaScriptの仕様」と呼べるものでもなかったと思う

749 = :

JavaScriptによるAPIなのか
JavaScriptのためのAPIなのか
コンテキストによるだろ

750 = :

それ単体で「JavaScriptの仕様」と呼べるものでもなかったと思う

に訂正しておく