When I first saw this video, besides laughing constantly I also generally anticipated what was coming next because I was intimately familiar with JS type coercion esoteria. A decade later with a near decade long strict personal rule to never rely on implicit type coercion (with one exception, undefined/null, because it’s almost always what you’d want/intend), quite a lot of that memorization has fallen out of my head, and I’m prepared to let it stay that way.

Because yep, it pretty much reduces to the category Type Coercion Rules. But that category in JS is so absurd that normal absurdities feel like minor tomfoolery. (And lest I paint myself as the typical HN anti-JS crusader, I do almost all of my work and personal dev in JS/TS, mostly without complaint.)

I once read the spec to see why the hell type coercion was the way it was... And it kinda made sense? But this was 5-6 years ago and I forgot all the details. Because without going into deep dark corners of the spec it doesn't really make sense. At all :)

And even that last one you can now finally explicitly account for with the incredibly unfortunately syntaxed, but critically useful, double question mark.

> None of this matters most of the time, but yeah it's still funny.

Implicit type coercion doesn't matter most of the time? You don't often have bugs because of it?

The sentiment is that JS coercion is so bad that explicit coercion programming behaviors, linters, Typescript, and adding parsing safeguard libraries (io-ts, Zod, Joi, json schema, etc) have become so commonplace that people don't really let implicit coercion occur very often, and thus it doesn't matter most of the time.

Whenever I kick off a new npm init, it's always followed by installing typescript, eslint, and usually Zod before I even write the first line of code. If double equals was removed from ECMAScript, I would likely never notice.

It doesn't matter in the sense that it's a case of "garbage in, garbage out". I have no idea what what `{} + 1` gives you (it's `'[object Object]1'` BTW), but whatever it is doesn't matter because it's a rubbish computation to make.

It would have made more sense to throw an exception, but JavaScript at it's origin was meant to be a simple scripting language. Nowadays with TypeScript it's much less of an issue.

I can't even recall the last I worked on a JS/TS codebase where type coercion wouldn't trigger a linting/compilation error

In the browser all user input, API responses, and application state is validated and sanitized before it ever gets to the application logic.

On the backend all requests and database values are similarly validated and sanitized before any logic occurs.

Anything less is bad code regardless of what languages are used.

> In the browser all user input, API responses, and application state is validated and sanitized before it ever gets to the application logic.

Good thing there are never any bugs in validation and sanitization code!

You shouldn't roll your own for this. From what I've had to do web-wise, here's a few tools.

First, for the APIs, you need documentation: https://swagger.io/

From which you can generate JSON schemas and use those to validate in the browser and on the backend. https://www.npmjs.com/package/jsonschema

As well you should be writing a few more schemas for your application state and leverage the regex validation of your input components...

Speaking of which, you also need to sanitize out some potentially nasty input. https://www.npmjs.com/package/dompurify

Obviously this isn't everything and not perfect, but a lot of this tedium can be automated away if you have a few good examples of the happy path and some basic tests in place to prevent quick and dirty changes from poking holes in these layers.

Sounds like you never make any mistakes. If that's the case, I'm hiring.

Implicit conversions are very pernicious. In Virgil, the only implicit conversions that happen are promotions, i.e. representation changes that don't change values, like float -> double, int -> larger int, int -> double (where no rounding occurs), etc. AFAICT this is a pretty sane model.

It's not just implicit conversions. It's misuse of operators, too. Using the '+' operator string append is the kind of thing that language designers get initially seduced by ("it just makes sense" "so convenient" "neat") but the reality is that combined with implicit type coercions it's just a recipe for exotic and unexpected behaviours.

Precedence rules and expectations for 'string append' vs 'add numbers' is different. And then if you through in 'multiplication = repeat.' It's ... now you have this Wat-talk video (which is a classic which I always share with people when the topic of this comes up.)

Maybe I'm just getting stuffy as I get old, but the older I get the more .. explicit.. I want my PL semantics to be.

Browbeating JS with this derision has/had become almost an article of faith amongst online circles. It's clearly not great behavior but generally it doesnt really have much impact on day to day.

Yet people love making themselves feel better by latching on to criticism. Signaling your greatness & expertness by beating up on others.

What if it's not beating up on others, but being very critical of languages because you believe language choice actually does matter?

That's completely fair, but I FEEL (don't know for sure) that many people who criticize JavaScript don't know it very well and don't pick meaningful things to criticize, but things like its rubbish type coercions (which doesn't have a big impact in real life).

You should a) pick big impact items to argue your case b) still acknowledge strengths & successes amid your critique.

Also if you are facing the world's most popular language & a very successful one people build all sorts of stuff with without complaint, it's a big barrier.

I think most language bigots lack a good narrative. They have a language they love, or a language they hate, but they harp upon specific issues. But to I think most coders, choice of language is actually pretty far down the list, especially if you ask them to ignore the ecosystem of packages/tooling & focus on the language itself. Trying to go beyond scoring points & telling a story about life being actually authentically really different on one path or another keeps being harder and harder to se, as we keep marching through the decades & seeing few really really strong distinct clear advantages anywhere, no one really excelling at their claimed bag, in an unreplicateable way that shows it really is the language, not just ecosystem. (rust being one genuine exception)

If you use JavaScript you need to be aware of these pitfalls, otherwise it will bite you. The video just does it in an entertaining way.

This is true for literally everything, wild overextrapolation from a single point of data, itself sometimes of dubious provenance.

Your only defense is to ignore it when you see it and avoid it in your own thinking.

Agreed that this is a wildly broad social phenomenon.

As for what to do, I think socializing a defense has merit. Talking about these dangers, trying to make people smart, critical of criticism, wary of over zeal or conviction. Posting about & sharing & discussing malignent maligning forces, drawing light to radicalization, showing some of the bad impacts this talk has had. Not as a talk itself, but in terms of what a magnet for very much problematic & zealotous negativities.

I see the challenge here as not merely personal, but also societal, in how we deal with especially highly critical highly skeptical behaviors, those that write things off. And the excuses, however shallow, they can stand on to reject.