私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.143 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
前へ
念の為にいっておくが、>>500は俺ではないからな
自演疑われたくないならsageなきゃ良いだけじゃん
逆にそうしないのは自演だと思われても構いませんよってことだろう
逆にそうしないのは自演だと思われても構いませんよってことだろう
念の為にいっておくが、>>502は俺ではないからな
念の為にいっておくが、>>504は俺ではないからな
>>512, 513
早速ありがとうございます。私が試している画像では、レンダリングがされなくて、
かえって見にくくなってしましました（涙）。残念…。
検証画像でもそうなのですが、表示されているものをマウスでドラッグしてローカルに
取り込んで開いてみると、表示されているものよりだいぶ綺麗なんですよね。同じ webkit
でも、なぜ Mac の Safariだけ？
早速ありがとうございます。私が試している画像では、レンダリングがされなくて、
かえって見にくくなってしましました（涙）。残念…。
検証画像でもそうなのですが、表示されているものをマウスでドラッグしてローカルに
取り込んで開いてみると、表示されているものよりだいぶ綺麗なんですよね。同じ webkit
でも、なぜ Mac の Safariだけ？
>>516
一応、ソースのパッケージにはデモのセットが入っているので、「image-rendering: -webkit-crisp-edges; 」
を入れて確認しました。確かにデモの写真ではぼやけは解消されていますね。
私が使っているのは線画なのですが、それだとこうはいかないみたいなんです。画像はどうやら
「解像度を調整」＋「レンダリング」という手順で処理されているみたいですが、線画だと
の前半の「解像度の調整」でかなり荒い画像になるみたいんです。
実はその処理はデモ画像中の文字にもかかっていて、ChromeやFirefoxで閲覧した画像と比べると、
フォントもかなりぼやけているのが見ていただけると思います。写真も綺麗になっているようには
見えますが、他のブラウザと比べるとやはり荒さが見て取れます。
一応、ソースのパッケージにはデモのセットが入っているので、「image-rendering: -webkit-crisp-edges; 」
を入れて確認しました。確かにデモの写真ではぼやけは解消されていますね。
私が使っているのは線画なのですが、それだとこうはいかないみたいなんです。画像はどうやら
「解像度を調整」＋「レンダリング」という手順で処理されているみたいですが、線画だと
の前半の「解像度の調整」でかなり荒い画像になるみたいんです。
実はその処理はデモ画像中の文字にもかかっていて、ChromeやFirefoxで閲覧した画像と比べると、
フォントもかなりぼやけているのが見ていただけると思います。写真も綺麗になっているようには
見えますが、他のブラウザと比べるとやはり荒さが見て取れます。
>>509
URL に文字列を入れるのなら、特殊文字をURI encode する必要があるのでは？
URL に文字列を入れるのなら、特殊文字をURI encode する必要があるのでは？
letとvarの違いが分かんなくなっちまったから教えてくれん？
for(let i)とfor(var i)でメモリパフォーマンスに違いはあるんかね。
letはループ毎に変数生成されるからメモリに悪そうなイメージだけど実際の所どうなの？
for(let i)とfor(var i)でメモリパフォーマンスに違いはあるんかね。
letはループ毎に変数生成されるからメモリに悪そうなイメージだけど実際の所どうなの？
今は、let
var は非推奨。
スコープの解釈が色々あって、バグるので難しい
var は非推奨。
スコープの解釈が色々あって、バグるので難しい
gulpは、メソッドチェーンで書けるから、左から右へ読めるけど、
npm scripts は書きにくい
VSCode, Node.js, webpack, babel を使っているけど、
webpack-dev-server を使うのが普通なのか？
npm scripts は書きにくい
VSCode, Node.js, webpack, babel を使っているけど、
webpack-dev-server を使うのが普通なのか？
>>521
varの関数スコープ以外の解釈はよ
varの関数スコープ以外の解釈はよ
var は、巻き上げが起こるので、ややこしい
var x = 0;
function f ( ) {
console.log(x); //=> undefined
var x = 1;
}
f( )
var x = 0;
function f ( ) {
console.log(x); //=> undefined
var x = 1;
}
f( )
>>524
varの関数スコープ以外の解釈はよ
色々あるんだろ？早くしろノロマ
521 Name_Not_Found sage 2020/03/24(火) 09:07:11.24 ID:???
今は、let
var は非推奨。
スコープの解釈が色々あって、バグるので難しい
varの関数スコープ以外の解釈はよ
色々あるんだろ？早くしろノロマ
521 Name_Not_Found sage 2020/03/24(火) 09:07:11.24 ID:???
今は、let
var は非推奨。
スコープの解釈が色々あって、バグるので難しい
な？誰もパフォーマンスの問題なんて気にしてねーだろ？
パフォーマンス以外のもっと重要なことに目が行かない時点で
初心者なんだよ
パフォーマンス以外のもっと重要なことに目が行かない時点で
初心者なんだよ
chromeしか知らんけどlet, const実装から結構長い間varのほうが速かったよ。
今はlet, const有利な実装に切り替えたらしい。
要するに実装依存で、ループ毎に変数生成～とかはあまり関係がない。
まだvarのほうが速い実装もあるかもしれない。
ちなみにconstが一番速い。
そしてその差は微々たるもの。
今はlet, const有利な実装に切り替えたらしい。
要するに実装依存で、ループ毎に変数生成～とかはあまり関係がない。
まだvarのほうが速い実装もあるかもしれない。
ちなみにconstが一番速い。
そしてその差は微々たるもの。
再代入したくないからconst
てかもう感覚がvarを拒否してる
lintでチェックするからどうでもいいけど
var使ってるエンジニアいたらビビるわ
てかもう感覚がvarを拒否してる
lintでチェックするからどうでもいいけど
var使ってるエンジニアいたらビビるわ
パフォーマンス気にしてletとvarの使い分けより、もっと他にパフォーマンスに気を遣うべき部分があるだろう
質問とはまるで見当違いな部分でごちゃごちゃマウント取るアスペども(笑)
せめて回答叩き付けてから語るならまだしも、スレのレベルが低すぎる
及第点なのは527だけやな
せめて回答叩き付けてから語るならまだしも、スレのレベルが低すぎる
及第点なのは527だけやな
>>536
ごちゃごちゃ言う前に自分で実測しろ
ごちゃごちゃ言う前に自分で実測しろ
藻舞らを、プロと見込んで聞いているのに、
webpack-dev-server を使っている香具師は、いないの？
所感を希望
webpack-dev-server を使っている香具師は、いないの？
所感を希望
>>542
各スレでのうんこruby駄文テロ辞めたら答えてやるよカス
各スレでのうんこruby駄文テロ辞めたら答えてやるよカス
巻き上げはletでも起こる
そもそも変数とはスコープに属するものなのでそれが当たり前。
letは変数を初期化しないだけ。TDZは存在の巻き上げはが起こっていない範囲ではなく、存在するが初期化がまだな範囲。
何回言ったら理解してくれるんだろうな。
そもそも変数とはスコープに属するものなのでそれが当たり前。
letは変数を初期化しないだけ。TDZは存在の巻き上げはが起こっていない範囲ではなく、存在するが初期化がまだな範囲。
何回言ったら理解してくれるんだろうな。
とにかく極力const
どうしようもないときはlet使えばよくね
巻き上げ以上の仕様はマニアだけ読めばよくね？
どうしようもないときはlet使えばよくね
巻き上げ以上の仕様はマニアだけ読めばよくね？
>>545
今でもvarを使ってる理由は、顧客の環境がlet使えないから
って書いてあるだろ
パフォーマンスのためにvar使ってるなんて書いてないだろ
顧客の環境がlet使えないからvar使ってんなら
babel使えってことだろ
今でもvarを使ってる理由は、顧客の環境がlet使えないから
って書いてあるだろ
パフォーマンスのためにvar使ってるなんて書いてないだろ
顧客の環境がlet使えないからvar使ってんなら
babel使えってことだろ
>>546
varのメモリパフォーマンスが良いことがあるんですね！
letやconstのメリットはよくわからないですが
パフォーマンスが良い方というのはわかります。
メモリパフォーマンスが良い方が適切な変数宣言ですものね！
と初心者は言う
varのメモリパフォーマンスが良いことがあるんですね！
letやconstのメリットはよくわからないですが
パフォーマンスが良い方というのはわかります。
メモリパフォーマンスが良い方が適切な変数宣言ですものね！
と初心者は言う
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.141 + (881) - [97%] - 2021/4/19 9:00
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.103 + (1001) - [97%] - 2012/11/9 15:30
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.141 + (1001) - [97%] - 2019/9/22 23:15
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.122 + (116) - [95%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.122 + (1004) - [95%] - 2015/2/14 4:45
- + 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
トップメニューへ / →のくす牧場書庫について