私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.142 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>443
すみません。追記です。
forEach内での関数のvar宣言をした場合配列の数だけ繰り返し宣言されてしまうが
呼び出しであれば、宣言は1回と考えていいのでしょうか?
また、変数や配列の場合forEach内で宣言させないことで、多少なりとも速度に影響はでるのでしょうか?
すみません。追記です。
forEach内での関数のvar宣言をした場合配列の数だけ繰り返し宣言されてしまうが
呼び出しであれば、宣言は1回と考えていいのでしょうか?
また、変数や配列の場合forEach内で宣言させないことで、多少なりとも速度に影響はでるのでしょうか?
>>442
Windows10 で、Edge, Chrome で実行したが、正常に、1回ずつ表示される!
Windows10 で、Edge, Chrome で実行したが、正常に、1回ずつ表示される!
>>450
ここで誰かがこっちの方が良いと言えば一生それに従うのか?
そういう言語もあるがJSでは言語としてこっちのスタイルが標準的という決めごとはない
JSは壮年期に差し掛かっているかもしれないがまだまだいくらでも成長する言語だ
流行は勿論気にし続けないといけないが、それと同時に自由に常に自分で模索し続けて
自分なりの様々な感覚を養っていくことがWebやJSにおいては重要
それにどっちが自然かなんて全体的な様子で変わる
ここで誰かがこっちの方が良いと言えば一生それに従うのか?
そういう言語もあるがJSでは言語としてこっちのスタイルが標準的という決めごとはない
JSは壮年期に差し掛かっているかもしれないがまだまだいくらでも成長する言語だ
流行は勿論気にし続けないといけないが、それと同時に自由に常に自分で模索し続けて
自分なりの様々な感覚を養っていくことがWebやJSにおいては重要
それにどっちが自然かなんて全体的な様子で変わる
>>445
どちらかというと逆でしょ
普通はインライン化されて、関数の中身がforEach内に展開されて
さらにforEach内全体で最適化がかかる
でもそこまで最適化されることは実際には少ない
最近のエンジンはインタプリタ強化に回帰していて
省メモリとかオーバーヘッド削減に力を入れている
どちらかというと逆でしょ
普通はインライン化されて、関数の中身がforEach内に展開されて
さらにforEach内全体で最適化がかかる
でもそこまで最適化されることは実際には少ない
最近のエンジンはインタプリタ強化に回帰していて
省メモリとかオーバーヘッド削減に力を入れている
昔は推奨された書き方が今では遅いなんてのが結構あるからね
ブラウザによっても逆転するから一概に言えない
ブラウザによっても逆転するから一概に言えない
>>453
主流なんて無い
極論を考えれば全部グローバルに宣言を出すのも馬鹿らしいし、
最小限になるようできるだけ細かく多くのスコープを区切るのも馬鹿らしい
どちらにすべきかではなくて、バランスを取ってその時その時で全体的に自然に書けとしか言えん
比較演算子で定数をどちらに置くべきかとか、拘るのが馬鹿らしい問題というのは数多くある
そんなことにいちいち惑わされる暇があったら別のところに時間を使え
主流なんて無い
極論を考えれば全部グローバルに宣言を出すのも馬鹿らしいし、
最小限になるようできるだけ細かく多くのスコープを区切るのも馬鹿らしい
どちらにすべきかではなくて、バランスを取ってその時その時で全体的に自然に書けとしか言えん
比較演算子で定数をどちらに置くべきかとか、拘るのが馬鹿らしい問題というのは数多くある
そんなことにいちいち惑わされる暇があったら別のところに時間を使え
>>456
極論についてはおっしゃる通りですね。
ESの仕様を理解はできていませんがバランスを見つつ改善を続けていきます。
関数やら変数の宣言って、最初の読み込み時にエンジンが把握するためのもので、
呼び出し時に宣言されるってことではないですよね?
それだとスクロールイベントで宣言した場合、毎回宣言されて大変ですよね?
極論についてはおっしゃる通りですね。
ESの仕様を理解はできていませんがバランスを見つつ改善を続けていきます。
関数やら変数の宣言って、最初の読み込み時にエンジンが把握するためのもので、
呼び出し時に宣言されるってことではないですよね?
それだとスクロールイベントで宣言した場合、毎回宣言されて大変ですよね?
最適化は仕様にない。各社、自由だろ。
無数にある環境・ブラウザの組み合わせを、考えても無駄!
例えば「Effective Ruby、2015」の項目47 では、
ループ内で、文字列リテラルを使うと、
文字列が生成して、すぐに破棄されるから無駄なので、ループ外に出す
次に、Ruby 2.1 では、文字列リテラル.freeze で、
文字列は、1回しか作られないから、ループ内でも大丈夫
次に、Ruby 2.3 では、スクリプトファイルの1行目に、
# frozen_string_literal: true
と書くと、すべての文字列リテラルは、immutable になる
このように最適化は、ドンドン変わっていく!
無数にある環境・ブラウザの組み合わせを、考えても無駄!
例えば「Effective Ruby、2015」の項目47 では、
ループ内で、文字列リテラルを使うと、
文字列が生成して、すぐに破棄されるから無駄なので、ループ外に出す
次に、Ruby 2.1 では、文字列リテラル.freeze で、
文字列は、1回しか作られないから、ループ内でも大丈夫
次に、Ruby 2.3 では、スクリプトファイルの1行目に、
# frozen_string_literal: true
と書くと、すべての文字列リテラルは、immutable になる
このように最適化は、ドンドン変わっていく!
>>457
宣言文というのは、関数コンテキスト生成時と、コンテキスト実行開始(スコープ到達)時、宣言文到達時にそれぞれ働きがある
宣言文というのは、関数コンテキスト生成時と、コンテキスト実行開始(スコープ到達)時、宣言文到達時にそれぞれ働きがある
仕様書なんて英語の文章としては超絶簡単な部類
その大部分がa is b , b is cで積み重ねだから
読むために必要な能力って言ったら追っかけ力だけで
それは読んでれば勝手に身につく
その大部分がa is b , b is cで積み重ねだから
読むために必要な能力って言ったら追っかけ力だけで
それは読んでれば勝手に身につく
その考え方でよい
実行速度にシビアな場面で初めて優先順位が変わる
実行速度にシビアな場面で初めて優先順位が変わる
あと念の為補足すると
varはブロックに入れてもスコープは狭くならない
varはブロックに入れてもスコープは狭くならない
>>465
宣言文というものはスコープに変数を作らないといけない
スコープが作られるのは宣言文より前のステップだ
だから実際宣言文に達する前にスコープを作る段階で働く
ステップが宣言文に達したらまた別の働きをする
他の多くの構文にもこのようにRuntimeな働きとStaticな働きと言うものがある
宣言文というものはスコープに変数を作らないといけない
スコープが作られるのは宣言文より前のステップだ
だから実際宣言文に達する前にスコープを作る段階で働く
ステップが宣言文に達したらまた別の働きをする
他の多くの構文にもこのようにRuntimeな働きとStaticな働きと言うものがある
今のJS初心者なんで
とりあえずletにしとこ、程度なんだけど
constにすると大きく違うシーンってどんなのがありますん?
自分じゃない人がメンテするときに
不用意に上書きされないってのはいいとは思うんですが
とりあえずletにしとこ、程度なんだけど
constにすると大きく違うシーンってどんなのがありますん?
自分じゃない人がメンテするときに
不用意に上書きされないってのはいいとは思うんですが
基本は、オブジェクトは可能な限りfreezeかsealしなくてはならない
基本は、等価判定は可能な限りObject.isを使わなければならない
基本は、可能な限りaltJSで書かなければならない
基本は、等価判定は可能な限りObject.isを使わなければならない
基本は、可能な限りaltJSで書かなければならない
問題に神経質に対処しようとするのではなく
おおらかに問題を飲み込むコーディングができない人にはJSは難しい
おおらかに問題を飲み込むコーディングができない人にはJSは難しい
>>468
この文なんかおかしい。
いやletはブロックスコープで、関数直下に書くと関数スコープと一致するからそれはいいんだけどvarは関数スコープだから「letで宣言してスコープを関数内に留めるのがいいかも」って言及はなんか違う。
だってvarで書いても関数スコープなんだもん。
letの使用を推奨するのはいいんだけどその理由の説明が間違ってる。
この文なんかおかしい。
いやletはブロックスコープで、関数直下に書くと関数スコープと一致するからそれはいいんだけどvarは関数スコープだから「letで宣言してスコープを関数内に留めるのがいいかも」って言及はなんか違う。
だってvarで書いても関数スコープなんだもん。
letの使用を推奨するのはいいんだけどその理由の説明が間違ってる。
>>475
forEachの第一引数がcallbackで第二引数がthisArgとあるが第三引数なんて出てないが。
forEachの第一引数がcallbackで第二引数がthisArgとあるが第三引数なんて出てないが。
IE対応でletやらconstやらclass構文使えてないです。
その辺の理解が浅いと転職できないですか。
その辺の理解が浅いと転職できないですか。
>>479
Uncaught SyntaxError: Unexpected identifier
Uncaught SyntaxError: Unexpected identifier
>>481
babel先生のお世話になってみるのはいかが?
babel先生のお世話になってみるのはいかが?
letやらconstやらclass構文使えない環境で頑張ってきていたら
むしろスコープや定数やクラスシステムを振る舞いから表現まで気にして
JSのバックグラウンドにも詳しくなってるはずだから
それらの構文を扱うのに経験なんて必要なく知って数日で馴染めるでしょ
むしろスコープや定数やクラスシステムを振る舞いから表現まで気にして
JSのバックグラウンドにも詳しくなってるはずだから
それらの構文を扱うのに経験なんて必要なく知って数日で馴染めるでしょ
chromeで動いていた重いJavaScriptが
vivaldiだと落ちます
おそらく処理時間が長すぎるとタイムアウトを起こすようになってるんじゃないかと思いますが
ブラウザによってタイムアウトのメカニズムがあったりなかったりすると困りますよね?
処理時間が長くなる場合はsetTimeoutなどを使ってはじめから処理を細切れにしておくべきなのでしょうか?
vivaldiだと落ちます
おそらく処理時間が長すぎるとタイムアウトを起こすようになってるんじゃないかと思いますが
ブラウザによってタイムアウトのメカニズムがあったりなかったりすると困りますよね?
処理時間が長くなる場合はsetTimeoutなどを使ってはじめから処理を細切れにしておくべきなのでしょうか?
今COTでScroll To Text使えるけど
これがデフォオンになったらいよいよjQueryとプラグインから卒業できるわ
これがデフォオンになったらいよいよjQueryとプラグインから卒業できるわ
jQueryは使ってるけど、jQueryプラグインは使ってないなぁ
jQueryは自分で実装するのが手間だから使うものだよ。
プラグインのためじゃない。普段コードを書かない人なのかな?
jQueryは自分で実装するのが手間だから使うものだよ。
プラグインのためじゃない。普段コードを書かない人なのかな?
クリックイベントとかの元々の処理を無効にする記述って
どのタイミングで書くかで変わったりする?
重たいしょりが思いつかなくて計測しても違いがわかりません
下の奴です
e.preventDefault();
jQueryと違ってイベント発火直後がいいのかな?
どのタイミングで書くかで変わったりする?
重たいしょりが思いつかなくて計測しても違いがわかりません
下の奴です
e.preventDefault();
jQueryと違ってイベント発火直後がいいのかな?
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.142 + (984) - [100%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.102 + (1001) - [97%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.141 + (881) - [97%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.141 + (1001) - [97%] - 2019/9/22 23:15
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.123 + (966) - [95%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.123 + (1002) - [95%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.115 + (1001) - [95%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2015/1/1 18:30
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2022/11/29 16:30
- + JavaScript の質問用スレッド vol.120 + (1002) - [95%] - 2014/11/8 1:15
トップメニューへ / →のくす牧場書庫について