well done, man

Not in a million years anyone with a working brain who knows both typescript/js and python would ever choose python for any kind of backend server, it literally offers no benefit apart from the fact that you like writing python, as for node I'm not even going to argue with your understanding of how async code works, people in the comments have already explained it multiple times, I honestly find this argument pretty stupid that nodejs is worse backend than python, node litreally lets you do multithreading on c++ under the hood for all sorts of network calls and I/O operations. so you're never waiting, you're essentially saying "when it' done, execute the lines below" and until then the server is free to take requests.

ok, now Im nervous about this. I got an interview for a devops position coming up

Is node js secure?

Do you reply to the comments?

You don't understand what are you talking about.

I just discovered this video in my feed and was surprised by the thumbnail. After watching, I realized he misunderstood async/await in the worst way possible 😂. I had to rewrite a service from Spring Boot to Node last month for EDA. It’s possible to implement EDA with Spring Boot, but Node.js definitely has a better approach.

Try one and if you decide to change later then do it, don't overthink this........ It was all enough to stop my confusion♥️

Internet computer

This moron of an insight is still around. Pity who hires this moron

routing to the localhost on port 8888?

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 !

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

I hope you have learnt node.js asynchronous nature after 3 years

you have only little knowledge on node.js....in node.js there is a 'worker thread' which will do parallel processing. that only understand by few people. you are hater because,you worked on different technologies and then you found node.js as strange because of little knowledge

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.

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!

I was trying to respond politely to all misconceptions about node that you, in your video and others that commented here, seem to have. But the more I read your answers to comments the more I think you should reevaluate your statements and possibly update or take down this video, because I really think it can make a lot of damage to beginners. You say in the comments that your problem with async in node is the style not that is not performant. That's not what you say and imply in the video. The worst of it all is the title "node.js is the wrong choice for APIs" when it was actually designed to make API implementation both easier and performant. It makes so by allowing you to maintain your business logic in one single thread while delegating expensive asynchronous operations to the node binary and the operative system, processing other requests while it waits, and returning to the original context once the async operation has finished with the data you needed. You can do async operations in parallel with Promise.all. You can do sync calls to most if no all system functions if you don't want async. And most libraries provide sync versions of API functions when it makes sense. You can use workers if you want to micromanage different threads. I agree on the general statement that it's better to know many languages and technologies to be able to choose the right one for the job. I agree that saying node is better because you don't have to learn another language for the server is plain stupid. Javascript on the server is so different to javascript on the front-end that anyone saying it knows as little about back-end development as you seem to know about back-end development with node. Yes, node is often not the best solution for any project. But is good enough for most. Yes, javascript is not as easy and straight forward as it looks at first and has many potential traps for beginners specially if they were trained only in class-oriented languages. Yes, using node efficiently requires to understand the event loop and how node manages asynchronous calls. But equivalent deep knowledge needs to be acquired if you want to do concurrency or parallelism in any language and in most of them it's actually more difficult to do properly. And none of the flaws or dislikes you find in javascript is an excuse to spread misconceptions and put beginners against a technology that does its work well and is currently an industry standard. I say all of this with the utmost respect to someone that puts the time and effort to create compelling educational content, which is something I value a lot. So I sincerely hope you or anyone who expressed their agreement with you don't take this as an offense.

The 1 million dollar question is: How many programming languages should be learned to secure a devops position? Is Node JS enough?

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.

Nice Clickbait!

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

Once upon a time like 30 years ago when I stared with COBOL on the mainframe I was in the Operations Room putting up my own tapes, cartridges and printer paper for reports. I also responded to the Operations monitor to start jobs. The Computer Operator on duty was too busy for some Jr. App Developer so I had to learn. For years Operations interactions was a way of life. Then I got into web development and APIs and Operations did something while I code and pushed my code to the github repository. Well often in life we swing back around to original ideas but with modifications. So now its less clear. What do you need me for? Write Jenkins scripts, do health checks or just respond when there is a crash to determine who should follow up and who should go back to their development task. So I'm here doing this deep dive to get a better idea of the details so that when I go back to work I'll have a better perspective.

Notice he works from home. Run it like your own business. The only way you can own the work.

4:17 to develop api, you reconnected rubyOnRails, python which is also not really multithreaded, go has go routines and wait groups which are like async await. don't give wrong advice to people

Love this

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

Does that save on memory? Are the zeroed stored or just ignored. Also, how does it work does it create pointers?

Nodejs is not framework, it is a platform!

Only reason I wouldn't use JavaScript/TypeScript is because it isn't as fast as Go or Rust, otherwise you're wrong.

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

00:32 node js is not a framework it is a run time env. Express.js is a node framework.

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

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

really find it amazing when some random guy actually believes he knows more than someone who developed a framework used for backend applications by Google, Meta, and other big techs. It's a prime example of the Dunning-Kruger effect.

Difficult to see this.

Sorry you're way off base here with async await. Data integrity is the major issue with JavaScript as the backend.

Why don't you create an entire DevOps course? I like your tutorials simple but powerful. That's what I need to be in DevOps

you are the best and you don't know it!

Why do you have to wait for async transactions? My man, you don't need to wait. The trick is, you can have multiple I/Os tasks running at the same time, because event loop will handle everything for you. And as it is I/O bound applications, this is not going to fill up your processor time. Probably you are going to use some RAM, but this is not a problem, because the runtime is capable of dealing with a threshold and the amount of availble RAM. Man, again, why do you need more then one thread to deal with so simple I/O task such as a DB query? Makes no sense. You are going to over use your system for nothing. Let's face the truth, even though I found JS and TS crappy languages, the node.js architecture is simply enough for simple applications.

One suggestion: The channel name & video description is overlapping with the output part of your video. Maybe consider reducing the height of you code editor next time so that output comes up?

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

this man should be selling ice cream on the street

Hello sir! how some one can talk to you pls?

What makes mentioning an example with ORM in NodeJS? ORMs are different. And in any framework, they are all evil for performance. I was using .Net EntityFramework from Microsoft - and EF was extremely slow, so I decided to use NHibernate. NH was better, but still slow. Both of them are running in a multithreaded environment in .Net C#. ORMs are evil [for performance] by their nature. Any framework in any environment. NodeJS has pros and cons of course, but telling things, which are common for any framework - is bad. I believe, the ORM mentioned in this video was "Prisma" (ORM framework for NodeJS). Prisma - is the worst case, in terms of performance for NodeJS. If you are reading this comment and wondering - if ORMs are bad, what should I use? - NOTHING! Write PLAIN SQL QUERIES. Or, if conditions don't allow you to write plain SQL queries - use Query Builders. There are plenty of them. For Node I use Knex or Kysely

shut up boomer

I agree golang is cool.

dude never heard of event loop

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.

It's 2024 and this is what I think: 1. NodeJS is High-level and you can write low level code which forces you to understand stuff 2. Rubby, GO, Python... they all support the asynchronous stuff it's just not mandatory 3. Rubby, GO, Python are High level code, very high level code, very clean I agree... but where's the flexibility, NodeJS on the other hand forces you to still understand a layer/half layer lower into the code... There has to be a balance you can't just do high level stuff, the higher the better? NO! the lower the better? NO! We are devs at the end of the day, neither we want to be speaking Machine code 0101010101 neither we wan't to build code like puzzle pieces like some Tinkercad kid, learning to code using dragabble puzzle like cards to code a damn Backend!!!! Just read a bit more and try to understand it only then you will find out why it is indeed the ritght tool for the Job. ⚠Lightness Tierlist, here the winner isn't the best choice it's just the lightest⚠: S - [GO(It can go to many places fast but can't enjoy them due to how fast it is), RUST(Flexible like C, no community, boring, yeah C-Level speeds, I'm sure you have to understand low level code here too)] A - [NodeJS(V8 on the road and offroad = freedom, nothing like the sound/power of a V8 and it's still damn fast, F1s used to have a V8 too), Elixir(Boring and pretty still fast) ] B - [Python Flask(Literally the mid tear not bad not good), Rubby Sinatra(I though they were white hats, nope a music label, nope a Rubby framework that's better than Ruby on Rails? that's impressive)] C - [PHP(Dumbo), C#(double-edged sword... a sharp one)] D - Java (This is older than Dumbo) F - [Ruby on Rails(If someone told you he once went to do ofroading with Ruby, it means he derailed), Python Django(Why is this still alive having Flask, just stop using it)] Here are some real world examples of right tool for the job: 1. Build something stable scalable or anything NodeJS is the right tool for APIs 2. More than 40% of the active dynamic websites needing manainance PHP is the right tool for those APIs (the other 30% are some legacy PHP sht sites that are used to just display text or are just weird forums that if you touch they explode literally, or some TOR Deep Web hosted from a cave) 3. Few developers, few competition = high salary Ruby on Rails is the tool for the right job... ups I derailed mentally Depending on how fast you adapt learning to efficiently code in a programming language you will be able to master any of these to build an API, but very often NodeJS due to it's huge Package Library will provide you with everything you need. And last but not least in 2012 a company launched Meteor it's the solution to what you're complaining in your video, try it and come back, it saves you the part of having to specify async, await, promises and all that stuff in NodeJS, again like I said very often you find solutions from the NPM