I didn't include this, bind, type coercion, let dead zones, or any typical "i hate js." I also didn't include Dates because I am convinced that when it was conceived it was considered the best way to handle dates (have you seen other languages in the mid 90s? It was a literal copy of another library at tha time) But the items I included are truly awful items that are not found in other languages (that i know of)
I think the forEach case is acceptable because sometimes you just want to iterate over the value in some iterable type. So having it value, key allows for key to be ignored entirely giving (val) => {}; Doing it the other way is more complicated to solve for.
5:36 This leads to one of my hot takes. Javascript is just the BASIC of the 2010-2020s. It's an approachable entry point for new programmers and people want to use it for everything, but that leads to it being used for things it has no business being used for. And everyone and their grandmother has their own library/way of doing things/dialect for any given task, which stretches the language beyond its comfortable limits
But isn't that the BEAUTY of it? It can be bent forwards, backwards and upside down and it still works amazingly! Sure there are caveats but which language doesn't?
@@aryandeora6631 I mean, it’s convenient, but I don’t think it’s ideal. Different tools/languages are appropriate for different tasks and trying to fit every task to JavaScript just feels like trying to turn a wrench into a hammer-sure, you can probably get to the same place eventually, but you’d have a way easier and better time if you just stopped and grabbed a hammer. Like, I wouldn’t use JS for systems programming, just as I wouldn’t use C for web ui programming and I wouldn’t develop an operating system APL.
@@aryandeora6631 and I 100% see your standpoint as well. I’m a bit of a hypocrite because I work in C# which has libraries and frameworks for pretty much everything under the sun.
When interfacing JS or TS people from my C++ code what I hate most is that they silently send you json with all kinds of shit in it - that is invisible to them because of JS-sloppyness... Like when they randomly send "empty string" instaed of null, undefined as string and such horrible pieces of shit. My code is having tens of special cases for parsing their fucked up shit :D
Silly footgun (and one that does somewhat fall into your type coercion moratorium), but checking whether a variable is undefined vs truthy or falsy as a practice (e.g. foo && ... ) has just caused no end of headaches for my applications in the past. Probably more of a best practices thing and goes back to the community being the problem, but it's still unbelievably aggravating.
I ve written a lil package for it. Rn it's pretty dumb, it just checks if the falsey is not 0 or "", cause those are the situations that i came across that really tripped me up.
This got me once: function average(averages: number[]) { return averages.reduce((sum, n) => sum + n) / average.length } we divide by average.length, not averages.length, and average.length is for some reason the number of arguments the function takes.
Lemme add number 6, this keyword with functions When I started to learn I used a normal anonymous function instead of arrow function within a class, i never suffered like that hour all I needed was the arrow function Number 7 threading: the reason why I switched to another lang whenever I needed threading it's pain =(
hah. I didn't want to talk about this. everyone knows about this being a bit confusing. And threading! Its the reason why people _like_ javascript unironically.
@@parlor3115 the prove isn't with promises I use them all the time dw, it's for certain cases where threading becomes painful like when I made a discord api wrapper I needed some variables to be shared and it was a real pain to get it done since my variables were constantly changing and needed to be updated across all threads, you can see how complex this problem can be by checking djs code they do that too. Long story short threads are nice but Javascript isn't made for this and I prefer to use another language like csharp to tackle it
The best place to use regex is for things that you know for a fact that has a very rigid and predictable pattern. Like repetitive codes and languages. Or just a quick tool for extracting data from large amount of text that you need very often. What regex is really not good at is filtering things that are potentially bad for your purposes.
I liked it when JS' forEach used value, key. Because in most cases we needed the value instead the key. It would be silly to write .foreach((undefined, value) => ...)when we just needed the value.
i've got a juicy fact that i just learnt about 5 minutes ago: associative arrays are NOT part of javascript. which leads to some hilarious results below. * if you access an array index using a numerical string, it coerces the string into an int. i.e. *a["420"] === a[420]* * _however,_ if it's not a numerical string it treats it as a property of the object. i.e. *a["07"] !== a["7"]* * all indices where you assigned a value (even if that value is `undefined`) WILL return true if you call hasOwnProperty. i.e. *[6,9,4,2,0].hasOwnProperty("4") === true* and even *[6,9,4,2,undefined,0].hasOwnProperty("4") === true* * if you skip an index, it'll fill the indices in between with empty slots (which is somehow different from assigning `undefined` values) so if you call hasOwnProperty on the in-between indices they'll return false (!!). i.e., if you initialise an array *a = [6, 9, 4, 2]; a[5] = 0;* then *a.hasOwnProperty("4") === false* HOWEVER *[6,9,4,2,undefined,0].every((v, i) => v === a[i]) === true* . wtf?? js isn't just too smart by half, it's too smart by half recursively. it's just unbridled genius all the way down.
Email regex validation is very easy when you learn that the TLD isn't required for emails and symbols like +, - are valid. Knowing the spec halves the regex expression :^)
I really wonder what people are even checking for when they are doing email validation. If it's just whether someone didn't understand that it was an email field, just check if it contains an @. Otherwise you're not going to be able to check if it actually exists or whatever!
I’m surprised that Netflix isn’t using erlang or elixir given how good they are for multi connection services. Imagine having to rewrite the whole backend with rust…but I guess you can use wasm so it could all be rust.
@@oskrm not as tried and teated as other languages, harder to find devs for, has a reputation for being associated with blockchain hopefully time will fix these issues
@@vitiok78 firstly, that's actually the sort of thing that runtimes are good at making as fast as C, secondly C is slow as deep copies too. Because a deep copy is by definition a lot of work. You could ask for immutable data structures though...
Here is another one, you would expect somearray.every(condition) to return true if the condition is true, which works fine untill the array is empty, then it return false, which is very misleading, Same for somearray,some
"The lords language Rust" made me laugh and started wondering... Are we all created in Rust? Are we all at heart Rustaceans? Are we all... Blazingly fast?
My "favorite" bit about JS is the fact that you can still manage to create memory leaks in a GCed language, and because of the nature of the language, you're not meant to be actively thinking about that sort of thing, so you don't notice it til your program is whoring an abnormal amount of memory.
For simple applications, no. If you ever start trying to do something clever "just because the compiler/interpreter allows it", that likelihood definitely shoots up, though. Likewise when dealing with lower level data structures and such.
I imagine it tends to happen when you have a huge stack of async functions all holding "temporary" named variables full of references to other large structures.
The regex one has actually screwed me over during my live exams, Luckily I was able to write a shitty function to replace what it was doing, but after the exam when I looked at why it was doing it what it was doing I had the same question, WHY?
Why were you using a global flag in a test function, though? If you're just doing a boolean test, I can't think of a good example where you actually want the global flag. Without the global flag, this isn't an issue. If you are reaching for the global flag, you're probably intending to use a different regex function, not test.
Rust sucks because it makes it unbelievably annoying to do things that should be basic. Things like making a temporary variable to a pointer which could be hidden behind many array indices. Rust has the philosophy where it forces you into doing things that are inconvenient and makes it hard to opt out. My vision for a language like rust that pleases c developers would be to simply make the rules easier to opt out of. Maybe a variable modifier that’s declared to ignore the borrow checker. Something very simple. None of that Refcell nonsense. Better yet, don’t allow the borrow checker to limit the number of write or readable references to an object. I get the thread safety bit, but I honestly don’t care. How about a modifier that adds those variable limits that programmers only use if they know the variable will be used on thread. Don’t get me started on the choice to use abbreviated keywords like pub and i32. They just want to make the language as cryptic as possible syntactically. I do like cargo though and the local crate system.
This isn't a JavaScript but a node issue. If you spawn a child process in node, and that node process logs so much that it crashes due to running out of memory, the callback in the parent process gets passed an exit code of - not a number - but the JS value `null`... which JSers will know is dangerously close to 0. So anyway Jest hurts sometimes.... Don't log a bunch of stuff in your unit tests.
this is actually a really great video, talking about stuff that most people will overlook instead of complaining about it's quirks that basically everyone already know
I was sure when I clicked that this is gonna be just another rant about implicit type conversion. Pleasantly surprised! I wasn’t aware of any of these issues lol
Here's my suggestion for JavaScript future. Implement TypeScript as a new JavaScript spec and let browsers implement it. I'm tired of having to do "builds" in a scripting language.
@@theodorealenas3171 main problem is, doing a simple web ui is waaay more complex nowadays. you don't need angular for a(ny thing) simple blog website. you don't need to build anything complex for a simple task. and nodejs makes you feel like you're in hell.
i'd suggest some sort of apk-like, but for web apps, where you bundle your typescript files, along with assets and whatnot, and the rest is right there, in a single package file.
@@hacktor_92 sorry I don't have the experience to understand, but APK is a package format apparently. So, you wish to send like a tarball with the dir tree to the browser? You don't like doing the same, but fragmented?
One could argue that forEach taking value first would make other functions easier to reuse for both Map/forEach and Array/forEach. Although, I personally never use forEach for either, since for loops allows for control flow and doesn't make it more unreadable.
Having the user name multiple implicit return variables is the root of the k v mixup. I'm surprised more people don't talk about this! Fundamentally, if programmers cannot easily see how data is being transformed, they will not be able to find and fix problems.
It's not even really a mixup. Array functions like forEach, map, and filter all have consistent parameter order and in a sensible order since often for those functions the user just wants to use the value and not the index. That you can destructure the array returned by an Object.entries into [key,value] is a language feature that came much later and has a very different context. I didn't see this one as an issue at all.
@@error.418 The implementation detail of it is logical enough, the problem comes when you use it. Logically you'd always expect key, then value, as in key-value pair. Suddenly having to deal with turning that idea around because of an implementation detail is not only problematic, it's incredibly limiting. It's not the worst here , but this aspect has bitten me numerous times when using JS libraries.
Principal Fullstack Lead developer here, 18 years of experience. I found your top things to hate about javascript really interesting and curious! Thanks for sharing! I think, in my personal opinion, that yes, this things can be really cumbersome, and it can lead to really messy situations where you face an additional layer of complexity. And of course, this things can leave you spending hours debugging your code for a piece of code that can be really difficult to find (Like the 'g' operator in the regex). However, the most I hate from Javascript it's a big portion of the community. Don't get me wrong. I've found many many many developers that create a really diverse and collaboratively community that ends up being helpful, thoughtful, and really really good educators about the perks and quirks of Javascript. However, particularly in Javascript and Python, I've also found the most toxic, irreverent and excruciating members I've faced. A few days ago, I found a video in a spanish-speaking channel focused on Javascript developers. The Video title was: "STOP using for cicles". That catched my attention and I went to watch the video. During the video, the presenter mentioned that instead of using "For" to iterate over a cycle, we should do it using a Array.map function, the reason: Legibility. However, during the video, the presenter also mentioned that the use of Array.map function allows you to "execute your code in a immutable way", which seemed kinda odd, because the very fact that you don't modify something during your code execution doesn't make it immutable. In the comments section, I saw one person mentioning how he disagreed with the video, because of multiple things. I added my support to this comment by also mentioning that the video was referring to Immutability when he wasn't actually doing immutability, as well as an improper use of the Array.map function. Not 5 minutes later, I got attacked by one of the people involved on the conversation saying that "Clearly I was just a junior developer that was scared of the Array.map function", and I just mentioned that even that you could achieve the same result using a for or an Array.map function, the Array.map function has much worse performance in terms of memory usage and time complexity. Long story short, I wrote a piece of code to demonstrate how using Array.map performed 28 times slower and could only manage arrays the 1/11 the size in comparison to use a for cicle, not to mention that the Array.map function semantical purpose is to map an object from one type to another, so using a map instead of a for would make the code "harder to read" because the semantics of the code itself. The next day, the youtube channel published a video that was titled: "Do not optimize your code" and pretty much what the video talked about is how nowadays, computers are so powerful that "small" optimizations are unnecessary, using the code I provided in the previous video. To finish up, I just decided to stop wasting my time with someone who's motto is: "Dont optimize your code". The person kept attacking me for around 3 days, trying to pull me into arguments. And although I've found amazing people that makes a great great great community around Javascript, these kinds of interactions are not rare.
There is this strange culture of putting people on pedestals and treating their opinions as facts or the only right way of doing things. If someone disagrees with it, they are treated as lesser skilled developers who simply 'don't get it'.
@@talhaakram Absolutely agree! Also, quite interesting is that as a response for being confronted, he decided to attack me as a person rather than discuss on the technology. This is something we shouldn't do at all when discussing about best methods
@Upcoming Weeb! So sorry to hear that. People are afraid of facing new things or not knowing about something. Honestly and personally, I'm glad when I found something I don't know so that I can study it, and I believe that being so aggressive against such scenarios is definitely a lost opportunity to grow. Sometimes, I think that languages get followers that treat said languages with religious fervour. And are willing to negate reality itself just to attach themselves to their point. This person I was talking about before insisted that the use of Map was better, despite the fact that it performed much, much worse, could handle much fewer data and at the cost of code semantics. His words: "This is the javascript way", reveals this religious fervour I'm talking about. For some reason, he thinks that Javascript existed in a separate realm, where code-optimizations, design patterns, algorithms and data structures don't apply to Javascript because "that's just how javascript works". And he's not willing to accept that he's wrong. That also shows a bit of immaturity in the developer as well. In my personal case, I really love and enjoy working with Java/Kotlin. However, I know that Java/Kotlin have their perks and that sometimes it is not the best fit for all. I'm willing to accept that it is "not the best language", but I do not think such a thing exists. Once again, I'm sorry that you had to pass through that trying to educate your colleagues about typescript. However, you are one clear example of how a community around Javascript can also be a really nice place. Let's keep it that way :D
callback to Map.prototype.forEach takes (value, key, map) to be in line with Array.prototype.forEach which passes (value, index, array) to its callback. Because indexes for arrays are same thing as keys for maps
for consistency the whole thing should just be for v,k if they want to go the route of “you iterate over values but can optionally get the index/key” unless there’s some design philosophy i’m missing, which is likely
thats actually programming 101... In simple for-loops you work with index and in foreach you work with values. (same thing in other languages too) ... and the second parameter is simply optional
I just started learning a bit of JavaScript a couple of days ago, so most of this video just flew over my head. But the important thing is that I watched it. :P
I feel like most regex issues are really, “people not admitting that their input is not actually regular” problems. Email addresses are the classic example of something that seems regular but is actually not. The only reliable way to test that an email address is valid is to send an email to it and see if it works.
I remember once making a procedural generation algorithm with a string sequence composed of a combinations of the characters ‘0123’. I wasn’t understanding why it was returning ‘ddeefinnu0123’. Turns out *undefined* was getting cast into a string and then sorted by characters in my algorithm. That had me stumped for a bit.
The single most annoying part imho is the lack of standards. There r 100x different ways of doing things one more ugly then the other. Crap gets added with every JS version but nothing gets deleted. It’s just like a teenagers room. Dirty, stinky and full of smartasses.
For HTML, use a dedicated parsing library, since HTML is not a regular language. If you’re trying to parse a regular language, there are libraries that allow you to write out a grammar and visit each node of the parse tree. This is a lot less brittle than trying to debug a manual regex parser when the spec changes. And then if you have a use case that’s not a regular grammar and/or you can’t use a library for, (I’m so sorry) reading char-by-char and parsing that way will often be faster and less error prone than a regex.
I've spent an extreme amount of time on build tooling. What do I hate about JavaScript? Modules! So many freaking options to package your code. No module, just use global scope! No module, just use an IIFE! AMD! CommonJS! RequireJS! Then combine shit, cause why not? UMD! Webpack! Babel! EcmaScript modules! That's right kids. EcmaScript modules has more than one standard. The standard module to replace all the other standards... has more than one standard implementation!
One time I used an object as a lookup table rather than using a Map. Turns out you can index it with the names of the members of the built-in `Object` and TypeScript won't save you. It was kind of a funny bug because it's one of those things where you can know the codebase inside and out and then you see the output being a stringified method of `Object` and if you never realized this fact before you'll think to yourself, "Where on earth could we possibly have any code that could produce such a result?" Luckily I realized pretty quickly what was going on, but I could imagine that someone could have taken many hours to figure that one out.
@@error.418 The issue was not the data that was stored inside the object. The issue was doing a lookup in the object with an arbitrary string, and expecting it to return one of the values in the object or undefined.
I don't necessarily hate this about JS / Web ecosystem, but I don't like it either; there are so many different tools that can combine to do the same / almost the same task. When I started, I was introduced to tools like ES Lint, TypeScript, Webpack, etc. A while back I had to deploy a no longer maintained project ("fbctf" for those that are curious) and I was introduced to a relic called Grunt. Now everyone is hyped about Deno, Bun, Vite, Snowpack. It's nice that the community is building on each other's work but I can't help but feel like everyone is reinventing the wheel. I can't imagine how new developers feel about this. The same can be said for Python's dependency management solution. I don't remember the XKCD strip that discusses this obsession with creating new tools that do pretty much the same thing.
The xkcd is something like this: There are 14 competing solutions, ha, we have to make a solution that works for everyone! Now there are 15 competing solutions.
Not unique to JS. C/C++ has how many compilers and tools for building C/C++ source code? The thing is that as languages evolved, so does the tools; As things become more standardized, tools tend to follow the good standards that makes it easier for developers to provide good UX. First DX was at the front, now it's the UX and the tools we have allows for better UX while also providing good DX (in terms of not having to configure everything from bottom up to provide good UX) by being more opinionated.
As someone who is currently sitting on an internal custom task runner script that's grown into an entire library with a plugin system, variable expansion, config file validation, dry run, caching, etc....? It's because it's so easy to get the 80% you care about done when you hit some case that doesn't work well with the existing tools, and it's so easy to add features after that. Bundling is a great example of this, where your internal crappy tool can get thrown together in an afternoon and be useful, and the existing tools are good at one thing but bad at others. Even then, there are only really two "real" bundlers out there right now: webpack and rollup, and the rest are all written on top of that (though the awesome swc project is working on one too, which should be amazing for my build times!)
to answer "why?" @3:43 - because the key value isn't used sometimes in forEach blocks and it makes the code tidier to ignore a var/arg in this way, but also it's available when/if you need it. Madness? Perhaps, but there is a method to it
From my perspective the forEach is reasonable, because for arrays etc. it also gives you value first, key second. Mabye the issue was introducing these functions in the first place, no idea why for shouldn't cut it.
2:55 actually, any kind of array of primitives will be shallow-copied, it's just that doing a deep-copy behaves exactly the same, because primitives aren't objects. Buffers are part of NodeJS. It seems the slice method does a pointer-copy (pass by reference) on Buffers. You should blame NodeJS, not ECMAScript
The strong point of JavaScript is it's Aquiles Heel, If you try to run JavaScript from 20 years ago, in a latest version of V8 it will still run, an run better then it did 20 years before. trying to keep the compatibility of everything that you've written makes it harder to create new features y fix everything that was mistake.
In addition to the things on your list and the things you deliberately left out in the pinned comment, I would say the thing I hate the most about writing Javascript is the lack of a standard library (insert leftpad joke). How many devs start every project by pulling in lodash and moment and... but the worst part about it to me is how it leads to tragicomically fragile transitive dependency graphs: you pull in some huge popular library and you look at their dependencies and half of them are throwaway utility functions and those haven't had an update in the last 5 years. Or the author of one of them gets butthurt over something and yanks it, breaking the internet in the process. You know, the little things. Oh, and PHP has the same inconsistent API issue: some of the "find this thing in a data structure" functions are needle, haystack and some of them are haystack, needle and no one can ever remember which is which. Of course, PHP pretty much sucks in general, so maybe not worth making fun of.
@@Winnetou17 not quite ten but it's definitely been at least 7 or 8 years since the last time I coded in it. So maybe it's better now? I've never actually met somebody actually willing to defend it as a language (plenty of people defend it as a technology choice while conceding its flaws).
@@jaredsmith5826 Well, getting more serious now, it actually improved a lot. Since PHP 7.0 (now we're at version 8.1), I'd say it's a decent language. Much more static typing, less bugs, less exotic behaviours and hidden errors because 0.1% might want that feature, and general modern features. It has pretty regular releases, though it also followed the extremely annoying and stupid trend of only supporting a version for a couple of years, but other than that, it's going well. There's still some of that haystack, needle and needle, haystack nonsense, because backwards compatibility (ugly or not, there's millions of websites written in PHP, so backwards compatibility is very important). I like it as a language because you can easily grow with it. You can start by simply having a really simple program with several functions and ifs and fors, fully procedural. And you can expand easily and at your own pace towards fully featured OOP style, with namespaces, interfaces and traits, with autoloading. You get the idea.
I actually really like regexps, but never use the g flag. I also tend to write regexps that are anchored and don't have multiple ways that they can match. I kind of wish that raku style regexps and friends were available in more languages. The using signed 32bit for bit-ops is super gross.
I completely agree that JavaScript was designed for web UI dev and It should be used that way. Most UI developers don't need bit manipulations anyway. Just because you can develop low level networking stuffs with js, doesn't mean you should do. I think developers nowadays are too lazy to learn another language and keep pushing javascript everywhere. Some people think C/C++ is for old people and JS is cool :D
No custom equality for maps. If your key is an object you can't use a field to check if its already there. This has caused me to either avoid maps or use maps in very weird ways.
Hmm .. if you show that FOR and FOR_EACH next each other it looks strange but it's kinda consistent from other standpoint -> FOR just iterate on key:value pairs while those functional methods like .map .filter .forEach .. they use index just as optional second argument(or key in this case) but they always use value as first 'thing'/argument/whatever -> and they work somewhat like this in many languages I think .. so it does make sense :D Thx for the video
Totally agree with everything you say, but enough with JavaScript we are waiting for the Elixir video, we need to know your thoughts on Elixir against Go, Rust and JavaScript.
@@ThePrimeagen which type? Although parsers require more code and are slower for short convoluted patterns. Don't you think? On the other hand, parsers are more easily read by humans. Wouldn't regex be "blazingly fast" compared to parsers ? Don't get me wrong, I love me some PEGs
well, if it's infinity then it might as well be now. are you trying to suggest that you UNDERSTAND infinity? of course you're not. and neither is jevascrapt.
@@jazzochannel hmmm... I have a physics and math degree that have given me enough of an understanding to know that something that happens an infinitely long time from now will not happen immediately.
You covered a lot of stuff that I don’t think is covered in Bootcamp and tutorials. Seems you tell things like they are. I’d be really interested on your take on self-taught developers. Not just no CS degree. Self taught with no degree period. How well do they do?
The fact that every function is a closure (I realize this is a fundamental feature of JavaScript and one of the reasons people love it). This is less of a footgun and more of a death by one thousand cuts situation. The fact that you can't trust any single javascript function signature to let you know what data a function interacts with makes it that much harder to reason about your code, and I think this slows down refactoring especially (or at least I notice it slowing me down). If you've ever read the body of a javascript function and thought "Where the fuck is that variable coming from" you've experienced this.
Having studied that topic recently after seeing this feature a lot in conjuction with callbacks, i agree. It's so strange to me to have data "leaking" downstream to functions on the same scope. The fact that it's so useful and heavily used makes me wonder if it's bad or not (i'm a beginner, so idk)
@@shimadabr lack of predictable behaviour makes it harder to write code with less bugs. if someone's aware of the behaviour and using it, i feel like there's easier ways to write clearer code?
2:42 OMG that's why my old surrended project isn't working ! I have passed so much time trying to understand why i can't copy correctly Uint8Array ! Guess i will give it a second chance now that i know this ! Thanks so much ! subscribing was worth it ! (It's actually so random to debug month later like this XD)
I always hear people say we shouldn't use regex but never provide alternatives. So could anyone please help me here? I'm not aware of any other way to validate input
I built the account creation page for our site, and I used a regex to validate emails. To be fair it's very loose validation to make sure you have some stuff, followed by an @, with some more stuff containing a dot at the end. And I know there's a bunch of bullshit RFC edge cases and I'm sure it doesn't work on at least a few of them but I don't give a shit because nobody uses email addresses like that anyway, and if they do then they should know they aren't welcome.
Storing functions as consts will always rub me the wrong way, but I've become used to it. Also, the fact that a function may or may not receive an argument is just weird -it always frustrates me when I realize something I needed in my code was given to me all along via an angument I neglected until now 😑
As in, when you're implementing a callback? That's one of the less talked about benefits of Typescript, the editor will tell you what arguments you can add. This one doesn't even need you to be writing Typescript, just have typings installed!
all the key, value vs value,key vs wtf are the arguments make js hard to write without help of an ide, however ide suggestions mitigate this this is a bit worse emotioinally, cuz you realize you wasted time for worse reinvention of a wheel, tedious and rather dumb
Great. Another green “Wah. I hate JavaScript because I don’t understand it”. Unfortunately, this video may deceive people into believing it has a semblance of credibility. It doesn’t
Alright, awesome, I agree that regexes are kinda hard to verify and I'll use them only for quick shell scripts and for find and replace........ What now tho? You can't just say avoid something that's used so widely (ofc, I understand this is just a short video), should I write a grammar and a parser for it instead? Tbh, now I think about it that would be kinda cool. But tell me, what's your idea of a replacement?
honestly, plenty of easy things. take this for example. you want to validate its a vim cmd. well.. you probably reach for a regex. Hold on devil. let index = cmd.chars().position(|c| !c.is_ascii_digit()).unwrap(); let (num, cmd) = cmd.split_at(index); let num_res = str::parse::(num); Rust code. Its easy, its easier to understand than a regex, and its performance is well understood.
The fact that the condition undefined > 0 simply evaluates to false and doesn't cause any sort of error has caused me endless pain debugging at work. When there's a function which isn't working probably, returning undefined instead of a number, which then gets compared to 0 and there's no way of knowing.
1 In those days came John the Baptist, preaching in the wilderness of Judaea, 2 And saying, Repent ye: for the kingdom of heaven is at hand. 3 For this is he that was spoken of by the prophet Esaias, saying, The voice of one crying in the wilderness, Prepare ye the way of the Lord, make his paths straight. 4 And the same John had his raiment of camel's hair, and a leathern girdle about his loins; and his meat was locusts and wild honey. 5 Then went out to him Jerusalem, and all Judaea, and all the region round about Jordan, 6 And were baptized of him in Jordan, confessing their sins. 7 But when he saw many of the Pharisees and Sadducees come to his baptism, he said unto them, O generation of vipers, who hath warned you to flee from the wrath to come? 8 Bring forth therefore fruits meet for repentance: 9 And think not to say within yourselves, We have Abraham to our father: for I say unto you, that God is able of these stones to raise up children unto Abraham. 10 And now also the axe is laid unto the root of the trees: therefore every tree which bringeth not forth good fruit is hewn down, and cast into the fire. 11 I indeed baptize you with water unto repentance: but he that cometh after me is mightier than I, whose shoes I am not worthy to bear: he shall baptize you with the Holy Ghost, and with fire: 12 Whose fan is in his hand, and he will throughly purge his floor, and gather his wheat into the garner; but he will burn up the chaff with unquenchable fire. 13 Then cometh Jesus from Galilee to Jordan unto John, to be baptized of him. 14 But John forbad him, saying, I have need to be baptized of thee, and comest thou to me? 15 And Jesus answering said unto him, Suffer it to be so now: for thus it becometh us to fulfil all righteousness. Then he suffered him. 16 And Jesus, when he was baptized, went up straightway out of the water: and, lo, the heavens were opened unto him, and he saw the Spirit of God descending like a dove, and lighting upon him: 17 And lo a voice from heaven, saying, This is my beloved Son, in whom I am well pleased. (Mt.3:1-17)
I didn't include this, bind, type coercion, let dead zones, or any typical "i hate js." I also didn't include Dates because I am convinced that when it was conceived it was considered the best way to handle dates (have you seen other languages in the mid 90s? It was a literal copy of another library at tha time)
But the items I included are truly awful items that are not found in other languages (that i know of)
This list is a unique one. Not just using the same broken CD.
Hello Mr @ThePrimeagent, Big Fan of your twitch stream.
What is the green that you're using ? Or it is your wall painted in that color.
I think the forEach case is acceptable because sometimes you just want to iterate over the value in some iterable type. So having it value, key allows for key to be ignored entirely giving (val) => {};
Doing it the other way is more complicated to solve for.
I just read up on `let dead zones` what a peculiar thing, I've never stumbled upon it, and I'm still confused on how someone might reach that edgecase
Thank you for not using the same lame examples people often use!
as Fireship once said: 'JS is a language used exclusively to build things it's not supposed to'
48 likes and 0 comments? lemme fix it.
...btw fireship rules
Right from the very beginning.
5:36 This leads to one of my hot takes. Javascript is just the BASIC of the 2010-2020s. It's an approachable entry point for new programmers and people want to use it for everything, but that leads to it being used for things it has no business being used for. And everyone and their grandmother has their own library/way of doing things/dialect for any given task, which stretches the language beyond its comfortable limits
Exactly
But isn't that the BEAUTY of it? It can be bent forwards, backwards and upside down and it still works amazingly! Sure there are caveats but which language doesn't?
@@aryandeora6631 I mean, it’s convenient, but I don’t think it’s ideal. Different tools/languages are appropriate for different tasks and trying to fit every task to JavaScript just feels like trying to turn a wrench into a hammer-sure, you can probably get to the same place eventually, but you’d have a way easier and better time if you just stopped and grabbed a hammer. Like, I wouldn’t use JS for systems programming, just as I wouldn’t use C for web ui programming and I wouldn’t develop an operating system APL.
@@leetaeryeo5269 fair critique I take your point
@@aryandeora6631 and I 100% see your standpoint as well. I’m a bit of a hypocrite because I work in C# which has libraries and frameworks for pretty much everything under the sun.
With css at the stage it’s at and faster backend languages, JavaScript should be limited to web carousels and scroll loading.
love this idea
@@ThePrimeagen To be fair, that was the intended use case ... THE ONLY INTENDED USE CASE I might add ... ;)
So how would you manage components and application state inside a browser app without JS? Go back to template engines? PHP? Lol
@@inakiarias7465 you laugh but there’s a reason the largest of web apps still use them.
@@keatonhatch6213 Yea, the reason being their code foundation is already built on that...
When interfacing JS or TS people from my C++ code what I hate most is that they silently send you json with all kinds of shit in it - that is invisible to them because of JS-sloppyness...
Like when they randomly send "empty string" instaed of null, undefined as string and such horrible pieces of shit. My code is having tens of special cases for parsing their fucked up shit :D
Clearly, [] is the same as 0. IDK how you'ren't seeing it.
If you're drunk they even look the same.
Loose comparison do be like that in dynamic languages
you are perfectly correct, drunkeness is the real reason [] = 0
Silly footgun (and one that does somewhat fall into your type coercion moratorium), but checking whether a variable is undefined vs truthy or falsy as a practice (e.g. foo && ... ) has just caused no end of headaches for my applications in the past. Probably more of a best practices thing and goes back to the community being the problem, but it's still unbelievably aggravating.
yeah, i really hate that one.
I ve written a lil package for it. Rn it's pretty dumb, it just checks if the falsey is not 0 or "", cause those are the situations that i came across that really tripped me up.
This is a React concern. As a policy, always check item?.length > 0 and use a ternary
@@kevinbatdorf yea, ?. I a nice one, but im workin on aws lambda and we have node12 here ... So damn tired of this && checks
Could you give an example of a situation that trips people up? And were you using TypeScript at all?
This got me once:
function average(averages: number[]) {
return averages.reduce((sum, n) => sum + n) / average.length
}
we divide by average.length, not averages.length, and average.length is for some reason the number of arguments the function takes.
This is cursed
the reason being every object in jevascrapt has a prototype. learn to
Lemme add number 6, this keyword with functions
When I started to learn I used a normal anonymous function instead of arrow function within a class, i never suffered like that hour all I needed was the arrow function
Number 7 threading: the reason why I switched to another lang whenever I needed threading it's pain =(
hah. I didn't want to talk about this. everyone knows about this being a bit confusing. And threading! Its the reason why people _like_ javascript unironically.
Use promise brooo
@@ThePrimeagen I liked at first too I was like woaaa it's cool but it's absolutely painful xd
@@anisoseryx No it's not. Promises is a really great API and I see a lot of languages having a similar approach to async programming.
@@parlor3115 the prove isn't with promises I use them all the time dw, it's for certain cases where threading becomes painful like when I made a discord api wrapper I needed some variables to be shared and it was a real pain to get it done since my variables were constantly changing and needed to be updated across all threads, you can see how complex this problem can be by checking djs code they do that too. Long story short threads are nice but Javascript isn't made for this and I prefer to use another language like csharp to tackle it
JavaScript: "is slow"
Python:
we don't talk about sneks
The best place to use regex is for things that you know for a fact that has a very rigid and predictable pattern. Like repetitive codes and languages.
Or just a quick tool for extracting data from large amount of text that you need very often.
What regex is really not good at is filtering things that are potentially bad for your purposes.
02:58 you can use
Uint8Array.prototype.slice.call(buffer,start,end)
to always deep copy
deep
I liked it when JS' forEach used value, key. Because in most cases we needed the value instead the key. It would be silly to write .foreach((undefined, value) => ...)when we just needed the value.
i've just been bitten by the bitwise operation thing 🤣
its so frustrating
everytime i watch his vids, my 'imposter syndrom' shows up :D
i've got a juicy fact that i just learnt about 5 minutes ago: associative arrays are NOT part of javascript. which leads to some hilarious results below.
* if you access an array index using a numerical string, it coerces the string into an int. i.e. *a["420"] === a[420]*
* _however,_ if it's not a numerical string it treats it as a property of the object. i.e. *a["07"] !== a["7"]*
* all indices where you assigned a value (even if that value is `undefined`) WILL return true if you call hasOwnProperty. i.e. *[6,9,4,2,0].hasOwnProperty("4") === true* and even *[6,9,4,2,undefined,0].hasOwnProperty("4") === true*
* if you skip an index, it'll fill the indices in between with empty slots (which is somehow different from assigning `undefined` values) so if you call hasOwnProperty on the in-between indices they'll return false (!!). i.e., if you initialise an array *a = [6, 9, 4, 2]; a[5] = 0;* then *a.hasOwnProperty("4") === false* HOWEVER *[6,9,4,2,undefined,0].every((v, i) => v === a[i]) === true* . wtf??
js isn't just too smart by half, it's too smart by half recursively. it's just unbridled genius all the way down.
honestly, i thought php was the worst language, but after reading the js docs, it's feeling like a strong contender....
Just subbed to get you to 100K!!!! also my first comment ever
It not just shoots in your food. It blasts your whole leg away.
Is it possible to create the C language from Javascript to make Javascript faster?
The module system, especially if you are working with typescript and node. It's a mess, some libraries use common js others ES modules...
Shout out Hummus
hummus?
A superior Mediterranean dip sir
@@ThePrimeagen yes hummus it is indeed a very calming relaxing evening snack dip🤌
Email regex validation is very easy when you learn that the TLD isn't required for emails and symbols like +, - are valid. Knowing the spec halves the regex expression :^)
I really wonder what people are even checking for when they are doing email validation. If it's just whether someone didn't understand that it was an email field, just check if it contains an @. Otherwise you're not going to be able to check if it actually exists or whatever!
@@SimonBuchanNz definitely
I don't like using toString or parseInt, it's just to long.
Instead I much prefer typing 123 + [] (toString) or "123" - 0 (parseInt)
Omg I hate javascript with a vengeance, can't believe it runs 90% of all of a space travelling species software
I’m surprised that Netflix isn’t using erlang or elixir given how good they are for multi connection services. Imagine having to rewrite the whole backend with rust…but I guess you can use wasm so it could all be rust.
i would love to write a backend in rust
@@ThePrimeagen Any reasons why higher-ups don't use Rust?
Elixir is life bro.
@@MarcosVMSoares I heard that WhatsApp uses erlang and how they were able to scale because of its concurrency and ability to run on low end tech.
@@oskrm not as tried and teated as other languages, harder to find devs for, has a reputation for being associated with blockchain
hopefully time will fix these issues
Shallow copying is pure evil. Period. Give us the fast deep clone alternative! No! We have to suffer!
well.. fast and deep aree... well they are sort of opposed to each other.
@@ThePrimeagen If it is written in C and is in the standard function then it will be faster than any custom implementation in JavaScript
@@vitiok78 firstly, that's actually the sort of thing that runtimes are good at making as fast as C, secondly C is slow as deep copies too. Because a deep copy is by definition a lot of work.
You could ask for immutable data structures though...
Door number three: copy-on-write???
Here is another one, you would expect somearray.every(condition) to return true if the condition is true, which works fine untill the array is empty, then it return false, which is very misleading,
Same for somearray,some
not that it necessarily excuses the second issue, but have you heard of the "structuredClone" method?
yayaya
1. The language itself
2. The people who use it
hey! be nice now. this is a safe spaece
“Any application that can be written in JavaScript will, eventually, be written in JavaScript.”
- Jeff Atwood, founder of Stack Overflow, in 2007
Only 5? You must've limited yourself pretty harshly :D
have to draw the line somewhere ;)
Just spreading the content, don't want people to be overwhelmed
( ); much better @@ThePrimeagen
"The lords language Rust" made me laugh and started wondering... Are we all created in Rust? Are we all at heart Rustaceans? Are we all... Blazingly fast?
Light is a wave and a particle, Rust doesn’t allow this nonsense. If God had used Rust, quantum physics would make sense
If we are then I must be running in debug mode or something then :(
I for sure am
we’re all unsafe code and use garbage collection.
somehow at the same time.
@@raffimolero64 speak for yourself
My "favorite" bit about JS is the fact that you can still manage to create memory leaks in a GCed language, and because of the nature of the language, you're not meant to be actively thinking about that sort of thing, so you don't notice it til your program is whoring an abnormal amount of memory.
Oh yeah and good luck finding it. Especially if it's an installed dependency and not your own code.
Ouch. Is that common? I'm not familiar with web dev but it sounds strangely stupid
For simple applications, no. If you ever start trying to do something clever "just because the compiler/interpreter allows it", that likelihood definitely shoots up, though. Likewise when dealing with lower level data structures and such.
"whoring an abnormal amount of memory" lmao. I like your phrasing
I imagine it tends to happen when you have a huge stack of async functions all holding "temporary" named variables full of references to other large structures.
The regex one has actually screwed me over during my live exams, Luckily I was able to write a shitty function to replace what it was doing, but after the exam when I looked at why it was doing it what it was doing I had the same question, WHY?
too clever by half of course
Why were you using a global flag in a test function, though? If you're just doing a boolean test, I can't think of a good example where you actually want the global flag. Without the global flag, this isn't an issue. If you are reaching for the global flag, you're probably intending to use a different regex function, not test.
Sort() defaulting to sorting lexiographically, despite dealing with numbers.
I enjoy working in JS from time to time, 0 indexed months get me every time. Every single time.
sure, but that's not js-specific. it seems to have been copied from another language with java in the name...
@@user-lb1ib8rz4h Correct. Also we have a new system coming soon, the TC-39 Temporal proposal which is now in Stage 3.
@@user-lb1ib8rz4h That's true, but it's been a literal decade since dates have been a problem in Java, if not more. In JS, it's still the same.
Rust sucks because it makes it unbelievably annoying to do things that should be basic. Things like making a temporary variable to a pointer which could be hidden behind many array indices. Rust has the philosophy where it forces you into doing things that are inconvenient and makes it hard to opt out. My vision for a language like rust that pleases c developers would be to simply make the rules easier to opt out of. Maybe a variable modifier that’s declared to ignore the borrow checker. Something very simple. None of that Refcell nonsense. Better yet, don’t allow the borrow checker to limit the number of write or readable references to an object. I get the thread safety bit, but I honestly don’t care. How about a modifier that adds those variable limits that programmers only use if they know the variable will be used on thread. Don’t get me started on the choice to use abbreviated keywords like pub and i32. They just want to make the language as cryptic as possible syntactically. I do like cargo though and the local crate system.
This isn't a JavaScript but a node issue. If you spawn a child process in node, and that node process logs so much that it crashes due to running out of memory, the callback in the parent process gets passed an exit code of - not a number - but the JS value `null`... which JSers will know is dangerously close to 0.
So anyway Jest hurts sometimes.... Don't log a bunch of stuff in your unit tests.
I encountered this problem recently. Jest crashed due to some API call I was making that was spamming warning logs.
Math.max();
// -Infinity
Math.min();
// Infinity
... that cannot be real
@@ThePrimeagen i actually had to test it, he is right, oh hell nauugh
My goodness!
OMG it’s true! 🤣
Holy Fk, It is true, Thanks god I am not working with JavaScript.
6. Starts with JAVA
Even java knows about OR numbers
proof its bad
this is actually a really great video, talking about stuff that most people will overlook instead of complaining about it's quirks that basically everyone already know
I was sure when I clicked that this is gonna be just another rant about implicit type conversion. Pleasantly surprised! I wasn’t aware of any of these issues lol
Yeah! I tried to be original
Modern life as we know it is standing on the thin legs of JS, I'm scared.
hahaha
Here's my suggestion for JavaScript future. Implement TypeScript as a new JavaScript spec and let browsers implement it. I'm tired of having to do "builds" in a scripting language.
i effing hate the eco system.
But you also want browsers to pack files for you? And minify? I don't see why or how the browser could build for you.
@@theodorealenas3171 main problem is, doing a simple web ui is waaay more complex nowadays. you don't need angular for a(ny thing) simple blog website. you don't need to build anything complex for a simple task. and nodejs makes you feel like you're in hell.
i'd suggest some sort of apk-like, but for web apps, where you bundle your typescript files, along with assets and whatnot, and the rest is right there, in a single package file.
@@hacktor_92 sorry I don't have the experience to understand, but APK is a package format apparently. So, you wish to send like a tarball with the dir tree to the browser? You don't like doing the same, but fragmented?
Atwood’s Law: “Any application that can be written in JavaScript, will eventually be written in JavaScript.”
Imagine coming to a JavaScript-labeled video and seeing TypeScript.
I too was thrown.
Yeah my rule for javascript is contain it on the front end. Don't let it get into cicd to much or you end up with a really flaky build system.
yep
One could argue that forEach taking value first would make other functions easier to reuse for both Map/forEach and Array/forEach. Although, I personally never use forEach for either, since for loops allows for control flow and doesn't make it more unreadable.
it also matches the usage of Array.forEach( (value, index) => { })
Having the user name multiple implicit return variables is the root of the k v mixup. I'm surprised more people don't talk about this! Fundamentally, if programmers cannot easily see how data is being transformed, they will not be able to find and fix problems.
It's not even really a mixup. Array functions like forEach, map, and filter all have consistent parameter order and in a sensible order since often for those functions the user just wants to use the value and not the index. That you can destructure the array returned by an Object.entries into [key,value] is a language feature that came much later and has a very different context. I didn't see this one as an issue at all.
@@error.418 The implementation detail of it is logical enough, the problem comes when you use it. Logically you'd always expect key, then value, as in key-value pair. Suddenly having to deal with turning that idea around because of an implementation detail is not only problematic, it's incredibly limiting. It's not the worst here , but this aspect has bitten me numerous times when using JS libraries.
Principal Fullstack Lead developer here, 18 years of experience. I found your top things to hate about javascript really interesting and curious! Thanks for sharing!
I think, in my personal opinion, that yes, this things can be really cumbersome, and it can lead to really messy situations where you face an additional layer of complexity. And of course, this things can leave you spending hours debugging your code for a piece of code that can be really difficult to find (Like the 'g' operator in the regex). However, the most I hate from Javascript it's a big portion of the community.
Don't get me wrong. I've found many many many developers that create a really diverse and collaboratively community that ends up being helpful, thoughtful, and really really good educators about the perks and quirks of Javascript. However, particularly in Javascript and Python, I've also found the most toxic, irreverent and excruciating members I've faced.
A few days ago, I found a video in a spanish-speaking channel focused on Javascript developers. The Video title was: "STOP using for cicles". That catched my attention and I went to watch the video.
During the video, the presenter mentioned that instead of using "For" to iterate over a cycle, we should do it using a Array.map function, the reason: Legibility.
However, during the video, the presenter also mentioned that the use of Array.map function allows you to "execute your code in a immutable way", which seemed kinda odd, because the very fact that you don't modify something during your code execution doesn't make it immutable.
In the comments section, I saw one person mentioning how he disagreed with the video, because of multiple things. I added my support to this comment by also mentioning that the video was referring to Immutability when he wasn't actually doing immutability, as well as an improper use of the Array.map function.
Not 5 minutes later, I got attacked by one of the people involved on the conversation saying that "Clearly I was just a junior developer that was scared of the Array.map function", and I just mentioned that even that you could achieve the same result using a for or an Array.map function, the Array.map function has much worse performance in terms of memory usage and time complexity. Long story short, I wrote a piece of code to demonstrate how using Array.map performed 28 times slower and could only manage arrays the 1/11 the size in comparison to use a for cicle, not to mention that the Array.map function semantical purpose is to map an object from one type to another, so using a map instead of a for would make the code "harder to read" because the semantics of the code itself.
The next day, the youtube channel published a video that was titled: "Do not optimize your code" and pretty much what the video talked about is how nowadays, computers are so powerful that "small" optimizations are unnecessary, using the code I provided in the previous video.
To finish up, I just decided to stop wasting my time with someone who's motto is: "Dont optimize your code". The person kept attacking me for around 3 days, trying to pull me into arguments.
And although I've found amazing people that makes a great great great community around Javascript, these kinds of interactions are not rare.
There is this strange culture of putting people on pedestals and treating their opinions as facts or the only right way of doing things. If someone disagrees with it, they are treated as lesser skilled developers who simply 'don't get it'.
@@talhaakram Absolutely agree! Also, quite interesting is that as a response for being confronted, he decided to attack me as a person rather than discuss on the technology. This is something we shouldn't do at all when discussing about best methods
I actually faced similar experience when I tried explaining to some of my colleagues why typescript is better than JavaScript.
@Upcoming Weeb! So sorry to hear that. People are afraid of facing new things or not knowing about something. Honestly and personally, I'm glad when I found something I don't know so that I can study it, and I believe that being so aggressive against such scenarios is definitely a lost opportunity to grow.
Sometimes, I think that languages get followers that treat said languages with religious fervour. And are willing to negate reality itself just to attach themselves to their point.
This person I was talking about before insisted that the use of Map was better, despite the fact that it performed much, much worse, could handle much fewer data and at the cost of code semantics. His words: "This is the javascript way", reveals this religious fervour I'm talking about.
For some reason, he thinks that Javascript existed in a separate realm, where code-optimizations, design patterns, algorithms and data structures don't apply to Javascript because "that's just how javascript works". And he's not willing to accept that he's wrong.
That also shows a bit of immaturity in the developer as well. In my personal case, I really love and enjoy working with Java/Kotlin. However, I know that Java/Kotlin have their perks and that sometimes it is not the best fit for all. I'm willing to accept that it is "not the best language", but I do not think such a thing exists.
Once again, I'm sorry that you had to pass through that trying to educate your colleagues about typescript. However, you are one clear example of how a community around Javascript can also be a really nice place. Let's keep it that way :D
@@arsereg 💯 agreed.
callback to Map.prototype.forEach takes (value, key, map) to be in line with Array.prototype.forEach which passes (value, index, array) to its callback. Because indexes for arrays are same thing as keys for maps
Was about to comment the same thing. It would have been much worse had they changed the definition of the forEach callback for a single type.
for consistency the whole thing should just be for v,k if they want to go the route of “you iterate over values but can optionally get the index/key”
unless there’s some design philosophy i’m missing, which is likely
thats actually programming 101... In simple for-loops you work with index and in foreach you work with values. (same thing in other languages too)
... and the second parameter is simply optional
I just started learning a bit of JavaScript a couple of days ago, so most of this video just flew over my head. But the important thing is that I watched it. :P
agreed. its like a boomerang, it flew over, but its coming back.
@@ThePrimeagen Deep. And when it comes back it hits you in the back of the head
JavaScript isn’t my favorite but I keep a toaster in my bathroom with a php sticker on it just in case.
this seems to be the most reasonable
I feel like most regex issues are really, “people not admitting that their input is not actually regular” problems. Email addresses are the classic example of something that seems regular but is actually not. The only reliable way to test that an email address is valid is to send an email to it and see if it works.
I remember once making a procedural generation algorithm with a string sequence composed of a combinations of the characters ‘0123’. I wasn’t understanding why it was returning ‘ddeefinnu0123’. Turns out *undefined* was getting cast into a string and then sorted by characters in my algorithm. That had me stumped for a bit.
1. Regex
2. Buffer/Uint8Array slice
3. Map forEach
4. Bitwise casting to 32 bit signed
5. Community
The single most annoying part imho is the lack of standards. There r 100x different ways of doing things one more ugly then the other. Crap gets added with every JS version but nothing gets deleted. It’s just like a teenagers room. Dirty, stinky and full of smartasses.
objects in js are nightmarish i don't know why anyone would write production grad code using such an unsafe structure
You said not to use regex , but what is the other alternative to that?
For HTML, use a dedicated parsing library, since HTML is not a regular language. If you’re trying to parse a regular language, there are libraries that allow you to write out a grammar and visit each node of the parse tree. This is a lot less brittle than trying to debug a manual regex parser when the spec changes. And then if you have a use case that’s not a regular grammar and/or you can’t use a library for, (I’m so sorry) reading char-by-char and parsing that way will often be faster and less error prone than a regex.
I've spent an extreme amount of time on build tooling. What do I hate about JavaScript?
Modules!
So many freaking options to package your code. No module, just use global scope! No module, just use an IIFE! AMD! CommonJS! RequireJS! Then combine shit, cause why not? UMD! Webpack! Babel! EcmaScript modules!
That's right kids. EcmaScript modules has more than one standard. The standard module to replace all the other standards... has more than one standard implementation!
Agree. So confusing. I am now using Webpack 5 to package my code, but it took me a week to set it up and make it work.
One time I used an object as a lookup table rather than using a Map. Turns out you can index it with the names of the members of the built-in `Object` and TypeScript won't save you. It was kind of a funny bug because it's one of those things where you can know the codebase inside and out and then you see the output being a stringified method of `Object` and if you never realized this fact before you'll think to yourself, "Where on earth could we possibly have any code that could produce such a result?" Luckily I realized pretty quickly what was going on, but I could imagine that someone could have taken many hours to figure that one out.
yikes
For example you used "entries" as a key?
@@error.418 The issue was not the data that was stored inside the object. The issue was doing a lookup in the object with an arbitrary string, and expecting it to return one of the values in the object or undefined.
@@niles_5003 Yeah, unless you set the object `as const` or use the `` prefix then it doesn't try to protect you, gotcha.
I don't necessarily hate this about JS / Web ecosystem, but I don't like it either; there are so many different tools that can combine to do the same / almost the same task.
When I started, I was introduced to tools like ES Lint, TypeScript, Webpack, etc.
A while back I had to deploy a no longer maintained project ("fbctf" for those that are curious) and I was introduced to a relic called Grunt.
Now everyone is hyped about Deno, Bun, Vite, Snowpack.
It's nice that the community is building on each other's work but I can't help but feel like everyone is reinventing the wheel.
I can't imagine how new developers feel about this.
The same can be said for Python's dependency management solution.
I don't remember the XKCD strip that discusses this obsession with creating new tools that do pretty much the same thing.
nim/go/zig/phix-lang/vlang bro , problems solved... use the better languages
The xkcd is something like this:
There are 14 competing solutions, ha, we have to make a solution that works for everyone! Now there are 15 competing solutions.
Not unique to JS. C/C++ has how many compilers and tools for building C/C++ source code?
The thing is that as languages evolved, so does the tools; As things become more standardized, tools tend to follow the good standards that makes it easier for developers to provide good UX.
First DX was at the front, now it's the UX and the tools we have allows for better UX while also providing good DX (in terms of not having to configure everything from bottom up to provide good UX) by being more opinionated.
As someone who is currently sitting on an internal custom task runner script that's grown into an entire library with a plugin system, variable expansion, config file validation, dry run, caching, etc....?
It's because it's so easy to get the 80% you care about done when you hit some case that doesn't work well with the existing tools, and it's so easy to add features after that.
Bundling is a great example of this, where your internal crappy tool can get thrown together in an afternoon and be useful, and the existing tools are good at one thing but bad at others.
Even then, there are only really two "real" bundlers out there right now: webpack and rollup, and the rest are all written on top of that (though the awesome swc project is working on one too, which should be amazing for my build times!)
to answer "why?" @3:43 - because the key value isn't used sometimes in forEach blocks and it makes the code tidier to ignore a var/arg in this way, but also it's available when/if you need it. Madness? Perhaps, but there is a method to it
That’s what we get for not enforcing function arity
So, we are all trusting the JavaScript based on 'Maybe we need it, but maybe we don't'?
From my perspective the forEach is reasonable, because for arrays etc. it also gives you value first, key second. Mabye the issue was introducing these functions in the first place, no idea why for shouldn't cut it.
thank you
2:55 actually, any kind of array of primitives will be shallow-copied, it's just that doing a deep-copy behaves exactly the same, because primitives aren't objects.
Buffers are part of NodeJS. It seems the slice method does a pointer-copy (pass by reference) on Buffers. You should blame NodeJS, not ECMAScript
JS was created in 10 days, I do not joke.
The strong point of JavaScript is it's Aquiles Heel, If you try to run JavaScript from 20 years ago, in a latest version of V8 it will still run, an run better then it did 20 years before. trying to keep the compatibility of everything that you've written makes it harder to create new features y fix everything that was mistake.
[1, 2, 10].sort() => [ 1, 10, 2 ]
Because sort coerces everything in the array into strings in the sort method. HF debugging
In addition to the things on your list and the things you deliberately left out in the pinned comment, I would say the thing I hate the most about writing Javascript is the lack of a standard library (insert leftpad joke). How many devs start every project by pulling in lodash and moment and... but the worst part about it to me is how it leads to tragicomically fragile transitive dependency graphs: you pull in some huge popular library and you look at their dependencies and half of them are throwaway utility functions and those haven't had an update in the last 5 years. Or the author of one of them gets butthurt over something and yanks it, breaking the internet in the process. You know, the little things. Oh, and PHP has the same inconsistent API issue: some of the "find this thing in a data structure" functions are needle, haystack and some of them are haystack, needle and no one can ever remember which is which. Of course, PHP pretty much sucks in general, so maybe not worth making fun of.
ok, this is a good call. the lack of std is mind boggling
PHP pretty much sucks in general ? *massively triggered* Have you even checked it in the last 10 years ? I'll fight you to death on this bro!
@@Winnetou17 not quite ten but it's definitely been at least 7 or 8 years since the last time I coded in it. So maybe it's better now? I've never actually met somebody actually willing to defend it as a language (plenty of people defend it as a technology choice while conceding its flaws).
@@jaredsmith5826 Well, getting more serious now, it actually improved a lot. Since PHP 7.0 (now we're at version 8.1), I'd say it's a decent language. Much more static typing, less bugs, less exotic behaviours and hidden errors because 0.1% might want that feature, and general modern features.
It has pretty regular releases, though it also followed the extremely annoying and stupid trend of only supporting a version for a couple of years, but other than that, it's going well.
There's still some of that haystack, needle and needle, haystack nonsense, because backwards compatibility (ugly or not, there's millions of websites written in PHP, so backwards compatibility is very important).
I like it as a language because you can easily grow with it. You can start by simply having a really simple program with several functions and ifs and fors, fully procedural. And you can expand easily and at your own pace towards fully featured OOP style, with namespaces, interfaces and traits, with autoloading. You get the idea.
"The lords language Rust" propaganda and blasfemy! the lords language is holy C 🙏
And the truest operating system is Temple OS
I actually really like regexps, but never use the g flag. I also tend to write regexps that are anchored and don't have multiple ways that they can match. I kind of wish that raku style regexps and friends were available in more languages.
The using signed 32bit for bit-ops is super gross.
I completely agree that JavaScript was designed for web UI dev and It should be used that way. Most UI developers don't need bit manipulations anyway. Just because you can develop low level networking stuffs with js, doesn't mean you should do. I think developers nowadays are too lazy to learn another language and keep pushing javascript everywhere. Some people think C/C++ is for old people and JS is cool :D
I really hope you're not writing backend with C/C++ when we have much better languages for that domain...
No custom equality for maps. If your key is an object you can't use a field to check if its already there. This has caused me to either avoid maps or use maps in very weird ways.
for (let i in arr) {
// Code
}
This index "i" is a string in JS...
God, what an awful language.
how bout I make a video like "5 Things I Hate Bout ThePrimeagen" how would u like dat Mr.Primeagen
The worst one to me is the behavior of "this" on UI callbacks like click.
Shockingly that's never bothered me. The rule is stupid, but I get it
Hmm .. if you show that FOR and FOR_EACH next each other it looks strange but it's kinda consistent from other standpoint ->
FOR just iterate on key:value pairs while those functional methods like .map .filter .forEach .. they use index just as optional second argument(or key in this case) but they always use value as first 'thing'/argument/whatever -> and they work somewhat like this in many languages I think .. so it does make sense :D
Thx for the video
Totally agree with everything you say, but enough with JavaScript we are waiting for the Elixir video, we need to know your thoughts on Elixir against Go, Rust and JavaScript.
My personal favorite is that NaN (not a number) has the type "number."
Not using regex patterns? What's the alternative you guys use?
parser
@@ThePrimeagen which type? Although parsers require more code and are slower for short convoluted patterns. Don't you think?
On the other hand, parsers are more easily read by humans.
Wouldn't regex be "blazingly fast" compared to parsers ?
Don't get me wrong, I love me some PEGs
setTimeout(f, 0) // f is instantly executed
setTimeout(f, Infinity) // f is instantly executed
... no way
@@ThePrimeagen i see that you just dropped a whole video on this. Nice!
well, if it's infinity then it might as well be now. are you trying to suggest that you UNDERSTAND infinity? of course you're not. and neither is jevascrapt.
@@jazzochannel hmmm... I have a physics and math degree that have given me enough of an understanding to know that something that happens an infinitely long time from now will not happen immediately.
You covered a lot of stuff that I don’t think is covered in Bootcamp and tutorials.
Seems you tell things like they are.
I’d be really interested on your take on self-taught developers.
Not just no CS degree. Self taught with no degree period. How well do they do?
The fact that every function is a closure (I realize this is a fundamental feature of JavaScript and one of the reasons people love it). This is less of a footgun and more of a death by one thousand cuts situation. The fact that you can't trust any single javascript function signature to let you know what data a function interacts with makes it that much harder to reason about your code, and I think this slows down refactoring especially (or at least I notice it slowing me down). If you've ever read the body of a javascript function and thought "Where the fuck is that variable coming from" you've experienced this.
Having studied that topic recently after seeing this feature a lot in conjuction with callbacks, i agree. It's so strange to me to have data "leaking" downstream to functions on the same scope. The fact that it's so useful and heavily used makes me wonder if it's bad or not (i'm a beginner, so idk)
@@shimadabr lack of predictable behaviour makes it harder to write code with less bugs. if someone's aware of the behaviour and using it, i feel like there's easier ways to write clearer code?
that weird nature is the only reason help him write JSFuck
For JS sake...
2:42 OMG that's why my old surrended project isn't working ! I have passed so much time trying to understand why i can't copy correctly Uint8Array !
Guess i will give it a second chance now that i know this !
Thanks so much ! subscribing was worth it ! (It's actually so random to debug month later like this XD)
hah! GOTEM
“Making money is a common sense. It’s not rocket science. But unfortunately, when it comes to money, common sense is uncommon.”
Robert Kiyosaki,,,
I might be late, but NaN === NaN returns false is my favorite.
I always hear people say we shouldn't use regex but never provide alternatives. So could anyone please help me here? I'm not aware of any other way to validate input
Parser
What alternative to regex would you recommend?
Regex is actually pretty amazing if you take some time to learn it properly
Agreed
You definitely end up using some library, i have been there.
just like APL?
There is no excuse for mutable regex object.
toFixed(2) returns a string got me today. Basically the entirety of Js's number system.
I built the account creation page for our site, and I used a regex to validate emails. To be fair it's very loose validation to make sure you have some stuff, followed by an @, with some more stuff containing a dot at the end. And I know there's a bunch of bullshit RFC edge cases and I'm sure it doesn't work on at least a few of them but I don't give a shit because nobody uses email addresses like that anyway, and if they do then they should know they aren't welcome.
1:34 What is the alternative to regex? how do you validate input to an API?
Is this the Dr. Disrespect of software development?
Also for learning first language, I think JS is not good for anyone who look for backend "intense" career. Python and Go much better than JS/Node.
Storing functions as consts will always rub me the wrong way, but I've become used to it. Also, the fact that a function may or may not receive an argument is just weird -it always frustrates me when I realize something I needed in my code was given to me all along via an angument I neglected until now 😑
As in, when you're implementing a callback? That's one of the less talked about benefits of Typescript, the editor will tell you what arguments you can add. This one doesn't even need you to be writing Typescript, just have typings installed!
all the key, value vs value,key vs wtf are the arguments make js hard to write without help of an ide, however ide suggestions mitigate this
this is a bit worse emotioinally, cuz you realize you wasted time for worse reinvention of a wheel, tedious and rather dumb
Great. Another green “Wah. I hate JavaScript because I don’t understand it”.
Unfortunately, this video may deceive people into believing it has a semblance of credibility. It doesn’t
Alright, awesome, I agree that regexes are kinda hard to verify and I'll use them only for quick shell scripts and for find and replace........ What now tho? You can't just say avoid something that's used so widely (ofc, I understand this is just a short video), should I write a grammar and a parser for it instead? Tbh, now I think about it that would be kinda cool. But tell me, what's your idea of a replacement?
honestly, plenty of easy things.
take this for example. you want to validate its a vim cmd. well.. you probably reach for a regex. Hold on devil.
let index = cmd.chars().position(|c| !c.is_ascii_digit()).unwrap();
let (num, cmd) = cmd.split_at(index);
let num_res = str::parse::(num);
Rust code.
Its easy, its easier to understand than a regex, and its performance is well understood.
@@ThePrimeagen What about stuff like email or particular codes like IBAN? can you do without regex?
The fact that the condition undefined > 0 simply evaluates to false and doesn't cause any sort of error has caused me endless pain debugging at work. When there's a function which isn't working probably, returning undefined instead of a number, which then gets compared to 0 and there's no way of knowing.
1 In those days came John the Baptist, preaching in the wilderness of Judaea,
2 And saying, Repent ye: for the kingdom of heaven is at hand.
3 For this is he that was spoken of by the prophet Esaias, saying, The voice of one crying in the wilderness, Prepare ye the way of the Lord, make his paths straight.
4 And the same John had his raiment of camel's hair, and a leathern girdle about his loins; and his meat was locusts and wild honey.
5 Then went out to him Jerusalem, and all Judaea, and all the region round about Jordan,
6 And were baptized of him in Jordan, confessing their sins.
7 But when he saw many of the Pharisees and Sadducees come to his baptism, he said unto them, O generation of vipers, who hath warned you to flee from the wrath to come?
8 Bring forth therefore fruits meet for repentance:
9 And think not to say within yourselves, We have Abraham to our father: for I say unto you, that God is able of these stones to raise up children unto Abraham.
10 And now also the axe is laid unto the root of the trees: therefore every tree which bringeth not forth good fruit is hewn down, and cast into the fire.
11 I indeed baptize you with water unto repentance: but he that cometh after me is mightier than I, whose shoes I am not worthy to bear: he shall baptize you with the Holy Ghost, and with fire:
12 Whose fan is in his hand, and he will throughly purge his floor, and gather his wheat into the garner; but he will burn up the chaff with unquenchable fire.
13 Then cometh Jesus from Galilee to Jordan unto John, to be baptized of him.
14 But John forbad him, saying, I have need to be baptized of thee, and comest thou to me?
15 And Jesus answering said unto him, Suffer it to be so now: for thus it becometh us to fulfil all righteousness. Then he suffered him.
16 And Jesus, when he was baptized, went up straightway out of the water: and, lo, the heavens were opened unto him, and he saw the Spirit of God descending like a dove, and lighting upon him:
17 And lo a voice from heaven, saying, This is my beloved Son, in whom I am well pleased.
(Mt.3:1-17)