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.
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.
@@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).
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?
@@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
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.
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
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.
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.
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.
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.
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
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
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.
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.
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?
"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
"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.
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
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
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!
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.
@@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
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).
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
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.
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.
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.
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
I love the async library, I use the 'auto' method when I want to collect data from the database or files, etc. I can do all sorts of things while waiting for a database query!
0:48 So I often have the case in everyday life that I can let one or the other load in parallel or certain tasks do not necessarily have to be processed directly one after the other. But the asynchronous not only has an effect on the current request, but also on parallel requests. You have to see this as a whole, not on the basis of "one pass" of the code for a request.
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
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!
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
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.
@@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.
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.
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.
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?
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.
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
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.
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.
@@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.
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
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.
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!
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.
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.
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.
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.
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.
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.
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!
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.
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.
@@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
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
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.
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.
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.
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!
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.
More complexity is not equal to wrong choice and I like the idea to master javascript because I can do everything and then I will learn SQL, python, c++, rust and I will be more proficient with them because I know everything of how to use a lenguage so I can apply any context in other logic
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.
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 😁
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
Coming from Django land and having been forced to be used Express in one of my latest projects, gave me a run for my money. There is no default ORM, the Prisma is just a definition & retrieve/write tool, with no class-based approach. Why write async await in the first place if you need to wait for every other line to complete its execution.
You only need an ORM if you're using a sql db. Express allows you to choose. Most frameworks are like this. This is like saying why can't I ride a normal bicycle but have my fairy wheels attached.
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.
I would not choose Java unless the application needed the level of performance that only Java can give. But, with that said, I also consider the team I'm working with. If my team consists of engineers with tons of Java experience and expertise, we're using Java.
I am a dedicated JavaScript developer, frequently using Node.js , Nest Js and React for my projects. However, I wholeheartedly agree with your thoughts.
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.
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?
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...
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.
I think node js is overhyped back to those days and ppl just use it to follow the trend and ignore the drawbacks. I did learn to use it cuz my manager and boss decided to follow the trend but they didn't really care if it's right or wrong or if it's pain(extra work) of using it since they're not the ones to do the code. lol.
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
I would say the best languages for the backend in order are C#, GO, Java, and Python. the feature C#, GO and Java have is that they are strictly typed without any extra shenanigans which is very important because why on earth would you want a backend application not to be strictly typed. python is last because while you can have types in Python the way it's implemented sucks so unless you are doing a data-oriented application you are really better off using any other language. any Node.js application I have ever written I have ended up rewriting because once the code base gets big enough it turns into a pile of garbage with no enforced structure that makes sense. the async nature of it is also almost useless in a backend application because 99% of the time you async-await the callbacks so the feature is not really useful when you are building a backend server.
python and go, the best on the backend? bruh. PHP is the best, deployment is not an issue, while you need a dedicated VPS for Go and Python. Also limited ecosystem compared to PHP-Laravel or C#
well, there are "service workers" which run in separated threats, and do many operations at once. it's been 2 years since you posted this video, maybe back then you did not know about this feature lol.
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! 👍
Tbf you're right. APIs are hardly read from db and vomit in the page. Add few calculations and business validations here and there, you're heading for a big mess up with node. Single threaded is better for front end - exactly the reason why we moved away from server side frameworks. Imagining services will always be simple read and write is not good system design.
I don't really understand why having a callback is necessarily a bad thing. I believe you should have spent some time to explain why you see picking node as bad. I have my bone to pick with node, but so far I've seen it used in many scenarios without big issues and it was picked over some of your recommendations due to its advantages. Sure, it may not be fit for everyone and there are faster alternatives, but most workloads are doing just fine on it. This video sounds to me more like complaining about the reasons why people pick it if anything else.
I disagree, his points were very clear to me. I have the same complaints actually. You can definitely tell you are using a language designed for clients to build your server code compared to Rails or Django where it feels very clean. My first impression of Node is that "JavaScript wasn't meant for this"
Thanks for sharing your thoughts. I personally worked with GO and C# and to this date .NET Core especially +6 is much more mature and organised than GO. Great SOC architecture. Its performance is going to be Native with AOT Native in version 8. Give it a try.
"Its performance is going to be Native with AOT Native in version 8." this is just promises from their marketing bs) I heard it a lot like this in othere languages. No one ever reached it so far. U can claim that only when it is actually there and widely adopted.
@@artemsokolov5007 It already exists in .Net 8 Preview. Most other languages don't have a billion dollar company like Microsoft behind them. It's been over 20 years that C# is getting evolved with newer techs not a new thing.
I have used Go, NET Core, Java Spring Boot, Python Django/Flask and NodeJS. I think NodeJS and NET Core are the top 2 choices for a back-end option. These 2 are the best in performance (NET Core is better than NodeJS while Java is much slower and requires more memory). Writing Go is like using an old car, there is only one way of doing things therefore it is easy to read pre-written code but it gets boring really quick. Java is memory hog. Python is actually a very good language and I like it very much. Its syntax is well structured to the point of being a bit obsessive. It is also lingua franca in Machine Learning / AI field. Therefore, if your project is about Machine Learning and AI, then you can then use one of the Python back-end frameworks to use 1 language for 2 things (back-end services and AI modules) similar to using only JS language in NodeJS and a front-end JS framework (like React, Angular and Svelte). NET Core is really the best nowadays. You can do all things in C# such as web programming, back-end services, game development, ML/AI, mobile develoment (using Avalonia UI and MAUI), database develoment (using Entity Framework) etc etc. Also it is really robust, scalable and easy on resources. What I do not like about NodeJS is that I think it lacks a bit in the ORM area and it really needs to be written with TypeScript (instead of JS) because TS makes the code much more readable. Other than that, it gives real time performance, easy to learn and develop. The development time decreases a lot with both NodeJS and NET Core.
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.
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.
Maybe. Depends on what the code is doing. The key thing is the programming language is not the bottleneck for the applications that most of us work on. If you're building Google Search, sure: it matters. For the rest of us, not so much.
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.
Great points!
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
very interesting comment
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.
@@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).
Async/await is largely WHY nodejs is the RIGHT choice for RestAPI's.
This!!
Could you provide a practical example?
totally agreed
yeah
No, it does not fix nodejs core problems for “fast” apis
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?
Go is cool but you still have to do insane to want to be writing Go code all day.
@@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
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.
Can I ask what you prefer instead?
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
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.
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.
You've heard of the pyscript tag which allows you to use python instead of JavaScript for the frontend?
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.
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.
Oh my! You’re understanding of “async” is really bad!!!!!
Lol. Maybe. Care to explain?
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
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
@@aimableruhumuriza8603 fair point! Thanks for commenting!
@@tesla1772spot on. Dude thinks “await” blocks everything… oh my.
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.
For sure. It’s not the implementation that bugs me, it’s the way I have to interact with it
you can typescript or jsdoc to ease your debugging
plus you can also do multithreading with node.js using worker thread which is easy to be achieved.
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.
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?
"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
@@airaction6423Not true. Have you ever tried Promise.all or calling async functions without await keyword?
"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.
That's definitely a redicilous video
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
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
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!
if you really believe this, you are a mediocre developer.
@@xxapoloxx yep, thanks for the opinion no one asked
@@phamlong4210 Yet most people hold it.
@@xxapoloxx I'm sure they do, how many like did that opinion get btw? Yes, exactly my point
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.
Right on. I appreciate the thoughtful, detailed response! You make some great points.
C# had this Async/Await long before JavaScript.
@@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
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).
Rust? It's a mid level programming language same as C++. AFAIK Deno - a successor to Node was built using Rust.
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
Agreed 💯 🤣
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.
Fair point!
What about spring boot, hibernate and all ?? Something related with java?
It depends on your goal, whether you need a quick build REST API or whether you need a complete algorithmic task.
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.
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.
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
I love the async library, I use the 'auto' method when I want to collect data from the database or files, etc. I can do all sorts of things while waiting for a database query!
Lot's of people do! 🤣
I love your intro and the way to put it with two wrappers
0:48 So I often have the case in everyday life that I can let one or the other load in parallel or certain tasks do not necessarily have to be processed directly one after the other. But the asynchronous not only has an effect on the current request, but also on parallel requests. You have to see this as a whole, not on the basis of "one pass" of the code for a request.
In that scenario, it makes perfect sense. In sequential workflows it feels like extra work (IMO)
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
Right on. I’ve not used neo4j. Glad to hear it’s working for you and will check it out. Thanks for sharing!
you just didn't push it hard enough.
maybe you just have a couple of concurrent users
So... In you understanding async operations blocking a whole thread, till operation will be completed?
My complaint isn't about the technical implementation.
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!
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
All true. Still doesn't make me a fan of the JS implementation though 🤣
@@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?
I love the mixture of nodeJs and PHP. Nodejs for async jobs and PHP for delivering the results
hey so any one out there can ler me know that is C # is a better choice then node js
if yes please please reply why
What's your take on php?
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.
True. My point is more about the implementation, not async itself.
@@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.
@@tarkgundogdu8940async/await first came in C# btw later got introduced to js
You had really good points!!!!!
Right on, thanks Jesse!
He really didn’t. 😂 He was largely wrong about everything he discussed. Some serious Jr. Dev energy right here.
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.
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.
Hi Will how are you? nice to see your contents about development. Just subscribed!
0:47 what do you mean. It is async call. While db quiry works.. your code proceeds. It does not wait
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?
Lol. Testify! 🤣
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.
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
The built-in hrtime is way old and a unit-test framework and runners were added in v18 (after this video published)..
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.
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.
@@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.
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
I do software engineering for a federal airline that uses node.js on the backend for APIs idk if I’d trust this.
Ack.
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
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.
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!
@@DevOpsForDevelopers thank you for replying!
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.
👏
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.
Yeah, for sure. Probably true for any language: we try to fit the new stuff into boxes we are already comfortable with
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.
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.
One good reason for using JavaScript (TypeScript to be more precise) on the back end is if you are going to use tRPC.
is tRPC even necessary?
Yes i totally agree, Ruby, Fortran and even Pascal are another good ones that you missed in your list.
🤣👏👏👏
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.
Once you said that you have nothing to do while waiting for a database query I knew your not an expert
great video!
Glad you enjoyed it!
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.
Just found this and like your explanation. With the little inaccuracy about async/nonblocking out of the way your reasoning still resonates with me.
Fair point re: async/nonblocking. Thanks for commenting!
i have one question would you use - MERN Stack or React with Lamp stack
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
React with lamp stack. Having a separate code is always good
May I add PHP
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!
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.
Right on, thanks for sharing your thoughts!
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.
@@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
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
Thank you
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.
Do you know js is more performant than python,
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.
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.
It’s fine not to like nodejs for backend, but from your words I feel like your understanding of async is totally wrong
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!
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.
More complexity is not equal to wrong choice and I like the idea to master javascript because I can do everything and then I will learn SQL, python, c++, rust and I will be more proficient with them because I know everything of how to use a lenguage so I can apply any context in other logic
Those are great personal reasons, but may not be true for the business.
what about using Dotnet Core as in for API , as also we use Async await in Dotnet Core web api, what is your take on this?
I'm not familiar with Dotnet Core. I'm also not against async, it's a good tool. My point is implementation trade-offs from choosing a particular tool
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.
that's not my point, but thanks for sharing!
besides the mentioned Go pros there's one more: built-in concurrency
Great point!
as long as it gets the job done, doesn't really matter what tool you use...
Absolutely!
What about Spring Boot?
I haven’t written enough code with it to have a valid opinion.
Such a soft spoken person... and then that fucking intro blows my ears
🤣🤣🔊🔈🔊🔈
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 😁
"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.
I agree 100%. In 30 years of programming I never needed async stuff to happen in the backend
This is spot onnnnnnnnn
👏
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
Totally agree.
Coming from Django land and having been forced to be used Express in one of my latest projects, gave me a run for my money.
There is no default ORM, the Prisma is just a definition & retrieve/write tool, with no class-based approach.
Why write async await in the first place if you need to wait for every other line to complete its execution.
Agreed 100%!
You only need an ORM if you're using a sql db. Express allows you to choose. Most frameworks are like this. This is like saying why can't I ride a normal bicycle but have my fairy wheels attached.
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.
So right!
👏
What about Java as backend?
I would not choose Java unless the application needed the level of performance that only Java can give. But, with that said, I also consider the team I'm working with. If my team consists of engineers with tons of Java experience and expertise, we're using Java.
I am a dedicated JavaScript developer, frequently using Node.js , Nest Js and React for my projects. However, I wholeheartedly agree with your thoughts.
Thanks for sharing! I’ve used Node.js a lot, and will do so again in the future when it fits the requirements
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.
If you're a js dev, you should know that his info on async is completely backwards
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?
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...
I am also waiting for bun to reach v1.0 so excited for it!
I haven't checked out bun. Might be worth a visit.
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.
c.mu.Lock()
defer c.mu.Unlock()
fmt.PrintF("That's fair")
nodejs perfect for backend web api with express library. Very stable, fast, simple and u can combine with nodejs cluster
I think node js is overhyped back to those days and ppl just use it to follow the trend and ignore the drawbacks. I did learn to use it cuz my manager and boss decided to follow the trend but they didn't really care if it's right or wrong or if it's pain(extra work) of using it since they're not the ones to do the code. lol.
Yeah. In some cases I think it falls into the "if all you have is a hammer, everything looks like a nail" category
Elixir?
Never used it personally. Seems to have a large following though
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
I would say the best languages for the backend in order are C#, GO, Java, and Python. the feature C#, GO and Java have is that they are strictly typed without any extra shenanigans which is very important because why on earth would you want a backend application not to be strictly typed. python is last because while you can have types in Python the way it's implemented sucks so unless you are doing a data-oriented application you are really better off using any other language.
any Node.js application I have ever written I have ended up rewriting because once the code base gets big enough it turns into a pile of garbage with no enforced structure that makes sense. the async nature of it is also almost useless in a backend application because 99% of the time you async-await the callbacks so the feature is not really useful when you are building a backend server.
I haven't used C# in a long time, but know a lot of people who 100% agree with you on that.
python and go, the best on the backend? bruh. PHP is the best, deployment is not an issue, while you need a dedicated VPS for Go and Python. Also limited ecosystem compared to PHP-Laravel or C#
well, there are "service workers" which run in separated threats, and do many operations at once. it's been 2 years since you posted this video, maybe back then you did not know about this feature lol.
True story.
What about Deno ?
Haven't used it, so can't comment on it.
after 2 years now still node is the go-to for all of us xd
I can't argue that. 🤣
It's true that is a wrong choice if we looking from PHP, Ruby dev perspective. But the idea of async/await is "the why" I'm choosing Nodejs over Java
1:42 couldn't agree more! 👏
🎉
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! 👍
Agree
👏👏👏👏
Tbf you're right. APIs are hardly read from db and vomit in the page. Add few calculations and business validations here and there, you're heading for a big mess up with node.
Single threaded is better for front end - exactly the reason why we moved away from server side frameworks. Imagining services will always be simple read and write is not good system design.
I don't really understand why having a callback is necessarily a bad thing. I believe you should have spent some time to explain why you see picking node as bad. I have my bone to pick with node, but so far I've seen it used in many scenarios without big issues and it was picked over some of your recommendations due to its advantages. Sure, it may not be fit for everyone and there are faster alternatives, but most workloads are doing just fine on it.
This video sounds to me more like complaining about the reasons why people pick it if anything else.
Fair point, and I agree: it has been used successfully in many scenarios by many people (including me).
I disagree, his points were very clear to me. I have the same complaints actually. You can definitely tell you are using a language designed for clients to build your server code compared to Rails or Django where it feels very clean. My first impression of Node is that "JavaScript wasn't meant for this"
Thanks for sharing your thoughts. I personally worked with GO and C# and to this date .NET Core especially +6 is much more mature and organised than GO. Great SOC architecture. Its performance is going to be Native with AOT Native in version 8. Give it a try.
The C# comments keep coming!!! I'm going to have to check it out 🤣
"Its performance is going to be Native with AOT Native in version 8." this is just promises from their marketing bs) I heard it a lot like this in othere languages. No one ever reached it so far. U can claim that only when it is actually there and widely adopted.
@@artemsokolov5007 It already exists in .Net 8 Preview. Most other languages don't have a billion dollar company like Microsoft behind them. It's been over 20 years that C# is getting evolved with newer techs not a new thing.
I have used Go, NET Core, Java Spring Boot, Python Django/Flask and NodeJS. I think NodeJS and NET Core are the top 2 choices for a back-end option. These 2 are the best in performance (NET Core is better than NodeJS while Java is much slower and requires more memory).
Writing Go is like using an old car, there is only one way of doing things therefore it is easy to read pre-written code but it gets boring really quick.
Java is memory hog.
Python is actually a very good language and I like it very much. Its syntax is well structured to the point of being a bit obsessive. It is also lingua franca in Machine Learning / AI field. Therefore, if your project is about Machine Learning and AI, then you can then use one of the Python back-end frameworks to use 1 language for 2 things (back-end services and AI modules) similar to using only JS language in NodeJS and a front-end JS framework (like React, Angular and Svelte).
NET Core is really the best nowadays. You can do all things in C# such as web programming, back-end services, game development, ML/AI, mobile develoment (using Avalonia UI and MAUI), database develoment (using Entity Framework) etc etc. Also it is really robust, scalable and easy on resources.
What I do not like about NodeJS is that I think it lacks a bit in the ORM area and it really needs to be written with TypeScript (instead of JS) because TS makes the code much more readable. Other than that, it gives real time performance, easy to learn and develop. The development time decreases a lot with both NodeJS and NET Core.
I would use golang for 99% of backend work. I may pick python but only for machine learning requirement.
Nice!
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.
Have u ever heard about child process and clustering in Nodejs? got the solution for your vídeo
That's one solution!
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.
i dont know if its just me but python flask is slower than express js
Maybe. Depends on what the code is doing. The key thing is the programming language is not the bottleneck for the applications that most of us work on. If you're building Google Search, sure: it matters. For the rest of us, not so much.