DEV Community: Syket Bhattachergee

Understanding Big O Notation: A Beginner's Guide to Time and Space Complexity

Syket Bhattachergee — Thu, 24 Oct 2024 06:25:36 +0000

Imagine we have different ways to write the same code. How do we figure out which one is the best? That's where Big O notation comes in. It helps us measure how much time and space the code will need, making it easier to compare them.

What is Big-O Notation?

Big O, also known as "Order of," is a way to describe how long an algorithm might take to run in the worst-case scenario. It gives us an idea of the maximum time an algorithm will need based on the input size. We write it as O(f(n)), where f(n) shows how many steps the algorithm takes to solve a problem with input size n.

Let’s try to understand by an example “Write a function that accepts a string input and returns a reversed copy“

Alright, I'm sharing a Stack Overflow solution with you, along with the image above, as you can see. It shows 10 different ways to solve the same problem, each with a unique approach.

Now, the question is: how do we know which one is the best?

Our goal is to understand time and space complexity. To do this, let's explore a concrete example with two different code snippets, so we can clearly see how these concepts matter.

Here's a function called addUpTo. This function uses a for loop that runs until it reaches the length of n and returns the total sum.

Now, let's look at another example that achieves the same functionality:

Which one is better?

Now, what does 'better' really mean in this context?

Is it faster?
Does it use less memory?
Is it more readable?

Typically, people focus on the first two—speed and memory usage—before considering readability. In this case, we'll be focusing on the first two. To measure the performance of both code examples, we'll use JavaScript's built-in timing functions to analyze and compare their execution times.

In the code above, I've added t1 and t2, which utilizes the performance.now() function built into JavaScript. This function helps us measure the time taken by the code to execute, allowing us to accurately compare the performance of the two approaches.

Exactly, the execution time varies depending on different factors, and you can see that on my computer as well—the times aren't consistent. The performance.now() function doesn't give us a fixed time, but it provides a useful estimate for comparison.

Now, let's take a look at the second example:

Now, observe the difference in execution time between the first and second code examples. The second one is noticeably faster than the first.

But what's the issue with relying solely on time measurements?

Different machines record different times.
Even the same machine will record different times on each run.
For very fast algorithms, speed measurements may not be precise enough to give an accurate comparison.

These factors make time-based performance assessments unreliable, especially for quick algorithms.

Okay, if not time then what?

That’s where Big O will help us to measure the time complexity and space both. So Big O Notation is a way to formalize fuzzy counting. It allows us to talk formally about how the runtime of algorithm grows as the input grows.

We say that an algorithm is O(f(n)) if the number of simple operations the computer has to do is eventually less than a constant times f(n), as n increases.

f(n) could be linear (f(n) = n)
f(n) could be quadratic (f(n) = n2)
f(n) could be constant (f(n) = 1)
f(n) could be something entirely different!

Here is an example:

In this case, we only have 3 operations, and no matter the size of the input, it will always remain 3 operations. This is why we can say that the time complexity of this function is constant, or O(1).

Now here is the first example:

In this case, as the input n grows, the number of operations also increases proportionally. Therefore, the time complexity depends on the size of the input, making it O(n).

Now, let's look at another example:

In this example, we have two nested for loops, both dependent on n—the input. This means that as the input n grows, the number of operations increases significantly. As a result, the time complexity of this code is O(n²), also known as quadratic time complexity.

Now, let's simplify Big O Notation. When determining the time complexity of an algorithm, there are a few helpful rules of thumb to keep in mind. These guidelines arise from the formal definition of Big O notation and make it easier to analyze algorithms.

Constants don’t matter

O(2n) = O(n)
O(500) = O(1)
O(13n²) = O(n²)
O(n+ 10) = O(n)
O(1000n + 500) = O(n)
O(n² + 5n + 8) = O(n²)

Big O Shorthands

Arithmetic operations are constant
Variable assignment is constant
Accessing elements in an array (by index) or object (by key) is constant
In a loop, the complexity is the length of the loop times the complexity of whatever happens inside the loop

Here is the Big O Chart:

So far, from the examples, we've learned about O(n) (linear time complexity), O(1) (constant time complexity), and O(n²) (quadratic time complexity). These cover the basic patterns where operations grow with input size.

We'll discuss O(log n) and O(n log n)—logarithmic and linearithmic time complexities—a bit later.

Space Complexity

So far, we've been focusing on time complexity: how can we analyze the runtime of an algorithm as the size of the inputs increases?

We can also use big O notation to analyze space complexity: how much additional memory do we need to allocate in order to run the code in our algorithm?

What about the inputs?

Sometimes you'll hear the term auxiliary space complexity to refer to space required by the algorithm, not including space taken up by the inputs. Unless otherwise noted, when we talk about space complexity, technically we'll be talking about auxiliary space complexity.

Space Complexity in JS

Most primitives (booleans, numbers, undefined, null) are constant space
Strings require O(n) space (where n is the string length) Reference types are generally O(n), where n is the length (for arrays) or the number of keys (for objects)

Remember, we're talking about space complexity, not time complexity. In this code, we can see we only have two variables. No matter how large the input grows, these two variables will always exist in the code. Since we're not adding any new variables as the input increases, we can say that the space complexity is O(1), meaning it's constant space complexity.

Let’s understand with another example:

In this code, the function returns newArr after doubling every element in the input array. Since the size of newArr is directly proportional to the size of the input arr, the space used by newArr grows with the input size. Unlike the previous example, where space was constant, here the space complexity depends on the size of the input array. Therefore, the space complexity is O(n), meaning it's linear.

I hope this makes space complexity clearer—just like time complexity, we're measuring it using Big O notation. So far, you've learned about different time complexities, in increasing order of complexity: O(1), O(log n), O(n), O(n log n), O(n²), O(n³), and so on. However, we haven't yet explored logarithmic time complexity.

Next, we'll dive into logarithmic time complexity and see how it works.

Logarithms

We've encountered some of the most common complexities: O(1), O(n), O(n2). Sometimes big O expressions involve more complex mathematical expressions. One that appears more often than you might like is the logarithm!

What's a log again?

log2 (8) = 3 → 2³ = 8

log2 (value) = exponent → 2^exponent = value

We'll omit the 2, which means:

log === log2

The logarithm of a number roughly measures how many times you can divide that number by 2 before it becomes less than or equal to 1. This makes logarithmic time complexity very efficient. As you saw in the chart, O(1) (constant time) is very close to O(log n), which is fantastic! It's also worth noting that O(n log n) is much better than O(n²) in terms of efficiency, making it a preferred complexity for many algorithms.

Certain searching algorithms have logarithmic time complexity.
Efficient sorting algorithms involve logarithms.
Recursion sometimes involves logarithmic space complexity.

Great! We've covered most of the key points on space and time complexity. Keep in mind that mastering these concepts takes practice, so don't feel overwhelmed if it's not completely clear right away. Take your time, review the material multiple times, and revisit examples as needed. It often takes a few repetitions for these ideas to really sink in, so be patient with yourself!

Finally, let’s do one more time recap:

To analyze the performance of an algorithm, we use Big O Notation
Big O Notation can give us a high-level understanding of the time or space complexity of an algorithm
Big O Notation doesn't care about precision, only about general trends (linear? quadratic? constant?)

Again, Big O Notation is everywhere, so get lots of practice!

We at CreoWis believe in sharing knowledge publicly to help the developer community grow. Let’s collaborate, ideate, and craft passion to deliver awe-inspiring product experiences to the world.

Let's connect:

This article is crafted by Syket Bhattachergee, a passionate developer at CreoWis. You can reach out to him on X/Twitter, LinkedIn, and follow his work on the GitHub.

The Magical Redis Cache: A Website's Best Friend

Syket Bhattachergee — Thu, 25 Jul 2024 11:36:38 +0000

Imagine you're running a busy coffee shop. Customers come in, place their orders, and wait for their drinks. At first, you're making each drink from scratch every time. It's slow, and people are getting impatient.

Then one day, you have a brilliant idea. What if you could make the most popular drinks ahead of time and keep them ready? That way, when someone orders a regular latte, you can just grab it and go. Suddenly, your service is lightning fast!

This is exactly what Redis does for websites, but instead of coffee, it's dealing with data.

Let's say you have a website that shows the weather. Every time someone visits, your website has to ask a weather service for the latest information. It's like making a fresh coffee each time - slow and inefficient.

Enter Redis, the magical helper. Redis is like a super-fast notepad that remembers things for your website. When the first person asks for the weather, Redis writes it down. When the next person asks, instead of going back to the weather service, your website just checks Redis's notepad. Boom! The answer is there, ready to go.

But Redis isn't just a one-trick pony. Oh no, it's got more tricks up its sleeve:

"The Forgetful Notepad": Redis can automatically erase old information after a set time. So your weather data doesn't get stale.
"The Countmaster": Need to know how many people visited your site today? Redis can keep count for you, faster than you can say "one, two, three."
"The Queue Manager": Imagine your website needs to send out a thousand emails. Redis can create a neat queue, so your website doesn't get overwhelmed trying to do everything at once.
"The Matchmaker": Redis is great at quickly finding connections between different pieces of information. This is super useful for things like social media sites that need to show you posts from your friends.

So, the next time you visit a website and it loads in the blink of an eye, give a little nod to Redis. It might just be working its magic behind the scenes, serving up data faster than a barista with a pot of pre-made coffee.

Remember, in the world of websites, every millisecond counts. And Redis? It's the speedster that helps keep the internet running smooth and fast, one piece of data at a time.

I am Syket Bhattachergee, Software Engineer at CreoWis and Content Creator at YouTube. If you want to discuss your technical writing needs or any role? You can reach out to me on LinkedIn and follow my work on GitHub.

Ultimate Guide to React Native Image Components

Syket Bhattachergee — Wed, 03 Jul 2024 12:06:04 +0000

Have you ever tried to work with images in your React Native app and felt a bit lost? Don't worry, you're not alone! Handling images in React Native can seem a little different from what you're used to on the web, but once you understand the basics, it becomes a breeze.

Let's start with the Image component. React Native provides this built-in component to display images in your app, just like how you'd use a tag on the web. However, there's a catch: if you want to set an image as a background, you'll need to use a different component called ImageBackground.

Now, you might be thinking, "Why can't I just use the Image component for backgrounds too?" Well, the Image component is designed specifically for displaying standalone images, like profile pictures or product images. It's optimized for performance and comes with features like caching and resizing out of the box.

On the other hand, the component is meant for, you guessed it, setting images as backgrounds for your app's views or components. This component acts as a container that stretches the image to fit its entire area, making it perfect for creating visually appealing backgrounds.

Today, our goal is to break down the Image component and explore how we can use it to meet our various requirements.

As I mentioned, the Image component is provided by React Native, so it's necessary to import the Image component from React Native.



import { Image } from 'react-native';

Amazing! Now, we will show three different examples of using the Image component in React Native with various variations:



import { StatusBar } from "expo-status-bar";
import { Image, View } from "react-native";
import { SafeAreaView } from "react-native-safe-area-context";
const Home = () => {
  return (
    <SafeAreaView className="flex-1 p-4">
      <View className="flex-1 space-y-3">
        <Image
          className="w-28 h-28"
          resizeMethod="contain"
          source={require("../assets/images/image.jpg")}
        />

        <Image
          className="w-28 h-28 rounded-full"
          source={{
            uri: "https://letsenhance.io/static/8f5e523ee6b2479e26ecc91b9c25261e/1015f/MainAfter.jpg",
          }}
        />
      </View>
      <StatusBar backgroundColor="#000" style="auto" />
    </SafeAreaView>
  );
};

export default Home;

Here is the output of the above code:

In the above component, you will notice two images. My concern is not with the images themselves but with the use of require() and URI. If you look closely, you'll see we used two different source options depending on the URL. For plain image URLs, you have to use URI instead of require(). If your images are already in your project directory in a static location, you can use the require() method.

I hope you understand how the Image component works in different setups. Depending on the situation, we can use either require() or a URI.

So far, we have covered the usage of the Image component. However, this is not the end of the story for the Image component, there are a couple of important things to discuss.

When it comes to the props of the Image component, the list is extensive. I highly recommend looking into the React Native Image component documentation. There, you will find numerous props that we can pass into the Image component, which can simplify our work based on your requirements.

For example, if we want to use the alt prop in the Image component, here is the code:



<Image
   className="w-28 h-28"
   resizeMethod="contain"
   source={require("../assets/images/image.jpg")}
   alt="Wildlife image"
/>

It's one example of how you can leverage the prop in the Image component.

Well, we have covered almost all of the important points. Just one more thing I want to highlight is the usage of GIF and WebP support on Android.

When building your native code, GIF and WebP are not supported by default on Android. You will need to add some optional modules in android/app/build.gradle, depending on the needs of your app.



dependencies {
  // If your app supports Android versions before Ice Cream Sandwich (API level 14)
  implementation 'com.facebook.fresco:animated-base-support:1.3.0'

  // For animated GIF support
  implementation 'com.facebook.fresco:animated-gif:3.1.3'

  // For WebP support, including animated WebP
  implementation 'com.facebook.fresco:animated-webp:3.1.3'
  implementation 'com.facebook.fresco:webpsupport:3.1.3'

  // For WebP support, without animations
  implementation 'com.facebook.fresco:webpsupport:3.1.3'
}

Amazing, I believe if you covered this part of the article, you won't have any problem using the Image component in your React Native applications. By thoroughly understanding the concepts and techniques discussed here, you'll be well-equipped to seamlessly integrate images into your projects, elevating the overall user experience and making your app more visually appealing.

I am Syket Bhattachergee, Software Engineer at CreoWis. If you want to discuss your technical writing needs or any role? You can reach out to me on LinkedIn and follow my work on GitHub.

How to add NativeWind in React Native Expo

Syket Bhattachergee — Mon, 01 Jul 2024 03:46:25 +0000

Are you a frontend developer who's fallen in love with the simplicity and power of Tailwind CSS? If so, you're not alone! I, too, was enamored by Tailwind's utility-first approach and the way it streamlined my workflow. However, when I made the transition to React Native, I found myself missing the convenience of Tailwind's classes terribly.

Writing CSS manually felt like a step back in time, and my productivity took a hit. That's when I found NativeWind, a game-changer for React Native developers who crave the same level of flexibility and ease that Tailwind offers.

NativeWind is a utility library that brings the magic of Tailwind CSS to your React Native projects, allowing you to style your components with the same familiar classes you know and love. Say goodbye to the tedious task of writing CSS from scratch and hello to a world of rapid development and consistent styling.

In this article, we'll dive deep into the world of NativeWind and explore how to integrate it into your React Native Expo project. Prepare to be amazed as you witness the seamless fusion of Tailwind's utility-first approach with the power of React Native.

So, I'm assuming you have already created an Expo app. Now, our mission is to make our app capable of writing Tailwind CSS code.

Add these two dependencies to your Expo project:



npm install nativewind
npm install --save-dev tailwindcss@3.3.2

Then, run npx tailwindcss init to create a tailwind.config.js file



// tailwind.config.js

module.exports = {
content: ["./App.{js,jsx,ts,tsx}", "./<custom directory>/**/*.{js,jsx,ts,tsx}"],
  theme: {
    extend: {},
  },
  plugins: [],
}
Modify your babel.config.js



// babel.config.js
module.exports = function (api) {
  api.cache(true);
  return {
    presets: ["babel-preset-expo"],
    plugins: ["nativewind/babel"],
  };
};

Believe it or not, that's it 🎉! Now your React Native app is eligible to use Tailwind CSS classes, just like your frontend app. Isn't that cool?

Modify your App.js like this:



import { StatusBar } from "expo-status-bar";
import React from "react";
import { Text, View } from "react-native";

export default function App() {
  return (
    <View className="flex-1 items-center justify-center bg-gray-600">
      <Text className="text-yellow-200 text-3xl">Hey! Welcome.</Text>
      <StatusBar style="light" />
    </View>
  );
}

Run your app, and you will see the effects of the Tailwind CSS styles in your app as shown below:

That's great! In this article, you learned a little bit about NativeWind, what it is, how it helps us in React Native, and how to integrate it with an Expo app.

About me

I am Syket Bhattachergee, Software Engineer at CreoWis. If you want to discuss your technical writing needs or any role? You can reach out to me on LinkedIn or My Website, and follow my work on GitHub.

Error handling in Next.js App Router

Syket Bhattachergee — Sat, 29 Jun 2024 08:40:29 +0000

If you've been working with Next.js 14 and you've spotted the error.js file in your directory, you might be wondering what it's all about. Well, you're in luck! Today, we're going to break down this file and see how it helps us out.

First of all, let's understand how the error file works. The error.js file convention allows you to gracefully handle unexpected runtime errors in nested routes.

Automatically protect each part of your route along with its nested parts using a React Error Boundary.
Design error displays are customized for each section by organizing files in a hierarchy.
Contain errors within specific sections while keeping the rest of your app running smoothly.
Implement features to try fixing errors without reloading the entire page.

One of the most important things is that the error.js file should be a client-side component. There is no option to make it a server-side component, as specified in the Next.js documentation. Let's look at the code of the error.js file:



'use client' // Error components must be Client Components

import { useEffect } from 'react'

export default function Error({
  error,
  reset,
}: {
  error: Error & { digest?: string }
  reset: () => void
}) {
  useEffect(() => {
    // Log the error to an error reporting service
    console.error(error)
  }, [error])

  return (
    <div>
      <h2>Something went wrong!</h2>
      <button
        onClick={
          // Attempt to recover by trying to re-render the segment
          () => reset()
        }
      >
        Try again
      </button>
    </div>
  )
}

Here is an overview of how error.js file work:

error.js creates a React Error Boundary around a specific component or page.js. It uses the exported React component from error.js as a backup. If an error occurs within this boundary, it's isolated, and the backup component is shown. Despite the error, layouts above the boundary stay functional, allowing for error recovery options within the backup component.

Recovering From Errors

If an error is temporary, retrying might fix it. Using the reset() function in an error component prompts users to try again. When reset() the Error Boundary attempts to re-render its contents. If successful, the fallback error component is replaced with the new result.



'use client'

export default function Error({

  error,

  reset,

}: {

  error: Error & { digest?: string }

  reset: () => void

}) {

  return (

    <div>

      <h2>Something went wrong!</h2>

      <button onClick={() => reset()}>Try again</button>

    </div>

  )

}

Nested Routes

Nested Routes in React involve rendering components in a structured hierarchy.

For instance, consider a scenario where two nested segments each contain layout.js and error.js files. This creates a hierarchy like this:

Nested Error Component Hierarchy

Errors propagate upwards to the nearest parent error boundary. This means that an error.js file will manage errors for all its nested child segments.
Adjustments to the granularity of error UI are possible by positioning error.js files at various levels within the nested route folders.
However, an error boundary defined in an error.js file won't handle errors from a layout.js component in the same segment, as the error boundary is nested within that layout's component.

Handling Errors in Layouts

Error boundaries defined error.js do not capture errors occurring in layout.js or template.js components within the same segment. This hierarchy is deliberate, ensuring that crucial UI elements shared among sibling routes, like navigation, remain accessible and usable during errors.

To manage errors within a particular layout or template, include an error.js file in the parent segment of that layout.

For handling errors within the root layout or template, utilize a variant named global-error.js.

When dealing with errors in root layouts:

The root app/error.js boundary doesn't handle errors from root app/layout.js or app/template.js components.
For handling errors in these root components, utilize a variant named app/global-error.js, placed in the root app directory.
Unlike app/error.js, global-error.js wraps the entire application, replacing the root layout with its fallback component when active. Thus, global-error.js must include its own and tags.
global-error.js serves as broad error handling for the entire application, less frequently triggered due to the static nature of root components. However, it's still advisable to have a root error.js file defining a fallback component within the root layout for consistent UI and branding.



// app/global-error.tsx

'use client'

export default function GlobalError({

    error,

    reset,

  }: {

    error: Error & { digest?: string }

    reset: () => void

  }) {

    return (

      <html>

        <body>

          <h2>Something went wrong!</h2>

          <button onClick={() => reset()}>Try again</button>

        </body>

      </html>

    )

  }

Handling Server Errors

When a Server Component encounters an error, Next.js forwards an Error object (with sensitive details removed in production) to the nearest error.js file as the error prop.

To protect sensitive data, in production, only a generic message and a digest property are sent to the client. The digest is a hash of the error useful for matching with server-side logs.

In development, the Error object sent to the client includes the original error message for easier debugging.

Conclusion

In conclusion, error files, such as error.js or global-error.js, serve as crucial components in React applications for defining error UI boundaries within route segments. They effectively catch unexpected errors, whether originating from Server Components or Client Components and display fallback UI to maintain a smooth user experience. These files offer functionalities like resetting error boundaries and ensuring error handling consistency throughout the application. Additionally, the distinction between error.js and global-error.js provides flexibility in managing errors at different levels, from specific layouts to the root application. By adhering to best practices and leveraging tools like React Developer Tools, developers can optimize error-handling mechanisms to enhance the reliability and usability of their React applications.

About me

How to create a Next.js 14 dynamic sitemap?

Syket Bhattachergee — Fri, 21 Jun 2024 04:27:13 +0000

What is a sitemap?

A sitemap is a file that contains a comprehensive list of all the pages on a website, along with their interrelationships. It plays a crucial role in aiding search engines to efficiently crawl and comprehend the structure of the website. Sitemaps also offer vital information about each page, such as its last update and frequency of changes. Particularly for larger or intricately structured websites, having a sitemap simplifies the process for search engines to discover and index all pages. According to Google, sitemaps prove beneficial for new websites with limited external links and those with content that lacks sufficient interlinking. In any scenario, integrating a sitemap can enhance a website's SEO by furnishing valuable insights to search engines and improving overall site navigation.

Is it necessary for my website?

Imagine your blog as a big library, and a sitemap as a well-organized catalog that helps people find books easily. Now, think of this catalog as not just static but magically updating itself whenever a new book arrives or an old one gets a makeover. That's what a dynamic sitemap does for your blog in the vast world of the internet.

Let's say your blog is built using Next.js 14 – a cool tool to create and manage your online library. The blog posts are like the books on your shelves, and the sitemap is your digital librarian, making sure search engines (like Google) and visitors can easily find and explore your literary treasures.

Now, the traditional way would be to manually update this catalog every time you add or change a book – quite a tedious job! But with a dynamic sitemap, it's like having a magical librarian who does this for you in real time. Every new blog post you publish or update is instantly added to the catalog, making it a breeze for search engines to know about your latest content and for readers to discover it.

Setting up your Next.js 14 project is like building the shelves and organizing the initial catalog. Once that's done, you teach your digital librarian to not only list the fixed sections but also dynamically add the latest books. This is where the coding magic happens.

If you publish a new blog post, your sitemap automatically updates to include it. No need to manually tell the librarian about each new book – it's taken care of. This ensures that your library (blog) is always up-to-date, easily found by search engines, and provides a smooth reading experience for your visitors.

For instance, create a "sitemap.js" file in your app directory for dynamic generation.

import { getAllPosts } from "./queries";

const sitemap = async () => {
  const BASE_URL = "https://www.YOUR_DOMAIN.com/";

  const posts = await getAllPosts();

  const postURLS =
    posts?.length > 0
      ? (posts[1] || []).map((post) => ({
          url: `${BASE_URL}/blog/${post?.slug}`,
          lastModified: new Date(post?.publishedAt),
        }))
      : [];

  return [
    {
      url: BASE_URL,
      lastModified: new Date(),
    },
    {
      url: `${BASE_URL}/blog`,
      lastModified: new Date(),
    },
    ...postURLS,
  ];
};
export default sitemap;

You're done! Now you know how to generate it dynamically.

How to reduce unused JavaScript in your code?

Syket Bhattachergee — Thu, 20 Jun 2024 06:00:37 +0000

Cutting down on JavaScript is super important when you're building modern websites. It's a big deal for making your pages work well and be more efficient overall.

As technology in software keeps growing, everyone wants websites to be quicker and work better, with less JavaScript taking up space. If you have extra JavaScript that you're not using, it just makes your web apps bigger and slower.

This article will show you some tricks and tips to get rid of this extra JavaScript, so you can save time, make your website work faster, and make things run more smoothly.

What is unused JavaScript?

Simply put, unused JavaScript, often referred to as "dead code," is any code in your web app that the app doesn't use or require, yet it's still present in the JavaScript bundle sent to the browser. This idle code just hangs around, making your JavaScript bundle larger, and that can affect how well your website performs.

There are a few reasons why you might have unused code in your JavaScript bundle.

One common reason is that you added code during development, but as your project progressed, you ended up not needing it anymore. Unfortunately, you might forget to take it out when you send the final bundle to the browser. This unused code could be functions, classes, or variables that are just sitting there, not doing anything in your app.

Another reason could be unused dependencies. This means you're using external JavaScript code in your project that you don't need. What's worse, these external bits of code might have their own unused JavaScript, adding even more unnecessary stuff to your project. It's like having extra baggage that your website doesn't need, and it can slow things down.

Removing unused code:

You can get rid of unused JavaScript in your web apps using a few methods. These tips and tricks will assist you in sending out JavaScript bundles that are stronger and work more efficiently on the web, whether you're using basic JavaScript or specific libraries/frameworks such as React, SolidJS, or Vue.js.

Code Splitting:

Code splitting is like breaking down your JavaScript code into smaller, more manageable pieces. Then, you can load these pieces when you need them or all at once, making it so you don't have to load your entire JavaScript package every single time—just what you need.

Imagine having just one JavaScript bundle that looks something like this:



<script src="main.js"></script> // 100kb file

You can split it into smaller chunks that can be downloaded only when needed:



<script async defer src="chunk1.js"></script> // 30 kb file
<script async defer src="chunk2.js"></script> // 30 kb file
<script async defer src="chunk3.js"></script> // 30 kb file

This approach lessens the overall network load on the main thread, which is in charge of kicking off and fetching JavaScript scripts:

If you're working with a JavaScript library or framework such as Next.js or Vue, you don't have to do this yourself — many modern JavaScript frameworks automatically take care of code splitting.

Yet, you can assign certain components for server-side use only. This helps the framework intelligently break down JavaScript into even smaller parts that don't need to be bundled with client-side JavaScript chunks.

A lot of organizations put this strategy to use in real-world scenarios, showing how effective it is. Let's take a look at how code splitting works on the React website as an example:

Tree shaking:

Tree shaking is about getting rid of useless code, which means cutting out the JavaScript that your app doesn't use. When you're putting together your JavaScript chunks to send to the browser, a bunch of popular bundlers like Webpack, Rollup, or Vite use a tree-shaking technique to make sure only the necessary stuff makes it into the mix.

To make sure tree shaking works in your bundle, stick to the modern ES6 syntax in your JavaScript components. That means using the import and export syntax.



// default import
import Header from 'Components'
// named import
import { Header } from 'Components'

// default export
export default Header
// named export
export { Header }

The modern ES6 syntax assists your bundler in spotting dead code, much like how ESLint signals if there's an imported component that isn't used anywhere.

JavaScript modification:

Having less JavaScript in your bundle translates to a quicker download for the browser. To keep your JavaScript file as compact as possible, make sure to minify it before sending it out.

Minifying JavaScript involves removing unnecessary elements like whitespaces, syntax highlighting, comments, and other parts of the code that aren't essential for the final production build. These extra bits can bloat the bundle with unused code.

Even seemingly straightforward JavaScript code can be condensed and tweaked. Take a look at this example of basic JavaScript code before the minification process:



// multiply function
const multiply = (a, b) => {
   return a * b
}

// call multiply function
multiply(3, 4)

Here’s how this code looks after minification:



const multiply = (a, b) => a * b;
multiply(3, 4);

Think about the impact minifying JavaScript could have on extensive bundles!

Minifying JavaScript is simpler than you'd imagine. There are various online tools for JavaScript minification, like Terser, Uglify, babel-minify, and others that you can choose from.

Load JavaScript asynchronously:

Here's a handy tip that can save you a bunch of time on network bandwidth: always load your JavaScript asynchronously.

You can achieve this by adding 'async' and 'defer' to your JavaScript scripts. This makes sure that downloading JavaScript won't hold up or stop your HTML from being parsed or displayed while the JavaScript is loading.

Both 'async' and 'defer' manage the downloading and execution of JavaScript scripts, but they do it in a slightly different order. You can choose what works best for your project.

An async JavaScript script works as shown in this image:

Meanwhile, a defer JavaScript script works like so:

In lots of situations, using both 'async' and 'defer' does the trick nicely. Here's an example of how you can write this:



<script async defer src="main.js"></script>

Dynamic Imports

Now, with ES6 modules in plain JavaScript, you can pull off dynamic imports. These come in handy when you need to load JavaScript modules or scripts based on certain conditions. Here's how you'd write dynamic imports:



import('./helper.js')
  .then((module) => {
    // use helper code here
  })
  .catch((error) => {
    // catch errors
});

This approach lets us ask for a JavaScript bundle once specific conditions are fulfilled, instead of importing every JavaScript component right at the beginning of the file. Check out this code snippet where the module loads only after the event listener is attached:



document.getElementById('dashboard').addEventListener('click', () => {

  import('./helper.js')

    .then((module) => {

      // Use helper module APIs

      module.callSomeFunction();

    })

    // catch unexpected error here

    .catch((error) => {

      console.error("Oops! An error has occurred");

    });

});

Lazy loading technique

Lazy loading in JavaScript is a simple yet super handy technique. When done right, it can save your network bandwidth. The basic idea is to only load the JavaScript modules that you need at that moment.

One smart trick is to load JavaScript based on the height of the viewport. Let's say you have a super long list of users. It wouldn't make sense to load the details of, let's say, the 430th user when that info isn't visible on the current screen.

Some cool libraries handle this. They make sure your JavaScript modules only load when a specific user, like the 430th, shows up on the screen.

And guess what? Lazy loading isn't just for lists. It works for other things too, like images, videos, a bunch of nodes, and more. For instance, you can show a placeholder first, and then the actual image and its related JavaScript get downloaded by the browser.

These tricks not only help in sending less JavaScript code but also make the user experience a whole lot better.

Conclusion

In this article, we covered six techniques to send out less JavaScript and boost your project's performance.

Remember, each project is unique with its architecture and patterns. While many of the tips we talked about should be helpful, not all may fit your specific situation.

Trust your instincts to figure out what suits you and your project the best. This way, you can make your websites and apps stronger with confidence.