What is an event? We are talking about low-level events here. It’s not those nice
.on() events, although the library implementing them can force a new low-level event to be created instead of just calling the callback. Some examples of low-level events are timers, network connections, disk I/O or user input.
The important thing here is that in order to keep the app responsive, the bursts should be as small as possible, because nothing will be processed until the previous burst has finished. In nodeJS, I/O, for instance, is natively split in separate bursts, which is great. One burst calls I/O, and then we can carry on processing others while we wait for the response, which will trigger another burst. We can even have separate bursts for chunks of data being read or written.
What happens if the main script has a chunk of code which is very slow (let’s say, because it runs an iterative algorithm that takes a while to complete)? The whole app is going to slow down because of this, and there is no way to put it in a separate thread. The answer is easy: run each iteration of the algorithm in a separate burst, or at least the whole chunk in its own burst. The first thing that a code needs in order to become a burst is to be a separate function. Then, instead of calling the function, call a low-level event dispatcher; for instance, set a timer that will fire in 0 milliseconds. This will defer the execution of the function until another burst.
The tricky thing here is that there might be another events on the queue, so you can’t guarantee when the code will actually run. That’s why you should supply a callback, and call it at the end of the slow function.
Notice that the slow function is not a low-level event by itself; the event is the timer, which has got a callback (the same way as we provide one to the slow function) that will run within the same burst.