That’s your prerogative, but it honestly doesn’t make sense. Typescript adds almost no functionality to JS (and the few pieces it adds are now considered mistakes that shouldn’t be used anymore). It only focuses on adding typing information, and in the future you’ll be able to run TS that doesn’t use those few added features as JS (see the proposal).
You can also add the TS types as comments in your JS code, which IMO shows that it’s not a different language.
Not really, considering Typescript only adds static types to JS. It’s not a different language, it’s an extension.
I wouldn’t use raw JS for anything new, yes. Typescript however is an excellent language.
Sure, but at this point it’s your own fault if you don’t use Typescript to keep these issues from happening.
There is operator overloading happening - the + operator has a different meaning depending on the types involved. Your issue however seems to be with the type coercion, not the operator overloading.
It should not happen no matter why it does happen under the hood.
If you don’t want it to happen either use a different language, or ensure you don’t run into this case (e.g. by using Typescript). It’s an unfortunate fact that this does happen, and it will never be removed due to backwards compatibility.
Sure, but then your issue is with type coercion, not operator overloading.
It should just randomly pick any “1”. Add a bit of spice, you know
That’s the case in many languages, pretty much in all that don’t have a separate string concatenation operator.
Python has a bunch of magic variables, like __name__. This one contains the name of the module you’re currently in (usually based on the file name), so if your file is called foo.py, it will have the value foo.
But that’s only if your module is being imported by another module. If it’s executed directly (e.g. python foo.py), it will instead have a __name__ of __main__. This is often used to add a standalone CLI section to modules - e.g. the module usually only defines functions that can be imported, but when executed it runs an example of those functions.
We had one null, yes. But what about second null?
typeof null === "object" was actually a bug in the early implementations, and they decided to keep it in the spec: https://2ality.com/2013/10/typeof-null.html
(see the comment from Brendan Eich)
OOPSIE WOOPSIE!! Uwu We made a fucky wucky!! A wittle fucko boingo! The code monkeys at our headquarters are working VEWY HAWD to fix this!
It’s not, like, a real baby.
You’re thinking a little too hard about a silly joke
That depends entirely on whether the un- prefix only negates the other un- prefix, or the entire adjective.
cap or no cap? fr fr which one is bussin
But if you’ve died, then were undead, and then died again, you’d be un-undead right? So alive? It’s basic double jeopardy.
Why is that silly? As long as the classes follow a strict naming scheme & have useful abstractions, that seems much better than having to give every node a unique class name that doesn’t necessarily have much meaning. I can’t count the number of “container” and “wrapper” and “content” classes I’ve seen & written, where the names don’t describe anything useful.
Nah, just flex them boxes
JS itself is great, I prefer it to most other languages due to the flexibility that it allows. Adding types through TS to safeguard against footguns doesn’t mean you’re not still using JS. You can also add the types using comments instead if you prefer it, which means you’re actually writing raw JS.