I have just started reading more about what asynchronous programming is all about and would ask if my reasoning below is correct and if it is not what am i misunderstanding?
My understanding is that asynchronous programming is mostly relevant when talking about I/O, this is because the execution of I/O events are handled by some other execution environment for example the operation system, or database. However I could also run two instances of Node.js for example one instance that needs to be highly responsive on which I instantly pass over execution of long running Javascript processes to another Node.js instance where the longer running processes can lock the singel thread and only send back the callback telling the responsive server that the execution was ok? The most common way to create an external execution environment in which to run asynchronous javascript is to start WebWorkers to avoid blocking the single three? It is also possible to write asynchronous code that has no positive effect, for example if all my asynchronous code is executed on a singel Node.js instance and not passed away to some other execution environment. This would give me no positive effect and only lead to a much more complicated program logic, all my code would still need to be executed in the same environment?
So in conclusion, asynchronous programming is all about avoiding executing anything in the singel thread, you only want to pass along the actual execution to some other process?
Is my reasoning correct?
Asynchronous programming is especially but not only useful for I/O.
The idea is that I/O reads and writes can take a long time, and it's not always necessary to wait for them. You can continue executing code while you wait. For instance, you can load a file, execute a query and do a REST request to another service. Your node application can start all these in the same time, asynchronously, and then wait until each of them is finished.
In PHP for instance, this is very hard to accomplish, and you will waste time waiting until the file is loaded, waste more time until the query is executed, and then wait even more for the REST request, because you cannot start them at the same time.
So this is a big advantage, although it's also a bit theoretical. In practise, you'll find quite often that you need the output of one request/query/file as the input for the next.
Node is not single threaded per se (actually, I cincerely hope it is not). But you won't have to implement multi-threading yourself. Also, it could be multithreaded although it doesn't have to be. Even in a single threaded and/or single-core environment it can still be faster, because you can actually pause executing of one task until the I/O that is part of it is finished. Like I said, in PHP your script cannot do anything else while it waits for a response of the database, while in Node you can.
The big deal about asynchronous Javascript is that you can write an asynchronous program without thinking in terms of low level constructs like threads. In Javascript you can handle complex concurrency logic by simply chaining together your program's execution using mechanisms like callbacks and events.
The big deal about asynchronous programming in general is that you can handle things that may take a significant amount of time to execute like opening a file, downloading an image or calculating Pi without blocking other processes from doing their jobs.
The secret to concurrency in Javascript is the "event loop" which allows asynchronous behavior in a single threaded environment.