Use TypeScript, and nonsensical things like adding arrays to objects will be compile-time errors.
Yup. The libraries underneath will still allow nonsense at runtime, though, and it will now be harder to see, so it’s a partial solution as done in standard practice.
An all-TypeScript stack, if you could pull it off, would be the way to go.
So a strictly typed language… I think those already exist.
If there was an easy way to use rust or something on webassemly and use that instead of JS. I’d be so happy, but I can’t find how to do it without npm.
It’s in alpha, but there is a Kotlin to wasm compiler in the works.
Does WASM do DOM manipulation nowadays?
Doesn’t look like it, unfortunately. But it’s planned. Kotlin can also compile to JavaScript with DOM manipulation. I’ve not tried either scenario, myself.
I can’t wait for the day I can use something like Kotlin to write Frontend code. Maybe there’ll be something like vue or react build on it
On the other hand, I don’t think you should add those ever
Sure. But in a sane language doing something totally nonsensical like that is an error, and in a statically typed language it’s a compiler error. It doesn’t just silently do weird shit.
Agreed! Unfortunately these maddening behaviors were kind of set in stone several decades ago, and it has been (correctly) decided “Don’t break the web”, these weird quirks are kept in modern interpreters/compilers.
It’s actually quite interesting to read through the logic to follow when implementing an interpreter:
https://262.ecma-international.org/13.0/#sec-object.prototype.tostring
Onfuscators probably use it though, so no spec ever will be able to get rid of this crap.
Can I vote for obsfuscators not holding a language hostage?
Best I can do is tie your pension to it.
In node, I get the same result in both cases.
"[object Object]"It’s calling the
toString()method on both of them, which in the array case is the same as calling.join(",")on the array. For an empty array, that results in an empty string added to"[object Object]"at either end in the respective case in the picture.Not sure how we’d get 0 though. Anybody know an implementation that does that? Browsers do that maybe? Which way is spec compliant?
Number([])is 0, and I think maybe it’s in the spec that the algorithm for type coercion includes an initial attempt to convert to Number before falling back totoString()? I dunno, this is all off the top of my head.The inspector REPL evaluates as a statement-with-value (like
eval), so the{}at the beginning is considered an empty block, not an object. This leaves+[], which is 0. I don’t know what would make Node differ, however.Edit: Tested it myself. It seems Node prefers evaluating this as an expression when it can, but explicitly using
evalgives the inspector behavior:
So there’s yet another level of quirkery to this bullshit then, it seems. 😆 Nice digging! 🤝
I also noticed that if you surround the curlies with parentheses, you get the same again:
> eval('{} + []') 0 > eval('({}) + []') '[object Object]'
This is why I try my damnedest not to write in weakly typed languages.
string+objectmakes no logical sense, but the language will be like “'no biggie, you probably meant string + string so let’s convert the object to string”! And so all hell breaks loose when the language’s assumption is wrong.I’m in this no-experience-to-apprenticeship program and everyone in my class thinks type coercion is the greatest thing ever.
