generated at
JS Is Weird
JavaScriptは謎の仕様がいっぱいある
だいたい最初のバージョンが10日くらいで作られたのに下位互換性を保ってるのが原因
こわSummer498


typeof null = "object" 綾坂こと
初期のバグがそのまま仕様になっちゃってる
Object.prototype.toString.call() あたりを使ったほうが直感に合ってるかもしれない
Lua: type(nil) == "nil"
typeofが万能じゃないせいで、型判別のやり方がややこしくなってるMijinko_SD
typeofで判別するやつと、===で判別するやつと、それら以外で判別するやつの3種類ある
型判別だけでこんだけ種類あるのはわりと初見殺し
どれかにまとめてほしい感じある
そもそも動的型言語なので、必要とするプロパティが存在するかとかで判定したほうが都合がいいとおもうbsahd

[1, 2, 3]+[4, 5, 6]
[1,2,3,4,5,6] (Python,ruby)模範解答
普通に考えたらこうですよね
「Number, Boolean, null, undefined(, BigInt)は加算、それ以外は文字列結合」。うん、簡単だね!!() 綾坂こと
_
class Array functioon +(b) return this.concat(b) end end # できたらいいな

btoa("たっかー")
btoaは、文字列(Latin1 only)をBase64に変換する関数です
Latin1 onlyになった理由:レガシー実装
実行結果:エラーになります
回避手段は自力実装しよう → /AyaExpTech/任意のデータとBase64の相互変換.js 綾坂こと
MDNのほうが短いbsahd
mdn.js
function base64ToBytes(b64){const bS = atob(b64);return Uint8Array.from(bS, (m) => m.codePointAt(0));} function bytesToBase64(bs){const bS = Array.from(bs, (bt) => String.fromCodePoint(bt),).join(""); return btoa(bS);} // 使用方法 bytesToBase64(new TextEncoder().encode("a Ā 𐀀 文 🦄")); // "YSDEgCDwkICAIOaWhyDwn6aE" new TextDecoder().decode(base64ToBytes("YSDEgCDwkICAIOaWhyDwn6aE")); // "a Ā 𐀀 文 🦄"
私のは任意データを変換可能にするためにごちゃごちゃやってるので、テキストしか使わないなら↑のほうがいい綾坂こと
FileReader.readAsDataURL()経由でbase64にencodingできないかな?takker
jsr:@std/encodingsにも実装があるから、そういうのを使うのも手takker
undefの扱いに困る
それを言うなら空リストと空オブジェクトとnullとundefを使い分ける人がいるらしい
「あれ、いい忘れたけどundefinedはリストに入れられるよ」
静的言語なら「えっ、未定義の変数にアクセスした時undefined返したいじゃない?」はない
コンパイル時にエラーにすればいい
undefinedとnullを使い分けるのは不毛なので、undefinedしか使わないようにしているMijinko_SD
サバイバルTypeScript等でも使い分けは推奨されていない

Javascriptも「完全な下位互換性」を捨てた新バージョンが必要な気がするbsahd
python2がpython3で大きく進化したように
それほどの互換性の捨て方ではないが
新バージョンを使う場合は厳格モードみたいに宣言する?
#include <stdio.h> 並みのおまじないになりそう
"ES2020"; みたいなイメージ?
互換性が無いと過去のライブラリや古いWebサイト使えなくなるので、それはそれであんまり良くないMijinko_SD
現状でもIE向けのWebサイトや古いNode.js向けのコードが最新環境で動かないとかあるので、互換性と一言で言っても古すぎる環境まで網羅しているわけではないけれど
それか別の拡張子、別のMIMEタイプにするとかbsahd
TypeScriptを用いる場合はtsconfig.jsonのフラグ設定でやばい機能を無効化することでどうにかなってる気がするMijinko_SD
もしくはESLintを使うという手もある
設定だるいけど
一応、やばい機能には代替が開発されている印象綾坂こと
今やってるやつだとTemporal(Dateの代替)とか
日付の内部表現はUTCのUnixtimeだけでいいのでは?bsahd
シリアライズしやすいし
代替でどうにかなるのでそこまで問題視されていない印象があるMijinko_SD
言語由来の構文(非公式の代替が作れないもの)での欠陥も以前はあったけど(for...in, var等)、それらは公式で代替が出てるし
varはしっかりとlintすればどうにかなったし、for...inは使わなきゃいい話(C言語のforと同等にもかける)だしbsahd

Juice WRLDに似ているはるひ