Hey Theo! The creator of the wtfjs repo here 👋 Thank you so much for making a walkthrough of my examples. I really enjoyed watching it, and I think we should definitely add a link to this video in the README. You’ve made it both entertaining and interesting to watch. P.S: I noticed that you decided to cut out the repo banner asking for support for Ukraine. As someone still living in Ukraine, I experience the daily realities of missile and drone strikes, electricity outages, and all the other hardships that come with war. I, along with all Ukrainians, still need the community’s support.

IIRC, NaN != NaN and -0 == 0 are part of the floating-point spec; most languages follow it.

This makes Dreamberd look credible

the reason -0 exists is because of IEEE 754. it makes sense, Floating point is an approximation of the real number line. -0 represents that the very small number we want to represent is negatice

I love how nearly all of these are impossible to do on accident if... - You use TypeScript - You don't do stupid shit

Ok 0*-1 =-0 is the funniest thing I have ever seen

Honestly, almost all of these weird things come down to the same root cause: type coercion. JS is just far too willing to coerce types, so if you code in a way that avoids it, you'll probably be fine; explicitly convert types yourself, don't rely on JS to do it for you. Or, you know, use TypeScript.

half off video is Theo doesn't understand floating point numbers

+0 and -0 is not JavaScript thing. This is feature of floa ting point numbers internal format which is used by CPUs and GPUs for a very long time.

Dude, seriously. Read the floating point spec. Most if those "errors" are in all programming language and for good reason

Honestly, I feel these issues are overblown by people who dislike javascript for entire different reasons. Most of these boil down to "don't use operators on non-primitive types". I genuinely don't remember last time I would trip on any of these in last 15 years writing JS.

The reason for NaN not being equal itself is that, if it was equal, then this would be true: Math.sqrt(-2) == Math.sqrt(-3) [NaN == NaN] where it is obviously false.

12:02 What do you mean why?? thats literally your epsilon

These kind of videos serve mostly to show off the ignorance of the person looking at the examples. In the nineties and naughties, people had this silly idea that languages shouldn't trigger error messages when people did something wrong, but instead try to do what the programmer intended. I think that was a reaction to the cryptic core dumps and errors of languages of the seventies and eighties. People thought error messages was the problem so they avoided them. This is common to all languages of that era, JavaScript, PHP (which has exactly one good feature), Ruby, Python, CoffeeScript, jQuery... Some are worse than others, but all are infected with that mindset. And then people usually go on to complaining about floating point arithmetic to just _really_ show off their ignorance.

> Why is `Number.MIN_VALUE` the smallest _positive_ value? Because the smallest _negative_ value is `-Number.MAX_VALUE`. As simple as that. Again, simple floating point practices, common to all languages I am aware of. The ways how JavaScript treats floating point numbers is actually *consistent* , even though they may look weird and illogical (and appear "truly JavaScript-y").

"Ask stupid question, get stupid answer" - JavaScript truthy, probably

I swear there's a cron job somewhere that churns these articles out on a quarterly basis, complete with all the same convoluted examples.

Mandatory comment complaining about blocks being called closures in this video

I'm frankly more surprised how little he knows about how javascript works tbh.

TLDW Every few years someone makes this video. These issues do exist but they don't seem to manifest in real code.

"Array equality makes NO SENSE!!" and then array equality makes complete sense

Honestly confused on why everybody hates this weird JS, you never run into these issues if you write good code

"Why does -0 exist?", "Why is NaN so weird?", etc most of the weird things pointed out here are just actual parts of IEEE 754. IEEE 754 is what we usually call the floating point spec but its actually more than that its the floating point arithmetic spec and as such includes a bunch of things that are weird or confusing if you dont work on a very low level with floats. Things like NaN, -0, infinity and -infinity are all values that IEEE 754 have defined for good reason and their weird behaviours follow therefrom. NaN should not equal NaN since NaN is more of an error state than an actual value and are in spec returned from any "invalid" arithmetic operation (0/0, infinity * 0 that kinda thing). This is good! This makes float arithmetic algebraically complete that is every operation returns some value even if that value is kinda nonsense. This also means that there are multiple ways of getting NaN hence why it would make no sense for NaN to equal itself. Most other "weird" operations with these values have similar justifications. In my opinion the fault isn't in the fact that these values behave like this. They should behave like this there is a good reason they do and they don't (or at least they shouldn't but who knows what happens once JS type coercion is done destroying everyone reasoning abilities) show up in most code because they are edge case definitions. In general these values are very low level constructs so you could even argue about whether or not JS should even expose these directly instead of handling them in a more language appropriate way within the engine itself but it's too late for that now so. If you want a better understanding of why IEEE 754 is like it is go read the "Design Rationale" part of it's Wikipedia page or better yet go read the spec itself! It's a very interesting topic if you like these more low level things

Saying +"5" is a bad way to coerce and then suggesting parseInt is hilarious

2:32 Honestly, when the first example here is about asking "why?" does the order of operations matter in a programming language, I'm really not sure what the point of this video is

Regarding the empty slots in array: They denote a missing index it's not a different type of `undefined`. Say you have the array `const sparseArray = [/* empty */, "1", 2]`, then you can check if a slot is empty by doing `0 in sparseArray` if the array doesn't have the property `0` it indicates an empty slot in index position `0`. The reason why the return type is a normal undefined is because if you access an attribute that's not there you simply get `undefined`. For example `const obj = { a: 1 }` then `obj.b` will yield `undefined`. Just like `sparseArray[0]` yields `undefined`. You are accessing a property that doesn't exist. If I would do `delete sparseArray[1]` then index `1` is now also an empty slot.

I thought the double not operator converts values to their boolean equivalent so !!"false" would be true because a string is truthy. !!"" would be false because an empty string is falsy. Same thing for the !!null, that would be false because null is falsy. The explanations around all the double nots seem to be convoluted at best.

I agree with most things but some stuff is really simple, such as 3:07, and I feel like you may be overexaggerating this a bit. !!"false" == !!"true" being true is completely normal. A non empty string is truthy. The first ! makes it false, and the second flips the false and makes it true. There is nothing wrong with this, and yet you make it seem like it's very strange, and that we are in "hell". 4:57, When checking if a boolean is equal to a string, it obviously wouldnt return true. Now given my previous point, you might then confuse why !!"true" is true, and that is because ! converts it to a boolean. So it goes !!"true" -> !false -> true, which also explains 5:03. I wouldn't say that is "dumb". 9:20 Now I know this one isn't intuitive to understand, but I will try to explain it in a way that hopefully the confusion would go away. I believe the reason why null == false is false but 0 == false and "" == false is true, is because null is loosely connected to undefined (which is also why at 10:28, document.all == null is true, while document.all == undefined would also be true, but document.all == false is fasle). Undefined is when the value isnt assigned, and null is when its been assigned but has no value, and so there is no type coercion. Strings and numbers go through type coercion but null doesnt, since it's not really a type. All you need to remember is that there is no type coercion for null and undefined and that should make sense of this. People should not be told these are challenging or strange. You can make simple things become difficult by simply pretending that they are. Many people including myself look up to you, and so I think we would all appreciate it if you would actually pause to think about these things instead of hopping on the "Yep there it is, JavaScript is dumb".

Really this just shows that the mentality of "sensible defaults" rather than erroring is a terrible idea for language design and programming in general

If you don't get -0, then you can't understand floating point. It's not a JavaScript thing at all. All floats are approximations. They have limited precision. And sometimes it matters if the result you get is slightly less than 0 or slightly more than 0. NaN !== NaN makes sense, too. NaN is a result you should not get. If two expressions fail, you don't really want them to be equal to each other. And I get why "false" != false. It's normal to check if a value has been input by doing "if (textbox)". It would suck if that failed because the user typed in "false." The idea that any non-empty string is true makes sense to me. I only find it weird when the DOM coerces false or undefined into "false" and "undefined". That's dumb, and should be the same as assigning the empty string. And of course string- number equal not a number. There is no defined operation for subtracting strings. What else could it return?

"the falseyness occurs before the number coercion...why?" I think you already know why, it's just about evaluation order. The real questions are why was it decided that the empty array is truthy and why was it decided that == coerces things to numbers.

-0 and 0 are warts of IEEE754 Floating numbers and as such they exist in most programming languages. There's no -0 in integer numbers.

Repo: Consider this step-by-step Theo: "I don't want to consider this step by step" cracked me up

15:57 sometimes I think that He doesn't know what he talking about ) so, basically what happened, first array is empty and when you try to access nonexisting key you will get undefined the same that you store in second array under existing key you can not get "empty" value from array

"I hate everything. I'm going to become a farmer." I think about this often...

Prototype helps so much when I need an insert function bc somehow js doesn’t have it yet😢. Edit: nvm I bothered to do research but still, why is it an extra arg on splice with 0 in the delete count?

I'm so early, most of the comments are spam!

Integer arrays being sorted alphabetically is remarkable...

I feel like Theo is the kind of guy that if he ever used ActionScript3, he'd be stuck using it since its got most modern syntax features (E4X, JS typing, Embedding file) in an old language

your sarcasm actually breaks me

Pretty rough. Grateful someone else went through it, not me.

"why is there a -0" thats because how the sign is stored in memory.

I'm wondering... What is I define a toString method which does not return a string? How will the + operator work then? Just try it: const a = { toString: ()=> 1, }; const b = { toString: ()=> 3, }; a + b;

It's weird because most people don't understand typecasting that's done by js when == is used instead of using ===.

the reason -0 exists is because of IEEE 754. it makes sense, Floating point is an approximation of the real number line. -0 represents that the very small number we want to represent is negative

the "wat" talk honestly summarizes javascript pretty well

I'm new to JavaScript and learning, I like it so far, coming from Java, But this looks scary lol! So should I even go further or do I still have time to change lol.

Bro I genuinely didn't know abt the sort thing at 40:49 and now my code doesn't randomly function in dumb orders

Its funny how TS devs talks about JS! Bro, you use a linter and call it language! Comm!

You can attach properties to String objects but not native string instances. I've used this for templating meta information for database string templates.

Your reaction thumbnail is spot on.

alternative title: theo grunting for 45 minutes straight

thank you for inspiring me to watch actual coding channels who know what they're talking about and also to join your nemesis as a member, he needs more funding to do what he's doing for the community :p

Javascript has a reason for most of its weirdness. The reason some design decisions are criticized is that much like required reading in highschool, if you work with the web at any point, you have to deal with javascript. People just grow resentful they have no choice to use it, and making fun of certain features become memes. Because of its position as the main programming language of the web, it can't really do breaking changes, and undoing certain core design desicions isnt feasiable. When it was created, its creator had no idea of the scope it would eventually cover, and since the community grew so huge, contributors had to balance giving everyone enough features so that everyone was only half angry. But yes it is fun to make fun of all the quirks of the language, just don't forget that there is context to all of the design decisions you don't love. Also python, get some brackets, ruby, not everything has to be magic, Php, you're cool now.

I would assume (I haven't looked at the actual implementation) that values are stored in a way similar to this: struct Value { bool is_empty; enum { VAL_UNDEFINED; VAL_NULL; /* ... */ } type; void *value; } so when you set no value, it just sets is_empty to true, but when you set a value manually, it sets it to false, and then sets the type to undefined. I'm not sure why undefined doesn't just always set it to empty, or empty is just the undefined type, but maybe its because JS is old and people rely on it now.

The more crazy js is, the more I like it. Awesome video!

I've been developing for a living for a few years now. Mostly building analytic tools in Python, and dabbling in low level stuff like Rust and C... As someone who knows nothing about Javascript, but has seen many videos like this before, I'm struggling to understand why anyone would ever learn JS in the first place. Is there any good reason? I want to expand my toolkit as much as I can, but I've avoided JS like a plague so far.

I do have some cases where I add numbers in JS like if I want to have atleast 2 out of 4 things to be truthy I can cast them to bools add them and check if the sum is greater or equal to 2

Someone looked at DreamBerd spec and thought "hmm not scuffed enought", and then invented JavaScript

21:59 which javascript engine `{} + {} // -> '[object Object][object Object]'`? I get NaN in librewolf 127.0.1-1

I think Google has a brain implant in me, I was just thinking about how cursed JS is, just a random thought, and I scrolled half a page, and here's this video. It's not even like I watch heaps of this channel 😂

12:00 This is an important concept in math. I was just reading about Kakeya’s Needle Problem today, and the goal in it is to minimize the area needed to sweep a needle of zero-width 180°. Various mathematicians found ways to minimize the area needed that approach zero at the limit, but the area can never actually _be_ zero. This would be a perfect application of Number.MIN_VALUE. The limit would be equal to it, and it would be greater than zero, for good reason. Meanwhile, negative infinity would be smaller than any number, and negative Number.MIN_VALUE would be the largest negative number before zero.

Fun fact, -0 is actually part of the FP standard, a lot of languages have it! I've specifically used it as a special flag in games I've made.

It seems like there is still an opportunity to create an npm package to warp these comparisons into custom comparators, just to break out of this madness

my mind is going blank

It’s so weird that toString unwraps an array of one element. No other language I know of does that.

i love how about 3 seconds into a video where he tries to pretend to defend dumb js crap, he just stops pretending and immediately wants to roll over

so many of JS's wonky-ahh casts makes me feel smug as someone who primarily uses ocaml (which is so strictly typed that float and int addition have to have separate symbols)

-0 is just the "ain't no" of JS.

About the new String thing: you can call the String and Number constructor with and without new: without new, it works just like you would expect, it converts the argument to the respective type, and typeof will give you a reasonable result. with new, you get a "String object" or "Number object", which is basically like a string or number, except that you can actually override functions and stuff, as you've shown with your "this is the wrong string" example.

The guy who made the floating point standard must have been high or something, they single-handedly caused 10% of all bugs in webdev...

35:00 This is why you should turn off "allowUnusedLabels" in your tsconfig when you write TypeScript. () => { hello: "world" }; will report an error with that option set to false.

37:40 so are you saying that the assignment operator evaluation order is left to right? foo.x = foo, then foo = {n:2} what about this then: var y=1; var x = y = 2; ???

I have 2 uses for the double equal: - x != null // check if variable x is defined - x == y // check if values are equal, when you KNOW they are either a number or a string, like for checks with input values

In the Godot game engine, a freed object == null, but is truthy. Assigning a freed object to a variable _sometimes_ throws an error, and a freed object inside a closure gets turned into a null. And of course you also need to check if an object is queued to be freed at the end of the frame but hasn't actually been freed yet. I think some of this is changing in 4.3.

patching the Number prototype has a neat application: you can make numbers iterable (counting 0 to n-1), so you can "for...of" them or use them everywhere iterables can be used. i also added some forEach, map and reduce methods. for numbers that aren't positive intergers, the behaviour isn't quite so obvious but your also unlikely to use them for those. :P i get why expanding builtins is probably not something you should do in a professional setting, but it's a very nice feature to use and it may be a cool in other languages.

I think I would have given up on learning programming had I started with JS.

I like how it started as "F this language" and then past 20 mins suddenly "it is cursed but it does make sense". See? That's how JS will get you

"why is the internet slow?"

I love reJular expressions lol

The hell I went through coming from Java and C to javascript. The syntax didn't make sense at all simply because of those small unintentional bugs until I started working it it from the beginning forgetting all the programming concepts, learning the syntax and then reapply those concepts. For a person starting with JavaScript its okay but coming from a statically typed language, you will hate it.

NaN != NaN is part of IEEE spec and same in other languages. It makes sense since something like 0/0 == parseInt(“hello”) would be crazy, and make debugging harder. Classic frontend script kiddie to blame standard floating point behaviour on js ;)

A lot of this didn't even seem that bad to me, knowing JS.

it was very fun, I am a beginner in JS (with a year of exp, nothing imo) and learned a lot

Funny how everyone was complaining about Perl when JavaScript has at least the same level of “unexpectedlyness” as Perl especially regarding strange automatic type conversions.

8 minutes in and I'm wondering if Theo knows of IEEE754's weird quirks... But to be fair JS would be the language that could falsely claim credit for them....

As a C developer, I genuinely have no idea how you deal with those atrocities. I think I'd just quit programming. This video actually made me have a lot more respect for web developers. Hats off, seriously.

And people are surprised google's js programmers created dart? And you know what? It has Java syntax, yep, Java will never die

I've done so much TypeScript' now... I can't even reason about js anymore

The String.split() behaviour is correct (at least the one shown here, it might do something weird in some other cases, it's JS after all): - There are empty strings between each character (conceptually), so splitting on "" must return an array of every character on the string. Since you are calling it on an empty string, that result will be empty. - Splitting by something not in the string should return nothing, because there's nothing to each side of that separator ( the case for "".split(" ") ). These are just edge cases, but the behaviour is logical.

Man, being a C# & Blazor dev is so much simpler, almost equals to becoming a farmer lol, it's complete inner peace

The fact Typescript even exists is a red flag for Javascript.

I would say the explanation would make more sense if it did it step by step, rather than just jumping straight to number. i.e. why does [] become 0? My understanding (which may be entirely wrong) is that it converts it to a string, and then parses that string as a number. This means if it is an empty array, it will be an empty string, which returns 0. If it is an array with 1 element, it will return 0 if that element is the empty string, whitespace, null or undefined; a number if that element is a number including a string representation of a number, and NaN otherwise. If it is an array with 2 elements, it will return NaN. For added cursedness: While [] == !![] returns false, [1] == !![1] returns true. And while [1] == [1] is false, [1] == ![1] is also false.

30:56 "I like spreading"💀 last video was "fuck am I a bottom?". are you trying to tell us something theo?

23:13 wouldn't monkey patching being a thing open up all sort of vulnerabilities? It is not just cursed it is a real danger 😱 how is this allowed ??? Why don't browsers just freeze prototypes ??????

There is a complicated table of how == equality works. But the truth is… you don't need it in reality, unless you're doing something strange. If you're comparing primitives they would be coerced to string or number depending on what you have passed in. So, it's handy to check for example == 2, when your backend may send "2" with no need of manual coercion Number('2'). I'd recommend to use strict comparing === to *true* or *false* , but that's a rare case, especially after defaults where introduced, and one can do something like function foo(bar = true) { if (bar) … // could be “if (bar !== false)” in the old days } Objects are compared their to strict identities between them, no matter are you using == or ===. [] != [] is same as [] !== [] and is true, since you're comparing two different freshly created arrays here. *null* and *undefined* are equal only to self, as already noted. So it's safe to compare anything with them. (Usually != null is handy and shorter.) The unexpected part begins when you're comparing any type of object to primitive, so it's a bad idea to do. Just don't do it. Why would you? Why would one compare *false* and an array? It's that case when explicit better than implicit. E.g. by using .toString(). But still it's quite a rare case too. Usually, objects compared to be same or being nullish. So, that WAT part is quite overhyped really. Yep, one cannot use + to concatenate arrays like in Python, [...array] spread or .concat() should be used for that. But you learn it when you learn basics about arrays and their methods. No big deal.

The promise flattening is unsurprising if you've ever used fetch() on an API. The .text() and .json() methods of the response return promises. Code I commonly saw and wrote (before async/await) was like fetch(...).then(r => r.json()).then(myJson => { ... } ) and myJson would not be the promise, it would be the resolved value.

The fun stuff for NaN is equality in the simple sense of numerical value. If the result of a math operation is undefined, then you get NaN. By definition, this cannot equal any other number. Just like infinity cannot equal infinity. As you cannot make a comparison between their values. For 0, by definition -0 is a different object to 0. But their values are both 0, so if you compare them by value, even using the strict equality operator, the result is true.

Whoever invented nodejs are the ones who are truly unhinged, taking this cursed frontend language and deciding to use it for backend

even though its totally obvious you are being sarcastic and having a fun, i still really appreciate your hint here at 1:45