私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.141 +

みんなの評価 :
レスフィルター : (試験中)
>>696
今回の質問のような検索は量子コンピュータに向いてる
今回の質問のような検索は量子コンピュータに向いてる
HTMLスレとどちらに書こうか一瞬迷ったけど
最新版のChromeに更新したらcoverageバグってないか?
通してないifルートもパスしたことになっちゃう
ブレークポイント仕掛けてもブレークしないから実際に通ってない
Promiseのcatchというかrejectルートはパスしてない表示なんで、全部おかしいわけじゃない
最新版のChromeに更新したらcoverageバグってないか?
通してないifルートもパスしたことになっちゃう
ブレークポイント仕掛けてもブレークしないから実際に通ってない
Promiseのcatchというかrejectルートはパスしてない表示なんで、全部おかしいわけじゃない
>>703
再現性のあるコードを出して
再現性のあるコードを出して
>>704
開発者ツールのSourcesでCoverage出して再読み込み
カバーされてない行は行番号横のラインが赤く表示される
関数内の通してないifブロックの行も今までは赤く出てた、と思う
昨日、Chromeの更新マークが出てたんで更新した
そして今日Coverageを実行したら赤く出なくなってた
開発者ツールのSourcesでCoverage出して再読み込み
カバーされてない行は行番号横のラインが赤く表示される
関数内の通してないifブロックの行も今までは赤く出てた、と思う
昨日、Chromeの更新マークが出てたんで更新した
そして今日Coverageを実行したら赤く出なくなってた
あのねぇ……
関数っていうのは定義時に例外判定で捜査される以外に、
呼び出しの瞬間に中の(ネストされた関数内を除く)構文が一度すべて評価されるの
じゃないと変数宣言とか処理できないでしょ?
だから関数が呼ばれた時点で中身はすべてカバーされたことになるのよ
わかる?
いくらif(false){}だろうが
もしif(false){var x}みたいな記述があったら当然関数全体に影響するでしょ?
実行系のバグを疑うのは最後の最後
最低でもbugs.chromium.orgくらいは見て考えてからにしたほうがいいよ
「。。。と思う」とか最悪だから
なんで君の妄言に俺らが付き合わないといけないの?
関数っていうのは定義時に例外判定で捜査される以外に、
呼び出しの瞬間に中の(ネストされた関数内を除く)構文が一度すべて評価されるの
じゃないと変数宣言とか処理できないでしょ?
だから関数が呼ばれた時点で中身はすべてカバーされたことになるのよ
わかる?
いくらif(false){}だろうが
もしif(false){var x}みたいな記述があったら当然関数全体に影響するでしょ?
実行系のバグを疑うのは最後の最後
最低でもbugs.chromium.orgくらいは見て考えてからにしたほうがいいよ
「。。。と思う」とか最悪だから
なんで君の妄言に俺らが付き合わないといけないの?
付き合うも付き合わぬもあなた次第
気に入らなければ喧嘩売るよりスルーしましょう
気に入らなければ喧嘩売るよりスルーしましょう
87と89で試したけど動きが変わってるのは確かだね
87だとなぜかPer functionでもif(false)を含めた3行が赤くなったが
89だとPer blockにしないとダメだった
修正項目にはあがってないけどなんか手入れたんじゃね?
87だとなぜかPer functionでもif(false)を含めた3行が赤くなったが
89だとPer blockにしないとダメだった
修正項目にはあがってないけどなんか手入れたんじゃね?
89でも関数の先頭行にブレークポイントを設定してF8とかで最後まで実行した時は
Per functionを選択しててもif(false)を含めた3行は赤くなるな
ブレークポイントの位置でも結果が変わるから
こういうやり方でカバレッジを見るのは想定してないのかもしれないが
Per functionを選択しててもif(false)を含めた3行は赤くなるな
ブレークポイントの位置でも結果が変わるから
こういうやり方でカバレッジを見るのは想定してないのかもしれないが
そうか逆なのかもしれませんね
今までも Per function だったけど何故か Per block として動いていたのがバグで
今回の更新で正しく Per function として動くようになった
と
今までも Per function だったけど何故か Per block として動いていたのがバグで
今回の更新で正しく Per function として動くようになった
と
イベントリスナの登録順序って先に読み込まれた方が上に来ると考えてよいのでしょうか?
2つの.jsファイルがあって、それぞれload完了後に処理が走るようになっているのですが
ファイルを読み込む順番を変えてもイベントリスナの登録順序は変わらなかったです。
今はcapture tureを使って制御しているのですが、可能であれば登録順序側で
制御したいです。
2つの.jsファイルがあって、それぞれload完了後に処理が走るようになっているのですが
ファイルを読み込む順番を変えてもイベントリスナの登録順序は変わらなかったです。
今はcapture tureを使って制御しているのですが、可能であれば登録順序側で
制御したいです。
$('#flg_' + n).attr('checked', !0) みたいな記述で、
1 や true でなく !0 とするのはどんな意味があるのでしょうか?
1 や true でなく !0 とするのはどんな意味があるのでしょうか?
年食うと細かい文字がキツイんでtrue/falseで通すがlinterが ! 使えば?とか言ってくるのがウザい
どの言語でもlinter導入すると、まず改行系と省略系を殺す設定を探すところから始まる
どの言語でもlinter導入すると、まず改行系と省略系を殺す設定を探すところから始まる
>>717
javascriptにおいてはまったく無意味なコードなんで格好つけてるだけですよ
javascriptにおいてはまったく無意味なコードなんで格好つけてるだけですよ
minifyってなんだろうーと思って調べてみたら
web系はインデントなんかも読み込み遅くさせる要因なのか…
初学者にはお勉強になりました 完成したら改行程度は残して詰めちゃおっと
web系はインデントなんかも読み込み遅くさせる要因なのか…
初学者にはお勉強になりました 完成したら改行程度は残して詰めちゃおっと
>>725
世界的には数十Kbpsしか出ない環境もまだまだあるからminifyが流行ってるが
日本じゃインデントをどうにかしたくらいじゃ誤差程度にしか変わらん
やるとしたら今策定中のバイナリastを送るのはパースまで含めて大きな効果が期待できる。
あと5年まて
世界的には数十Kbpsしか出ない環境もまだまだあるからminifyが流行ってるが
日本じゃインデントをどうにかしたくらいじゃ誤差程度にしか変わらん
やるとしたら今策定中のバイナリastを送るのはパースまで含めて大きな効果が期待できる。
あと5年まて
だから人間が書く時にやるんじゃねぇって
network traffic的にはgzipしてればminifyの有無では数%しか変わらないがそれに価値がある場合もある
network以外でもparse & loadはサイズが小さいほうが有利
network traffic的にはgzipしてればminifyの有無では数%しか変わらないがそれに価値がある場合もある
network以外でもparse & loadはサイズが小さいほうが有利
>>723
策定中ということは、ファイルの読み込み順序を変えることは意味がないってことなのですか?
策定中ということは、ファイルの読み込み順序を変えることは意味がないってことなのですか?
あと5年待てと言うが5年後には状況変わってると思う
来年には待望のIntel7nmCPU(PC向け)が出る
3年後には5nm、そしてチップ積層化、メニーコア化
5年以上前からIntelのPC向けCPUは大きく成長していないが、漸くここ数年で大きく成長できそうな目処が付いてる
パース周りは勿論、他にもworklet系もそのメニーコアを活かす形でまともに使えるようになってるでしょ
ミニファイとかアイコン画像を1枚にまとめていたような半ば黒歴史になるだけだと思うけどね
来年には待望のIntel7nmCPU(PC向け)が出る
3年後には5nm、そしてチップ積層化、メニーコア化
5年以上前からIntelのPC向けCPUは大きく成長していないが、漸くここ数年で大きく成長できそうな目処が付いてる
パース周りは勿論、他にもworklet系もそのメニーコアを活かす形でまともに使えるようになってるでしょ
ミニファイとかアイコン画像を1枚にまとめていたような半ば黒歴史になるだけだと思うけどね
>>733
その辺の事情はあまり関係ないと思う
コードの圧縮や画像のスプライトは
1ページのユーザビリティを考えて出来たものではなく
大アクセスのあるサイト運営のコストとなる
伝送量やリクエスト数を減らそうというものだから
なのでその辺のテクニックが黒歴史化するのは
ハードウェアやブラウザなどの進化ではなく
サーバと回線を売るビジネスが変わったときになるはず
その辺の事情はあまり関係ないと思う
コードの圧縮や画像のスプライトは
1ページのユーザビリティを考えて出来たものではなく
大アクセスのあるサイト運営のコストとなる
伝送量やリクエスト数を減らそうというものだから
なのでその辺のテクニックが黒歴史化するのは
ハードウェアやブラウザなどの進化ではなく
サーバと回線を売るビジネスが変わったときになるはず
それは理想的な話
この世界は理想通りでは動かない
実際ベストプラクティスみたいにされて
そんな伝送量気にしなくていいサイトまで使ってたしな
ただハードの事情が直接関係ないというのは合ってる
そういうのはただの流行り廃りでしかないからね
この世界は理想通りでは動かない
実際ベストプラクティスみたいにされて
そんな伝送量気にしなくていいサイトまで使ってたしな
ただハードの事情が直接関係ないというのは合ってる
そういうのはただの流行り廃りでしかないからね
>>740
そうそう
この手の技術が生まれた頃は
伝送量いくらまでおいくら万円という
携帯電話のプランのような段階的な契約を
データセンターやサイト自体が回線事業者としていた
それが現代ではAWSのようなクラウド鯖や
akamaiのようなCDNになって
もっと細かな従量課金になったので
小アクセスでもこの手の伝送量削減のテクニックは
むしろ活かされやすくなった
そうそう
この手の技術が生まれた頃は
伝送量いくらまでおいくら万円という
携帯電話のプランのような段階的な契約を
データセンターやサイト自体が回線事業者としていた
それが現代ではAWSのようなクラウド鯖や
akamaiのようなCDNになって
もっと細かな従量課金になったので
小アクセスでもこの手の伝送量削減のテクニックは
むしろ活かされやすくなった
アイコンをまとめても伝送量削減にはならんでしょ
使わないアイコンだって含まれているだろうし
もし100%使うとしてもそれを制御するJSやCSSの分伝送量が増えるんだから
それで伝送量を減らそうというのは継続的に相当難しいことだと思うよ
レスポンスの事考えてもHTTP2で数が多いファイルの伝送効率上がったしね
Googleくらいのアクセスがあって初めて効果があるようなこと
そのGoogleでも1回しか使われないアイコンはインラインSVGにするとか
1枚に組み合わせるのではなくて何枚かに分ける
(1つの目的は読み込み順と表示位置からくるレスポンス担保のため)
とか本当に様々な工夫と組み合わせて使ってるし
ただアイコンは1枚にバンドルすればいいというものではけしてない
素人は勿論、普通レベルのデベロッパーもやらない方がいい
使わないアイコンだって含まれているだろうし
もし100%使うとしてもそれを制御するJSやCSSの分伝送量が増えるんだから
それで伝送量を減らそうというのは継続的に相当難しいことだと思うよ
レスポンスの事考えてもHTTP2で数が多いファイルの伝送効率上がったしね
Googleくらいのアクセスがあって初めて効果があるようなこと
そのGoogleでも1回しか使われないアイコンはインラインSVGにするとか
1枚に組み合わせるのではなくて何枚かに分ける
(1つの目的は読み込み順と表示位置からくるレスポンス担保のため)
とか本当に様々な工夫と組み合わせて使ってるし
ただアイコンは1枚にバンドルすればいいというものではけしてない
素人は勿論、普通レベルのデベロッパーもやらない方がいい
http2で思ったほど効率上げられなくてあっという間にhttp3策定されちゃったよね
>>742
スプライトはリクエスト数が減るんだよ
スプライトはリクエスト数が減るんだよ
同一ページや共通ページで使う画像とかに対して普通やるもんだから
いらん画像なんて入れるのはただのアホやで
いらん画像なんて入れるのはただのアホやで
gifアニメーション的な動きを多方位でやらせるために
html5ベースのゲームで多用されてる
html5ベースのゲームで多用されてる
種々の最適化は手間と効果の兼合いだから採用しないってのも十分あり
minifyについてはそんなん考える前にビルド時に自動で走らせる場合が多い気がするけど
minifyについてはそんなん考える前にビルド時に自動で走らせる場合が多い気がするけど



類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (1001) - [100%] - 2019/9/22 23:15
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [97%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.101 + (1001) - [97%] - 2012/7/16 14:15
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.102 + (1001) - [95%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.123 + (966) - [95%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.122 + (116) - [95%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.100 + (1001) - [95%] - 2012/6/13 22:46
トップメニューへ / →のくす牧場書庫について