absolutely

Get "Learn and understand NodeJS" by Anthony Alicea on Udemy. It's a gem. Takes apart NodeJS and explains its basic behaviors.

Others can be, Unapologetically greedy.

Yes that's a good suggest

hahahaha

i bet you "work" with wordpress

When your client insists that you should "destroy an already existing wordpress solution"

so true

LOL

At that point, you would be using C lol

I tried to do that once.

But, I guess, it's often put like this - if you have a multhithreaded framework, go ahead and use the luxury of a blocking model. The resulting code is more clean and decoupled.

​@@piotrgoabek6166 .net support non-blocking i/o api out of the box with async/await (sort of like coroutine). the benefits of coroutine is that you have a nice synchronous-like control flow, look really clean, easy to reason about even in multithreaded environment. other example is boost::asio in C++ support coroutine, callbacks, proactor model, blocking and non-blocking operations and possible to decouple with template. it's often like this, if you have a multhithreaded framework, go ahead and use the luxury support of non-blocking api, the resulting code might be efficient, might be clean if you know what are you doing. the point here is multithreading with asynchronous is possible, there are framework support these thing. to be honest, i think people that write multithreaded program will use non-blocking i/o if they can, their concern is performance. you can write clean, decoupled asynchronous code in multithreaded, because again these things aren't really relate.

He did not conflate the two though. He used examples of typical situations where synchronous calls are used with multi threading and asynchronous calls are used with single threading. His diagram of a thread pool even shows an asynchronous call being made

when exactly did he claim this?

@@jesuslovespee 6:50 , 7:17 "it has to wait". he did mention at 7:26 "thread pool with `synchronous` execution has that kind of behavior". he tried too hard on selling nodejs's singlethread model by compare it with a very inefficient multithread model and failed mention about multithread with asynchronous. yes, he didn't claim mutlthread models can't do asynchronous. I won't discuss this anymore, he didn't even bother to comment, so it's a negetive-sum game.

Still it carries the javascript overhead which is quite negated with io bound concurrency. And 70% of the real world business require that io bound concurrency.

@@manikanth2166 yeah it really depends on the size of the project/business as well. Node is so quick and painless to develop for that it's worth using for almost any app that will have a small userbase. I've even just gone and created microservices with GO that sit on the same box and communicate with the main node web server through a REST api.

this is a good enough approach, although processes are heavier than real multi-threading. Worker threads solve this well but they have a funny api.

Cruz Ortiz No, promises are nothing but a syntactic sugar on top of callbacks so it basically means whatever computation heavy task you wrapped inside promises still have to be executed by node’s main thread only

my thoughts too exactly