I Tried Defending EVERY Cursed JS Behavior
ฝัง
- เผยแพร่เมื่อ 23 มิ.ย. 2024
- JavaScript isn't cursed at all.....
Shoutout to Wat for inspiring me for over a decade now.
WTFJS SUPPORTS UKRAINE AND I DO TOO, YOU SHOULD CONSIDER DONATING
prytulafoundation.org/en/huma...
SOURCES
github.com/denysdovhan/wtfjs
x.com/t3dotgg/status/17674502...
www.destroyallsoftware.com/ta...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏 - วิทยาศาสตร์และเทคโนโลยี
![ความรักของยักษ์เขียว (ทศกัณฐ์) - เดี่ยว ไออุ่น [OFFICIAL MUSICVIDEO 4K]](http://i.ytimg.com/vi/yCCy-QVHqK8/mqdefault.jpg)
I'm frankly more surprised how little he knows about how javascript works tbh.
I love how nearly all of these are impossible to do on accident if...
- You use TypeScript
- You don't do stupid shit
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
+0 and -0 in floats are more like right and left limits. Floats simply don't have *real* 0. Real 0 inversed is always undefined (in a NaN sense, not js-undefined sense) while left and right limits are inversions of infinities
@@PaweMateuszBytner the reason why there's -0 is because unlike integers in 2's complement, the mantissa in a floating point type, is stored as an unsigned integer, and there's a separate bit for sign. So, if you have a bit pattern for zero, then if you just flip the sign bit, well, you have a bit pattern for -0 (-0.0, actually). CPUs will take care of it, tho, and will compare as equal one to the other.
IIRC, NaN != NaN and -0 == 0 are part of the floating-point spec; most languages follow it.
most languages simply don't have NaN or -0 as far as I know
@@jnoded Those are values defined by the floating point spec all processors implement. Any language that has a floating point type has to support them.
@jnoded in other languages is "spelled" `-0.0`, JS simply drop `.0` and handle every thing as float until you force to` int` using some thing like `x | 0`
Yeah, the real problem here is that JS doesn't really have integers. It has floating point numbers and then pretends really hard that they are integers.
@@ruroruro I would not say "pretends" as if you try enough that you will get real `int`, other wise `asm.js` would not work.
Ok 0*-1 =-0 is the funniest thing I have ever seen
Not a JS issue. It's called IEEE754
@@thomassynths regardless it’s funny 🤷🏻♂️
@@thomassynthsyeah, other languages just hide the negative sign when you print
i feel like its actually intuitive... 0 * positive int = 0, 0 * negative int = -0
@@nitsanbhno, every other language i know evaluates literal -0 to integer 0. but yes, 0.0 and -0.0 are different values according to IEEE
half off video is Theo doesn't understand floating point numbers
Exactly. But also, the author of the document. I find it weird that they dwell so long on `NaN` not being equal to itself. Is as if no one has elementary computer org classes anymore.
JavaScript makes it a bit quirkier because all of the automatic promotions/coercions between objects, arrays, numbers, and booleans, then somewhere some silent `NaN`s pop up and act weirdly. But the rest of the `NaN` behavior is standard across the board on any language.
This makes Dreamberd look credible
I hope you find the charity DB supports credible
Dude, seriously. Read the floating point spec. Most if those "errors" are in all programming language and for good reason
12:02 What do you mean why?? thats literally your epsilon
+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.
That is in deed correct!
the 0 and -0 literals meaning 0.0 and -0.0, respectively, are, however, a javascript thing. even python got that right. hence bigint being tacked on
NaN != NaN is also a floa ting point quirk
@@carlpittenger Any scripting lan guage that follows the ECMAScript spec (i.e. ActionS cript and JScript) represents Numbers as 64-bit floating points. not just JavaScript.
@@dealloc jscript is dead and no one uses actionscript anymore. i'm obviously in this context meaning (and in fact most people in any context mean) ecmascript implicitly
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.
Throwing stuff in strings in general (vs a more fitting type) has always given me the heebie-jeebies, and it seems like JS is super eager to do just that.
This comment right here. This. This. This.
just be somewhat aware of types and readability then all these weird code will not appear
@@seanchen9771 Just rely on the every single person in the team of people you work with throughout time to be this way and your codebase won't be awful? I'd rather not.
@@zanebartlett8004 what you gonna do about it. Rewrite the whole codebase? I mean people throw objects in for boolean checks every now and then right?
If the project youre working on started with js you are most likely stuck with it and most people would not do obscure things mentioned in this video. If it happens it happens there is nothing you can do about it.
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.
Exactly!
As someone who doesn’t use Js these seem a pain to deal with or could cause completely stupid bugs if you ain’t paying attention like what on earth is going on here 30:47
> 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").
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.
"Array equality makes NO SENSE!!" and then array equality makes complete sense
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.
TLDW Every few years someone makes this video. These issues do exist but they don't seem to manifest in real code.
"Ask stupid question, get stupid answer" - JavaScript truthy, probably
"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
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.
I did not mean to cut out the banner I just trimmed up the page to make it readable on my 720p screen!
Donated $1k to Ukraine a week ago and will add a link in description to your preferred Ukrainian charity if you dm it to me (yt eats links)
@@t3dotgg oh, got it. Sorry and thanks for your generous donation! DMed you on twitter.
I swear there's a cron job somewhere that churns these articles out on a quarterly basis, complete with all the same convoluted examples.
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
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?
Mandatory comment complaining about blocks being called closures in this video
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.
Saying +"5" is a bad way to coerce and then suggesting parseInt is hilarious
why?
@@kartikjha833 You have explenation on video for example you shoud always set type of parsing as second argument, because not all runtimes have it the same
Imagine a language that you need a fucking phd to convert a string to int, lol
He should have use Number("5"). it actually is the same thing as +"5". but Number actually is a declarative way to say what you're doing.
@@CrazyWinner357 fortunetry in lower languages like C or rust converting to int is a breeze
Yes? Yes?!
Really this just shows that the mentality of "sensible defaults" rather than erroring is a terrible idea for language design and programming in general
nah it just shows that js defaults are everything but sensible XD
@@benebene9525 But maybe there is just NO way to have sensible defaults: they will always result in unsensible results in some scenario.
yeah; websites blowing left and right would have been so much better!
or, you know... don't use type coercion - just an an extra =
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.
No, the single bang (unary logical negation) not only coerces the value into a boolean, but also negates the operand after coercion. This is boolean logic and it is equivalent to `Boolean("string") === false`. Applying two bangs just negates the negated value i.e. `(Boolean("string") === false) === false`
It's the same for unary plus/minus operator (+, -). It coerces into a number like (Number("123string")) and evaluates it. So -`"-12" === 12`. This is different from the addition operator, which will coerce both operands into primitives before evaluating the expression. If one side is a string, the other is coerced to a string as well. Otherwise if both are numbers it will perform an addition.
-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.
Honestly confused on why everybody hates this weird JS, you never run into these issues if you write good code
Hype
All fun and games till you have to touch a 30k line codebase that uses == everywhere
@@woofcaptain8212 If you use == to compare potentially unknown stuff that can lead to unexpected scenarios, then I'd say that's bad code.
@@woofcaptain8212 Well, if you aren't dealing with data that isn't very specific like data with strings only, then yes
"I hate everything. I'm going to become a farmer."
I think about this often...
Repo: Consider this step-by-step
Theo: "I don't want to consider this step by step"
cracked me up
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".
Agreed
It's convoluted BS that, in my opinion, hardly anyone uses and would cause unintended side effects. There is no need to use boolean negation on a string, it makes no sense and it just causes massive amounts of type confusion.
It is not normal, in any sense, to boolean negate a string to a boolean value because what if you never intended said string to be a boolean, but simply a string with the word true or false?
This is why I hate dynamically typed languages. They treat everything as a variant essentially which causes all these conversion side effects that you never intend.
@@user-oj7uc8tw9r Yeah I mean there is literally no reason anyone would be using double negation like that. I find myself using boolean negation on strings in situations such as:
if (!node.textContent) throw Error(“Node has no content”)
Or for double negation:
function isValidName(name) {
return !!name
}
But the above could also just be written as:
return name != “”.
For me, I think projects that I faced some side effects were the ones that I used a ton of APIs with varying and sometimes unpredictable response values. And even then, I never really found myself thinking JavaScript was the problem, it was just that I didn’t know enough. With what I know now, I would make fewer mistakes and likely waste little to no time dealing with these side effects. I think all of this JS hate is pointless, it’s still a very powerful language regardless. If you write good code, it would be easy to debug the side effects if they ever occur
@@user-oj7uc8tw9r It's actually normal to use negation on a string to check if it's empty or not in a dynamically typed language. That's what you would expect: an empty structure is falsy. Tho I prefer the C++ way, just a simple empty() mehod to check.
@@user-ky6cc9bq4b Ive never see it done in a statically typed language. It would fail in C#, fail in Java, fail in C.
You dont use a negation operator to convert a "false" or "true" string to boolean. You convert it to boolean through a cast or parse method, then use boolean operators on it. That makes sense because a string is not a boolean type. This way, Javascript just assumes the string value should be boolean and converts it as a side effect.
"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.
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.
We should break things more often.
I'm so early, most of the comments are spam!
isn’t that the usual?
Lol fr
Fr
I'm not spam
@@thepeer ok
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
"why is there a -0" thats because how the sign is stored in memory.
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
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
Someone looked at DreamBerd spec and thought "hmm not scuffed enought", and then invented JavaScript
Its funny how TS devs talks about JS! Bro, you use a linter and call it language! Comm!
It's weird because most people don't understand typecasting that's done by js when == is used instead of using ===.
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
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
The guy who made the floating point standard must have been high or something, they single-handedly caused 10% of all bugs in webdev...
Man, being a C# & Blazor dev is so much simpler, almost equals to becoming a farmer lol, it's complete inner peace
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?
Pretty rough. Grateful someone else went through it, not me.
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.
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.
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.
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.
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.
This is what happens when values lose their types and try to mingle with each other.
And you must mingle. No errors or crashes should avoid their meeting.
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.
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.
even though its totally obvious you are being sarcastic and having a fun, i still really appreciate your hint here at 1:45
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.
you can even create unrelated properties on the String/Number objects if you created them with new:
> s = "hello"
'hello'
> s.a = 42
42
> s.a
undefined
> s = new String("hello")
[String: 'hello']
> s.a = 42
42
> s.a
42
>
alternative title: theo grunting for 45 minutes straight
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
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.
The more crazy js is, the more I like it. Awesome video!
your sarcasm actually breaks me
The fact Typescript even exists is a red flag for Javascript.
And people are surprised google's js programmers created dart? And you know what? It has Java syntax, yep, Java will never die
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.
What looks like a duck, quacks like a... You entered the JS world with the knowledge that is not completely transferable and applicable. Most devs with different backgrounds make assumptions about how JS works. When they get hoisted on their own petard, they hate the language.
ECMAScript spec (and some other standards) addresses most if not all the weird stuff shown here. It is 2024, Theo's take on this topic is archaic.
let's just make Gleam the industry standard and leave JavaScript as a compilation target, never to be touched by mere mortals.
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
x == null // check if x is nullish (null or undefined)
You can attach properties to String objects but not native string instances.
I've used this for templating meta information for database string templates.
1 < 2 < 3 becoming true < 3 actually hurt my insides, i can't keep fighting for this language if they throw shit like this 😭
Bro I genuinely didn't know abt the sort thing at 40:49 and now my code doesn't randomly function in dumb orders
The `0` and `-0` are "real" values you can increment/decrement your way to --- if you're playing Minecraft. ;)
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.
you can go further, i doubt you will ever have to face all those weird shenanigans during development.
Learn other languages for the backend. JS and TS add so much complexity compared to the nice dev environments in kotlin, go, hell even java
since you're used to java, i think you'll be way more careful about variable type that the usual JS shenanigans won't be much of an issue.
you could also easily switch to TS if JS type weirdness gets to you, TS is just JS with type safety, no need to relearn JS syntax.
Well, if you watch out for what types you are using (it is tedious with dynamic types and implicit casting everywhere) and don't throw random operators at random variables, there is nothing to be scared about. Also please don't repeat OPs mistakes and just 1. read the documentation, 2. get some grasp about higher level math and actual computer science.
Your reaction thumbnail is spot on.
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;
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.
I love the magic in Python and Ruby, but seeing this, I can understand why people hate magic
It’s so weird that toString unwraps an array of one element. No other language I know of does that.
-0 is just the "ain't no" of JS.
30:56 "I like spreading"💀
last video was "fuck am I a bottom?". are you trying to tell us something theo?
it was very fun, I am a beginner in JS (with a year of exp, nothing imo) and learned a lot
Given how much of JS's weirdness is actually just IEEE754 abuse (like .1+.2 = .30..04). Go look up some talks on it!
The embodiment of a dumpsterfire tornado in a scripting language.
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.
I think I would have given up on learning programming had I started with JS.
@theo deviding by zero is technically undefined (in mathematics) as assigning it a value would break maths ;) if you’d do that you could do stuff like reasoning 1 === 2 === 3 === 4 === …
The intuitive way of assigning it infinity leads to infinity === -infinity - because it depends on from which direction you approach zero from.
there is a nice numberphile video on that if you are interessted in the specifincs ;)
Javascript such a messy language. I love it
2:32 explanation here was slightly wrong as far as I can tell from the spec. LHS is interpreted as "+[]" because "![]" is a boolean value. If my understanding of the spec is accurate the breakdown should instead look like this:
```
[] == ![]
[] == false
+[] == false
0 == false
true
```
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
In the reading of "wtfjs" I heard "has a big ego system"...😂
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
A lot of this didn't even seem that bad to me, knowing JS.
NaN != NaN is IEEE floating point spec. The bit representation of NaN is not unique, so you have to make a choice between comparing primitives with different bit patterns as equal or giving up reflexivity of ==.
this. within a class is ok, but i still prefer the functional way
"why is the internet slow?"
So basically javascript is full of edge cases. I wonder how in the world they land on such decisions 😂
The document.all explanation is terrifying re. the people running JS for decades. Like who cares. Break thing. Give us a warning and break the damn thing 1-2 Years later..
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)
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.
maybe because browsers dont understand python.
Because if you want to develop on the web, you have to use JS. The browser runs JS and nothing else. (There is Webassembly, but it's not used for general frontend stuff, it's quite specialized use cases only.) And since you have to use JS on the frontend, using it on the backend as well (Node.js) is a common option. But on the backend you do have other options (PHP, Python, etc...)
@@kimailis Didn't know it was a browser exclusive thing. I just write backend stuff.
@@tylisirn Interesting. I didn't know it was the only option for browsers. I don't do any sort of front end or UI work at all, CLI stuff only for me, so probably not something I need to dive into any time soon.
@@mcfincher29 yeah and because of that it has a very large community, which grows bigger with options of backend development with node.js and mobile development with react native. all of that makes javascript to be a very versatile language.