
JavaScript Coercions Grid - bfoks
https://getify.github.io/coercions-grid/
======
seanwilson
JavaScript gets a lot of flak about weird coercions but I never found them a
big source of errors compared to say more basic things like forgetting
function arguments or getting them in the wrong order. Coercions are way less
of a problem in TypeScript as well because coercions that change the type will
get flagged at compile time.

~~~
shawnz
Agreed, These corner cases are weird only because there's basically no
sensible thing to do in these situations which would be consistent with the
rest of the rules. Since there's no real reason you'd be doing any of these
weird coersions I think it's pretty unlikely that they'd result in bugs. It's
not fail-fast, but I don't see this stuff resulting in any subtly incorrect
behaviors.

~~~
seanwilson
> there's basically no sensible thing to do in these situations

Are there any better options for dynamic languages when a weird coercion is
going to be done? Throw an exception? Exit with an error? Convert to some
special invalid_coercion value similar to NaN?

It's another reason static type checking (i.e. don't let the code run) is a
no-brainer to me.

~~~
gruez
>Throw an exception?

Seems like the best choice rather than plowing ahead with assumptions

~~~
jimmaswell
I feel like it's fine for languages in a web context to take a "the show must
go on" attitude as they do. Partially working webpages (slightly broken
html/js/etc) are generally much better than a blank page/error message or none
of the js working at all.

------
tuesdayrain
I'm not entirely sure why all of this even exists, it seems like it creates a
lot of potential for bugs. I've been developing in JS for years and I've never
intentionally used type coercion. If I ever needed to operate on multiple
types I would always explicitly cast them to the correct type beforehand.

~~~
saghm
I think it's mostly just backwards compatibility at this point; unlike with
server-side languages, you can't just bump the major version and let people
switch to it at their own pace. No browser is motivated to make breaking
changes because there's a chance that they could break existing sites, and
from a user's perspective, all they'll see is that site Foo works in Browser A
but not Browser B, so Browser A will presumably lose some market share.

~~~
gambler
_> unlike with server-side languages, you can't just bump the major version
and let people switch to it at their own pace._

That's what strict mode was for.

~~~
saghm
I'm not super knowledgeable about JS, but my guess is that most of the stuff
described in the article probably don't happen under strict mode, right?

~~~
gambler
Correct.

------
wongarsu
I don't really get why `-0 + 0 == 0` is marked as a WTF? I guess getting -0
would be marginally better, but 0 is a perfectly fine answer.

I also think `true + 0 == 1` is perfectly reasonable, but I get that this
might not be reasonable for everyone. All the other fixes look like genuine
improvements.

~~~
detaro
I think -0 + 0 == 0 is correct IEEE 754 behavior too. Two numbers that only
differ in the sign cancel out to +0 when added together.

~~~
lelf
Yep, it is +0 under default rounding direction. But +0 == -0 anyway.

------
teddyh
See also: JavaScript Equality Minesweeper:
[https://eqeq.js.org/](https://eqeq.js.org/)

------
jacobolus
Turning +true into 1 and +false into 0 does not seem surprising or
problematical. To me this seems like the obviously only correct behavior.
Turning these into NaN would be a giant terrible WTF for me.

The author might want to add !!foo as an additional type of coercion (to
bool).

------
sarcasmOrTears
Don't worry, it looks scarier than it is

------
DonHopkins
Brendan Eich never really understood the concept of equality.

[https://dorey.github.io/JavaScript-Equality-
Table/](https://dorey.github.io/JavaScript-Equality-Table/)

------
beders
Sometimes I feel like we are living in the wrong timeline.

In the right timeline, a deeply flawed language like JavaScript would never
have been successful and we would use a decent application delivery mechanism
that is platform-sensitive and not a hypertext document browser with a
document model unsuitable for interactive apps.

But here we are: Never bet against JavaScript

~~~
jerrysievert
> In the right timeline, a deeply flawed language like JavaScript would never
> have been successful

but in that same timeline, we had Java, which was touted to solve all of those
problems, vs Javascript which was touted to add slight interactivity. We took
a step sideways, instead, with Java offering a lousy user experience for what
it promised, and Javascript getting progressively better, while promising
nothing in the early days.

The other competitor, Flash, ended up flawed in its own right.

And here we are.

~~~
ChrisSD
The trouble with Java in the browser wasn't the language per se; it was the
external runtime. This was also the problem with Flash. It was basically like
downloading and running a random exe from any site you visited.

From the start Javascript was built in to browsers and even as it grew it was
running in the context of a web page. By the time Javascript had grown large
enough that people were looking for other languages it had become too
entrenched.

Besides, Javascript is good enough for most websites. It's only larger web
apps where it becomes more of a problem.

~~~
jerrysievert
> It was basically like downloading and running a random exe from any site you
> visited.

which is pretty much where we are today, especially with wasm and bundles. we
just went around the virtual machine and byte code before coming back.

from Javascript's start, it was embedded, but Java applets were pretty early
as well. The core problem was direct interactivity with the browser, which
Javascript had a small amount of initially, and Flash/Java tried to subsume.
The difference was how the browser itself was treated.

~~~
ChrisSD
The key difference is in the context. "Embedded" Java and Flash still required
an external runtime, but the browser provided them a surface to paint on.
Later on browsers like Chrome tried sandboxing the Flash process but the
trouble is Flash was built under the assumption it would have full user
access, so that could only go so far. There's a reason news of Flash exploits
used to regularly appear in the tech press.

Wasm was built from the ground up to be run in the context of a browser. It's
also implemented by browser vendors so they can take responsibility for
security. In essence, the difference is that it's made to be sandboxed from
the rest of the system.

~~~
goatlover
> The key difference is in the context. "Embedded" Java and Flash still
> required an external runtime,

But that was Netscape's initial decision. There was nothing stopping a browser
vendor from embedding Java into the browser the same way. Microsoft ended up
doing that for VBScript in IE. Lotus Notes was embedding Java on their clients
in the mid 90s alongside LotusScript. In addition to that, you could even
copy/paste a Java applet from the web into Lotus email, and it would run,
although that was different from having Java embedded as a language.

