Why node.js is the wrong choice for APIs (and what to use instead)

[@ggcbDev-124]

"A callback is just an indicator I've used the wrong tool for the job" why? Only reason you give is "you should learn more languages" and "use python for backend"... And yeah python is great but NodeJS as well. "You want your backend structured and know when things happen"... dude, you can do that with NodeJS. Too bad this is the videos that popup on youtube when looking to learn Node. I wish he would be able to convince me by giving me real reason, talk about performance, IT scaling in NodeJS vs others, not just "callback is not the tool" kind of thing.

[@yonigoldberg634]

That's definitely a redicilous video

[@AapVanDieKaap]

His explanation is terrible but I know what he means. With something like a web page, the ability to stack things on an event loop in an abstracted way is very important. On a big (lots of code) web server you don't really want that. It's better to be abstracted away from it by a reliable web server like Apache/Nginx and have a script to handle each request. I will refer to this as "CGI style" for brevity. If you want to do things in parallel you can use a message queue or anything you want really since you can do whatever you want in the server environment. It's important to understand that node is indeed multithreaded. Every IO connection is handled on a separate thread, but the script you write in JavaScript runs in a single thread. In contrast, using CGI style, each script is run in an entirely separate process. This means that by writing your own web server using e.g node, you open yourself up to an entire class of possible bugs and failures. For example: - One that I did personally: There was a (accidental) global variable holding customer details for payments. So I created a bug where the name on the invoice would be the name of the previous customer. This mistake would not be possible using CGI style because the scripts are separate processes. - If the server crashes because of one request, it crashes for all users. The main downside with CGI style is that the entire app must be loaded from scratch for each request. This creates a small performance overhead, but it's quite easy to solve if it becomes a problem. NodeJS is a fantastic tool for many things but it is a poor choice for writing large monolithic web servers and the ecosystem reflects that. And for most small to medium businesses you definitely want a large monolithic web server as the frontend server to your system in my humble opinion.

[@ghhuutrd2140]

​@@AapVanDieKaap bro just use db. when you create a global variable or whatever it means you need to save some application/process state. btw, there are clusters in nodejs for what you described

[@ggcbDev-124]

@@AapVanDieKaap What you describe is just a matter of understanding the tool. Your problems have an easy fix, you just need to use NodeJS in a NodeJS way. Same for any language really. I still don't hear real relevant problems where a NodeJS backend is a problem. There are ways to scale your node app (clusters for example) and you can do threads on modern NodeJS as well. I do know scenarios where you would like to use another language/platform rather than NodeJS, but this guy or you haven't mentioned something similar.

[@AapVanDieKaap]

@@ggcbDev-124 I've been working on a nodejs web server professionally for 5 years. I think I understand it fairly well.

[@mantality312]

Async/await is largely WHY nodejs is the RIGHT choice for RestAPI's.

[@anindhap]

This!!

[@airaction6423]

Could you provide a practical example?

[@juanjosecruzortiz111]

totally agreed

[@eliseoac966]

yeah

[@codingwithjamal]

No, it does not fix nodejs core problems for “fast” apis

[@LucaStasio]

Oh my! You’re understanding of “async” is really bad!!!!!

[@DevOpsForDevelopers]

Lol. Maybe. Care to explain?

[@tanzimchowdhury320]

I had to stop watching around 1:05. First, let's define Asynchronous - Non blocking. Which means, there's no waiting for anything Second the event loop - keeps one serving events (requests) one after the other. Their, callback queue - when calls backs are received from Asynchronous operations, attend to them. This whole concept of non blocking is what gave this single threaded language so much power in node envelope

[@tesla1772]

Yeah i also thought that await doesn't mean that you are blocking anything. Your other operations are still processed by event loop until your promise is resolved/rejected . Node js only blocks main thread when you do some cpu bound work

[@DevOpsForDevelopers]

@@aimableruhumuriza8603 fair point! Thanks for commenting!

[@nubunto]

@@tesla1772spot on. Dude thinks “await” blocks everything… oh my.

[@datacentrejawatimur]

I have over 20 years of experience with JavaScript and love working with it. While I agree that building an API with NodeJS just because it's JavaScript isn't always the best choice, I've found that NodeJS as-is might not perform as well as other backend solutions like NGINX+PHP, which are more stable and easier to maintain. However, I must disagree with your assessment of the asynchronous nature of NodeJS as a liability. On the contrary, it's a remarkable feature that has tremendous potential. If you haven't worked on projects large enough to fully harness the power of NodeJS's asynchronous nature, it's understandable that you may not fully appreciate its benefits. We know that basically JavaScript only runs on a single thread. Running thousands of requests per minute on a single thread is not a very good idea. Processes need to be distributed among other threads, other CPUs, or even different machines in the same cluster. And that's where asynchronous process shine. And JavaScript makes this asynchronous programming a breeze. That's why other programming languages have adopted the JavaScript way of handling asynchronous task. That being said, Creating a good enterprise-level API requires a comprehensive understanding of asynchronous programming and NodeJS's nature. Without this understanding, micro-managing everything on your own might prove challenging. In such cases, opting for a ready-made solution like nginx combined with another programming language can be a sensible choice.

[@DevOpsForDevelopers]

Great points!

[@DaPaBe1999]

Do you have repositories or a profile where i can see your work? I'm interested in your experience. I'm passionate about JavaScript, that's why

[@user-cj5jm7cv9o]

very interesting comment

[@daemonelectricity]

Exactly. This guy preaches the problems of blocking code as virtues. The choice is either between blocking an entire thread and waiting for a response or easily handling concurrent requests on one thread and async/await isn't some voodoo that's hard to understand once you've spent any substantial amount of time with it. Some junior developers DO lean too heavily on async/await and make every function async without knowing how it works behind the scenes and create a lot of overhead on data that can be returned right away, but it does solve all the problems this guy is talking about pretty elegantly instead of throwing an entire CPU thread at the problem and waiting. I was losing my mind watching this video. I've done it both ways. Node.js destroys blocking code based back-ends in responsiveness on less resources.

[@nubunto]

@@daemonelectricity right? per this video, why would I use async Rust, if I have to "await" a database query? let's just go back to doing IO and blocking threads! and honestly, threads are fine if you only have to handle a couple thousand of them, maybe tens of thousands depending on your hardware. But for hundreds of thousands/millions, it's much better to multiplex IO operations on a pool using something like, you know, NodeJS or async Rust or even Go (coroutines).

[@elimgarak3597]

Actually, node offloads blocking operations to libuv, which IS multithreaded and processes jobs in parallel. It's only the event loop that is single threaded, but concurrent still (meaning, it doesn't wait idle until a blocking operation finishes like you said, but it works in a non-blocking manner: it sets the task aside for the moment, offloading it to libuv, but keeps doing other tasks in the meantime). The real reason why you shouldn't use it is because Js lacks strong typing and so it is harder to debug. Ts exists but it is garbage still.

[@DevOpsForDevelopers]

For sure. It’s not the implementation that bugs me, it’s the way I have to interact with it

[@MrLinuxFreak]

you can typescript or jsdoc to ease your debugging

[@elomatsouagboka6844]

plus you can also do multithreading with node.js using worker thread which is easy to be achieved.

[@mikegriffin616]

This clicked for me recently and it makes so much sense. The event loop is a systems idiom that feels unfamiliar if you’re coming to Node from client-side development.

[@parlor3115]

Hi, I wanted to say that the asynchronous model of JS, and subsequently promises and async-await, is the most powerful feature of the language and is something other languages are copying (C#, Rust, Python, ...). This is because of the huge advantage this model provides in terms of resource management. I agree that JS cannot possibly be the be-all and end-all programming language, but it's for other reasons. Also, I don't necessarily agree with your viewpoint on focusing on a single language or stack. I personally think one should invest in learning and practicing a limited set of technologies, honing their skills and deepening their understanding of them and only when they have become very proficient and productive that they ultimately move to learn a different set (all according to the job market requirements ofc). Trying to learn a bunch of languages, databases and tools at the same time will prevent you from being an expert in any of them and will make unable to compete with specialists.

[@DevOpsForDevelopers]

Right on. I appreciate the thoughtful, detailed response! You make some great points.

[@alitorabi7960]

C# had this Async/Await long before JavaScript.

[@DevOpsForDevelopers]

@@alitorabi7960 right on. As an afterthought, it’s not async that I’m opposed to but how it feels like you have to write extra code in nodejs to accommodate it

[@shimadabr]

Actually the first language to implement async-await was C# (version 5, 2012), which is not only asynchronous, but also multithreaded. Javascript implemented promises in 2015 (ECMA6) and async-wait in 2017 (ECMA8).

[@michaelerwin8744]

Rust? It's a mid level programming language same as C++. AFAIK Deno - a successor to Node was built using Rust.

[@SlosII]

If you're using python or java to write a backend api in 2024 you're crazy! There you go, I said it. Python just was never designed to be used for this (speaking of using the wrong tool for the job), I've tried it and it sucks on many levels. And Java is so verbose and so drenched in builders, factories and all sorts of crazy overcomplicated design patterns that only an insane person would like to spend time in that environment. As an ex Java EE dev, when I now look back at Java code I think to myself.... who wants to deal with this crap still (for making something as simple as a backend api that in essence, only returns you some JSON data at the end of the day)? Why should I write 300 lines of unreadable, incomprehensible code to do what javascript can do in 10 really clear lines of code that even non programmers can understand. Really, why?

[@worldbosspf1]

Go is cool but you still have to do insane to want to be writing Go code all day.

[@igorcastilhos]

@@worldbosspf1Go is the goat, honestly, if there were at least more opportunities for juniors to work with Go I would dive in to it, but the majority is Node and Java

[@szigyartom]

Java is perfect for this purpose. You have so much fw support that you don’t need to write just a single line for a crud. You just have to know your tool.

[@tiltMOD]

Can I ask what you prefer instead?

[@agmeag]

So, what would you use, im currently on laravel framework, i think its good but i would like to increase query performance and support massive requests usage, having itself a more secure environment

[@phamlong4210]

Node as a backend has been living quite well and I cannot see why a callback would be a reason to not use it. Having to not use 2 languages and get to concentrate on 1 is really beneficial and it doesn't indicate anyone's ability to learn new languages at all. The only thing I can bash about Node and JS (or TS) is the performance, but unless it is some real-time critical application then I cannot see an issue. Bad take imo

[@DevOpsForDevelopers]

Agree on performance: most of us aren’t building apps where the performance difference has an impact. Personal preference for the rest. Thanks for sharing your thoughts!

[@xxapoloxx]

if you really believe this, you are a mediocre developer.

[@phamlong4210]

@@xxapoloxx yep, thanks for the opinion no one asked

[@xxapoloxx]

@@phamlong4210 Yet most people hold it.

[@phamlong4210]

@@xxapoloxx I'm sure they do, how many like did that opinion get btw? Yes, exactly my point

[@morhaham6609]

The single threaded event loop mechanism of nodejs is there for resources utilization and it's an effective one. You can still open worker threads when needed, or split the app into microservices. Regarding the "one language rules it all" argument, your'e right from the developer perspective but misses the opportunities and benefits for enterprises in this manner.

[@shapelessed]

Not only microservices, many single services can easily be scaled vertically even despite being written in NodeJS. On the backend you can easily just deploy your app in a cluster. Say you have 8 cores, use 6 of them for NodeJS nodes, 2 of them for Node's internals like FS/network calls and you're good to go for quite a long time before needing to split into microservices, or at least gives you some time to rework your infrastructure to scale further.

[@WebDevCody]

I can understand your arguments. I think I'm one of those people who enjoy the lack of context switching node provides. I could easily write js on the frontend and maybe go, python, or java on the backend, but the whole context switching when doing full-stack development isn't worth it. Every language has so many different pitfalls and gotchas you have to be aware of to write quality code, so focusing on writing one language well vs 2 language sub-par is a tradeoff. Just my 2 cents. Honestly, I wish the front end was written in python and I'd use python for my whole stack. Thanks for the video.

[@DevOpsForDevelopers]

Thanks for your feedback! If you are able to spend a majority of your time in one language, I understand the desire to keep it that way. Context switching definitely sucks. My experience supporting many applications & microservices has never allowed that to happen. My code quality represents that too: I'll never be one of those devs who is a deep-expert in writing code for a given language. I think that's consistent with DevOps- a generalist in many areas, specialist in none.

[@veektor_v]

You've heard of the pyscript tag which allows you to use python instead of JavaScript for the frontend?

[@josippardon8933]

One main benefit of writing both front-end and back-end in same language is ability to use identical functions and constants in both of them, without having to create duplicate functions in two different langauges. For example, in my project I compress data before sending it from front-end to back-end. Back-end then decompresses data, changes it, and sends back changed data (compressed, of course). Front-end receives this, decompresses it, and do what it needs to do with it. For that, i have two tunctions, compressData and decompressData, which I use on both front-end and back-end. I dont need to write same code twice in different langauges. My project structure looks something like this: /data (folder designed for functions that are used both on front and back) /back-end /front-end

[@ayylmao782]

And it's nice not to have to deal with, say, different handling of floats or more precise number types.

[@DarthVader11912]

I don't get how someone could mess up the introductory sentence to a video, but this guy did it. NodeJS isn't a framework it's a runtime environment for JS that allows us to write JS code outside the browser.

[@fatih-araz]

I love the mixture of nodeJs and PHP. Nodejs for async jobs and PHP for delivering the results

[@ammarmohamedsaadawy5870]

Let’s say on the backend I want to perform 2 operations before responding. With asynchronous, I can write the one with less time then await on the one with more time, in this case, by the time the one taking more time is done, I would have both ready. By your words I would wait for each one alone, so which is more realistic/reliable and time saver?

[@airaction6423]

"With asynchronous, I can write the one with less time then await on the one with more time" Not true. NodeJS is single threaded this means it runs ALWAYS on the ONE core. The time required to perform two async operations is IDENTICAL to that required to perform two serial sync operations

[@_qdrx]

@@airaction6423Not true. Have you ever tried Promise.all or calling async functions without await keyword?

[@ramsulley]

1:59 Node.js is still a strong choice for APIs thanks to its non-blocking, asynchronous nature, which excels in handling I/O-heavy operations and real-time apps. Its single-threaded event loop is a strength in many cases where CPU-bound tasks aren’t a bottleneck

[@vectoralphaSec]

Many reasons why I became a Django developer. I never been this happy when I was writing JavaScript. Im never going back to Nodejs or anything JavaScript ever again.

[@oghenekarouzezi4504]

I don't think you understand how nodejs work internally... First of all, there is no waiting around. Second, most of the work that we do on the backend are not processor intensive, but rather communicating with various services over the network. Thus, nodejs is the perfect tool for handling concurrency very well. But if most your task has to do with computation, then nodejs is not the right tool, as advised in the nodejs documentation. In simple term nodejs is a tool that makes synchronous I/O asynchronous. Thirdly, nodejs come built in with an assertion library and test runner... But many developers aren't aware of it, that doesn't mean it is not provided. Similarly, Nodejs also comes with performance testing via perf_hook module. So, I don't know the excuse!

[@Sebscholl]

Really valued the perspective of "single language" argument being impractical. Thanks for the video.

[@carloss3028]

Async/await in JavaScript doesn't block the process like synchronous operations. It allows other tasks to continue while waiting for asynchronous operations to complete. Is so powerful that it has been adopted by other programming languages. WTF

[@DevOpsForDevelopers]

All true. Still doesn't make me a fan of the JS implementation though 🤣

[@alexgavril385]

​@@DevOpsForDeveloperssuppose you are not a fan of microwaves. Wouldn't you then say that microwawec can only heat up one glass of water at a time?

[@zlatkoiliev8927]

This is not true, if you have async/await the code we are awaiting has to execute first before we continue down. It is blocking piece of code and you can't continue, you don't have other threads. Other languages like C#, Java, Rust... they can use another thread if they want to run tasks in parallel, but JS is stuck only with single thread and that's it. This is huge limitation especially if you are looking for performance and quick responses.

[@glan-tucan]

@@zlatkoiliev8927 1. If you await for an asynchronous call when processing a request node either spawns a thread for it or delegates the task to the OS and continues processing requests, until the async call gets resolved or rejected. Then it continues processing the code after the awaited call sinchronously until it finds the next async call to be awaited for or until the request is reponded. So in practice all the expensive operations are run in parallel, or concurrently. You have a single thread for processing in js, but all async operations run in different threads spawned either by node or by the operative system, and this is done automatically without you having to micromanage the threads yourself. 2. You are not forced to await for every single asynchronous call, yo can collect all their returned promisses in an array and await to a Promise.all(promisearray) that returns an array with the resolved values. So you can call non interdependent async ops in parallel from the single js thread. 3. You can manage threads yourself by using workers. I understand the reticence coming from other languages, and wouldn't recommend usong node for everithing, but I think you should read about the node event loop before forming strong opinions about what node can and can't do.

[@thenaijagamer7837]

​@@zlatkoiliev8927 Try to refresh your knowledge on how node js works behind the scenes cos even a beginner that's just starting out will know what you said is absolutely wrong. You don't have to talk about other languages if you are not familiar with them.

[@attilaszombathelyi3]

nodejs perfect for backend web api with express library. Very stable, fast, simple and u can combine with nodejs cluster

[@AbubakerMahmoudshangab]

I agree man. And thank you for your advice I am doing a project and was dangling between fastapi, express js or php api. But I guess I am going for fastapi. Thank you again

[@gauravkelkar8824]

What a bad argument. You point out no specific reasons, and blame promises when you can't differentiate between a cb and event loop. Then go on to blame the dev on not wanting to learn more languages. And attempt to justify other languages by mentioning their name and the first line in the docs. What a low value video

[@macro312]

I dont think it is a matter of "refusing to learn multiple languages" - more a matter of if they are willing to look deeper beyond the MERN stack for something. However, I am a noob and I share the opinion that if you're learning, you shouldn't worry - just be aware there are pitfalls in each tech stack and only experience can allow you to see these pitfalls.

[@DevOpsForDevelopers]

Fair point!

[@_willow007]

On my opinion Node is not the best option for backend development but is not the worst either, I agre with you on Golang, and would add Laravel along with Ruby on Rails, but I honestly think Node is a much better choice than python at least for API development. My general options are always Node and NestJS or PHP and Laravel for general Apis and Go for some calculation heavy work.

[@Heroselohim]

Same options for me! I moved to Node to have everything in Typescript/Javascript Frontend/Backend. If not, I would still be using Laravel/PHP. In time, Node and package management seemed better than Composer to me.

[@mateszurovecz7751]

It’s fine not to like nodejs for backend, but from your words I feel like your understanding of async is totally wrong

[@DevOpsForDevelopers]

Fair point, and based on the comments that seems to be a common theme. The point I was trying to make was not against async itself, but the Node.js implementation and I didn't convey that well. Thanks for commenting!

[@szeredaiakos]

Not sure if I get your point... All the complexity management a language needs are present in both python and JS. C#, Go, java... are of them are equivalent on that front. The runtime choice is something one can argue about. But performance is definitely not the only metric a tool is chosen for.

[@DevOpsForDevelopers]

Fair points. My point was it feels like I have to write more code in Nodejs to perform the same tasks when compared to some other languages. Personal preference only.

[@szeredaiakos]

​@@DevOpsForDevelopers Yes, Node is like that. And I can't argue against preference. What I can argue is that a lot of people confuse productivity with number of characters they write.

[@Zoulz666]

async/await simplifies promises to the point where it's pretty much the same as writing synchronous code. So I don't really view that as a problem. As for using only one language, that's kinda missing the point. It's more about using as few different languages as possible. If you can achieve the same result using the same language, why make things more complex than they need to be.

[@DevOpsForDevelopers]

I agree with your first point: async/await has simplified it and is a great improvement (IMO). Re: if you can achieve the same result with one language, why make it more complex -->> I semi-agree here as well. Since a lot of my viewers are relatively new to the field, my goal with this video was to help them avoid the "one tool to rule them all" trap. When you add HTML, CSS, SQL, Terraform, Ansible, etc... it can be tempting to "just find an npm package that does that", but that approach can limit your career growth when either those tools don't exist, or those tools themselves mask complexity and create an artificially bloated stack. TL;DR: I agree as long as you understand the trade-offs and aren't using Node.js as a crutch to avoid choosing a more proper-fitting tool for the problem at hand.

[@ultrasys]

God damn ME!!! Took me THREE years for Google to suggest me this video. Great and sensible take on a lot of aspects, especially strategic ones. Other than the Windows screen at the back, you got a very respectful point. Thanks!

[@visualmindgame]

if you do not have the data you need to calculate then what would you do at that time? you said ruby and python are you fond of easy languages? Node.js uses a single-threaded event loop and an asynchronous, non-blocking I/O model. When a request comes in, Node.js processes it and delegates time-consuming tasks (like database queries, file operations, or API calls) to the background using asynchronous operations. The main thread is free to handle other requests while waiting for these tasks to complete.

[@IgorKravets81]

Async part really misses me. Why? I use node on backend because I reuse typescript types, zod schemas on both front and back. For small projects it's a booster especially when nuxt and next make it so simple.

[@devonthefloor6429]

It depends on your goal, whether you need a quick build REST API or whether you need a complete algorithmic task.

[@debiprasaddash6403]

All developers who came from java background when they move to a different language they try to compare that language with java they expect everything should work like java. That’s the only problem, javascript is a tricky thing to learn once you understand thoroughly everything will make sense to you.

[@DevOpsForDevelopers]

Yeah, for sure. Probably true for any language: we try to fit the new stuff into boxes we are already comfortable with

[@tanmayrathod3609]

I am a dedicated JavaScript developer, frequently using Node.js , Nest Js and React for my projects. However, I wholeheartedly agree with your thoughts.

[@DevOpsForDevelopers]

Thanks for sharing! I’ve used Node.js a lot, and will do so again in the future when it fits the requirements

[@sambines3463]

Dude. If you use node, seriously swap to a proper language for backend. I started as a node developer, it sucks for large scale projects. I recommend golang or like rust as a solution but stop with node. Even though is isomorphic you end up needing stuff like typescript and it becomes a mess or packages.

[@TheRealCornPop]

If you're a js dev, you should know that his info on async is completely backwards

[@aki1840]

I respect that but I don't really understand why Node is the wrong choice. It's using libuv for it's async I/O same as many other languages such C#, Java and Python. Of course Node is not that good at heavy CPU tasks but seems to be perfect or at least good choice for API's. I might be wrong but looks like you don't really like Node.

[@DevOpsForDevelopers]

Hey, thanks for chiming in! Node is definitely performant, no doubt about it. My complaint is purely stylistic, not performance. It feels like I’m writing code to accommodate node rather than writing code to accommodate my features.

[@MoawiaAlmardoud]

All languages are working around async, with any query/function we should wait for the logic response. Even with multi thread languages like java, you should wait for the thread response. I believe the difference depends on the response time, and the main factors here is the server resources, and internet speed.

[@NattyTrader]

What about spring boot, hibernate and all ?? Something related with java?

[@nyplace1]

You are so right about being adaptable to language, as you grow your career for example into IAM field, you will be forced to use many languages just because large enterprise applications are already there and you must utilize them when working within companies that are committed to various products (Java, Groovy, PHP/laravel, bash, javascript, powershell, sql etc...) i had to tap into all kinds of technologies as you grow towards solutions architect (that is where the money is :) ) don't get stuck on a single technology, although i would say Java / Spring is essential as a base. I personally dislike how long some of the projects take when for example someone chooses Spring while writing a small application etc.. pick the right tool for the project at hand

[@DevOpsForDevelopers]

Agreed 💯 🤣

[@sidisting1381]

One good reason for using JavaScript (TypeScript to be more precise) on the back end is if you are going to use tRPC.

[@reilwaystation4372]

is tRPC even necessary?

[@RealNaisuCinema]

I do software engineering for a federal airline that uses node.js on the backend for APIs idk if I’d trust this.

[@DevOpsForDevelopers]

Ack.

[@wandacode]

I stop watching the video since He says "Node.js is the most popular framework". NodeJs is not a framework.

[@DevOpsForDevelopers]

Yeah. I mis-spoke. My bad.

[@YaserFarid]

Sorry, if you haven't understood how Async/Await works that isn't my problem.

[@Cloudland117]

Hmmm. I am one of the js people you're talking about. I'm using server less functions to avoid the backend as much as possible with netlify but in noticing my API fetch times out at ten seconds so I need a different devops situation but I don't know what to do. Python and Django was such a a pain in the ass to deploy compared to netlify with a little js

[@saksham00]

I usually don't leave comments but I think that the whole purpose of this video is to generate enough comments so that they can profit from algo and get more recommendation.... the title makes you click the video but honestly there is nothing, no argument, no valid points at all to support "Why node.js is the wrong choice for APIs"... a classic example of creating a clickbait !

[@BinaryReader]

There are legitimate reasons not to use Node on the back end, but none of them were mentioned in this video. Also, suggesting Ruby or Python as better alternatives to Node makes no sense (what value is gained by using these over JavaScript?). As for Go...perhaps...but again, no reasons were given for why you would opt for Go over Node. I can think of several, none of which have anything to do with the languages themselves.

[@DevOpsForDevelopers]

Right on, thanks for sharing your thoughts!

[@cn1878]

Javascript is designed with one thing in mind - to be a singly threaded, asynchronous language. Its baked into all of the design principles. In clientside this is very useful, you don't want the website to freeze when you click on a link for example. On server-side both of these qualities are liabilities that have to be worked around because a server rarely has use for asynchronous code and is multi threaded. Everything that makes javascript good for clientside makes it bad for serverside. Ruby, Python, and Go are designed to be synchronous and multithreaded by default which is why they are a good fit for serverside.

[@nulI_dev]

​@@cn1878 Node.js is most commonly used as a web server where most operations taking place are asynchronous. Querying the database, and reading/writing to file system are both async operations. Any CPU intensive tasks can be run in a worker thread which will not block the main thread. You can also use the cluster module to run multiple instances of the Node app on multiple different cores and load balance IO evenly

[@TheRealCornPop]

Node's concurrency model makes it more performant as a web server vs Ruby and Python web servers. I'm not sure what you're talking about. Node generally outperforms those two languages. When it comes to handling async operations, you need to introduce something like sidekiq to handle them, whereas node via as supports this natively

[@AmerAlsabbagh]

Once you said that you have nothing to do while waiting for a database query I knew your not an expert

[@petemoss3160]

that Windows desktop in the background told me.

[@danny_the_K]

Ok, so I’m interested in your viewpoint. I am not a dev by trade but want to develop an application that I can operate as a SaaS product. That’s why I’m using javascript in both the front end and Node in the backend. I don’t care about my 20 yr dev life cycle, first, because I’m 68 and 2ndly, because I want to get this up and built quickly, but I don’t have the money to hire a team of devs, so I’m stuck. I am somewhat of an expert in the RF design and implementation area for cellular, Wi-Fi, Public Safety, and some other commercially used wireless services. I want to apply my knowledge inside the tools I’m developing. So right now I’m drinking from a fire hose and getting really full… so help me understand how to undrown myself.

[@aeronwolfe7072]

I would never claim that node is the best tool for all situations... But i just freaking LOVE js and i love node so... I like one lang for my full apps. I make mostly small apps for small companies and it works very well for me.

[@DevOpsForDevelopers]

Right on! And I agree with you: I use it a lot for small apps/teams. Keeping the tech stack minimal can be pivotal in their ability to deliver and achieve success. Thanks for commenting!

[@aeronwolfe7072]

@@DevOpsForDevelopers thank you for replying!

[@mouaddigoug8361]

I been using nodejs with express for some time and I'm not gon lie I have never seen a decrease of performance in any way I just love it, Ive turned to neo4j as a database and i just love its performance its so much better than any relational db so I had to consider switching to spring boot cause it's a better match for neo4j than nodejs and express

[@DevOpsForDevelopers]

Right on. I’ve not used neo4j. Glad to hear it’s working for you and will check it out. Thanks for sharing!

[@ruyvieira104]

you just didn't push it hard enough.

[@renzcarlosalanga6077]

maybe you just have a couple of concurrent users

[@snow2357-b8n]

Node is not for big ass tech companies who have countless users its for startups to ship the product so that they can start getting users and then switch parts of code and node is so simple to start and have a good experience with frontend if u use trpc ts , in python and java apis half of the time devs check the response and useless discussions about that data they will need in front and back

[@dbred67]

I think it's reasonable to say there's better languages to write backend code depending on the use case. The reason's in the video are just the wrong reasons to make a decision on which to use. Feels like this creator wanted to promote learning more that one language is good (agreed) and this was the best example they could come up with.

[@tracer822]

Well, async on backend is a pretty good thing if you are building an event driven system , using pooling with your connections and deploying to a container management platform. You have all you need to crate an efficient design.

[@Md.TauhidulIslam-wv3bb]

I think you misunderstood some point. First of all Nodejs by default single threaded but we can make it multiple threads. Secondly Nodejs by default single process but if you need multi processor we can create multiple process. Finaly, asynchronous programming meaning that is not blocking to other code or function. In my opinion, NodeJS have lot of features but by default provide small feature, if we need those feature we need to implement.

[@johnentertained]

I agree, the fact of working the backend and the frontend with the same language should not be a reason to choose server-side JavaScript. The last few years I've learned that the best thing for the backend is a strongly typed language and server-side validations. Greetings! 👍

[@davealma88]

I think I understand your point, it could be cumbersome to handle asynchronous code, you could use async - await to overcome this in someway but for begineers it could be an extra step that you could save using other tools. But I think NodeJS is a great tool that one should know about it.

[@guled669]

The Async and Await argument that every database call is a promise I totally agree on. It makes writing unit test for the backend hard and not fun

[@human12three]

While waiting for the db query results it can keep handling incoming requests. It doesn't just wait in idle. So your arguement is just wrong and there is no other arguement really.

[@DevOpsForDevelopers]

that's not my point, but thanks for sharing!

[@tranhien6526]

I'm surprised that there's so many people out there does not take learning the core of nodejs more seriously

[@BatteryProductions]

as long as it gets the job done, doesn't really matter what tool you use...

[@DevOpsForDevelopers]

Absolutely!

[@Dimi-Tech]

Node.js is not a framework. You discredited yourself in first 5 seconds.

[@DevOpsForDevelopers]

I mis-spoke. My bad.

[@tech3425]

Such a soft spoken person... and then that fucking intro blows my ears

[@DevOpsForDevelopers]

🤣🤣🔊🔈🔊🔈

[@yalcinozer4434]

I created an Monorepo that includes React and Express. I am sharing interfaces, helper functions between FE and BE. Whole process is so smooth and I am totally ok with my tech stack. There are lots of choices. Our choices may depends just on preferences. So nothing wrong with that. I don't like Taildwind and prefer StyledComponents rather than it. This doesn't mean its a bad technology, I just don't like it. So it just a preference.

[@petertyldesley6542]

I'm not sure I agree with you there. Your argument about Node being a bad server side language is basically just "because it's JS" and the reasons you gave seem to be based on a flawed understanding of the language. You also didn't explain in any shape or form why Ruby and Python are preferable languages to use. What is it about these that make them better server side languages than Node?

[@dtesta]

Hmm, it's not about not wanting to learn different languages, it's about things like sharing code! You can use the same library for something on both sides. Also very convenient to use the same type definitions (for typescript) on both sides! You simply send one object with certain attributes defined inside, probably encoded to json, to the server and the server can easily convert it back to the same object, with all types already defined. Also, the whole idea with something like nodes event-loop style paradigm is that you can scale up to milllions of connections with little RAM usage. What you obviously want instead, is something like PHPs threadding style, where each request runs in it's own thread or process, which is super inefficient and will struggle to handles the web of today where it's common with things like websockets etc.

[@TheLondekZdroj]

Seriously, you present yourself as an expert and call Node a framework?

[@alexgavril385]

0:47 what do you mean. It is async call. While db quiry works.. your code proceeds. It does not wait

[@nyahhbinghi]

Node.js is the baddest backend runtime I have seen. Elixir is cool, but without something like TypeScript, Elixir's dynamic types aren't for me. Golang would be cooler if I didn't have to put locks every-fucking-where and if it had an async/await construct.

[@DevOpsForDevelopers]

c.mu.Lock() defer c.mu.Unlock() fmt.PrintF("That's fair")

[@dntwantgglplus]

I've never seen an API that didn't need to handle async operations. async await is just one way of handling the task that all APIs must handle. node seems like a great option for this.

[@DevOpsForDevelopers]

True. My point is more about the implementation, not async itself.

[@tarkgundogdu8940]

@@DevOpsForDevelopersWhen NodeJS was first introduced in 2009, it had much better performance due to that non blocking instruction cycle especially compared to Java and any other framework. The other languages or frameworks just implemented async/await similar to NodeJS after seeing it.

[@parrurox01]

​@@tarkgundogdu8940async/await first came in C# btw later got introduced to js

[@michaelcheung9936]

I totally agree with you. I hate node js as the back-end. I've no problem like using js code in front-end especially using those js framework like vue. I will use php/laravel backend then vue in front end. It's really pain in the 6utt to do those async and also that nested bracket/function within is also pain as well. I just don't understand why the hell ppl want to use it for backend if u want to write/maintain re-useable code.

[@DevOpsForDevelopers]

👏

[@lcfsoft]

reading all the comments I have to write this: you are, obviously, right about everything.

[@Xeras82]

Theoretically, you right, but in the real world it is often a decision of which people you can hire. Finding a go developer is much harder than finding a nodejs developer.

[@elflotech]

Even 3 years after this video was made, I have to agree totally 100% with what you are describing in case particular. Go is aa better choice for API development also. Great thoughts even in 2024 this is still the same as the above aforementioned.

[@vincent_retro]

How to trigger an entire coding community in 5 mins 😅

[@DevOpsForDevelopers]

Right? 🤣

[@narimanmortezaei5888]

Yes i totally agree, Ruby, Fortran and even Pascal are another good ones that you missed in your list.

[@DevOpsForDevelopers]

🤣👏👏👏

[@fafaratze]

its not about the language, its about how you architect your overall app.

[@xpertj007]

i have one question would you use - MERN Stack or React with Lamp stack

[@DevOpsForDevelopers]

If I'm working with a team that already has skills on one of those, I'd stick with what they know. If it's just me, I'd probably go with MERN

[@joshuaakinwale3155]

React with lamp stack. Having a separate code is always good

[@gargara123456]

I do not agree on the point that one must know 500 programing languages, this is just plain stupid.

[@DevOpsForDevelopers]

Agreed. Definitely not 500. But two or three? Absolutely.

[@akazakou]

So... In you understanding async operations blocking a whole thread, till operation will be completed?

[@DevOpsForDevelopers]

My complaint isn't about the technical implementation.

[@JustKatoh]

They do actually. NodeJS can only use one thread, let's say you send out 5 comands on this thread which are all async, 4 of those commands are a request to some web page with a GET and they complete in 50ms or less, but the 5th command is an intensive task such as report generation or something along the lines which is not uncommon in an API. What will happen is pretty much randomly unless you designate it, it might run 2 of the GETs and let them run in the background non-blocking then hit the performance throttling report generation task, what will happen is that EVERYTHING will get stuck until that report is completed, then they resume the async/await behaviour hou are familiar with. Now let's take something like Go/Java/Rust, these languages have extremely easy to use multithreading feautres, goroutines, java virtual threads and tokio make this even easier! By default they work like async/await that nodejs does, but if the task is massive and is taking too long it will be automatically taken over by a separate thread! as such it's better distributed. It is stupid to write big APIs using python/nodeJs and you are doomed to fail as a company if you want to implement a gigantic API using it, such as software solutions, or payment systems, etc... scalability is literally "pay more to aws/gc/azure" it's stupid. Whilst with java/go/rust it takes full advantage on the machine the software is present on be it a VM with 1 core ( performs a little bit better than nodejs because all these languages are faster than javascript/python ) and on something with multiple cores it demolishes it!

[@saxtant]

You're supposed to build with Async because it can build your initial page with parallel access... If you aren't using Async, you may as well use python. You don't need to use bash, JS can also do that. Async is why it's so much better for decoupled apps, Web apps.

[@samferrer]

Guys ... give him a break ... it was 3 years ago ... now you use whatever language you want using GPTs ...

[@74Bagas]

i go with Go whenever i can for api or backend related, idk. came from nodejs, don't get me wrong i love nodejs and its rabbithole, it cures my nerdy brain 😂. but hey, i decide to take "devops" endless road, so.. i have something in the pocket, it is not really harmful i guess.. till another "blazingly fast" framework arives 😁

[@DevOpsForDevelopers]

"it is not really harmful" --> 💯 agreed. For the code that most of us write, the language/runtime is probably not going to be the limiting factor.

[@burkskurk82]

The built-in hrtime is way old and a unit-test framework and runners were added in v18 (after this video published)..

[@mr_don_key]

sql is not a programming language though.. html isn't either.. so in that sense, yes, one programming language makes sense, in that people want that.(less cognitive switching, which is often discarded)

[@malachibergman902]

I think go is better. Not sure about rails, because i don't know much about it. I know some of the limitations of node.js. I also know that python has limitations. Go is probably the better choice, but it's not a perfect world and the libraries for Go are not where the libraries are for npm. I could be totally wrong, and I would love to be proven wrong here, but libraries for database access like drizzle or kysely are not available in the same way in Go as they are in npm. Is that a reason to stick with node? For me, yes it is. I appreciate the massive amount of effort people have put into their node.js libraries and how easy it has made it for me who knows nothing even after getting a CS degree to build something useful for the company i work for.

[@ricardoferrari3228]

I start side project with nodejs, it became huge, running in RBpi and super fast and amazing uptime. For enterprise.

[@michaelcarneal7573]

As a career engineer, I want to, like many others have stated, disagree with your opinion on at least the async nature of the lang. question your overall knowledge of modern web tool or at least comprehension on them if this is the take away. Now while I would prefer to not build an express.js app or use another node framework, there are plenty of real and practical uses where it’s a viable solution. I have a difficult time finding credibility if this is how you view certain tools, or you are doing for the clicks to which point I’d say most viable up and coming developers probably won’t be fooled

[@Zizaco]

With all due respect. The premise of this video is completely off. The non-blocking IO of node is precisely why it is so good for backend. For a "rails-like" experience, theres adonisJS

[@SzaboB33]

me when 4 functions deep I need to use an await so I either have to use then() or add await but then I need to add asynch and then I need to await that function when I call it then I need to add async so I just wrap the rest of the function into then() and it looks horrible. Also, await should mean: I want this code synchronous but I have to make it async, is it bothering only me?

[@DevOpsForDevelopers]

Lol. Testify! 🤣

[@tejasjani2544]

Ohh man, you just explain in detail what this guy wants to say in this video. i felt same while doing Async task Synchronously . when first time learning JS , I was finding delay function simular like (java and c++) and I found SetTimeOut(). At that moment I understood this going to make me expert coder to write an 😅unreadable wrapper code.

[@Luxcium]

You can think it inside out and split your functions into smaller chunks so that nothing is using await (in the function) because it would be passing the thing already awaited to your function… I don’t know what is your specific situation but it seems like it could be easy to separate the stuff you want to await from the rest of your logic… if you await and pass it to a function that will also use async stuff then you will have no problem because you are already in an async and you can also chain a then and catch and then await the result as you see fit with respect to your code

[@havocindustries3078]

I face-palmed so hard that my desk broke. I'll send you the bill.

[@Kranael93]

If bun goes v1.0 all that not matter anymore. You have no transpiling step for typescript and the performance gain is insane because its a complete new runtime. Don't know what will happen in the future but python will maybe get rid of the GIL and Typescript will maybe replace javascript for new projects and will get performance boost because of new runtimes, bundlers etc. In the while java gets old. The Spring Framework is what keeps java alive...

[@justinnl4332]

I am also waiting for bun to reach v1.0 so excited for it!

[@DevOpsForDevelopers]

I haven't checked out bun. Might be worth a visit.

[@FredoCorleone]

NodeJS is actually pretty good for backend. Put TS and Express and your are ready to create great APIs in no time.

[@wdeath]

Async programming is what makes node.js fast, because thread is non-blocking while waiting. There is no other alternative to async programming if perfomance is needed. The only alternative nowdays is Java virtual threads, that the JVM handles that for you, maybe learn this if you want to be fast and write blocking code the same time.

[@moathdw910]

Man at least try to understand the async/ await before publishing such a video any intermediate NodeJs developer can spot that you know almost nothing about async/ await and how the sync behavior of nodejs is an advantage if you use it the right way. your argument is very weak and does not make any sense, like hey folks async/await is a wrapper for a callback so let's not use node js lol We migrated from java to node js in an application, and it was much better in performance, much cleaner code and less code and much easier for maintenance and better in productivity, what takes 4 months in java you can build in a month and a half using node js

[@DevOpsForDevelopers]

I kinda feel like I have. I've been using Node.js for about 8 years: egghead.io/courses/learn-the-fundamentals-of-node-js-for-beginners-7b6f4282 FWIW, I agree with you re: Java. Given the choice of Java or Node, I'd pick Node every single day as long as the application didn't need capabilities that only Java could provide.

[@thatsalot3577]

@@DevOpsForDevelopers 0:54 this says something else That's literally opposite of what async await it yeah if you have to await for a response from db to send it to the client or something but it doesn't mean that server is stuck while making that db call, it'll be able to execute any other function that's not awaiting for this particular call, how did you missed that with 8 years of experience ?

[@bahtiyarozdere9303]

Go with C#. Thank me later.

[@MonicaMoore-ju1he]

This is spot onnnnnnnnn

[@DevOpsForDevelopers]

👏

[@OmgImAlexis]

0:57 bruh.. you clearly have no idea how js works. 🤦‍♀️

[@stopPlannedObsolescence]

Have u ever heard about child process and clustering in Nodejs? got the solution for your vídeo

[@DevOpsForDevelopers]

That's one solution!

[@mauriciomdea]

1:42 couldn't agree more! 👏

[@DevOpsForDevelopers]

🎉

[@uxmetadata8477]

Has this video aged well? Or do most of you agree?

[@randomapperatus3773]

Honestly, I am a Django developer learning node and Express and I have to say it is much quicker to spin up an API using node and Express then using Django

[@DevOpsForDevelopers]

It's definitely quick to spin up. I'm curious to hear your feedback after supporting the same application for a few years.

[@Steviee77]

Just found this and like your explanation. With the little inaccuracy about async/nonblocking out of the way your reasoning still resonates with me.

[@DevOpsForDevelopers]

Fair point re: async/nonblocking. Thanks for commenting!