Debouncing and Throttling! During your programming journey, you might have heard these 2 fancy sounding or may be heavy sounding words ( have to admit that I was among them honestly! ). So, I studied about them, and found that I, and I am sure that you as well, have seen lot of their implementations in real life. So by this blog, I will try my best to present them in front of you in as easy way as possible. So, let's start!

Throttling and debouncing give us control over the rate at which a function is called. They are need to know techniques for any web developer. They are one of the widely-used techniques to improve the performance of code that gets executed repeatedly within a period of time.

Throttling

Throttling is a technique in which, no matter how many times the user fires the event, the attached function will be executed only once in a given time interval.

So, let's talk some maths here. Say under normal circumstances you would call this function 1,000 times over 10 seconds. If you throttle it to only once per 100 milliseconds, it would only execute that function at most 100 times

(10s * 1,000) = 10,000ms 10,000ms / 100ms throttling = 100 maximum calls

Debouncing

In the debouncing technique, no matter how many times the user fires the event, the attached function will be executed only after the specified time once the user stops firing the event.

Again let's do some maths. Perhaps a function is called 1,000 times in a quick burst, dispersed over 3 seconds, then stops being called. If you have debounced it at 100 milliseconds, the function will only fire once, at 3.1 seconds, once the burst is over. Each time the function is called during the burst it resets the debouncing timer.

I know that some of us might still be stuck with these calculations. No worries! I will give some of their use cases to explain them in a more relatable way.

When you would need them?

Debouncing and throttling are recommended to use on events that a user can fire more often than you need them to.

Examples include window resizing, scrolling and mouse clicks. The main difference between throttling and debouncing is that throttling executes the function at a regular interval, while debouncing executes the function only after some cooling period.

Debouncing and throttling are not something provided by JavaScript itself. They’re just concepts we can implement using the setTimeout web API. Some libraries like underscore.js and loadash provide these methods out of the box.

Both throttling and debouncing can be implemented with the help of the setTimeout function.

Why would you want to throttle or debounce your code?

Let’s look at two common use cases of throttling and debouncing.

• Case 1 : Gaming :

Let's start with more relatable reference. In action games, the user often performs a key action by pushing a button (example: shooting, punching). But users often press the buttons much more than is necessary, probably due to the excitement and intensity of the action. We all do that, please don't deny! ;)

So the user might hit “Shoot” 10 times in 5 seconds, but the game character can only shoot one bullet in one second. In such a situation, it makes sense to throttle the action. In this case, throttling the “Shoot” action to one second would ignore the second button press each second.

• Case 2 : Search box :

Often times, search boxes offer dropdowns that provide autocomplete options for the user’s current input. Sometimes the items suggested are fetched from the backend via API (for instance, on simple Google search).

Supposing you’re searching for “findwise” and the autocomplete API gets called when the text in the search box changes. Without debounce, an API call would be made for every letter you type, even if you’re typing very fast.

This approach has two major problems:

1. If the user is a fast typist and types “findwise” at a go, the autocomplete box would contain the results for “f”, before switching to those for “fi”, then “fin”, and so on. This would be a source of confusion to the user.

2. API calls aren’t guaranteed to return in the order they were sent. This means the autocomplete request for “fin” could return after the call for “find”. This means the user would first see the up-to-date list (items starting with “find”), which would then be replaced by the out-of-date one (items starting with “fin”).

So it makes sense to debounce the search here. Debouncing by one second will ensure that the autocomplete function does nothing until one second after the user is done typing.

In short, if throttle is a person says, “Hey, we heard you the first time, but if you want to keep going, no problem. We’ll just ignore you for a while.”

Same like that, Debounce says, “Looks like you’re still busy. No problem, we’ll wait for you to finish, we will act once you are done!”

Conclusion

So, the most useful applications of throttling and debouncing are on the frontend, where users can perform actions at rates we cannot control. They can also be useful to the server, though. API servers often implement throttling (“rate limiting”) to prevent the application from being overloaded.

Throttling is most useful when the input to the function call doesn’t matter, or is the same each time (for instance, a scroll event), whereas debouncing fits best when the result of the most recent event occurrence (for instance, when resizing a window) is what matters to the end user. I hope that I made these fancy looking terms easy for you now.