DEV Community: Afraz Momin

Debouncing v/s Throttling: What's the difference?

Afraz Momin — Tue, 29 Sep 2020 09:12:25 +0000

Website performance plays a huge role in enhancing the user experience of our websites. In this article, we will learn about performance optimization techniques like Debouncing and Throttling and the key difference between them.

Debouncing and Throttling are widely-used techniques that help us in limiting the rate at which a function fires off. These two techniques give us a layer of control between the event and the execution of the functions attached to them. API servers often implement either of these two techniques to prevent the application from being overloaded.

These function calls could be anything from a simple scroll event to an API call to the server. Both these techniques are almost identical and help us reduce the number of function calls being made but they have one small, but significant difference among them.

Before we get into the difference, let's understand how they work individually -

What is Debouncing?

Debouncing is a technique in which no matter how many times a user fires an event,
the call will be made only after a specific amount of time has passed after the user stops firing the event.

For example, let's say a user is typing something in a search box. This search box makes API calls and has a debounce function attached to it with a specified time duration of 400ms. So now, unless 400ms have passed after the user stopped typing, the API call wouldn't be made.

I wrote a detailed article on Debouncing in Javascript, a couple of months ago. If the concept of debouncing is completely new to you, I strongly suggest you go to this link and read the post before moving ahead with this one.

What is Throttling?

Throttling is a technique that makes the next function call strictly after a certain period of time. No matter how many times the user fires an event, the function attached will be executed only once in the given time period.

Let's understand this by coding a simple throttle function ourselves -

We will start by taking a simple Button. Let's say this button calls some API. The onclick attribute on this button will call two functions - normalFunc() and apiWithThrottle()

In our Javascript file, we'll define the functions -

The normalFunc() keeps track of the number of clicks made on the button, and apiCallFunc() keeps track of the number of API calls being made. The function apiWithThrottle() when triggered by the button, will call the throttle() function in which the function to be throttled and the time limit are given as parameters.

After running this code, we see something like this -

Here, we have set the time limit to 1 second (1000ms). Notice how the user clicks the button multiple times but the call to the API is only made 3 times, each after an interval of 1 second. To sum it up in simple words - even if the user clicks the button 15 times in 3 seconds, the number of times the API call will be made is 3 only.

Here's the link to the CodePen, if you want to try this out yourself.

Debouncing vs Throttling

The difference between the two can be understood by taking a simple real-life example -

Debouncing

Imagine you're a 7-year toddler who loves chocolates. You persistently keep asking your mom for some chocolates. She gives you some but then you start asking for some more. You ask her so many times that she gets annoyed and tells you that you can have it only if you don't bother her and remain silent for the next one hour. This means if you keep asking her, you will only get it one hour after the last time you asked her.

This is debouncing.

Throttling

Consider the same example - You ask your mom for chocolates despite having them a few minutes ago. You persistently keep asking her, she gets annoyed and finally decides to give you some. But she, being your mom, knows that you will ask for some more in a few minutes. So she gives you the chocolates with a condition that you won't get any more for the next one hour. You still keep bothering her for more but now she ignores you. Finally, after an hour has passed, she gives you the chocolates. If you ask for more, you will get it only after an hour, no matter how many times you ask her.

This is what throttling is!

Use-cases

Both these techniques have their own set of use-cases.

Debouncing can be used when the result of the most recent event occurrence is what is important. For example, a search query on an e-commerce website.

Throttling can be used when the input provided to the function call doesn't matter or is the same each time. For example, infinite scrolling on a webpage. Here, we need to check how far the user is from the bottom of the page. If they're too close, we request more data and append it to the page. Here debouncing wouldn't work as it would only trigger the event when the user has stopped scrolling but we need to start fetching the content before the user reaches the bottom.

Another example would be a multiplayer fighting game where your character has to punch to defeat its opponent. Throttling can be applied to this punching ability of the character such that it can punch only once per second. Now even if the player gives the command to punch 10 times in 5 seconds, the number of punches thrown would be 5 only.

Wrapping Up

Techniques like debouncing and throttling give us control over the execution of events in our websites, helping us reduce the number of high computational tasks that may hamper the performance of our website. They might have different use-cases but the end goal remains the same i.e better performance. So if you're a developer looking to optimize your website, you know what to do!

If you liked what you read, share the article with a friend and connect with me on Twitter - @afraz_momin. I plan on writing similar articles on Javascript in the coming days!

Function Currying in JavaScript

Afraz Momin — Sat, 29 Aug 2020 11:15:04 +0000

Javascript is a multi-paradigm language that allows you to freely mix and match object-oriented, procedural, and functional paradigms. Recently there has been a growing trend towards functional programming. The functional programming style not only attempts to pass functions as arguments, a.k.a callbacks, but also returns back functions as well. This feature of functional programming gives us many new and useful concepts. One of these concepts is Currying.

In this article, we will take a look at what currying is and how it helps us make our code clean and much simpler.

What is Currying?

Before diving into currying, we first need to understand the arity of a function. The arity of a function is basically the number of arguments it requires.

Consider these two examples -

function addTwo(a, b) {
  return a+b;
}

function addThree(a, b, c) {
  return a + b + c; 
}

In this case, the arity of the function addTwo is 2 and the arity of the function addThree is 3.

Currying a function means to convert a function of N arity into N different functions of arity 1.

In much simpler words, currying is the process of restructuring the function so that it takes only one argument and then returns another function that takes the next argument, and so on.

To give you a sense of how this could work, let's create a couple of functions -

// Un-curried function
function add(x, y) {
  return x + y;
}

// Curried function
function addCurried(x) {
  return function(y) {
    return x + y;
  }
}

add(1, 2);  // Returns 3
addCurried(1)(2);  // Returns 3

Notice the difference between the two. The first function is a simple function that takes two parameters - a and b, and adds them. On the other hand, the second function addCurried takes only one argument i.e a, and returns another function which takes b as the argument. Both give us the same result.

Currying can be helpful when we can't provide all arguments to a function at one time.

Each function call can be saved into a variable, which will hold the returned function reference that takes the next argument when it's available. Let's take another example to understand this better -

// Curried function
function greet(msg) {
  return function (name) {
    console.log(msg, name);
  };
}

let english = greet("Hello,");
let spanish = greet("Hola,");
let german = greet("Geuten Tag,");

german("Dwight"); // Prints "Geuten Tag, Dwight"

spanish("Oscar"); // Prints "Hola, Oscar"

english("Michael"); // Prints "Hello, Michael"
english("Jim"); // Prints "Hello, Jim"

Notice how currying helps us avoid passing the same variable again and again. In this case, the variable msg, which will print "Hello" when called using english. This is a great strategy to avoid frequently calling a function with the same argument.

ES6 Pattern

Currying is part of functional programming and such curried functions can also be easily written using the arrow function syntax in ES6 for more cleaner and elegant code in the following way :

const addCurried = x => y => x + y;

addCurried(1)(2);   // Returns 3

Partial Application Function

When we talk about currying, the concept of Partial Application Function is bound to come up. Currying and Partial application function are almost identical concepts with one significant difference.

Partial application function is a function that returns another function but each returned function can take multiple arguments. In currying, the returning function can only take one argument.

Let's take a simple example to demonstrate this difference-

// Curried function
function addCurried(x) {
  return function (y) {
    return function (z) {
      return x + y + z;
    };
  };
}

// Partial Application function
function addPartial(x) {
  return function (y, z) {
    return x + y + z;
  };
}

addCurried(1)(2)(3); // Returns 6
addPartial(1)(2, 3); // Returns 6

The implementation of both these concepts totally depends upon the use-case and the availability of the arguments at that point in time. But they definitely help us write more cleaner and elegant code.

Wrapping Up

Currying is an incredibly useful concept when it comes to functional programming with Javascript. As seen, using currying we can have functions that are more definite in what they do, avoiding potential repetition in our code, which ultimately leads to simplification of our code.

If you liked what you read, connect with me on Twitter - @afraz_momin.
I plan to write similar articles on JavaScript in the coming days!

Event Bubbling and Event Capturing in Javascript

Afraz Momin — Sat, 04 Jul 2020 11:30:12 +0000

The interactivity of our HTML web page is handled by Javascript. This interactivity is nothing but a bunch of events that the HTML elements undergo. An event can be something the browser does or something a user does. They tell us some change has happened and where it has happened. It could an onClick event that indicates something has been clicked. Another instance could be an onSubmit event that says that the form has been submitted.

How well these events are handled decide how user-friendly the web page is.

Event Bubbling and Event Capturing are two phases of event propagation/flow in Javascript. Event flow is basically the order in which the events are received on a web page. In Javascript, event flow takes place in three phases -

Capture Phase
Target Phase
Bubble Phase

This propagation is bidirectional, from the window to the target and back. What differentiates these phases is the type of listeners that are called.

Let's start by understanding Bubbling first.

Event Bubbling:

Bubbling is the flow of events where, when an event takes place on an element, it first runs the handler on itself, then on its parent and then on all of its ancestors.

It basically moves up the hierarchy from the innermost element to the outermost element.

This can be better understood by taking an example -

<body>
    <div id="grandparent">
      <p>Grandparent</p>
      <div id="parent">
        <p>Parent</p>
        <div id="child">
          <p>Child</p>
        </div>
      </div>
    </div>
    <button onClick="history.go(0)">
      Reset Elements
    </button>
  </body>

In our HTML file, we take 3 divs nested one inside the other and give them ids of child, parent, and grandparent starting from the innermost div.

Add a bit of styling

div {
  min-width: 75px;
  min-height: 75px;
  padding: 25px;
  border: 1px solid black;
}

button {
  margin-top: 20px;
  width: 200px;
  font-size: 14px;
  padding: 10px;
}

We will set a click event on each of the 3 divs in our JS file

document.querySelector("#grandparent").addEventListener("click", () => {
  document.querySelector("#grandparent > p").textContent =
    "Grandparent Clicked!";
  console.log("Grandparent Clicked");
});

document.querySelector("#parent").addEventListener("click", () => {
  document.querySelector("#parent > p").textContent = "Parent Clicked!";
  console.log("Parent Clicked");
});

document.querySelector("#child").addEventListener("click", () => {
  document.querySelector("#child > p").textContent = "Child Clicked!";
  console.log("Child Clicked");
});

The code above will perform in the following way -

Notice how, even when the child div is clicked, the handlers on all its ancestors get triggered as well. Similarly, when the parent div is clicked, the handler on the grandparent div will get fired as well. But, keep in mind, in this example, the handler on the child div won't be triggered.

Although, what's more important here is the way the event flow happened. It started from the innermost element, i.e. is the child div and then propagated up the hierarchy eventually reaching the parent and grandparent divs (in that order strictly).

This type of flow of events is called Event Bubbling.

Event Capturing:

The capturing principle is the exact opposite of bubbling.
In Event Capturing, the event propagation takes place from the outermost element to the innermost element. Event capturing is sometimes also referred to as event trickling.

We often use the addEventListener() when working with Javascript, in which we usually pass two parameters -

the event
the callback function

The addEventListener() function also takes a 3rd hidden parameter - useCapture which takes a boolean value. This useCapture parameter is set to default by false. Setting it to false, makes our events propagate using the principle of Bubbling. Setting it to true will make them propagate in a top-down approach, that is, Capturing.

To implement event capturing we will make a few small changes to our JS code -

document.querySelector("#grandparent").addEventListener("click", () => {
  document.querySelector("#grandparent > p").textContent =
    "Grandparent Clicked!";
  console.log("Grandparent Clicked");
},true); // useCapture parameter is now set to true

document.querySelector("#parent").addEventListener("click", () => {
  document.querySelector("#parent > p").textContent = "Parent Clicked!";
  console.log("Parent Clicked");
},true); // useCapture parameter is now set to true

document.querySelector("#child").addEventListener("click", () => {
  document.querySelector("#child > p").textContent = "Child Clicked!";
  console.log("Child Clicked");
},true); // useCapture parameter is now set to true

Now our code will run in the following way -

Notice how the flow of events now propagates from the outermost element to the innermost element.

i.e grandparent -> parent -> child

This flow of events is called Event Capturing.

Wrapping Up

The reason I spoke about bubbling first is because event capturing is rarely used. It is set to false by default. For most of the browsers, Event bubbling is the default way of event flow.

Javascript helps us make interactive web applications. It makes use of a lot of user-generated events in doing so. The user experience of a website depends on how well these events are handled. Hence it is important to know how events work and the flow behind them.

Here's the link to the Codepen, if you want to demonstrate this yourself.

If you liked what you read, follow me on Twitter - @afraz_momin to stay updated.
I plan on writing similar articles about JavaScript in the coming days!

Debouncing in JavaScript

Afraz Momin — Tue, 23 Jun 2020 15:37:13 +0000

Often situations arise, when we want a certain event to fire off only after a certain amount of time has passed. The most common example would be the search bars we see on e-commerce websites like Amazon or Flipkart. In these search bars, when you type something, an API call is made, and results similar to your query are displayed on the screen.

Now imagine making an API call every time a key is pressed on your keyboard. Doesn't sound viable right? Firing an event continuously (in this case, the call to the API) would hamper the performance of the website.

This can be avoided by using the concept of debouncing. Debouncing limits the rate at which a function fires off. In the example above, it drastically reduces the number of API calls that are made to the server.

The setTimeout function of Javascript plays a vital role in implementing debouncing. For those who don't know what setTimeout does, it is a scheduling function provided by Javascript which allows us to run a task after a certain interval of time.

Let's see how we can implement debouncing with a simple example,

The very first thing we'll do here is - create a simple input in our HTML file. On this input box, we will call a method searchData() for the onkeyup event. So that every time the user releases the key after pressing it, searchData() is called.

<body>
    <label for="search">Search</label><br /><br />
    <input type="text" onkeyup="searchData()" />

    <script src="script.js"></script>
  </body>

In our Javascript file, we'll define the searchData() function and create a counter to track the number of times it gets called.

let counter = 1; // To track number of calls

const searchData = () => {
  // Let's say this function calls some API and gets us some data
  console.log("Looking for data..", counter++);
};

After running this program, we see something like this -

Notice how for every letter of the word "Michael", the function gets called. Imagine firing off API calls for a bigger query on a much bigger site. That would be very browser intensive and may hinder the performance. To reduce these continuous function calls, we'll make use of the debounce function :

let counter = 1; // To track number of calls

const searchData = () => {
  // Let's say this function calls some API and gets us some data
  console.log("Looking for data..", counter++);
};

// Debounce function
const debounce = function (fn, delay) {
  let timer = 0;
  return function () {
    clearTimeout(timer);
    timer = setTimeout(() => {
      fn();
    }, delay);
  };
};

const callDebounce = debounce(searchData, 300);

Note that we make a change in our HTML file and will be calling callDebounce() now instead of searchData()

 <input type="text" onkeyup="callDebounce()" />

The code above will do the following -

Notice how no call is made until a delay of 300ms is encountered. Instead of making more than a dozen calls for each letter in "Michael Scott", our input bar will only make calls whenever the delay between two keypresses is more than 300 milliseconds. In this case, 2 times.

When the user enters the first character "M", debounce() is triggered which waits for 300ms to fire off the searchData() function. But before 300ms have passed, the user enters another character which will wait another 300ms to fire off searchData() and so on. This will create multiple copies of the timer running in the background. So to clear out the timers in cases where consecutive keypresses are being made without a pause 300ms, we make use of the inbuilt clearTimeout() function. This sets the timer to 0.

This goes on until the user takes a pause after completing the word "Michael", this pause is noticed by the function which in turn fires off our searchData() function.

In simple words, what happens here is that the function waits 300 milliseconds after the last keypress. Only when 300ms have passed and no keypress has been made, it fires off the searchData() function.

Wrapping Up

This was a simple demonstration of debouncing. Using this we can reduce the number of calls made several times in succession by a function, which will ultimately lead to an improvement in the performance of our website.

This article was originally posted here

If you liked what you read, consider following me on Twitter - @afraz_momin to stay updated. I plan on writing similar articles about JavaScript in the coming days!

React v/s Vanilla JS - When to use what?

Afraz Momin — Tue, 14 Apr 2020 14:32:04 +0000

Web apps can be complex and may require a lot of dynamic functionalities. One can opt for Vanilla JS to build their applications but if you have worked with Vanilla JS before, you know how messy it can get. Here's when JS frameworks like, React, Angular and Vue, come into the picture.

In this article, I'll walk you through the main differences between a JS library like React and plain Javascript - when to choose which and why?

Let's start by answering two simple questions.

What is Vanilla JS?

Vanilla JS is nothing but plain JS without any external libraries or frameworks. Using this we can build powerful and cross-platform applications.

What is React?

React is a Javascript library used for building user interfaces. It allows us to make complex UIs from isolated pieces of code called "components".

React has quickly become one of the most popular Javascript libraries. This is entirely because of its flexibility and the improvement it brings in the performance. React breaks down the UI into smaller and reusable components that can move around data amongst each other. This breaking down of the UI is what gives React an edge over Vanilla JS.

In Vanilla JS, the code becomes very difficult to maintain if the application is large because in such cases the UI needs to be updated regularly. Here, to change a UI element you need to first find the element in the DOM and then update it. This is fine when you have to update only a single element but imagine doing this on long-form which a user needs to fill. This could be very memory and browser intensive.

This is where React comes in with a great feature i.e its own virtual DOM. The virtual DOM is a shortcut to bypass the manual work. It is a lightweight copy of the actual DOM. It has the same properties as the real DOM but lacks the power to make changes on the screen.

The most important and fundamental reason why modern frameworks are used is that, with Vanilla JS, keeping the UI in sync with the state is hard.

Let's understand this by taking an example

Consider Facebook. Say at a given time, your friends comment on a picture of yours and you want to see it immediately. You'd want to shift from liking posts to commenting or sharing without being slowed down.

Now, this can be done in Vanilla JS too, but the number of changes you'd have to do in the code would be very tedious. All this tiresome work can be avoided by using something like React.

Basically, with React, we can manage to keep the UI and the state synchronized with each other. In Vanilla JS, if you have to change the state, you would need to update the UI. One small mistake and your UI could be out of sync with your data.

Code organization and re-use is another important aspect of React. A component created only once can be used multiple times with different data.

Conclusion

Whether you should use Vanilla JS or React depends very much on your use case.

Vanilla JS is awesome but it's not a great alternative when it comes to building huge applications with complex dynamic functionalities. Besides, it cannot create complex and efficient UIs. So if you have an app that changes frequently and drastically with thousands of pages, it is better to use a modern Javascript framework.

On the other hand, React which allows us to use reusable components and is capable of keeping the UI in sync with the state, can definitely solve this problem.

If you liked this post, you can find more by:

Following me on twitter: @afraz_momin
Joining the newsletter: afrazblogs.netlify.com

Thanks for reading!