The lagging in the first 2 minutes is part of the demonstration of single threaded model and totally not because I had docker running on the background with 10 large postgres instances. 😝
I wanna add one thing. Event loop is not the one that executes functions on the call stack. That is done by javascript engine. Event loop monitors the call stack and event queue. when the call stack is empty it looks for the event in event queue, if found executes the associated callback which will be added to the call stack.
Exactly , I was wondering for few seconds like did I learn the Javascript wrong since beginning 😂 then I realised by event loop he meant the main thread which is the v8 engine. Yeah event loop is the one which monitors the stack and passes on the callbacks
Great content man! The clusterization part is very interesting for me, and the clarification about the UV lib is gonna be of very much help! Keep doing great videos as such.
With great content coming one after another, I was expecting some kind of illustrations that you do via the presentation of gliffy. That clears out the real deal with the event loop. Great content as always. 👍🙌
Nice vid, though forgot to mention another major use case where node uses it's threadpool - submitting new requests into the event queue (as callbacks). Not executing it, just submitting it becauss the main thread can be busy.
Interesting thanks , I have missed that in the doc “For the sake of completeness, we note that when you call one of these APIs from a callback on the Event Loop, the Event Loop pays some minor setup costs as it enters the Node.js C++ bindings for that API and submits a task to the Worker Pool. These costs are negligible compared to the overall cost of the task, which is why the Event Loop is offloading it. When submitting one of these tasks to the Worker Pool, Node.js provides a pointer to the corresponding C++ function in the Node.js C++ bindings.” nodejs.org/en/docs/guides/dont-block-the-event-loop/
There are actually so many ways, before that you need to answer what environment are you using docker-compose, docker-swarm or Kubernetes or running directly on a linux server. Major differences between cluster and worker 1. Cluster spawns multiple processes which may create memory issues but is great if you have a HTTP server sharing the same port ( Nodejs main process multiplexes it in the child processes) 2. Worker Threads will work on same process but spawn new threads, the threads share memory. This is great for CPU intensive tasks, file accessing. We use Worker Threads for Consumers in Pub-Sub Environment, where each thread may run a consumer. How to Scale: 1. Docker-compose,Docker-Swarm, Kubernetes :- For this I would recommend creating a single app instance without any threads or processes. Instead just create one app and scale it horizontally by spawning more containers. 2. Running on a Linux Server Directly :- i) For this I would recommend using Cluster or Worker Threads (Based on what task you are going to run eg: HTTP Server(Cluster), CPU Tasks(Worker Threads)) ii) I highly recommend using PM2 instead of Cluster as it will give you a nice way to get logs scale-in and scale out the app when running in cluster mode. If you have any suggestions or corrections please do let me know.
Can you please these quick questions and clear the confusion? 1. Is Event Loop single threaded or due to one call stack, Node.js is threaded? 2. Isn't the purpose of Event Loop just to check whether the call stack is empty or not and bring instructions from queues to call stack? Or there is more to it? 3. Is event loop implemented in a different way in browser and node.js? 4. When we send network request or use setTimeout, does the Web API container spawns new threads for these operations? For e.g. there is an API call in the code. The call gets out of Call stack and goes to Web API container. When it completes, it comes to Callback/Priority Queue and from there it comes back to Call Stack when Call Stack is empty. But what happens in Web API container? Does it spawns a new thread for network request and setTimeout? What happens there exactly?
You didn't mention when and how an async i/o request is handed off to I/O pool and how the callback works between 2 different threads. Are you really sure creation and dispatch of TCP packets is done by a main loop thread?
Hey Hussein big fan of yours, I request you to please order the content in each of your playlist so a novice like me can know where to start from and what's the sequence
So nodejs uses a pool of worker threads for two particular reasons. The first is to perform CPU intensive tasks (like crypto). The second is to handle some types of asynchronous I/O, like filesystem I/O or DNS querying, because back when libuv was implemented some OSs did not provide asynchronous I/O interfaces for those, so the worker thread in this case really blocks on the I/O task, and a callback is registered to be executed on the main thread, am I right?
thank you for this video could you do a video to compare and explain coroutines vs event loop? and why there is a saying that coroutines handle async better than event loop or vice versa? why for example google developed a language (go) with coroutines (goroutines) and not an event loop? because to me, event loop handles async much more efficiently and as you said in the video, it could run on multi-core systems with clustering.
hi hussein, i really liked your video, but still i have a confusion, i really hope you will reply to this , from what i understood till now, i think for database i/o promises and some node apis like 'fs', 'crypto' , nodejs will create a worker thread so that main thread is not disturbed ( i am not sure though ), but what about the custom promises i create in my node app, will these promises execute in main thread or nodejs automatically spawns worker thread for all promises in the app, your response is very much appreciated, thank you 🙏
All promises/async await execute on the main thread including database queries from db clients, (unless specified otherwise by the client author) the database query is nothing but a network call which we established that it runs on the main thread. As a rule of thumb, if its not crypto, DNS, or io file read (directly to machine node is on) then it runs on the main thread. That being said If you used a third party npm package those might utilize threading so you need to read their doc. Stripe payment comes to mind Thanks, good question
6:50 How does synchronously reading file go to or use the event loop when event loop is a non blocking whereas synchronously means blocking? Doesnt sync reading stay on the main thread and complete the reading ? What am I getting wrong here?
What happens if I use all the cores with forks and then I use fs.readFile which is using 4 cores and what happens if I use fs.readFile in one of the forks? Do I run out of cores?
1. Why - Node.js primary purpose is to run JS. File system ops are usually handled by the OS. To avoid blocking JS code execution, Node.js creates a separate thread for file ops. Using a single thread would have blocked the app. 2. I think #1 answers you're question.
1. No. A non-master cluster doesn't have the fork function available to it. A script starts as the master cluster by default - i.e. master is created by the Node.js (we don't write code for it). This means that there can never be multiple masters. So - single master and clusters, that's it. 2. If you mean different Node.js processes, yes it'll work, since processes are isolated from each other.
@@joshuaifara2736 True he did make on http, but I actually want him to discuss about some other popular protocols as well, that might be useful in different scenarios
Putting nodejs in a container and using cluster has no difference than placing it in a VM (well maybe if you put many containers are sidecars to the main node process but haven’t tested that) , In both cases there will be multiple processes. If you want to leverage the container orchestration you can spin up multiple containers each has a nodejs process and then use a reverse proxy / LB to distribute requests to those node containers.
Not quite, I would dare to say not actually. Network calls, file system tasks, DNS lookup, etc. are actually not handled by the main thread(NodeJs itself) and are instead written in C/C++, witch are themselves multithreaded(that's where libuv enters the show). JavaScript itself remains single-threaded. The issue of having a full JS code(without underlaying C/C++) witch is CPU intensive blocking your whole nodeJs instance persists. You will still have to work around it with things like worker_threads. That's just the way it is. As Alberto Gimeno points out on his blog on LogRocket, it is not a question of someone adding a new module in the NodeJs core and allow us to create and sync threads. If we add threads, then we are changing the nature of the language. We cannot just add threads as a new set of classes or functions available. We need to change the language. And change it without breaking it. I don't know, to be quite honest, if that's possible with JS, someone else may jump in and fill this gap for me, that would be great and add weight to the discussion. Let's take C# for instance, Java, and most versions of C++, they were designed with threads in mind from the get go, therefore they all have all of the facilities to handle them built in since their inceptions, not the case with JS. I remember while ago, like more than 10 years, a simple alert() in the browser was enough to block anything ajax you were doing in the background. It seems that all this time has passed and the 'single-thredeadness' is still there, still a single call stack, so it may be quite difficult to get rid of it without breaking some stuff. Relying on C/C++ bindings/wrappers taking advantages of libuv for everything you need to do in nodeJs is not sustainable on the long run. And finally I would just like to point out that I'm not a frond-end guy and my knowledge of JS is limited to the bare minimum I need to know. I gave up on frontends while ago and focused myself on the backend only. I've been just very curious about nodeJs for a few weeks and started learning about the technology before trying to learn the language itself.
@@jefersonnl You lengthy argument is useless except when you said "We cannot just add threads as a new set of classes or functions available. We need to change the language." And even here you didn't support this alleged "need" with any argument. So no, you can add threads without a problem and end up with performance that matches compiled languages. Side note: libuv was designed for Node only, then used by others. Another side note: the Majority of backend developers around the world are Node developers, and they are backend developers only. This means JS is a backend language with excellence, not a "quick fix" in the backend for those coming from frontend background.
@@alithejumbo My bad if I went too technical or went down deep in low level stuff unnecessarily, with the risk of doing it again. What Gimeno meant with that was, we do not need to change the language, rather, a big change *would be needed* to make JS multithreaded, if one wished so. Since you seem to believe all the rest is useless, there's apparently no point in repeating what wasn't understood here. As Hussein always is point out to us, do not fall in love with a technology. Just understand what it is good for and what it is not good for. For instance, NodeJs will shine very bright in IO-intensive environments, no doubt about that, however it still has its shortcomings when CPU intensive jobs are regarded. And if you have a lot of CPU intensive jobs going on, and a lot of CPU cores to work with, you will need to take care of the complexity yourself with worker_threads and clusters, something other languages will just give to you out of the box, even PHP with the veteran HTTPd will give you that from the get go(though at the cost of several threads and processes and the dreaded context switchings). It's important to understand how things go under the hood, and sometimes take a look at what one's neighbor is doing, otherwise one can break one's heart when another language comes out with new features like virtual threads, fibers, transparent user space threads or light weighted threads like goroutines. All that we must avoid in the tech industry is to become close-minded and entrenched in our neck of the woods . This is why I started investigating NodeJs in the first place.
@@jefersonnl I went through your replies again to figure if I've missed anything . See, I write in Golang too, and I know how "better" than Node it is. But an easy Goroutine and Channel functionality doesn't outweigh the practicality and quick delivery of Node. At the end of the day 95% of the needs of any cloud server can be easily met with Node. So I won't nag much about the fact that Node's multithread-ability is on high level. It just works.
@@alithejumbo Yes, everything seems to be centered around quick delivery nowadays. So Node will shine there. Also 95% of the needs of any cloud server (maybe not 95%, maybe a little less, but still above 80%), is centered around IO, "query this, give me back that, save this, delete that, retrieve that, put that on a queue, fetch that from so and so", and so on. Node will certainly shine quite bright in such environments as well. And when hiring separated frontend and backend developers could become expensive, having one programing language ruling them all becomes very attractive, especially in a startup environment. I can see when and where it works. How will we deal with some immaturities of JS? Only time will tell. PHP began as something very immature with a lot of issues and hacks, even so, it took the web by storm, and only them it mature into something like PHP 7/8.
it should be - process.env.UV_THREADPOOL_SIZE = OS.cpus().length; it works with hyperthreading as well. Setting any number greater than logical/physical cores count will not make any sense.
The lagging in the first 2 minutes is part of the demonstration of single threaded model and totally not because I had docker running on the background with 10 large postgres instances. 😝
😝 I refreshed my page 3 times.
Getting a play button from recoding videos from laptop webcam is very impressive.
Thanks for pinning this comment. I was about to restart my mac. :/
@@abhijiths148 kkkkk
i seriously started relaunched browser twice
I wanna add one thing.
Event loop is not the one that executes functions on the call stack. That is done by javascript engine. Event loop monitors the call stack and event queue. when the call stack is empty it looks for the event in event queue, if found executes the associated callback which will be added to the call stack.
thanks for the clarification
Exactly , I was wondering for few seconds like did I learn the Javascript wrong since beginning 😂 then I realised by event loop he meant the main thread which is the v8 engine. Yeah event loop is the one which monitors the stack and passes on the callbacks
goddamn this is the clearest and most concise explanation of nodeJs event loop and scaling
Am I the only one for whom the video feels choppy, like a lot
EDIT: Just for the first 2 minutes
Same
Same from my side as well
I restarted my phone twice 😂😂😂
@@bibekjoshi3522 i was also planning the same, but checked other video that was working fine, so i skipped my plan 🤣😂😂
after downloading i came back to youtube to confirm quality
Great content man! The clusterization part is very interesting for me, and the clarification about the UV lib is gonna be of very much help! Keep doing great videos as such.
🙏 glad it helped!
This was the best video I watched on youtube regarding Nodejs and threading. Thank you so much!
Amazing content Hussein ! Learning so much from this one single video !
very detailed explanations, really hard to find these days. Keep making these kind of videos. Really appreciate it
top learning:
1. Synchronous Operations - Go into Main Thread
2. Asynchronous Operations - Go into Thread Pool
Hussein, your camera seems to be running on single thread, video is little choppy 😄
But still, great content as usual
Edit - Just the first 2 minutes
i thought my windows is working slow😂😂
With great content coming one after another, I was expecting some kind of illustrations that you do via the presentation of gliffy. That clears out the real deal with the event loop. Great content as always. 👍🙌
Thanks! I try to add graphics when I can its just consumes so much time and I only have an hour or two a day to make content.
@@hnasr no worries. I'm glad that you're enjoying your parenthood. 🤗
Can you make video discussing node event loop and each of it's phases.
Nice vid, though forgot to mention another major use case where node uses it's threadpool - submitting new requests into the event queue (as callbacks). Not executing it, just submitting it becauss the main thread can be busy.
Interesting thanks , I have missed that in the doc
“For the sake of completeness, we note that when you call one of these APIs from a callback on the Event Loop, the Event Loop pays some minor setup costs as it enters the Node.js C++ bindings for that API and submits a task to the Worker Pool. These costs are negligible compared to the overall cost of the task, which is why the Event Loop is offloading it. When submitting one of these tasks to the Worker Pool, Node.js provides a pointer to the corresponding C++ function in the Node.js C++ bindings.”
nodejs.org/en/docs/guides/dont-block-the-event-loop/
Learned a lot. Please don't stop making awesome content.
Which one should we use for scaling nodejs app cluster module or worker thread?
Good question, I would love to follow this comment if youtube has a feature for it..
Good question.
There are actually so many ways, before that you need to answer what environment are you using docker-compose, docker-swarm or Kubernetes or running directly on a linux server.
Major differences between cluster and worker
1. Cluster spawns multiple processes which may create memory issues but is great if you have a HTTP server sharing the same port ( Nodejs main process multiplexes it in the child processes)
2. Worker Threads will work on same process but spawn new threads, the threads share memory. This is great for CPU intensive tasks, file accessing. We use Worker Threads for Consumers in Pub-Sub Environment, where each thread may run a consumer.
How to Scale:
1. Docker-compose,Docker-Swarm, Kubernetes :- For this I would recommend creating a single app instance without any threads or processes. Instead just create one app and scale it horizontally by spawning more containers.
2. Running on a Linux Server Directly :-
i) For this I would recommend using Cluster or Worker Threads (Based on what task you are going to run eg: HTTP Server(Cluster), CPU Tasks(Worker Threads))
ii) I highly recommend using PM2 instead of Cluster as it will give you a nice way to get logs scale-in and scale out the app when running in cluster mode.
If you have any suggestions or corrections please do let me know.
@@vrushabhgore8170 thanks for explaining things
You can use pm2 if your application is stateless
Thanks for the video man! Always putting out good content!
Thanks Naseer, for clarifying doubt on thread
16:00 Love the Clustering Nodejs part, I need to learn more about scaling Node.js
first 2 minutes of choppiness is due to i/o blocking of matrix
I need to remember to turn off docker or get a new machine . My 2015 mac seems can’t handle obs
Can you please these quick questions and clear the confusion?
1. Is Event Loop single threaded or due to one call stack, Node.js is threaded?
2. Isn't the purpose of Event Loop just to check whether the call stack is empty or not and bring instructions from queues to call stack? Or there is more to it?
3. Is event loop implemented in a different way in browser and node.js?
4. When we send network request or use setTimeout, does the Web API container spawns new threads for these operations? For e.g. there is an API call in the code. The call gets out of Call stack and goes to Web API container. When it completes, it comes to Callback/Priority Queue and from there it comes back to Call Stack when Call Stack is empty.
But what happens in Web API container? Does it spawns a new thread for network request and setTimeout? What happens there exactly?
i think most of the places hussein was saying event loop was actually suppose to be the main thread, got me confused as well
16:36 great tone man!!
Great Haircut, new style looks good 😎
Thanks very much for the video bro. Love from Bangladesh
Thanks for the awesome explanation Hussein..
An explanation of nodejs under the hood in a funny way !! god bless you mate !!
You didn't mention when and how an async i/o request is handed off to I/O pool and how the callback works between 2 different threads. Are you really sure creation and dispatch of TCP packets is done by a main loop thread?
Thank you 🙏 . Any future plans of doing a service worker video & code ?
Hey Hussein big fan of yours, I request you to please order the content in each of your playlist so a novice like me can know where to start from and what's the sequence
Eg
We can say OSI first then tcp then http then tls
I don't know if I get it right or not 😂
I just revised the order they look correct to me (beginners) start with osi , tcp, http, ..
Mind-blowing Videos ....super sir 👏👏👏🙏🙏😊.if possible kindly make nodejs/express course on udemy ...😊
It seems to me that you're saying that server.listen() is a leaky abstraction...?
So nodejs uses a pool of worker threads for two particular reasons. The first is to perform CPU intensive tasks (like crypto). The second is to handle some types of asynchronous I/O, like filesystem I/O or DNS querying, because back when libuv was implemented some OSs did not provide asynchronous I/O interfaces for those, so the worker thread in this case really blocks on the I/O task, and a callback is registered to be executed on the main thread, am I right?
Wow new hair cut 👌🏽
Very informative 😃
Hussein! Which is better to use for a highly scalable financial product's backend development and why: Node JS or Java?
isn't fork method used for multiprocessing ? not multithreading
thank you for this video
could you do a video to compare and explain coroutines vs event loop? and why there is a saying that coroutines handle async better than event loop or vice versa?
why for example google developed a language (go) with coroutines (goroutines) and not an event loop? because to me, event loop handles async much more efficiently and as you said in the video, it could run on multi-core systems with clustering.
hi hussein, i really liked your video, but still i have a confusion, i really hope you will reply to this , from what i understood till now, i think for database i/o promises and some node apis like 'fs', 'crypto' , nodejs will create a worker thread so that main thread is not disturbed ( i am not sure though ), but what about the custom promises i create in my node app, will these promises execute in main thread or nodejs automatically spawns worker thread for all promises in the app, your response is very much appreciated, thank you 🙏
All promises/async await execute on the main thread including database queries from db clients, (unless specified otherwise by the client author) the database query is nothing but a network call which we established that it runs on the main thread.
As a rule of thumb, if its not crypto, DNS, or io file read (directly to machine node is on) then it runs on the main thread.
That being said If you used a third party npm package those might utilize threading so you need to read their doc. Stripe payment comes to mind
Thanks, good question
thank you soo much 🤩, i was searching all over, its been really helpful 🙏
6:50 How does synchronously reading file go to or use the event loop when event loop is a non blocking whereas synchronously means blocking? Doesnt sync reading stay on the main thread and complete the reading ? What am I getting wrong here?
does the main thread run inside event loop ?
You are a great
YOU ARE GREAT
What happens if I use all the cores with forks and then I use fs.readFile which is using 4 cores and what happens if I use fs.readFile in one of the forks? Do I run out of cores?
I know that libuv library is used in Shiny web framework from R programming as well...
This is so cool
Why does NodeJs need to use threads for I/O intensive operations? Isn’t this work not part of the NodeJs runtime responsability?
1. Why - Node.js primary purpose is to run JS. File system ops are usually handled by the OS. To avoid blocking JS code execution, Node.js creates a separate thread for file ops. Using a single thread would have blocked the app.
2. I think #1 answers you're question.
Why your video is lagging? Did you use single thread for recording? 🙃
8:31 what is \b
? I have never seen that. Or did you mean to write
?
\b means go back one character, I used it another script to print the output next to each other. And copied it here where its not needed
works as well..
How do i get your exclusive content? Guide me through purchase
But can you cluster the cluster? Will the cluster module work over multiple physical nodejs installs/network hosts?
1. No. A non-master cluster doesn't have the fork function available to it. A script starts as the master cluster by default - i.e. master is created by the Node.js (we don't write code for it). This means that there can never be multiple masters. So - single master and clusters, that's it.
2. If you mean different Node.js processes, yes it'll work, since processes are isolated from each other.
loved the video.. ✨, what can i learn after this ?
Hi @naseer, If node is handling 10 file operations then does it create 10 threads
if the file operations is asynchronous, it is handled concurrently as node delegates file operations to the os...not entirely sure how it does it
Yes, assuming cores are available. Otherwise these tasks will complete with each other.
Sir is it possible to make good electronic wallet(not crypto wallet) with python django?(both sides: client side and backend side)
What is dd used for?
Is this 16:00 similar to what process management tools like PM2 does?
Correct! They even say that in their doc
Thanks a lot Sir 😊
Can you please make a video on the popular protocols like http, xmpp etc., there pros and cons, scenarios where each one can be used
I am not so sure about Xmpp, but there are videos on http on this channel. There's probably one for xmpp too if you check
@@joshuaifara2736 True he did make on http, but I actually want him to discuss about some other popular protocols as well, that might be useful in different scenarios
@@navjot7397 Alright then
I did make videos on http here ua-cam.com/video/0OrmKCB0UrQ/v-deo.html
And recently xmpp
ua-cam.com/video/OVN99SgBGkM/v-deo.html
how the second client request got connected to the server in the first place if the main thread is executing the while(1) loop ?
the second connection didnt reach the main thread, it only reached the queue for the main thread
I am so happy to see you using vim....I guess you are a real programmer now 😂
Node.js is indeed powerful!
Meet deno
very helpful
superb
How do you build a bitcoin
Thanks!
Superb
نعيماً علي الحلاقة xD
Can you add subtitles to this video in spanish or english?
so if we dockerize our nodejs can it benefit from cluster ?
Putting nodejs in a container and using cluster has no difference than placing it in a VM (well maybe if you put many containers are sidecars to the main node process but haven’t tested that) , In both cases there will be multiple processes. If you want to leverage the container orchestration you can spin up multiple containers each has a nodejs process and then use a reverse proxy / LB to distribute requests to those node containers.
There's no point in doing so, except if you have a weird requirement for very high security.
Nowadays Node can be multithreaded from the get go. All advantages of Golang, Java, etc... are blown out.
Not quite, I would dare to say not actually. Network calls, file system tasks, DNS lookup, etc. are actually not handled by the main thread(NodeJs itself) and are instead written in C/C++, witch are themselves multithreaded(that's where libuv enters the show). JavaScript itself remains single-threaded. The issue of having a full JS code(without underlaying C/C++) witch is CPU intensive blocking your whole nodeJs instance persists. You will still have to work around it with things like worker_threads. That's just the way it is. As Alberto Gimeno points out on his blog on LogRocket, it is not a question of someone adding a new module in the NodeJs core and allow us to create and sync threads. If we add threads, then we are changing the nature of the language. We cannot just add threads as a new set of classes or functions available. We need to change the language. And change it without breaking it. I don't know, to be quite honest, if that's possible with JS, someone else may jump in and fill this gap for me, that would be great and add weight to the discussion. Let's take C# for instance, Java, and most versions of C++, they were designed with threads in mind from the get go, therefore they all have all of the facilities to handle them built in since their inceptions, not the case with JS. I remember while ago, like more than 10 years, a simple alert() in the browser was enough to block anything ajax you were doing in the background. It seems that all this time has passed and the 'single-thredeadness' is still there, still a single call stack, so it may be quite difficult to get rid of it without breaking some stuff. Relying on C/C++ bindings/wrappers taking advantages of libuv for everything you need to do in nodeJs is not sustainable on the long run. And finally I would just like to point out that I'm not a frond-end guy and my knowledge of JS is limited to the bare minimum I need to know. I gave up on frontends while ago and focused myself on the backend only. I've been just very curious about nodeJs for a few weeks and started learning about the technology before trying to learn the language itself.
@@jefersonnl
You lengthy argument is useless except when you said "We cannot just add threads as a new set of classes or functions available. We need to change the language." And even here you didn't support this alleged "need" with any argument. So no, you can add threads without a problem and end up with performance that matches compiled languages.
Side note: libuv was designed for Node only, then used by others.
Another side note: the Majority of backend developers around the world are Node developers, and they are backend developers only. This means JS is a backend language with excellence, not a "quick fix" in the backend for those coming from frontend background.
@@alithejumbo My bad if I went too technical or went down deep in low level stuff unnecessarily, with the risk of doing it again. What Gimeno meant with that was, we do not need to change the language, rather, a big change *would be needed* to make JS multithreaded, if one wished so. Since you seem to believe all the rest is useless, there's apparently no point in repeating what wasn't understood here. As Hussein always is point out to us, do not fall in love with a technology. Just understand what it is good for and what it is not good for. For instance, NodeJs will shine very bright in IO-intensive environments, no doubt about that, however it still has its shortcomings when CPU intensive jobs are regarded. And if you have a lot of CPU intensive jobs going on, and a lot of CPU cores to work with, you will need to take care of the complexity yourself with worker_threads and clusters, something other languages will just give to you out of the box, even PHP with the veteran HTTPd will give you that from the get go(though at the cost of several threads and processes and the dreaded context switchings). It's important to understand how things go under the hood, and sometimes take a look at what one's neighbor is doing, otherwise one can break one's heart when another language comes out with new features like virtual threads, fibers, transparent user space threads or light weighted threads like goroutines. All that we must avoid in the tech industry is to become close-minded and entrenched in our neck of the woods
. This is why I started investigating NodeJs in the first place.
@@jefersonnl
I went through your replies again to figure if I've missed anything . See, I write in Golang too, and I know how "better" than Node it is. But an easy Goroutine and Channel functionality doesn't outweigh the practicality and quick delivery of Node. At the end of the day 95% of the needs of any cloud server can be easily met with Node. So I won't nag much about the fact that Node's multithread-ability is on high level. It just works.
@@alithejumbo Yes, everything seems to be centered around quick delivery nowadays. So Node will shine there. Also 95% of the needs of any cloud server (maybe not 95%, maybe a little less, but still above 80%), is centered around IO, "query this, give me back that, save this, delete that, retrieve that, put that on a queue, fetch that from so and so", and so on. Node will certainly shine quite bright in such environments as well. And when hiring separated frontend and backend developers could become expensive, having one programing language ruling them all becomes very attractive, especially in a startup environment. I can see when and where it works. How will we deal with some immaturities of JS? Only time will tell. PHP began as something very immature with a lot of issues and hacks, even so, it took the web by storm, and only them it mature into something like PHP 7/8.
What did you do with your hair
great quiz :) learned alot from it
all good until u started rushing through, from next time, can we pls spend more time on the hands on?
What about express?
Express uses http server behind the scenes so the same applies
ممكن لو حضرتك تشرح الكلام تانى بس بالعربى ؟ انا وكل العرب اللى بنتعلم برمجة هنستفيد جدا. الحكاية بى الانجليزي صعب فى مصطلحات مش فاهمها كتير جدا
ان شاء الله بحاول اتطرق لها في قناتي العربيه
@@hnasr ممكن لينك القناة من فضلك
TODAY I WILL QUITE UNIVERSITY, AND JUST WATCH YOUR VIDEOS
🙏🙏🙏
I gave dislike just to be on a different thread
Great Content tho keep it going 👍
I/O non blocking, javascript itself will be blocking if you're calculating Fibonacci by recursion lol
Nice haircut
16:40 😂😂😂
peep pundamane
cpu().length() lol boomer programmer dies inside.
true, haha.
👎👎👎 hazelnut
it should be - process.env.UV_THREADPOOL_SIZE = OS.cpus().length;
it works with hyperthreading as well. Setting any number greater than logical/physical cores count will not make any sense.