Why I hate JavaScript

If you know anything about me, you know that I'm not a big fan of JavaScript. I hate that language. And I hate how the only way you can make writing JavaScript code tolerable is by slapping different solutions on top of it instead of fixing the actual underlying language. Now, my hate for JavaScript is nothing new. This has been going on for years now. But I recently came across this tweet over here that I'm going to show you. And I posted a reply and everything. And this is what really reminded me of how much I absolutely hate writing code in JavaScript. So this guy says, "With RAM crisis bubble that who knows when it's gonna burst, it's more important than ever to fight against web and Electron slop that was built on memory is free premise." So apparently, the developers of today think that memory is free, and they just write unoptimized applications that have terrible performance. And their excuse is, well, we need to ship fast, and so we're just going to build the most non-performant applications of all time that are going to consume gigabytes of memory, tons of storage and CPU and compute, and we're not even going to bother trying to optimize it. Anyway, I declare 2026 a year of FEBNA, whatever that means. Fast, efficient, beautiful, native applications. Okay, that's what it means. You work on something that fits, post your project in replies. Now, it would be amazing if we had native projects being built now, but the sad reality is that's not gonna happen. Most likely, it's not gonna happen. And I posted a little reply over here. I was being pretty sarcastic, I'm not gonna lie. I was being kind of a pity right now. But what I basically said was, "Only real solution is to make something that converts JavaScript into native apps because 99% of devs have never even seen a world outside of JavaScript and npm, and you're not gonna get them to learn native tech anytime soon." And you know what? I stand by my statement. I stand by every word I said. The reality is most people, most developers, start off with JavaScript or Python. Most of them start off with JavaScript, and they just don't even think about learning something new, learning different other languages. They don't even see a world outside of JavaScript because everything is being built with JavaScript, even AI and everything else, Internet of Things. We're just pumping JavaScript into everything, and as you can see, the results are horrible. So he posted a little reply over here: "Only real solution? Not a solution, not even real. I'll just hope that insane RAM prices will encourage proper software to emerge, and then the market will decide." Of course, we kind of have an elephant in the room: VCs with infinite money. How come VCs get to have infinite money, meanwhile I'm stuck here struggling to eat? Anyway, but we've recently learned that this money is not that infinite after all. Well, money is kind of infinite in the sense that they can just print more money, but that's a completely different discussion. Yeah, I'm being sarcastic. I'd rather these people learn other languages so you can develop native directly. Heck, learn them just for the sake of learning. See Go, Rust, whatever. See what problems they solve that JavaScript and TypeScript can't. And this is the thing: you need to learn new other languages just to see what kind of problems they're solving, just to see what kind of features they're offering. Like, try using Go. I've been using Go for a couple months now, and it's just such a beautiful language to work with. Try using Rust. Try using C. Try your hand at manual memory management. See how that works. See how much you can actually write better applications with better memory management and everything. Better performance in these languages. You don't just have to be stuck with JavaScript. Now, one of the reasons I hate JavaScript so much, the whole JavaScript ecosystem, not just the language, is because it doesn't even have a proper standard library. And this is something that I really started to hate about JavaScript. Once I learned Go, if you've used Go before, you know how amazing the Go standard library is. It is so well written. It covers so many different use cases. I rarely have to go and look for a third-party package when I'm building applications in Go because the standard library is just so amazing. But we just can't say the same about JavaScript. So on that topic, I have this little Stack Overflow forum post over here that we're going to go through. And by the way, guys, even though AI and LLMs have just taken the world by storm, Stack Overflow still has a ton of value over here. Not necessarily in asking questions anymore, because you can just use ChatGPT for that, but more so kind of like it's an archive of information, right? It has a ton of different niche problems that people have posted solutions for, and that is still very valuable. Anyway, what is JavaScript's version of .NET standard class library? Well, none. JavaScript doesn't have a standard class library. But let's see what this guy said. This is a very, this is a very detailed reply, and there's a lot of cool insights in here, so we're going to go through that. The JavaScript language itself does not have what most people call a full-blown standard library. The two largest environments where JavaScript is used are the browser and Node.js, and each has their own library, and it adds functionality on top of the language. Yeah, that's how that works. Most of the interfaces added in the browser are standardized through the W3C in an effort to make all browsers work the same. I'm not aware of any standards effort for the Node.js libraries. Yeah, because there is none. You can kind of see how it would evolve this way because the browser is purposely limited in what it can do for security reasons, and thus it doesn't contain rich access to the file system, child processes, TCP stack, creating servers, etc. Then along came Node.js, and it had an objective to be able to do all of those things. So if you're programming in Node.js, then your standard are the libraries built into Node.js and documented with it. If you're fetching HTTP requests from external sources, ironically, the Node.js built-in support for that is not great, perhaps because there are so many very good open-source third-party libraries for it in npm. That is, that I think, is what most people use. We're going to talk about all of these third-party packages as well. They're great, but they're not reliable. Fuck off, Windows. I don't know why I get these notifications still. Anyway, you can use the built-in HTTP request, and it works, but it's lower level than most people want and not very feature-rich when it comes to auth and processing requests and responses and other things like that. For years, the Request library on npm was about as standard a third-party choice as you could get, and what was often used in online tutorials and was relied upon by many other packages. But for a variety of reasons, this has been put into maintenance mode and deprecated for new projects, and there are many other good choices such as GOT, Axios, NodeFetch, SuperAgent, and so on. You can see a listing of many other choices here. I personally like GOT. It seems simple when you just need something simple. It's ground-up promise-based and can do much more complicated things when required. Many of the other choices work very well too. With the huge success of the NPM ecosystem for publicly sharing Node.js modules, after a while, many Node.js programmers just start thinking of npm as their available library. Yeah, that's what most people do in JavaScript. Yeah, obviously, you need to understand a little bit of what's behind the module you rely on from npm: how many other people are using it, how frequently is it maintained, is it reasonably documented, etc. But if it's a widely used module with a lot of projects using and depending upon it, and it seems to be getting regular updates, then the worst thing that happens is that you have to create a fork sometime in the future to fix or add something you want that isn't getting the attention you want. You always have the source, so you're never left high and dry that way. Okay, it's not entirely clear exactly what you're asking here. Yes, you can write. Yes, you can clearly. Yes, you can. What the hell is wrong with me? Why can't I speak? Yes, you can cleanly write classes that implement business logic, that provide data or formatted text for use in the front end, but that answer has to do little with standard libraries. You can do all that with non-standard libraries just fine. You just put your classes and their implementation into a module and export the class from the module so you can use it in any other module of your project. The class implementation details will be hidden in its module. Now, as this genius over here said, many Node.js programmers just start thinking of npm as their available library. And yes, that is what most people do. But the problem with that is you have no control over npm. NPM, the Node.js developers don't have control over npm, like the guys who actually work on Node.js and npm and everything. These packages come from third-party sources. And honestly, even though I love open source and I love that other people are sharing these free tools online that we can use to not have to reinvent the wheel and everything, even though I love open source, this is not reliable. Because let's say you're using some third-party package on NPM. And let's say the developer of that package takes down the project. Because you literally can't do that. In fact, this has happened multiple times before, and I guess the most famous incident is just gonna be the left-pad incident. Let's check this out. So basically, this was a tiny, tiny 11 lines of code npm package called left-pad, and the developer of this project unpublished it, removed it from npm, and it broke some of the most important packages on all of npm. Now, how exactly did this happen? There's a whole story behind this, and we're not gonna go too deep into it because honestly, it doesn't even matter who cares what this guy thinks. It honestly doesn't even matter. But the big thing is this tiny incident caused such a long chain of issues down the line that it just broke some of the most important packages that you ever use. And the reason this happens is because JavaScript developers have this culture of writing tiny libraries to solve problems instead of just implementing the solution yourself. Like, if I talk to a programmer in literally any other programming language, they would probably just write a function to do whatever this 11-line package was doing, right? Instead of downloading another dependency just for 11 lines of code, they would probably just write a function or a utility or something and just use that because 11 lines of code is not that hard to maintain, right? But adding an extra dependency for that, that's just dumb, right? But JavaScript developers and the JavaScript way of doing things has this modular approach where you're stuck thinking, "Hey, should I build this myself or should I just look for a package that does this for me?" Because, like, if you go on npm, there are such niche packages over there that handle such niche use cases. It's weird. Like, there is literally, let me just show you something crazy. If you've never seen this before, you are, you are going to love this. Let me show you some packages over here. So there is a package on npm. Why can't I search? There we go. There is literally a package on npm called is-even. You know what this does? You know what this package does? It returns true if the given number is even. And you know how many downloads this gets? 130 or 150 thousand per week. And I can just keep going through this, I guess, but it seems to be getting like 150, 160, 170 thousand, even 180 thousand downloads every single week. In other words, this is a very popular package. Now, are you telling me that JavaScript developers cannot even tell whether a number is even or not? Like, is this how far we've fallen as programmers? And this isn't even the worst of it. There is literally another package called isOdd. Guess what this does? I'll tell you, it returns true if the given number is odd, as an integer that does not exceed the JavaScript maximum safe integer. Now, please, someone please tell me. And this one gets even more downloads than the is-even package. 436,000 downloads just this week. So an extremely popular package. Now, can someone please explain to me why JavaScript developers find it so hard to tell whether a number is even or odd? It is so fucking easy in literally any language. How are you guys failing this? 2.3 million downloads a month. You guys see this shit? Anyway, now I'm being a bit too harsh because most packages, most applications are not using these packages directly. What they're doing is they're using other larger packages, like let's say Express or React or Next.js or Tailwind or, you know, Electron or some other packages, and these packages in turn have their own dependencies, and those dependencies have their own dependencies, and it just becomes a long chain of dependencies. And one of those dependencies is going to be this isOdd and is-even packages, and probably a bunch of other dumb packages that have no sense in being a dependency. But you basically end up with dumb-ass packages like these stuck in your dependencies list, and it makes no sense to have packages like these. Like, why do you need a separate dependency to tell whether a number is odd or even? It just makes no sense. And there are tons of packages just like this on npm, and different applications are using different packages to solve the exact same problems. And this just leads to inconsistent APIs, and when you have multiple different packages that solve the same problem in different ways, you start to have, you start to encounter inconsistent APIs and edge cases, and it just takes so much more mental bandwidth to track how everything works in your application because you've just added so much more complexity to it. Like, as much as I love open source and using stuff that other people built to save time, I would also be very careful of using packages on npm, because especially if they are such tiny and dumb packages like these that I can build myself in like five minutes, right? Especially if it's packages like these, because anyone could take it down at any time, and then your entire application would break just like what happened with the left-pad incident over here, which was 10 years ago, but it's still relevant. Why? Because the underlying problems have still not been fixed. So make of that what you will. Now, the standard library is one reason and the ecosystem is another reason why I hate JavaScript so much. Another reason why I'm not a fan of JavaScript is because it's such a beginner-friendly language, and you might, you might hate me for saying this, but I mean no harm to anyone. But since JavaScript is a beginner-friendly language, and I should probably write these things down just so it's, just so it's clear what we're talking about, since JavaScript is a beginner-friendly language, and to be clear, this is not even like a bad thing, but it does lead to some bad effects down the line. Since it's a beginner-friendly language, it's going to attract newbies to coding, right? And newbies, let's just be honest, they're not good at writing good code. They're not good at following best practices. They're not good at building performant applications. Now, this is obviously to be expected. I mean, they're new to the, to the whole industry, right? You don't expect a new programmer to be writing elite, top-tier Linus Torvalds code, right? It's going to take a lot of time for that junior programmer to get to that elite level, right? So I'm not saying that JavaScript being a beginner-friendly language is a bad thing, but this does lead to a lot of applications being built in a very terrible and non-performant way because just by the nature of being a beginner-friendly language, most developers in JavaScript just don't even know how things like performance and other things even work, right? Security, performance, scaling. Most developers have not even encountered something like this in their careers. Now, another reason why JavaScript should build some sort of a standard library, or at least agree on some standards, right, is because it would solve a lot of the problems that being a beginner-friendly language attracts. So how does, how does having a standard lib for JavaScript help fix the beginner-friendly issues? So we talked about why JavaScript attracts beginners, and we talked about how they are probably not the most best of coders. We talked about how they probably don't really know a lot about performance and security and stuff like that. So how does building a standard library for JavaScript help fix these issues that beginners would attract and build in their applications? Well, a standard library would solve all of the common problems that JavaScript developers go through. And all of the new developers, all the beginner developers, instead of writing their own implementation for solving the same problem or using some third-party packages on npm with inconsistent APIs and stuff, they can just use the standard library. We would have a standard library with different packages that solve the same, that solve all of the common problems of programming, and all developers would just use the standard library to solve those problems. And we would have a standardized approach to solving most common problems instead of having these third-party packages scattered across npm, with each their own way of implementing solutions. Instead of all of that mess, we would have one standardized library that all developers of JavaScript can use to solve all sorts of different problems. And this standard library would be built in the most performance and secure way so that we can build faster and more secure applications. This is actually the same thing that Python encourages its developers to do. So Python has a very nicely built standard library, just like Go. I love the Python standard library. I love the Go standard library. The thing about the Python standard library is that most Python built-in packages have been built in C, right? And since they've been built in C, you know that they're going to have some amazing performance. And so, in a lot of cases in Python, I would just encourage you to try to use the standard library to solve any sort of problem in your code instead of trying to implement your own solution in Python code. And the reason is because most Python built-in packages are built in C, which means they're going to be very, very fast, right? And that is why you need a standard library. That is why the Python standard library is so much better than writing your own solutions in Python whenever possible, right? Sometimes you just have to write your own solution because you're doing something custom, right? But in a lot of cases, you can just use the standard library, and it's going to be so much faster and easier to maintain as well than whatever custom solution you build up. Right, so that's the thing with Python, and that's how JavaScript can get inspired by other languages doing the same thing, build its own standard library, or at least agree on some sort of standards that developers can use and should be encouraged to use to solve all sorts of common problems. And beyond all of this, beyond all the JavaScript stuff, I would encourage all JavaScript developers to go and learn other languages. And there's a couple reasons why, why I'm encouraging you to do this. Because the biggest reason is because each language solves different sets of problems, right? Like people love Go and Python for their simplicity, right? People love Rust for the speed and the memory management approach that Rust takes, right? People love C for its simplicity and its memory, not necessarily for memory management. People love C for its simplicity and its performance, right? When you want to write some really fast, really system-critical, super fast code, you either pick C or I guess you pick Rust nowadays. So there's different languages out there, and each has its own strengths and weaknesses. And I encourage you, if you've never seen other languages or worked with other languages other than JavaScript, I highly encourage you to go out there and practice a new language. Try learning something like Go or Rust or even C or anything like that, right? Maybe even C sharp or Java. There are so many other languages out there that are worth your time. The thing with the JavaScript ecosystem is that they just try to shove JS into everything. They just try to just build JavaScript implementations into every industry. Like, you can see this yourself. JavaScript started off on the web, right? When the internet was first being built, it was JavaScript that we were using in browsers to build websites, right? To add functionality to our websites. So JS started off in the web, in the browsers, but now you see it being used literally everywhere: in AI and machine learning, in desktop applications, in mobile applications, in the Internet of Things, in pretty much any industry and any tech product you can think of. There is a JavaScript implementation for it that you can use to write the application in JavaScript. And while this does give us some powers as well, because we can use JavaScript in building any sort of application at all, it does also introduce a ton of other problems. The same problems we talked about earlier in the video, right? And the same reason that this guy on my Twitter is complaining about JavaScript and Electron apps. So this video is kind of just all over the place. I've just been ranting and rambling the entire time with no real clear structure. But if you stuck around the entire time listening to me ramble on and on about my hate for JavaScript, respect to you, man. We're gonna end the video over there because, yeah, it's getting a bit long, and I think I've, I think I've given enough hate to JavaScript for one day. We've been recording for 30 minutes. This is gonna take me an hour or two to just edit. But I'm gonna leave you with just one clear message: learn other languages, learn other programming languages. See what problems they solve, see what strengths they have, what weaknesses they have, and figure out in what use cases you would use some other language and in what use case you would use JavaScript or TypeScript. Because this is the kind of stuff that's going to really turn you into a much better developer and a much better software engineer. Do not just be married to one single language. That's all for this video, guys. Thank you so much for watching. If you liked it, press like. If you want to subscribe, then subscribe, and I will see you in the next video.