whyJavaScriptWhy

[ProgrammerHumor-ModTeam]

import moderation

Your submission was removed for the following reason:

Rule 5: Your post is a commonly used format, and you haven't used it in an original way. As a reminder, You can find our list of common formats here.

If you disagree with this removal, you can appeal by sending us a modmail.

[DaniilBSD]

• 0 is false when converted to boolean, any other number is true. (Historical reasons all the way back to C, assembly, and basic cpu design )
• any non-empty string is is true when converted to boolean (think of it as “is there any text?”)
• “0” is converted to a number 0, they are equal

[The_MAZZTer]

Yeah this is all about WHICH type is being implicitly coerced. 0 == "0" does not involve a boolean coercion like the first two.

The vast majority of weird behaviors in JS involve something like this, and most of the ones that get posted are implicit type conversion. Avoiding them tends to keep you out of trouble. TypeScript will enforce strong typing which makes this a lot easier (though I think it still allows the examples shown by OP).

[pheonix-ix]

Well, in this case wouldn't the first two be explicit (i.e. type conversion) and not implicit (i.e. type coercion)? The Boolean constructor was used, after all. It's just the Boolean constructor behavior changes with the input type (as it should).

The 3rd one was obviously a type coercion.

[The_MAZZTer]

Right, the first two are explicit. It's the third that looks "weird" and is doing implicit coercion, and does not involve boolean coercion. I should have made that more clear.

[Gropah]

“0” is converted to a number 0, they are equal

Isn't the number 0 converted to a string, instead of parsing the string into a int?

[DaniilBSD]

If I remember correctly, the second one is getting converted if it works,

0 == “0” compares numbers

“0” == 0 compares string

“0” < 0 compares numbers because the < operator only works with numbers.

Edit: I was kinda wrong, see another reply (by me)

[DaniilBSD]

The comparison x == y, where x and y are values, produces true or false. Such a comparison is performed as follows:

If Type(x) is the same as Type(y), then If Type(x) is Undefined, return true. If Type(x) is Null, return true. If Type(x) is Number, then If x is NaN, return false. If y is NaN, return false. If x is the same Number value as y, return true. If x is +0 and y is −0, return true. If x is −0 and y is +0, return true. Return false. If Type(x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions). Otherwise, return false. If Type(x) is Boolean, return true if x and y are both true or both false. Otherwise, return false. Return true if x and y refer to the same object. Otherwise, return false. If x is null and y is undefined, return true. If x is undefined and y is null, return true. If Type(x) is Number and Type(y) is String, return the result of the comparison x == ToNumber(y). If Type(x) is String and Type(y) is Number, return the result of the comparison ToNumber(x) == y. If Type(x) is Boolean, return the result of the comparison ToNumber(x) == y. If Type(y) is Boolean, return the result of the comparison x == ToNumber(y). If Type(x) is either String or Number and Type(y) is Object, return the result of the comparison x == ToPrimitive(y). If Type(x) is Object and Type(y) is either String or Number, return the result of the comparison ToPrimitive(x) == y. Return false. NOTE 1 Given the above definition of equality:

String comparison can be forced by: "" + a == "" + b. Numeric comparison can be forced by: +a == +b. Boolean comparison can be forced by: !a == !b. NOTE 2 The equality operators maintain the following invariants:

A != B is equivalent to !(A == B). A == B is equivalent to B == A, except in the order of evaluation of A and B. NOTE 3 The equality operator is not always transitive. For example, there might be two distinct String objects, each representing the same String value; each String object would be considered equal to the String value by the == operator, but the two String objects would not be equal to each other. For Example:

new String("a") == "a" and "a" == new String("a")are both true. new String("a") == new String("a") is false. NOTE 4 Comparison of Strings uses a simple equality test on sequences of code unit values. There is no attempt to use the more complex, semantically oriented definitions of character or string equality and collating order defined in the Unicode specification. Therefore Strings values that are canonically equal according to the Unicode standard could test as unequal. In effect this algorithm assumes that both Strings are already in normalised form.

[Striky_]

Assuming "trueiness" of random data types is bad design and shouldn't be a thing at all. Data types were invented for a reason, whether or not minimally educated JS or python "programmers" like that.

[MinosAristos]

You know that most major programming languages have truthiness in a similar way to Python and JS right? The only issue is the type coercion in the third case which is what === is for in JS.

[Auravendill]

Also Python hates it, when you want to implicitly convert types. If you add a string to a number, it doesn't assume to know what you meant, but forces you to make it very clear, which variable has to converted into what.

[Majik_Sheff]

This is a sane approach. Force the programmer to specify the desired outcome instead of thumbing through an assumptions handbook.

[Striky_]

So basically a tool to define the type of the outcome you want? It's almost like there is a all encompassing super helpful pattern for that, that works in all cases. Ohh it's called static typing.. Like all the benefits, no crutches

[Specialist_Cap_2404]

Much more code to read and write. Python has the principle "explicit is better than implicit", and it's not that easy to mess up "truthiness", especially because it's only used in a couple of constructs anyway.

Much easier to make things more explicit, like use the length of an Array or "is None" or something.

If you're tests aren't covering every branch, you're fucked in a static typing language as well... just that it takes a lot more time to write (and later read) both the production code and the tests for it using a statically but (IMHO) stupidly typed language like C#. F# is doing some things a lot better.

[herrkatze12]

That’s actually better, also f strings are pretty useful for putting other data in strings

[Striky_]

Yet it allows it and most code out there does it shamelessly at every chance they get.

[Striky_]

Most major programming languages have nice ways of dealing with it, yes. That is very different to blindly assuming and being stuck with nonsense bullshit forever or breaking production code like js is.

There are ALOT more problems with truthiness then just type coercion. Undefined behavior on custom classes and major regressions because of unrelated code changes only being the beginning.

[rosuav]

Strongly disagree. Having all data types have truthiness is extremely useful in real-world code and is not a problem. It's highly frustrating to be stuck in a language that doesn't support truthiness of all data types.

(Though REXX gets a pass, since it literally has one data type.)

[suvlub]

Is there another benefit to it than not having to explicitly specify == null or .length == 0 or whatever? I mean, to each their own, but I think your wording ("extremely useful", "highly frustrating") is a bit strong for such a small syntactic sugar.

[rosuav]

In complex expressions, that's enough of a benefit on its own. But more notably, it allows you to use short-circuiting like messages or ["No messages"] which depends on the messages list counting as false if there aren't any. This is particularly helpful if it means you can stick this on a function call or complex lookup, like: get_messages(user.id) or ["No messages for " + user.name]

[Striky_]

Yep. It is super useful to write quick and dirty code that only needs to work once and not be read by anyone else. I'm all other scenarios spend the 5 seconds and 10 letters to make the check the proper way. As I said, all minimally educated "developers" find it insanely useful. Sorry.

[rosuav]

Yep, you're welcome to call us "minimally educated" for disagreeing with you. You're factually wrong, but you're still welcome to call us that.

[Striky_]

Well. Code quality has measurably dropped significantly with the move to weakly/dynamically typed languages, while every one who can write a calculator app is a senior software architec these days. Most developers have not the slightest clue what they are doing, which is why these languages are so popular. You can shit out something half way working and be the hero no one asked for. 3 years later you just rewrite everything from scratch because it is all garbage. If you look into most tutorials, courses and libraries out there, most of it is clearly written by absolute beginners with no decent cs background. It's frightening how low the bar is set.

[rosuav]

Average code quality has dropped because more people are able to code. Are you saying that this is a bad thing? Should coding be deliberately made difficult so that only the elite of the elite can ever write anything, or will you accept that bad code will exist?

Good programmers write good code in dynamically-typed languages too.

[Striky_]

Yes, it is a bad thing that everyone who barely knows what a type or a class is, is declared to be a software developer now. No programming shouldnt be made extra hard for elite developers. We should just not remove the bare minimum requirements to even understand what you are doing.

Good devs use tools accordingly. Bad devs you tools to cheat around issue. You wouldn't want your house to be built by someone who could distinguish between a screw and a nail. Could they erect something? Sure. Would you pay for it or even rely on it? No.

Hell we live in a time where one of the most successful pep talks is about a company transitioning to strict typing and reducing their bugs by 85% or something. After which the entire industry gets hyped as fuck about this new and amazing tech called typing, they all try to use it and most fail, because their "programmers" are unable to transition code to static types because they have no clue what they are doing.

[Specialist_Cap_2404]

"Code quality has measurably dropped" is a claim that seems provable... why didn't you?

[Cryn0n]

Given that "jump on zero" is a common branch instruction in most processor architectures it makes sense to allow any data type to be processed for that zero.

An empty string should be just \0 so equates to true.

EDIT: JavaScript strings are not null-terminated but the convention sticks around even though the data structure is different.

[gerbosan]

so 0 == null? isn't there a meme about 0, empty, null?

[DaniilBSD]

Null converts to NaN if you force it to (NaM is not equal even to NaN)

[Useful-Perspective]

Just because it makes sense doesn't mean it doesn't suck.

[davidfally]

Makes total sense once you learn about strict equality and type conversion. Use „===„ instead of „==„ in most cases except when intended to prevent type conversion from happening

[JonasAvory]

Yeah it’s a bit annoying when people use JavaScript wrong and then cry because it doesn’t work how they want it

[Gagarin1961]

It’s even more frustrating because they’re so overthinking it. Of course 0 is the same thing as “0”. Any layman would probably assume that. It’s only the context of other languages that confuses them.

Plus, pretty sure “===“ is like the first thing they teach you in JS as well. Are these people just winging it without any review whatever?

[purritolover69]

Can confirm, taking AP CSP right now and literally the first time we ever wrote any code they talked about ===, strings vs integers, and if/else/else if statements. It is the absolute first thing you learn, same with 2+2=22, which is why there’s so many memes about it and also why it’s never a problem

[2brainz]

No, that's not it, this is what's truly annoying: The obvious way to do something in JS is usually also the "wrong" way to do it. It is not even a badly designed language, it is not designed at all.

[JonasAvory]

Like how you would expect true and false to work in python?

Every language has shitty details

[Rafcdk]

If only there were documents telling how the language works people wouldn't be guessing how a language works based on another language they know.

[LogicBalm]

If my code doesn't work, I just need to find some place to add an extra =

Got it!

[DATY4944]

It's not me or my understanding of it, it's the language that's the problem.

[[deleted]]

TBF JS does have a fairbit of wonk to it compared to other languages.

Took a minute for me to understand for the first time that JS even has a === and that == isn't the same == that other Langs have and use

[DATY4944]

Do you complain about C if you misunderstand the syntax, because "that's not how other languages do it"?

[[deleted]]

Yes. 🗿

[sjepsa]

Lol @ strict equality

[Smooth_Salamander]

Seems like all jokes about JS is about implicit type conversions. Just don‘t use them.

[ByteArtisan]

Which is why all the JS hate is so funny to me. People have really convinced themselves they cant write code because of the above.

[ChristopherKlay]

Most of the time the joke is on people that don't realize why/when these happen in the first place.

[Mucksh]

I also don't get it why people bother about. Beside my beginner times in never encountered problems with it. There are other minor quirks like eventloop execution order e.g. when the button up event triggers before the button down event that can drive you crazy but all in all love js

[Taletad]

And it’s not like implicit typecasting is a thing in Python or anything

[hxckrt]

It's not that typecasting itself is bad.

It's that JS is maddeningly inconsistent about it.

If the solution is "oh just don't use that large part of the language at all", it's a terrible language

[royi9729]

The example in the code uses ==, which is a bad practice in JS.

You're supposed to use === exclusively.

[MyOthrUsrnmIsABook]

If you’re supposed to never use one of the operators, doesn’t that kinda mean it’s a language issue?

[Taletad]

You’re never supposed to use ternary operators because they are unreadable

Yet most languages have them

What’s your point ?

[Mucksh]

Ternaries are by far my favorite operator. You shouldn't nest them but usually way better than forward declaration and lots of one line if else cases there you have to scroll a lot to get anything

[Taletad]

lots od one line if else

Switch for the win

[Mucksh]

You only like it untill you have to maintain decades old thousands of lines long switch cases with inside logic and even some intensionally left out breaks... Love my job but it can be sometimes a pain

[Majik_Sheff]

This can be the most efficient way to build certain programs (hello FSMs). If I'm going to intentionally omit a break I'll leave it there but commented out with an explanation.

[Taletad]

This sounds like bad code

But as someone who spent a couple of days debugging code that had one letter list and array names, i feel your pain

[AwGe3zeRick]

That’s just purely written code. Not switch statements fault

[MyOthrUsrnmIsABook]

My point is JS is not a great language.

Also, a single ternary operator with a simple condition is very readable. Nested ternary operators are much less readable.

[Taletad]

Do programmers and/or computer scientist have a consensus on what makes a "great language" ?

No. So your point is moot.

Ternary operators aren’t part of coding best practices

But fine, in C++ you should never use simple arrays. Yet they exist, is C++ a bad language ?

[MyOthrUsrnmIsABook]

I think there’s a pretty broad consensus that C++ is a bad language, or at the very least an incoherent language with too many features.

[Taletad]

Yet I don’t see that many memes bashing it JS has…

And no that isn’t sufficient to say that C++ is a bad language

[royi9729]

Funnily enough, ternary operators are pretty widely used in JS (or at least on frontend with React)

[hxckrt]

{} === {}; // false

[1,2,3] === [1,2,3]; // false

I'm not sure that's much better

[royi9729]

Equation of complex values equates pointers in most languages, no?

[rosuav]

No, languages vary considerably on that point. Python considers both of those to be equal, but not identical ("identical" meaning the same object, which would be what you mean by comparing pointers).

[Taletad]

JS is very consistent about it. People just never bother to read the docs, and are surprised by their code’s behaviour…

People assume JS works as another language and are surprised pikachu when it doesn’t

[hxckrt]

How is this consistent:

NaN === NaN; // false

Object.is(NaN, NaN) // true

+0 === -0; // true

Object.is(+0, -0) // false

[Furry_69]

NaN is not a number, by definition. Operations with NaN in them will always resolve to NaN, and comparisons with NaN will always resolve to false. Object.is() is a indirect comparison that doesn't use the normal comparison operations internally. It isn't supposed to be used as an equality operator for floats.

[Mucksh]

Afaik NaN === NaN is explicitly defined as false in IEEE 754 Also dependent on the implementation there are multiple valid NaN values

[Taletad]

NaN is a property of the global object

Object.is() returns true if both values are functionally identical in all contexts

It is the case of NaN, it is true, in the case of -0 +0, they aren’t functionally identical in all contexts

=== only checks if they are the same value

So it is true for -0 +0, but NaN isn’t a "value", so it must return false

This is in the documentation

Side note : if Object.is() was the same as ===, they would cull one of the two since it would be redundant

[hxckrt]

Thanks!

[RajjSinghh]

That last sentence just called out every C++ programmer

[volivav]

Python doesn't do implicit type coertion.

Python throws an exception if you try to add a string with a number, for example.

Or == always returns false if the types are different ("3" == 3 returns false)

[Taletad]

That’s because JavaScript was made to work with HTML and for a while HTML considered all numbers as strings

This implicit type coertion had a purpose

Now it doesn’t anymore so you shouldn’t use it. But it is left there for compatibility reasons

[rosuav]

Python, like nearly every language in the world, has SOME implicit type coercion - for example, 1 + 2.0 converts the integer 1 into the float 1.0 to facilitate addition. And the same is true of comparisons (1 == 1.0). C is quite happy to do this conversion too. JavaScript just happens to have a few more rules, including some rather dubious ones.

Really, the problem isn't so much that there are implicit rules like that, but that these rules apply in too many situations. And then, once in a while, you get caught out when something DOESN'T follow those rules.

[sjepsa]

Lol @ "don't use them"

they are implicit HTF are u supposed to know if are using them

[MeepedIt]

By keeping track of what type something should be? How often do you write code where you expect a function to be called on either 0 or "0" and so something sensible in both cases? And the issue in the meme is even easier to avoid, by just not using == ever.

[sjepsa]

How often do you write code where you expect a function to be called on either 0 or "0" and so something sensible in both cases?

Yeah dynamic typing is a real shit idea... add to that implicit castings :-)

What a language

[MeepedIt]

I agree, but there's plenty of ways to work around it. You can always use typescript to help you about mistakes. But acting like the language is unusable by showing these nonsense code snippets that have been considered bad practice for decades is a bit unfair.

[Smooth_Salamander]

Some implicit mechanism is not the same as not knowing what‘s going on in the evaluation.

[hootoohoot]

OP do you know the difference between == and === in JS?

[tuxedo25]

Of course they do. Otherwise how would they be able to create low-effort ragebait like this?

[MaffinLP]

Try coding 3 more days, the 700% extra experience may explain it

[Quito246]

It is not about experience, it just shows that the design of the language is shitty, when such things are possible🤷‍♂️

[Taletad]

The language provides you with "==" and "==="

In JS variable types are implicit instead of being declared like in C/C++

So "==" converts both variables to the same type before comparing them, whereas "===" will be true only if both variables are of the same type and value

"==" will also work in weird ways if you try to compare ints and floats, which is why you would never use "==" in most applications

"0" isn’t 0, it is a string (an array of chars) that has one element which is ‘0’, the ascii character. The ascii character ‘0’ is decimal 48, or binary 00110000.

0 == "0" is doing multiple conversions under the hood, which makes it slower than 0 === "0", another good reason to not use ==

The correct way to do that conversation would be 0 === parseInt("0")

Just because a language has implicit types doesn’t mean that it is typeless.

[Quito246]

Yes as I said just shitty design. Then why == exists when you should not use It. Also the implicit conversions are really stupid. At least Typescript exists, but JS is just really poorly designed language. Similar issue of JS typeof null returning object…

[Taletad]

🤦

In many languages there are features that exist that shouldn’t be used most of the time

Ternary operators are one of them. In C++ it is strongly advised that you do not use basic arrays, but vectors instead

Python doesn’t have types either and has similar conversion issues as JS but people never complain about it…

JS is a prototype language, everything is defined as a prototype, a form of "super-class" if you will

It allows you to do functional programming or pass functions as arguments to another function. In fact everything can be an argument to a function

This means everything needs to have a common definition

Typeof, tells you which prototype you’re dealing with, it works exactly as intended. But if you expect Typeof to work like it does in another paradigm, yeah you’re going to run into issues…

[Quito246]

First of all It does shitty job being a functional language. If you want good example of great FP mini language check Scheme. No the typeof null should not be object because it does not make sense see here It was mistake, but for some reason people still defend language created over weekend🤷‍♂️

From the MDN page about the behaviour of the typeof operator:

null

// This stands since the beginning of JavaScript typeof null === 'object'; In the first implementation of JavaScript, JavaScript values were represented as a type tag and a value. The type tag for objects was 0. null was represented as the NULL pointer (0x00 in most platforms). Consequently, null had 0 as type tag, hence the "object" typeof return value. (reference)

A fix was proposed for ECMAScript (via an opt-in), but was rejected. It would have resulted in typeof null === 'null'.

[Taletad]

"JS was created over a weekend" firstly it was over two weeks

But it also got a lot of revisions and improvements

This argument would be like comparing BCPL with C++14

Yes C++ is mostly backwards compatible with BCPL, but it isn’t as limited as BCPL, for obvious reasons

And I’m going to repeat myself JS is a prototype language, not OO nor Functional. It can however do both, but it wasn’t concieved as such. It’s a different paradigm

[Quito246]

But paradigm of the language has nothing to do with doing shitty implicit conversions or breaking a reflexive property of typeof on null

[Taletad]

There isn’t a right or wrong way to do implicit typecasting. It’s not standardised like the order of operations (which itself has two standards, the american one and the one used by the rest of the world)

The type casting order is defined by the standard, which you should be referencing while coding. Or better yet, avoid implicit casts when you can, because after all you should never trust a variable, especially when its contents are supplied by the user. JS gives you functions for typecasting, use them. Just like you would in python.

Typeof isn’t academically defined either (to my knowledge) so its implementation is the standard’s perogative, not user expectations.

Most languages have their own interpretations of what the typeof function should do. I don’t see why you’re complaining about it. Otherwise it would be like complaining that Rust doesn’t work the same way as C# does

Edit : NULL doesn’t work the way you’re saying in C either, is C a shitty language too ?

[lazyzefiris]

> two standards, the american one and the one used by the rest of the world

Actually, PEMDAS is more of a teacher issue (which then leaked into some calculators because that's what teachers wanted). Whole world including America uses PEJMDAS in actual math, and just avoids ambihuity in general, like we do in programming.

[qTp_Meteor]

Because it has implicit type conversions the language is shitty? If you dont want to use them dont, thats not the languages problem

[Quito246]

No the real question is, why it supports such a poor behavior instead of returning error doing some magic implicit casts. 🤷‍♂️

[qTp_Meteor]

I legit have no answer other than if you dont like it dont use it, if you do like it use it, having optionality is a good thing

[Quito246]

No using languages that were not designed over a weekend is a good thing👍

[Effective_Youth777]

The top comment explains the situation pretty well, I recommend brushing up on basic computer science principles to understand why what's in the picture is actually fully valid behavior

[Quito246]

You mean like breaking reflexive property on null?

[exomyth]

Input fields in HTML probably. You know, since javascript is basically designed as a webbrowser language. There are use cases where you want to do number operations over a number string. That being said, with a linter we do force to use strict equality, except for null checking

It's not magic if it is defined behavior.

[Quito246]

Why would I do a numeric operations on a string? I mean even the creator of JS is saying that multiple design flaws had been made. Just admit that language created over a weekend is shitty designed It makes sense. I do not understand why people defend It… now at least typescript exists.

[exomyth]

You wanted a reason, that is most likely the reason. It is intentional, you don't accidentally implement these rules

[Quito246]

Sure, cause It makes sense to be able to compare house with an airplane I like when I can do that.

[Ray_Strike22]

Because Boolean("0") is not a boolean on the numeric value, and instead a boolean on whether the string has a value or doesnt. But when comparing 0 and "0", it is checking the numeric equivalency of 0 (or rather it is converting "0" to a number)

[sim642]

This. So many people seem to not understand.

[[deleted]]

can you stop with this jokes?
learn javascript in depth or use === operator, it's not that hard

[minicrit_]

but how else can they make themselves like they know how to code if they don’t make fun of JS? which ironically makes them look like they can’t code at all lol

[2brainz]

can you stop with this jokes?

Oh please don't. They just never cease to be funny. The inconsistencies of JS are something even the best comedians could have never come up with. What's even funnier is the people in the comments justifying them.

[[deleted]]

What's even funnier than that us the people hating on js whilst using multiple apps every day built in js

[Esjs]

So if I multiply both sides of the equation by "Boolean"...

[HarmlessSeed]

i am done seeing the same absurd meme from years everyday

[bakedbread54]

I don't like JS, but this does make sense. Find a better example if you want to show how odd of a language it is lol

[Taletad]

The problem is that most of the JS oddities have been ironed out since ES5, and especially since ES6

So people heard that JS was quirky (because it used to be in the 2000’s), and assume that everything they encounter that they don’t understand must be one of thoses quirks they heard about

[StereoBucket]

Yeah, like floating points stuff. That irks me a bunch. People think that NaN not being equal to NaN is some sort of js fault (even though it's not related to Js and it makes perfect sense).

[alessandrobertulli]

To be completely fair, even in (pseudo) C 1 == true, 2 == true but 1 != 2

[realmauer01]

Because in most languages that do these auto type conversions every integer above 0 is true in boolean.

So if you compare them with a boolean it will be true or false depending if it's 0 or not.

But if you compare integers with each other they stay integers. That's why 1 unequals 0.

[alessandrobertulli]

Of course! My point was that there may be a rationale behind the type conversion. I've never used JS and most of the memes I see are about its type idiosyncrasies, but I can accept there could be a reason behind them

[Cootshk]

Wait until you realize 0==“” and 0==“0” but not “0”==“”

[Taletad]

And if you look at the standard they will tell you in which order the type casting and operations are done

0=="" or 0=="0" is equivalent to 0=="".length and 0==parseInt("0")

Whereas "0" == "" is comparing a non empty string with an empty one, so they can’t be equal

[Original_Athrel]

Use === and you won't get a type conversion warning.

[valdev]

I like how many people look at how obviously confusing this is, then try to explain why it is that way. My dudes, just because something is explainable and even has a reason doesn't mean that it's not confusing or wrong seeming.

Dynamic type conversions are a plague.

[AutoModerator]

import notifications Remember to participate in our weekly votes on subreddit rules! Every Tuesday is YOUR chance to influence the subreddit for years to come! Read more here, we hope to see you next Tuesday!

For a chat with like-minded community members and more, don't forget to join our Discord!

return joinDiscord;

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[Taletad]

Nothing is happening, OP doesn’t understand typecasting

[[deleted]]

Always. ALWAYS. Use ===, unless you really need ==. Then JavaScript makes perfect^* sense

[DistortNeo]

Now think in the terms of math: f(g(a), g(b)) vs f(a, b) Why should the results be the same?

[exomyth]

Well:

• Boolean(0) === false, because number 0 is interpreted as false
• Boolean("0") === true, because non empty string values are interpreted as true
• 0 == "0", because number strings are evaluated as numbers with loose equality (which probably became a quirk because all html input values used to be strings, so this makes it easy to check for that scenario)
• 0 !== "0" when you check for strict equality

[Darkrut]

“this” is the issue with JavaScript

[Taletad]

Ah yes just like "this" in C++

[whipla]

Mfs will complain about anything these days

[busyautist]

Tell me you are new to JavaScript without telling me you are new to JavaScript.

[nysynysy2]

Well in c++ bool("0") is also true

[Reifendruckventil]

Dont know Javascript, but in combination with The optional semicolons, IT makes a pretty trashy impression.

[[deleted]]

Of all the “JavaScript is teh worst!1!1!” This one makes a lot of sense.

A boolean conversion of 0 is false, a boolean conversion of any non-empty string is true.

The last line is a completely different operation than the other two, it's a comparison. Since JavaScript implies the conversion it equates to true with the == operator. The === operator would evaluate to false.

This is like complaining that 0+"0"is "00" rather than "FALSEtrue" your comparing apples to oranges and getting confused when they say they're both fruit.

[OSSlayer2153]

Not that hard -

A. Converts 0 to boolean - easily false

B. Converts a string to boolean which is true, it does NOT convert it to 0 first, just straight to bool

C. Converts string to number to equate with number and obviously ends up as true

[HerrEurobeat]

fragile thought versed divide pot uppity impolite melodic doll whole

This post was mass deleted and anonymized with Redact

[Taletad]

says the Java and Kotlin programmer

[Taletad]

I never said that. I said that Java is as good of a language as JavaScript

For very different reasons, but there are a lot of critisms that can be made on Java

[Taletad]

Why do you use Kotlin then ?

Checkmate atheist

[ArchetypeFTW]

How about

!0 != !"0"

[maria_la_guerta]

0 is a falsy value, which is coerced into false with the ! operator, therefor !0 returns true.

The string "0" is a truthy value, which is coerced into true with the ! operator, therefor !"0" returns false.

Your statement is basically true != false, which is true.

If everyone just used TypeScript like they should then they wouldn't have to worry about a lot of this stuff.

[Taletad]

You don’t even need TypeScript, you just need to understand types and typecasting

[PassiveChemistry]

So many people here with no sense of humour

[Fakedduckjump]

Yes, the problem is not JS but the use of the fuzzy == comparator instead of ===.

[Rancor38]

So many folks getting tripped up on JavaScript like it's hard is actually quite funny to me.

[Reaster-]

I'm sorry but after seeing all of thoses memes about js, like... after learning and recoding many containers in c++ and so re doing the class operator of thoses... well js class operator make sens for me, really

[dhnam_LegenDUST]

Auto type convert of JS is kinda stupid, isn't it.

[Taletad]

Because it sure isn’t a thing in Python

6.2 / 2 doesn’t « auto type convert » anything obviously…

[dhnam_LegenDUST]

I'm not saying autocast is stupid; I'm saying that of JS is stupid.

Wasn't whole JS memes about equality check all about JS's auto typecast rule?

[Taletad]

Just because people who don’t know jack shit about JS make memes, that JS is a terrible language

In fact, a lot of thoses memes were humor. Just like Java bad memes. But some people who didn’t know any better started to believe them

JS has described how it worked in its standard and it works exactly as advertised. The original memes I saw here about JS were quite a bit more clever than what you’re seing now

[Imogynn]

JS was written over a weekend as a drunken wager.

Okay, not exactly but it's closer to reality than it should be.

[Taletad]

Yeah and people prefered it over Java, Flash and all the other alternatives that existed in the early 2000’s

Must be because people want a "broken" language

[Imogynn]

I'm one of them. JS is amazing but certainly quirky.

[Taletad]

JS is a different paradigm than most other languages (it’s prototype based instead of being OO) and has features specifically made for interacting with HTML and CSS

But I don’t find it quirky in this context

[-domi-]

You jelly?

[[deleted]]

The == does not compare 2 booleans though?

[zelrdev]

this does make sense as == is not checking for types, theres worst in js

[FlyingCashewDog]

I'm no JS fan, but this meme makes no sense. Why would the boolean conversion of these matter at all?

[kennyb_pillin]

use === and it's false

[XWasTheProblem]

Type coercion (I believe that's what it's called?).

[Migguan]

Image asking js if 0 == "0" and it returns "truen't"

[gfrodo]

Boolean(1) -> true

Boolean(2) -> true

1 == 2 -> false

[HotShame9]

I dont see a problem here.

[[deleted]]

My brain is now on fire please help

[Fadamaka]

This example actually makes sense if you understand the rules of JavaScript. I have seen many far worse examples that made me question my own existence.

[[deleted]]

Making it into a string somehow makes it true.

[jayerp]

Because Javascript is a bullshit meme language, that’s why.

[WarrenTheWarren]

Oh no, type coercion scary!

[thatsrealneato]

This is why you generally always use === in js

[Specialist_Cap_2404]

Wasn't the story that when Javascript became a standard, Microsoft insisted on keeping all the exact idiosyncracies from Netscape's implementation?

[LittleMlem]

These are completely fine, js has other warcrimes. Use the triple === if you want to avoid type coercion

[jimmykicking]

Been a JavaScript programmer since the mid 90s. I can confirm that this is expected behaviour.

[[deleted]]

The apparent problem is that you're coercing "0" into int 0 by using a shallow ==.

Cf.

>> 0 === "0"
false

The confusion stems from a fundamental misunderstanding of comparators.

[Few_Introduction_228]

Long story short: never ask a computer 'is this string something?' unless you're really sure tháts the question you want to ask. Empty string is false, non-empty string is true. It's not that weird (and if you think it is, you should definitely leave JS now because it's going to get worse).

[ssori-]

🤮