私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript & jQuery 質問用スレッド vol.5 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
とりあえず>>652はお手本のコードを提示すればいい
それができないのに他人のコードにケチつけるなら口だけでこのスレには不要だな
それができないのに他人のコードにケチつけるなら口だけでこのスレには不要だな
「可読性」とは言うけれど
「可書性」とは言わんのよ。
jQuery使わなくても書ける!と書ける自慢をするのはいいけど、
そんなのはいいから可読性が高いのはどっち?となるわけ。
可読性っていうのは長いものを知識に置き換えることで実現する。
たとえば数学の公式。あれを自然言語で書いていればややこしいだけだが、
数式という知識に置き換えることで、可読性が高くなる。
自分しか知らない知識に置き換えた所で、他人の可読性は上がらないんだよ。
一人でやってるならいいが、現場とかチームでやることには
個人でしか通用しない知識は排除させなければいけない。
「可書性」とは言わんのよ。
jQuery使わなくても書ける!と書ける自慢をするのはいいけど、
そんなのはいいから可読性が高いのはどっち?となるわけ。
可読性っていうのは長いものを知識に置き換えることで実現する。
たとえば数学の公式。あれを自然言語で書いていればややこしいだけだが、
数式という知識に置き換えることで、可読性が高くなる。
自分しか知らない知識に置き換えた所で、他人の可読性は上がらないんだよ。
一人でやってるならいいが、現場とかチームでやることには
個人でしか通用しない知識は排除させなければいけない。
そもそも、オレオレライブラリを作るわけではないからなあ
ライブラリ信者は何かと発想がおかしい
ライブラリ信者は何かと発想がおかしい
>>659
> ドキュメントの多さ、ノウハウの多さ、
> 情報の共有の量
多いというが、ソースはどこになるんだ?
どこの誰とも知らない非公式ドキュメントを信用する理由が全くないんだが
jQueryにせよDOMにせよ、公式文書を読むのが基本
資料が分散してるのはメリットにはならない
あとな、jQueryを使って書いたコードの品質はどうでもいいのか
jQueryは使うだけで誰でも高品質なコードを量産できる代物ではないぞ
> ドキュメントの多さ、ノウハウの多さ、
> 情報の共有の量
多いというが、ソースはどこになるんだ?
どこの誰とも知らない非公式ドキュメントを信用する理由が全くないんだが
jQueryにせよDOMにせよ、公式文書を読むのが基本
資料が分散してるのはメリットにはならない
あとな、jQueryを使って書いたコードの品質はどうでもいいのか
jQueryは使うだけで誰でも高品質なコードを量産できる代物ではないぞ
<table>の中に
<td>データ</td>
が沢山入っている場合に、
それらのデータを全部削除して<td></td>のように空のテーブルにしたいのです。
jQueryでどう書けば良いでしょうか?
<td>データ</td>
が沢山入っている場合に、
それらのデータを全部削除して<td></td>のように空のテーブルにしたいのです。
jQueryでどう書けば良いでしょうか?
>>661
> 多いというが、ソースはどこになるんだ?
ソースはgithubにあるし、ドキュメントは公式サイトにあるが?
ソース
http://github.com/jquery/jquery
API Document
http://api.jquery.com/
その他 jQuery fandation
http://jquery.org/
で、対抗してお前のソースは?
> あとな、jQueryを使って書いたコードの品質はどうでもいいのか
> jQueryは使うだけで誰でも高品質なコードを量産できる代物ではないぞ
なんでjQueryに関係ない話するかな?
関係ないから↓このようにjQueryじゃない話をしても当てはまる。
あとな、jQueryを使わずに使って書いたコードの品質はどうでもいいのか
jQuery使わないだけで誰でも高品質なコードを量産できる代物ではないぞ
> 多いというが、ソースはどこになるんだ?
ソースはgithubにあるし、ドキュメントは公式サイトにあるが?
ソース
http://github.com/jquery/jquery
API Document
http://api.jquery.com/
その他 jQuery fandation
http://jquery.org/
で、対抗してお前のソースは?
> あとな、jQueryを使って書いたコードの品質はどうでもいいのか
> jQueryは使うだけで誰でも高品質なコードを量産できる代物ではないぞ
なんでjQueryに関係ない話するかな?
関係ないから↓このようにjQueryじゃない話をしても当てはまる。
あとな、jQueryを使わずに使って書いたコードの品質はどうでもいいのか
jQuery使わないだけで誰でも高品質なコードを量産できる代物ではないぞ
>>664
ありがとうございました。うまくいきました。
ありがとうございました。うまくいきました。
>>663
それのどこがドキュメントが多くてどんなメリットがある?
DOMならW3CとWHATWGで仕様書は揃うが、仕様書の数はjQueryよりも圧倒的に多いな
多いことがメリットとは全く思わんが、おまえさんの理論だとドキュメントが多い事がメリットになるらしいな
> あとな、jQueryを使わずに使って書いたコードの品質はどうでもいいのか
どうでもいいと思わないから>>652の意見なんだがね
>>635がオレオレライブラリならオレオレコードも避けるべきであり、そこにjQueryを使うか否かは関係しない
jQuery使いが書いたコードに「おまえ、そんなコード書いてるの?」とdisってるのと同じ
この程度のコードでオレオレコードも何もないとは思うがね
これは誰が書いても大抵同じようなコードになるものだろ
それのどこがドキュメントが多くてどんなメリットがある?
DOMならW3CとWHATWGで仕様書は揃うが、仕様書の数はjQueryよりも圧倒的に多いな
多いことがメリットとは全く思わんが、おまえさんの理論だとドキュメントが多い事がメリットになるらしいな
> あとな、jQueryを使わずに使って書いたコードの品質はどうでもいいのか
どうでもいいと思わないから>>652の意見なんだがね
>>635がオレオレライブラリならオレオレコードも避けるべきであり、そこにjQueryを使うか否かは関係しない
jQuery使いが書いたコードに「おまえ、そんなコード書いてるの?」とdisってるのと同じ
この程度のコードでオレオレコードも何もないとは思うがね
これは誰が書いても大抵同じようなコードになるものだろ
>>666
もしかして話の流れがわかってない?
DOM APIとjQueryの比較の話であれば、
DOM APIは明らかに冗長で、DOM APIを使うぐらいならば
jQueryを使ったほうがいいと俺は言ったんだよ。
そしたらDOM APIでもオレオレライブラリを使えば短く書けるってお前がいい出したんだろ?
だからオレオレライブラリはjQueryを超えられないって話をしたんだが。
一番の問題点はDOM APIは冗長ってところなんだよ。
そこにオレオレライブラリを持ってきても何の反論にもならないから持ってくんな。
話を戻すぞ? DOM APIはjQueryよりも冗長
もしかして話の流れがわかってない?
DOM APIとjQueryの比較の話であれば、
DOM APIは明らかに冗長で、DOM APIを使うぐらいならば
jQueryを使ったほうがいいと俺は言ったんだよ。
そしたらDOM APIでもオレオレライブラリを使えば短く書けるってお前がいい出したんだろ?
だからオレオレライブラリはjQueryを超えられないって話をしたんだが。
一番の問題点はDOM APIは冗長ってところなんだよ。
そこにオレオレライブラリを持ってきても何の反論にもならないから持ってくんな。
話を戻すぞ? DOM APIはjQueryよりも冗長
>>669
querySelectorAll 以外は jQuery と関係ない所でも使える汎用知識
(言い換えれば querySelectorAll 知っとけば
jQuery 知らなくともなんとかなる場合が多いかな)
querySelectorAll 以外は jQuery と関係ない所でも使える汎用知識
(言い換えれば querySelectorAll 知っとけば
jQuery 知らなくともなんとかなる場合が多いかな)
上の方でも書いたけど「可読性」とは言うけれど
「可書性」とは言わんのよ。
コピペすればそりゃ書くのは楽だろうけど、
「可書性」は重要なところじゃない。重要なのは「可読性」
snippetが何をいいたいのか知らんが、何をやっているか把握するために
他人がコードを読まないといけないのはだめなんだよ。
コードを読まずに、つまり記憶することで、読まなければいけないコードが減る。
些細な所を読まずに、本質的な所だけ読めばいいようにすることが高い可読性につながる。
>>670
「面倒くさい」っていう言葉には二通りあって覚えることが面倒くさい と
(少ない知識で)冗長に書くのが面倒くさい。
querySelectorAll知っとけばっていういのは、要するに
覚えることが面倒だから、読み書きするのが面倒な方を選ぶっていう考え
勉強したくねぇ、新しいこと学びたくねぇ、今までの効率の悪いやり方でいいじゃん。
と言ってるのと同じなんだ。
「可書性」とは言わんのよ。
コピペすればそりゃ書くのは楽だろうけど、
「可書性」は重要なところじゃない。重要なのは「可読性」
snippetが何をいいたいのか知らんが、何をやっているか把握するために
他人がコードを読まないといけないのはだめなんだよ。
コードを読まずに、つまり記憶することで、読まなければいけないコードが減る。
些細な所を読まずに、本質的な所だけ読めばいいようにすることが高い可読性につながる。
>>670
「面倒くさい」っていう言葉には二通りあって覚えることが面倒くさい と
(少ない知識で)冗長に書くのが面倒くさい。
querySelectorAll知っとけばっていういのは、要するに
覚えることが面倒だから、読み書きするのが面倒な方を選ぶっていう考え
勉強したくねぇ、新しいこと学びたくねぇ、今までの効率の悪いやり方でいいじゃん。
と言ってるのと同じなんだ。
記憶の底から、「オナペッツ」って単語が浮かび上がったのだが・・・
>>668
> オレオレライブラリではなく、snippetだと何度伝えても全く理解せず、オレオレライブラリを連呼してる
> いつの間にか「オレオレライブラリ VS jQuery」の図式だと勘違いして>>659で「ドキュメントの多さ」とかいうメリットにもならない意味不明な論理を展開した
「オレオレライブラリ VS jQuery」の図式じゃなくて
「オレオレsnippet VS jQuery」の図式だっていいたいのか?w
何も変わっとらんがw
で、結局お前の書いたものにはドキュメントも何も存在しないんだろう?
じゃあjQueryに劣ってるよね。
DOM APIはドキュメントは多くても、jQueryよりも記述量が多い。
(最初から言ってること)
> オレオレライブラリではなく、snippetだと何度伝えても全く理解せず、オレオレライブラリを連呼してる
> いつの間にか「オレオレライブラリ VS jQuery」の図式だと勘違いして>>659で「ドキュメントの多さ」とかいうメリットにもならない意味不明な論理を展開した
「オレオレライブラリ VS jQuery」の図式じゃなくて
「オレオレsnippet VS jQuery」の図式だっていいたいのか?w
何も変わっとらんがw
で、結局お前の書いたものにはドキュメントも何も存在しないんだろう?
じゃあjQueryに劣ってるよね。
DOM APIはドキュメントは多くても、jQueryよりも記述量が多い。
(最初から言ってること)
>>669
ES6のfor-ofはともかく、Array.prototypeぐらいは知っていてほしいとは思う
itetableはNodeListにSymbol.iterator なおまじないが必要で実装も選ぶ
ES6のfor-ofはともかく、Array.prototypeぐらいは知っていてほしいとは思う
itetableはNodeListにSymbol.iterator なおまじないが必要で実装も選ぶ
> 定型文はsnippetにするだろ
しねーよw
アホだろw
ライブラリで済むものはライブラリを使う。
当たり前だよね
しねーよw
アホだろw
ライブラリで済むものはライブラリを使う。
当たり前だよね
> ちょっとしたfor-of文やArray.prototype文をいちいちライブラリ化するわけがない
ライブラリっていうのは、ちょっとしたものをたくさん集めるから
ライブラリ(書庫)っていうんだよw
お前がほんの僅かしかsnippetを持ってないのなら、
所詮その程度の人間てことだし、
沢山あるのなら、ライブラリを使ったほうがいい。
ライブラリっていうのは、ちょっとしたものをたくさん集めるから
ライブラリ(書庫)っていうんだよw
お前がほんの僅かしかsnippetを持ってないのなら、
所詮その程度の人間てことだし、
沢山あるのなら、ライブラリを使ったほうがいい。
はい、みなさん。よく聞いて下さいね。
ライブラリを使わないとこうなります。
> おまえはsnippetコードに俺が書いたドキュメントを付けろといいたいのか
ドキュメントありません。
> そんなものは分からない人が教えを求めたときに教育すればすむ話
教育する必要があります。わからない人が5人いれば5人に教育
> 基礎知識が足りない人用にドキュメントを作るのは時間の無駄でしかない
だからドキュメントありませんw
> 必要ならMDNなり仕様書なりのドキュメントを読ませれば良かろう
snippetのドキュメントではありません。
こいつは自分が作ったsnippetを読めと言っています。
時間の無駄です。
有名ライブラリならば覚えれば、他の会社でだって使える知識です。
ライブラリを使わないとこうなります。
> おまえはsnippetコードに俺が書いたドキュメントを付けろといいたいのか
ドキュメントありません。
> そんなものは分からない人が教えを求めたときに教育すればすむ話
教育する必要があります。わからない人が5人いれば5人に教育
> 基礎知識が足りない人用にドキュメントを作るのは時間の無駄でしかない
だからドキュメントありませんw
> 必要ならMDNなり仕様書なりのドキュメントを読ませれば良かろう
snippetのドキュメントではありません。
こいつは自分が作ったsnippetを読めと言っています。
時間の無駄です。
有名ライブラリならば覚えれば、他の会社でだって使える知識です。
>>672
querySelectorAll知っとけばそれで済むとは言ってないが。
querySelectorAll知っとけばっていうのは、
jQueryを詳しく知らずともそれなりに使いこなせる、または
jQuery的なものを早く学習できる
すなわち、querySelectorAllも知っておくことに越したことは無い
という含みもある
querySelectorAll知っとけばそれで済むとは言ってないが。
querySelectorAll知っとけばっていうのは、
jQueryを詳しく知らずともそれなりに使いこなせる、または
jQuery的なものを早く学習できる
すなわち、querySelectorAllも知っておくことに越したことは無い
という含みもある
querySelectorAllは所詮手続き型なので、
jQueryみたいな関数型的なコードは書けない。
関数型的っていうのは処理を記述するのではなく
○○は○○であるのような定義を書くということ。
たとえば「.classはdisable属性がtrueである」のような書き方が
querySelectorAllではできない。
定義を記述するというやり方は、CSSと同じ。
CSSも.class { color: red} (.classの色は赤である)というような書き方をする。
この書き方をすることでループや条件分岐がなくなりバグが減る。
関数型の利点を知っている人ほどjQueryの素晴らしさが理解できる。
jQueryみたいな関数型的なコードは書けない。
関数型的っていうのは処理を記述するのではなく
○○は○○であるのような定義を書くということ。
たとえば「.classはdisable属性がtrueである」のような書き方が
querySelectorAllではできない。
定義を記述するというやり方は、CSSと同じ。
CSSも.class { color: red} (.classの色は赤である)というような書き方をする。
この書き方をすることでループや条件分岐がなくなりバグが減る。
関数型の利点を知っている人ほどjQueryの素晴らしさが理解できる。
質問板とか探したのですが無かったので失礼しますm(_ _)m
スマホサイトにスムーズにスクロールできるの機能を付けたいのですが、cssのwebkitとかリンク先までスムーズスクロールではなく表示範囲ををスルスルとスクロールできるようなのを探してます。
脱獄tweakのwebscrollianみたいな感じです。
色々と探したのですが変なエフェクトまでついてきてしまうのでその機能だけが欲しいです。
超初心者で申し訳ありませんが、どなたかご助言頂けると大変助かります。
お願いします。
スマホサイトにスムーズにスクロールできるの機能を付けたいのですが、cssのwebkitとかリンク先までスムーズスクロールではなく表示範囲ををスルスルとスクロールできるようなのを探してます。
脱獄tweakのwebscrollianみたいな感じです。
色々と探したのですが変なエフェクトまでついてきてしまうのでその機能だけが欲しいです。
超初心者で申し訳ありませんが、どなたかご助言頂けると大変助かります。
お願いします。
>>683
jQueryのanimateでできるんじゃね?
jQueryのanimateでできるんじゃね?
ミックのDB本を読むと、カーソルやループを使った、ぐるぐる系SQLを書くなと言う
ループ処理がなくなれば、バグが減るから、
SQLが難しくなっても、SQLだけで済ますべきと言う
ただ、メソッドチェーンは、パイプと同じで、どこでエラーが起こったのか、わからないのが欠点
A | B | C | D
A~Dのどこで、エラーが起きたのか、わからない
ループ処理がなくなれば、バグが減るから、
SQLが難しくなっても、SQLだけで済ますべきと言う
ただ、メソッドチェーンは、パイプと同じで、どこでエラーが起こったのか、わからないのが欠点
A | B | C | D
A~Dのどこで、エラーが起きたのか、わからない
同一ドメイン内で、
index.htmlに
iframe.htmlをiframeで埋め込んでいる場合に
両者で同じjavascript.jsファイルを読み込む場合、
ファイルのダウンロードは二回行われますか?
それとも、一回だけですか?
index.htmlに
iframe.htmlをiframeで埋め込んでいる場合に
両者で同じjavascript.jsファイルを読み込む場合、
ファイルのダウンロードは二回行われますか?
それとも、一回だけですか?
ブラウザや同じブラウザでも設定によって挙動が待った気違うからどっちでも対応できるようにしないとだめ
jQuery用のオレオレプラグインなら、メソッドチェーンでエラーになるかも
>>688
キャッシュで0回とか更新チェックのアクセスもあるかも知れない
キャッシュで0回とか更新チェックのアクセスもあるかも知れない
>>692
結論としては二回読み込まれてしまうんですか?
結論としては二回読み込まれてしまうんですか?
>>694
ネットワークアクセスは 1 回。
内部処理では2回に数えるかもしれないが、
どっちにしろ外からは違いは判別できないだろう
しかし、HTTPレスポンスでキャッシュ不可に設定されてる場合とか
どうなるんかな
ネットワークアクセスは 1 回。
内部処理では2回に数えるかもしれないが、
どっちにしろ外からは違いは判別できないだろう
しかし、HTTPレスポンスでキャッシュ不可に設定されてる場合とか
どうなるんかな
>>688
サーバ側で Last-Modified, Cache-Control を出力してHTTP 304 を正しく返せば、2回目以降の更新のない通信はキャッシュから読み込まれる
ただし、ブラウザにもキャッシュ制御の設定があるので、ブラウザの設定も確認する必要があるだろう
Fiddler やブラウザ付属の developper tools を使うことで通信の流れは確認できるのでブラウザとサーバの設定を確認しつつ、検証してみるといい
http://www.google.co.jp/search?q=If-Modified-Since+Last-Modified+Cache-Control+304
http://www.google.co.jp/search?q=chrome+developper+tools+network
http://www.google.co.jp/search?q=fiddler
サーバ側で Last-Modified, Cache-Control を出力してHTTP 304 を正しく返せば、2回目以降の更新のない通信はキャッシュから読み込まれる
ただし、ブラウザにもキャッシュ制御の設定があるので、ブラウザの設定も確認する必要があるだろう
Fiddler やブラウザ付属の developper tools を使うことで通信の流れは確認できるのでブラウザとサーバの設定を確認しつつ、検証してみるといい
http://www.google.co.jp/search?q=If-Modified-Since+Last-Modified+Cache-Control+304
http://www.google.co.jp/search?q=chrome+developper+tools+network
http://www.google.co.jp/search?q=fiddler
>>688
まあJavaScriptの質問でないことは確か
まあJavaScriptの質問でないことは確か
一般的にjQueryを使わずにJSだけで書くと処理速度や表示速度は速くなりますか?
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript & jQuery 質問用スレッド vol.8 + (1001) - [98%] - 2019/2/9 14:00
- + JavaScript & jQuery 質問用スレッド vol.7 + (701) - [98%] - 2022/12/19 17:15
- + JavaScript & jQuery 質問用スレッド vol.7 + (993) - [98%] - 2017/11/10 8:15
- + JavaScript & jQuery 質問用スレッド vol.6 + (980) - [98%] - 2016/11/20 14:31
- + JavaScript の質問用スレッド vol.95 + (1001) - [72%] - 2012/1/17 4:16
- + JavaScript の質問用スレッド vol.75 + (1001) - [72%] - 2010/1/23 1:07 ○
- + JavaScript の質問用スレッド vol.85 + (1001) - [72%] - 2011/4/25 21:32
- + JavaScript の質問用スレッド vol.135 + (1002) - [70%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.105 + (1001) - [70%] - 2013/5/20 4:45
- + JavaScript の質問用スレッド vol.125 + (1001) - [70%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [70%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.93 + (1001) - [70%] - 2011/12/10 18:31
トップメニューへ / →のくす牧場書庫について