Ironic indeed as you seem to not only have failed to grasp a single blasted thing I said, you also don't seem to realize the ADVANTAGES of type fluidity. Types and casting are not the be-all end all -- as much as I like them in some cases.
As evidenced by your apparently not even knowing -- by your own admission --what strict typecasting is. Aka variable and parameters have types, and that type is immutable after the declaration. What you would know as "type safety" is just an aspect of this.
By itself JavaScript only really "pretends" to have types. Those types are transitory. It is not "strictly typecast" as a variables type can change at any time. It is to that end the code I wrote leverages that. You're apparently trying to dive in to follow a variables type when I'm using loose boolean to my advantages. The code I write in JavaScript does not follow strict typing conventions or type safety because the LANGUAGE ITSELF ISN'T TYPE SAFE!
Rather than piss and moan like some career educator who's never been outside the classroom about JavaScripts type fluidity, I embrace it since that seems to have been the intent from the start! It's not Ada, it's not C, and I'm not going to try to force it to be such.
And honestly that's PART of the pedantry things like React, Typescript, and so forth bring that's so infuriating. Rather than embrace what JavaScript is, and use what people incorrectly label as "flaws" to your advantage, people are jumping through hoops to try and shoe-horn it into programming ideas, ideals, models, and concepts that are the polar opposite of how the language was designed to work!
That's the mistake I made 20 years ago when I first started using JavaScript, trying to make it something it was not instead of embracing and understanding what it is. I've learned better.... the problem is most of the people making these frameworks, pre-processors, pre-compilers and so forth is they cannot get past that hurdle and insist on trying to force the underlying languages into programming models and concepts that are... well, like shoving a fat cow's size 14 hoof into a size 5 pump.
Seriously, that you're looking for the type of a variable in a type fluid language? Shows you haven't embraced the basic concepts of JavaScript. If I can leave Ada at the door, you can try leaving C at the door. So you're unaware of case-typing, variant-typing, AND state-typing? I can only assume so with your failing to understand pre-declaration, a failed state, or a stored state.
Something in a language with actual typecasting I'd define with an enumerated and/or relational structure type; but JavaScript doesn't have that.
... and Ada's case-is Is called variant records. I believe I mentioned that? But sure, I'm the one who doesn't know the terminology or concepts.
You must REALLY hate PHP's in-built library, with how it too embraces variant typing and type fluidity on nearly every return from a function or method. Hell, surprised you can stomach JavaScript at that point given the number of methods that return false or null on failure, but numeric, string, or array on success.
When the language itself lacks typecasting, type safety, or any other aspect of strict typecasting, stop assuming type even matters! Suddenly doors open to faster, leaner, easier, and more efficient code if you stop caring about that because it simply doesn't EXIST in the language to begin with!