私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.133 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
他人が書いたphpも他人が書いたjsも同じくらいゲロいと思うんだが
嫌いな理由というのも色々あるということだ
perlはガチ言語仕様がガチ
perlはガチ言語仕様がガチ
3項演算子をつかって時間がひと桁の時0を頭につけるコードをどっかで見たので
自分でやったけどできない
var sec = (((new Date()).getSeconds < 10 )? "0" : "a") + (new Date()).getSeconds()
なにがだめ?
検証のために"a"いれてます
自分でやったけどできない
var sec = (((new Date()).getSeconds < 10 )? "0" : "a") + (new Date()).getSeconds()
なにがだめ?
検証のために"a"いれてます
最初の new Date() と
二回目の new Date() で
同じ時刻になるとは限らない
二回目の new Date() で
同じ時刻になるとは限らない
moment.jsはapiが古くimmutableになっていない。（破壊操作ばかり）
date-fnsやday.jsがよい。
またライブラリ使う場合はパフォーマンス問題も考慮しろよ？
素のjsで十分な案件じゃないか？
http://medium.com/@jerrylowm/moment-js-vs-native-performance-issues-5b85d6518014
date-fnsやday.jsがよい。
またライブラリ使う場合はパフォーマンス問題も考慮しろよ？
素のjsで十分な案件じゃないか？
http://medium.com/@jerrylowm/moment-js-vs-native-performance-issues-5b85d6518014
パフォーマンスと言われても1回あたり
1msでも20ms対して変わらん
1msでも20ms対して変わらん
moment.js 50000byte
day.js 2000byte
画像の50kBと違いjsはダウンロード時間よりもパース時間のほうが長い。
また画像と違ってasyncをつけられなければブロックする。
day.js 2000byte
画像の50kBと違いjsはダウンロード時間よりもパース時間のほうが長い。
また画像と違ってasyncをつけられなければブロックする。
> また画像と違ってasyncをつけられなければブロックする。
</body>直前に読み込めばいいだけでは？
</body>直前に読み込めばいいだけでは？
body直前で問題ないならそれが一番いいよ。
moment.jsロードして使わないなんて何してるのか分からんが。
moment.jsロードして使わないなんて何してるのか分からんが。
てかjQueryなんかと同じで被依存ライブラリなんだから事実上asyncなんか付けられるわけないし/body直前もあり得ないだろ
へ？ 使う前に読み込んでいればいいんだから
asyncも</body>直前でもできるけど？
例えば、clickイベントの中で使うなら、
クリックする前に読み込んでいればいい
asyncも</body>直前でもできるけど？
例えば、clickイベントの中で使うなら、
クリックする前に読み込んでいればいい
だから当たり前のことを言っただけなんだが。
ありえない？当たり前の事を知っていれば、
ありえないが間違いだってわかるよね？
ありえない？当たり前の事を知っていれば、
ありえないが間違いだってわかるよね？
素のjsのDateを使おう。サイズは驚異のゼロbyte。速度はmoment.jsの20倍速い。
moment.jsは便利だがAPIがイケてないということでdate-fnsに追い捲られてるはず。
このようにライブラリには流行り廃りがあるのだ。
素のjsのDateのAPIもイケてないが、moment.jsとは違う点がある。それは決して廃れないことだ。
じゃあもう覚えちゃえばいいんじゃん？
moment.jsは便利だがAPIがイケてないということでdate-fnsに追い捲られてるはず。
このようにライブラリには流行り廃りがあるのだ。
素のjsのDateのAPIもイケてないが、moment.jsとは違う点がある。それは決して廃れないことだ。
じゃあもう覚えちゃえばいいんじゃん？
> 素のjsのDateを使おう。
めんどくせぇ、俺の仕事はDateを使いこなすことじゃないんだよ
めんどくせぇ、俺の仕事はDateを使いこなすことじゃないんだよ
別に使いこなさなくても時刻0埋めはIntlAPIで簡単にできる
date = new Date('2018/06/01 01:02:03')
date.toLocaleTimeString( 'en', { hour12: false } )
// "01:02:03"
date.toLocaleTimeString( 'en', { minute: '2-digit', second: '2-digit', hour12: false } )
// "02:03"
date = new Date('2018/06/01 01:02:03')
date.toLocaleTimeString( 'en', { hour12: false } )
// "01:02:03"
date.toLocaleTimeString( 'en', { minute: '2-digit', second: '2-digit', hour12: false } )
// "02:03"
>>927
こんなんじゃ使い物にならないな
date = new Date('2018/06/01 01:02:03')
date.toLocaleTimeString( 'en', { hour12: false } )
// "?1?:?02?:?03"
date.toLocaleTimeString( 'en', { minute: '2-digit', second: '2-digit', hour12: false } )
// "?6?/?1?/?2018? ?1?:?02?:?03? ?AM"
こんなんじゃ使い物にならないな
date = new Date('2018/06/01 01:02:03')
date.toLocaleTimeString( 'en', { hour12: false } )
// "?1?:?02?:?03"
date.toLocaleTimeString( 'en', { minute: '2-digit', second: '2-digit', hour12: false } )
// "?6?/?1?/?2018? ?1?:?02?:?03? ?AM"
しかも文字化けｗｗｗ
IntlAPIでできるとか、こいつ実際に使ってるのか？
どうせ使ってねーんだろうな
IntlAPIでできるとか、こいつ実際に使ってるのか？
どうせ使ってねーんだろうな
JavaScript（？）のAPI設計してるやつって
センスないのか？
なぜ短く書く方法が他にもいくらでも見つかるのに
それを無視して冗長なやり方をするんだ？
センスないのか？
なぜ短く書く方法が他にもいくらでも見つかるのに
それを無視して冗長なやり方をするんだ？
オプションオブジェクトのこと？
昔のAPIはフラットに引数足してったけどそのやりかたは拡張性・互換性に乏しいということで最近のAPIは基本引数の後ろでオプションオブジェクトとるようになったんだよ。
センスは良くなったの。冗長だけど。
昔のAPIはフラットに引数足してったけどそのやりかたは拡張性・互換性に乏しいということで最近のAPIは基本引数の後ろでオプションオブジェクトとるようになったんだよ。
センスは良くなったの。冗長だけど。
素のJSがイケてないからライブラリが出来たのに
素のJSを使おうとは・・
そもそもSPAならパースは始めだけなので大して問題にならないですよね？
軽いに越したことはないですが・・
素のJSを使おうとは・・
そもそもSPAならパースは始めだけなので大して問題にならないですよね？
軽いに越したことはないですが・・
「SPA」の「始め」ってメガトン級じゃん。そこにさらに50KB積むのか…
まぁせめてSSRはしとけよ？
まぁせめてSSRはしとけよ？
>>928
君の壊れたブラウザじゃ使いものにならないのだろうね
君の壊れたブラウザじゃ使いものにならないのだろうね
Edgeが壊れたブラウザで、動かなくて平気っていう人は楽だねｗ
でも仕事じゃそうはいかないんだよ
でも仕事じゃそうはいかないんだよ
シンプルに'0'つけて1回変数に入れてからsubstringすりゃいい
と言ってはいけない雰囲気
と言ってはいけない雰囲気
ライブラリは必要だから作られたものなのですから
それが必要でなくなるのは、ブラウザの標準化がめざましく進むなどの前提条件の変化があった場合か
それよりもいい代替が現れた場合だけです。
前提条件はたいして変わっていないのですから
ライブラリいらないガーという主張には頷けませんね
それが必要でなくなるのは、ブラウザの標準化がめざましく進むなどの前提条件の変化があった場合か
それよりもいい代替が現れた場合だけです。
前提条件はたいして変わっていないのですから
ライブラリいらないガーという主張には頷けませんね
githubではスター数ゼロの誰からも必要とされないライブラリが量産され続けています。
ライブラリは必要だから作られる、の反例として。
ライブラリは必要だから作られる、の反例として。
そのライブラリを作った人には少なくとも必要だったのでしょう
その必要性が広い潜在的需要に応えたものもあり、そうでもないものもあります
当たり前の話です
ここでは広く受け入れられたライブラリの話をしてるのですから、反例というかただのトンチンカンです
その必要性が広い潜在的需要に応えたものもあり、そうでもないものもあります
当たり前の話です
ここでは広く受け入れられたライブラリの話をしてるのですから、反例というかただのトンチンカンです
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.123 + (1002) - [97%] - 2015/4/27 23:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.123 + (966) - [97%] - 2020/10/20 2:30
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.143 + (753) - [97%] - 2020/4/19 5:00
- + JavaScript の質問用スレッド vol.103 + (1001) - [97%] - 2012/11/9 15:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
トップメニューへ / →のくす牧場書庫について