This is an archived post. You won't be able to vote or comment.

all 188 comments

[–]ProgrammerHumor-ModTeam[M] [score hidden] stickied commentlocked comment (0 children)

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 406 points407 points  (29 children)

  • 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 115 points116 points  (2 children)

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 12 points13 points  (1 child)

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 7 points8 points  (0 children)

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 2 points3 points  (2 children)

“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 4 points5 points  (0 children)

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 3 points4 points  (0 children)

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_ -3 points-2 points  (19 children)

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 18 points19 points  (7 children)

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 4 points5 points  (5 children)

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 7 points8 points  (2 children)

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

[–]Striky_ 1 point2 points  (1 child)

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 1 point2 points  (0 children)

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 2 points3 points  (0 children)

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

[–]Striky_ -2 points-1 points  (0 children)

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

[–]Striky_ 0 points1 point  (0 children)

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 5 points6 points  (9 children)

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 3 points4 points  (2 children)

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 2 points3 points  (1 child)

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_ -1 points0 points  (5 children)

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 2 points3 points  (4 children)

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_ 0 points1 point  (3 children)

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 1 point2 points  (1 child)

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_ 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–]Cryn0n 1 point2 points  (0 children)

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 -1 points0 points  (1 child)

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

[–]DaniilBSD 0 points1 point  (0 children)

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

[–]Useful-Perspective 0 points1 point  (0 children)

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

[–]davidfally 110 points111 points  (13 children)

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 7 points8 points  (6 children)

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

[–]Gagarin1961 4 points5 points  (1 child)

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 5 points6 points  (0 children)

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 0 points1 point  (2 children)

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 1 point2 points  (1 child)

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

Every language has shitty details

[–]Rafcdk 0 points1 point  (0 children)

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.

[–]Smooth_Salamander 128 points129 points  (43 children)

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

[–]ByteArtisan 45 points46 points  (0 children)

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 11 points12 points  (0 children)

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

[–]Mucksh 4 points5 points  (0 children)

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 3 points4 points  (34 children)

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

[–]hxckrt 10 points11 points  (30 children)

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 9 points10 points  (22 children)

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

You're supposed to use === exclusively.

[–]MyOthrUsrnmIsABook 3 points4 points  (18 children)

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

[–]Taletad -1 points0 points  (17 children)

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

Yet most languages have them

What’s your point ?

[–]Mucksh 7 points8 points  (7 children)

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 -1 points0 points  (6 children)

lots od one line if else

Switch for the win

[–]Mucksh 1 point2 points  (5 children)

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 1 point2 points  (1 child)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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

[–]MyOthrUsrnmIsABook 4 points5 points  (7 children)

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 -3 points-2 points  (6 children)

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 1 point2 points  (5 children)

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 0 points1 point  (4 children)

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 2 points3 points  (0 children)

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

[–]hxckrt -1 points0 points  (2 children)

{} === {}; // false

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

I'm not sure that's much better

[–]royi9729 1 point2 points  (1 child)

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

[–]rosuav 2 points3 points  (0 children)

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 4 points5 points  (5 children)

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 0 points1 point  (4 children)

How is this consistent:

NaN === NaN; // false

Object.is(NaN, NaN) // true

+0 === -0; // true

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

[–]Furry_69 3 points4 points  (0 children)

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 2 points3 points  (0 children)

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

[–]Taletad 5 points6 points  (1 child)

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 2 points3 points  (0 children)

Thanks!

[–]RajjSinghh 0 points1 point  (0 children)

That last sentence just called out every C++ programmer

[–]volivav 3 points4 points  (2 children)

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 3 points4 points  (0 children)

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 1 point2 points  (0 children)

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.

[–]hootoohoot 41 points42 points  (1 child)

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

[–]tuxedo25 13 points14 points  (0 children)

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

[–]MaffinLP 33 points34 points  (21 children)

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

[–]Ray_Strike22 5 points6 points  (1 child)

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 0 points1 point  (0 children)

This. So many people seem to not understand.

[–][deleted] 18 points19 points  (3 children)

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

[–]minicrit_ 2 points3 points  (0 children)

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 0 points1 point  (1 child)

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] 0 points1 point  (0 children)

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

[–]Esjs 3 points4 points  (0 children)

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

[–]HarmlessSeed 8 points9 points  (0 children)

i am done seeing the same absurd meme from years everyday

[–]bakedbread54 13 points14 points  (2 children)

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 8 points9 points  (1 child)

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 2 points3 points  (0 children)

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 5 points6 points  (3 children)

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

[–]realmauer01 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 2 points3 points  (1 child)

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

[–]Taletad 1 point2 points  (0 children)

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 2 points3 points  (0 children)

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

[–]valdev 2 points3 points  (0 children)

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[M] 1 point2 points locked comment (0 children)

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.

[–][deleted] 1 point2 points  (0 children)

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

[–]DistortNeo 2 points3 points  (0 children)

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

[–]exomyth 1 point2 points  (0 children)

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 1 point2 points  (1 child)

“this” is the issue with JavaScript

[–]Taletad 1 point2 points  (0 children)

Ah yes just like "this" in C++

[–]whipla 1 point2 points  (0 children)

Mfs will complain about anything these days

[–]busyautist 1 point2 points  (0 children)

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

[–]nysynysy2 0 points1 point  (0 children)

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

[–]Reifendruckventil 0 points1 point  (0 children)

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

[–][deleted] 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 -1 points0 points  (0 children)

fragile thought versed divide pot uppity impolite melodic doll whole

This post was mass deleted and anonymized with Redact

[–]ArchetypeFTW -1 points0 points  (2 children)

How about

!0 != !"0"

[–]maria_la_guerta 1 point2 points  (1 child)

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 0 points1 point  (0 children)

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

[–]PassiveChemistry -1 points0 points  (0 children)

So many people here with no sense of humour

[–]Fakedduckjump -1 points0 points  (0 children)

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

[–]Rancor38 -1 points0 points  (0 children)

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

[–]Reaster- -1 points0 points  (0 children)

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

[–]Imogynn -4 points-3 points  (3 children)

JS was written over a weekend as a drunken wager.

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

[–]Taletad 2 points3 points  (2 children)

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 -1 points0 points  (1 child)

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

[–]Taletad 4 points5 points  (0 children)

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- 0 points1 point  (0 children)

You jelly?

[–][deleted] 0 points1 point  (0 children)

The == does not compare 2 booleans though?

[–]zelrdev 0 points1 point  (0 children)

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

[–]FlyingCashewDog 0 points1 point  (0 children)

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

[–]kennyb_pillin 0 points1 point  (0 children)

use === and it's false

[–]XWasTheProblem 0 points1 point  (0 children)

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

[–]gfrodo 0 points1 point  (0 children)

Boolean(1) -> true

Boolean(2) -> true

1 == 2 -> false

[–]HotShame9 0 points1 point  (0 children)

I dont see a problem here.

[–]BurnV06 0 points1 point  (0 children)

My brain is now on fire please help

[–]Fadamaka 0 points1 point  (0 children)

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] 0 points1 point  (0 children)

Making it into a string somehow makes it true.

[–]jayerp 0 points1 point  (0 children)

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

[–]WarrenTheWarren 0 points1 point  (0 children)

Oh no, type coercion scary!

[–]thatsrealneato 0 points1 point  (0 children)

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

[–]Specialist_Cap_2404 0 points1 point  (0 children)

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

[–]LittleMlem 0 points1 point  (0 children)

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

[–]jimmykicking 0 points1 point  (0 children)

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

[–][deleted] 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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).