asynchronous by design.
Asynchronous means that things can happen
independently of the main program flow.
In the current consumer computers, every program runs for a specific time slot and then it stops its execution to let another program continue their
execution. This thing runs in a cycle so fast that it's impossible to notice. We think our computers run many programs simultaneously, but this is an illusion (except on multiprocessor machines).
Programs internally use
interrupts, a signal that's emitted to the processor to gain the attention of the system.
I won’t go into the internals of this, but just keep in mind that it’s normal for programs to be asynchronous and halt their execution until they need attention, allowing the computer to execute other things in the meantime. When a program is waiting for a response from the network, it cannot halt the processor until the request finishes.
Normally, programming languages are
synchronous and some provide a way to manage
asynchronicity in the language or through libraries. C, Java, C#, PHP, Go, Ruby, Swift, and Python are all synchronous by default. Some of them handle async by using threads, spawning a new process.
synchronous by default and is
single threaded. This means that code cannot create new threads and run in parallel.
Lines of code are executed in series, one after another, this type of execution flow is also called as
Blocking Code Example
Create a text file named input.txt with the following content -
No other lines will execute until the whole file is read.
Create a js file named
app.js with the following code -
Now run the
main.js to see the result -
Here, we can clearly see code of line are executed one after the other.
born inside the
browser, its main job, in the beginning, was to respond to user actions, like
onSubmit and so on. How could it do this with a synchronous programming model?
The answer was in its environment. The browser provides a way to do it by providing a set of APIs that can handle this kind of functionality.
More recently, Node.js introduced a
non-blocking I/O environment to extend this concept to file access, network calls and so on.
You can’t know when a user is going to click a button. So, you define an event handler for the click event. This event handler accepts a function, which will be called when the event is triggered:
This is the so-called
It’s common to wrap all your client code in a load event listener on the window object, which runs the callback function only when the page is ready:
Callbacks are used everywhere, not just in DOM events.
One common example is by using timers:
Handling errors in callbacks
How do you handle errors with callbacks? One very common strategy is to use what Node.js adopted: the first parameter in any callback function is the error object: error-first callbacks
If there is no error, the object is
null. If there is an error, it contains some description of the error and other information.
The problem with callbacks
Callbacks are great for simple cases!
However every callback adds a level of nesting, and when you have lots of callbacks, the code starts to be complicated very quickly:
This is just a simple 4-levels code, but I’ve seen much more levels of nesting and it’s not fun. This nesting of call-backs is termed as a
Call-back Hell problem in JS world.
How do we solve this?
Alternatives to callbacks
Promises (ES6) and
Thank You for reading the article, I hope you got to learn something new from it : )
Originally published at https://blog.teachmebro.com.