Me: Hey programming languages, is 0 == [ ] ?

PHP: Nope. It's not.
Python: Nope. Easy.
Java: Heh. No it isn't.

Javascript: Oh, um yeah, hurrr durrr harr harr YES it is.
But screw it, hAvE yOu hEaRd oF nExTjS? wE sUpPoRt sQl qUeRiEs nOw.

JS devs have trained themselves to always use === instead. If you use the default ==, you are obviously a noob.
Come on, it’s just one additional rule that you need to remember when using JS to not be fucked in the butt by the language.
Just remember all the other 1000 rules and you are fine.

Non-issue for real programmer. Don't compare arrays and numbers, problem solved.

@Lensflare maybe I like getting fucked in the butt.

Alternative question: Why would you cmp a numeric value with an array?!

@Ranchonyx if its variables in my code, I could get fucked in the butt, wouldn't I

@SidTheITGuy i did js for 20 years now and I never encountered an issue like this.

@mostr4am because js always silently fails

@Lensflare which is way better. When I fail I want to be silent about it. Imagine you're hanging out in a nice cafe, the outside smells like summer, and then some weirdos start screaming "HEY LOOK AT ME I FAILED MY EXAMS"

@mostr4am "I did JS for 20 yrs". You make it sound like JS is a drug or something lmao.

@SidTheITGuy Have you tried washing your face

@kanyewest yes. Have you washed your mom's face though? I bust a pretty fat nut on her face last night.

@SidTheITGuy If a variable is a black box, you can cast it to a Typescript type with Zod. JS is an interop standard. You wouldn't complain about the ergonomics of hand-typed SMTP.

I think the biggest problem with JS is that it remains just good enough that people keep mistaking it for a language frontend. ES is in a symmetric position to ARM. It governs consumer technologies produced by several otherwise independent organizations. DX is way out of scope.

@lorentz it would restore my faith in humanity if all devs would actually think like that.
But in my experience, most js fans in fact use plain js as a language frontend and they see things like ts as something that is needlessly complicated and useless. They are annoyed by the need to specify types. They think that they know what they are doing and don’t want to be patronized by the language.

You can find many of those people here on devrant. But they are everywhere.

@mostr4am just came here to say that. Stupid comparison to begin with.

Not understanding the very basic characteristics of the tool you use makes any of these complaints shit posts to me.
It's like blaming the screwdriver for painting falling off the wall when not using plugs in plaster.

In any dynamic typed language you need to use strict comparison operator when you care about the type or non empty-like checks.
It's a nice convenience that you can do
If (myList) {
// Yay have an actual non empty list/value
}
If zero or "" is also valid you need to specify that because guess what you want something explicit.

@hjk101 except implicit type conversion and truthyness have absolutely nothing to do with dynamic typing.

And what you are describing as convenience is actually a time bomb without clear intent, based on the assumption about the complicated internal details of that language.

In other words: The problem is that it’s not clear what the code is supposed to do and it’s not clear if it actually does what it’s supposed to do.

@hjk101 accusing js criticizers of not understanding it, is a common fallacy among js fans. Unfortunately for js fans, this assumption is complete bullshit.

@hjk101

(list.length > 0) asserts exactly what you're checking, (list) asserts a lot of different things in different scenarios and what you want is one of its less obvious meanings. When reading that, I would think that `list` is a poorly named boolean before I would think that you're deliberately casting it.

I'd seen more nullish checks that accidentally failed on empty lists than legitimate empty list checks via boolean cast so far.

@lorentz good devs learn to avoid that shit when they become more experienced.
Bad devs embrace it and integrate it in their daily business tool belt.

@Lensflare I'm actually more in the JS hate camp, actively avoid it as much as possible. htmx is the best framework that came out for me.

Dynamic typed languages often use loosely typed checks to be able to be used dynamically in the code as well. So I consider it a feature of the dynamic type system even though a strong typed language like python proves that it does not need to be the case.

@lorentz crashes on null/undefined. This is why I do both checks as indeed it is far better to be explicit about what you want here.

I always do explicit checks unless it really needs to be more flexible but that is almost never. Was just trying to provide an example while still using an array.

Hate the whole null and undefined difference by the way. It's not a big enough of a dream to warrant two different types in my opinion.

@hjk101 If you want a nullish-or-empty-array check, I recommend a nullish check followed by an empty array check. Any attempt to combine the two will call into question whether both are intentional.

@hjk101 My example assumed that you're working with an array, not an array-or-nullish. Typescript uses non-nullable types so when talking about preconditions in JS in abstract terms I tend not to assume that any variable could also be nullish besides a value that satisfies the stated precondition.

@hjk101 If you don't know _anything_ about the value, you need an instanceof or Array.isArray check anyway, truthiness on its own is not a very useful constraint if you can't assume anything else.

do people actually use ==?

@spoiledgoods two of my go-to arguments for ESLint are to ban == and to ban implicit casts (except string interpolation)

my personal hatred for JS implicit casts stems from the fact that a promise is truthy so forgetting to await an async check causes it to always succeed.

@lorentz a good language makes forgetting to await a compile time error.

Btw this is a great example of why truthyness is a very bad idea in almost every use case.

It blows my mind again and again how so many people try do defend this shit.

@lorentz that is exactly what I mean!

@lorentz again on the array of was a bad example to begin with. As stated from the very first line it's a the original issue is a non issue because on practice it's not done in TS (what I mostly use professionally) it's even less likely.
There are still some cases where not set at all needs to be handled differently from explicitly entity empty list resulting in nullable array in TS.

Just to keep the circle jerk going:
typeof null === "object"

This is widely regarded as a bug/oversight, but it stuck.

@Ranchonyx 👌