のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,432,532人
頁
昨日:no data人
頁
今日:人
頁
最近の注目
人気の最安値情報

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

JavaScript覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

501 = :

念の為にいっておくが、>>500は俺ではないからな

502 :

自演疑われたくないならsageなきゃ良いだけじゃん
逆にそうしないのは自演だと思われても構いませんよってことだろう

503 = :

まああげても自演って言うけどな！

504 = :

念の為にいっておくが、>>502は俺ではないからな

505 = :

念の為にいっておくが、>>504は俺ではないからな

506 = :

>>502
以前、そう伝えたら、「やりたきゃ勝手にやれ。俺は一向に困らん。」といわれた
困らんのなら、「俺ではない」発言が不要なはずなんだけどな

514 = :

ありがとうございました！

515 = :

>>512, 513
早速ありがとうございます。私が試している画像では、レンダリングがされなくて、
かえって見にくくなってしましました（涙）。残念…。

検証画像でもそうなのですが、表示されているものをマウスでドラッグしてローカルに
取り込んで開いてみると、表示されているものよりだいぶ綺麗なんですよね。同じ webkit
でも、なぜ Mac の Safariだけ？

517 = :

>>516
一応、ソースのパッケージにはデモのセットが入っているので、「image-rendering: -webkit-crisp-edges; 」
を入れて確認しました。確かにデモの写真ではぼやけは解消されていますね。

私が使っているのは線画なのですが、それだとこうはいかないみたいなんです。画像はどうやら
「解像度を調整」＋「レンダリング」という手順で処理されているみたいですが、線画だと
の前半の「解像度の調整」でかなり荒い画像になるみたいんです。

実はその処理はデモ画像中の文字にもかかっていて、ChromeやFirefoxで閲覧した画像と比べると、
フォントもかなりぼやけているのが見ていただけると思います。写真も綺麗になっているようには
見えますが、他のブラウザと比べるとやはり荒さが見て取れます。

519 = :

letとvarの違いが分かんなくなっちまったから教えてくれん？

for(let i)とfor(var i)でメモリパフォーマンスに違いはあるんかね。
letはループ毎に変数生成されるからメモリに悪そうなイメージだけど実際の所どうなの？

520 = :

>>519
初心者＝計測せずにパフォーマンスがーといいだす
初心者＝実行速度しか見えてない

521 = :

今は、let

var は非推奨。
スコープの解釈が色々あって、バグるので難しい

522 = :

gulpは、メソッドチェーンで書けるから、左から右へ読めるけど、
npm scripts は書きにくい

VSCode, Node.js, webpack, babel を使っているけど、
webpack-dev-server を使うのが普通なのか？

523 = :

>>521
varの関数スコープ以外の解釈はよ

524 = :

var は、巻き上げが起こるので、ややこしい

var x = 0;

function f ( ) {
console.log(x); //=> undefined
var x = 1;
}

f( )

525 = :

>>524
varの関数スコープ以外の解釈はよ
色々あるんだろ？早くしろノロマ


521 Name_Not_Found sage 2020/03/24(火) 09:07:11.24 ID:???
今は、let

var は非推奨。
スコープの解釈が色々あって、バグるので難しい

526 = :

な？誰もパフォーマンスの問題なんて気にしてねーだろ？
パフォーマンス以外のもっと重要なことに目が行かない時点で
初心者なんだよ

527 = :

chromeしか知らんけどlet, const実装から結構長い間varのほうが速かったよ。
今はlet, const有利な実装に切り替えたらしい。
要するに実装依存で、ループ毎に変数生成～とかはあまり関係がない。
まだvarのほうが速い実装もあるかもしれない。
ちなみにconstが一番速い。
そしてその差は微々たるもの。

528 = :

再代入したくないからconst
てかもう感覚がvarを拒否してる
lintでチェックするからどうでもいいけど
var使ってるエンジニアいたらビビるわ

529 = :

>>523
>>520がいいたいことをいってた

> 初心者＝計測せずにパフォーマンスがーといいだす

530 = :

>>528
今でもvar使ってるよ
顧客の環境がlet使えないやつなもんで

531 = :

パフォーマンス気にするなら、速度を測れ

532 = :

パフォーマンス気にしてletとvarの使い分けより、もっと他にパフォーマンスに気を遣うべき部分があるだろう

533 :

>>522
ワンライナーで書けないような複雑なことしたいときは
gulpfileみたいに別途jsを書いてファイルにして
それを実行してもいいんだぜ

534 = :

>>532
それでは、>>519への答えにはならない

536 = :

質問とはまるで見当違いな部分でごちゃごちゃマウント取るアスペども(笑)
せめて回答叩き付けてから語るならまだしも、スレのレベルが低すぎる
及第点なのは527だけやな

537 = :

数字も出さないのに及第点って、及第点低すぎやろ

539 = :

>>538
結局varになるからなんなの？
結局アセンブラになるから、高級言語使う意味がないっていいたいの？

540 = :

>>536
ごちゃごちゃ言う前に自分で実測しろ

542 = :

藻舞らを、プロと見込んで聞いているのに、
webpack-dev-server を使っている香具師は、いないの？

所感を希望

543 = :

>>542
各スレでのうんこruby駄文テロ辞めたら答えてやるよカス

544 = :

巻き上げはletでも起こる
そもそも変数とはスコープに属するものなのでそれが当たり前。
letは変数を初期化しないだけ。TDZは存在の巻き上げはが起こっていない範囲ではなく、存在するが初期化がまだな範囲。
何回言ったら理解してくれるんだろうな。

547 = :

とにかく極力const
どうしようもないときはlet使えばよくね
巻き上げ以上の仕様はマニアだけ読めばよくね？

548 = :

> 何回言ったら理解してくれるんだろうな。

人間の数

549 = :

>>545
今でもvarを使ってる理由は、顧客の環境がlet使えないから
って書いてあるだろ

パフォーマンスのためにvar使ってるなんて書いてないだろ
顧客の環境がlet使えないからvar使ってんなら
babel使えってことだろ

550 = :

>>546
varのメモリパフォーマンスが良いことがあるんですね！
letやconstのメリットはよくわからないですが
パフォーマンスが良い方というのはわかります。
メモリパフォーマンスが良い方が適切な変数宣言ですものね！

と初心者は言う


←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド

トップメニューへ / →のくす牧場書庫について