DEV Community: Sumit Saha

Hoisting is clear now!

Sumit Saha — Fri, 30 May 2025 10:36:21 +0000

Sumit Saha

May 29 '25

JavaScript Hoisting + Temporal Dead Zone made easy

#javascript #webdev #programming #beginners

Comments 5

4 min read

JavaScript Hoisting + Temporal Dead Zone made easy

Sumit Saha — Thu, 29 May 2025 19:41:00 +0000

You write JavaScript. You log a variable... and boom – "undefined" or even a scary "ReferenceError"! What just happened?!
Let's finally understand what's going on – once and for all – with a real story!! In this article, I'm going to explain what Hoisting really is and break down the mysterious concept of the Temporal Dead Zone in a way that actually makes sense. After reading this, if anyone asks you about these in a job interview - you'll have the perfect answer, no more confusion.

If you prefer watching over reading, I've also created a video tutorial with animated explanations and a live coding demo. Feel free to check it out below before diving into the details:

If you prefer reading over watching video, let's continue.

Meet Sam. Every morning, Sam goes to a coffee shop.
One day, before the waiter even arrives, Sam shouts: "I'll have my regular coffee!"

The waiter is confused. "Uh… we haven't even given you the menu yet, sir!"
Turns out, they changed the menu yesterday — no more regular coffee!

This is exactly what happens when you try to use a variable before declaring it. You're shouting at JavaScript: "Give me the value!"
But JS says: "Hold on — I haven't seen that variable yet!"

Now let's reveal the real twist: JavaScript does know that the variable exists! It just hasn't given it a value yet.

Why?

Because of something called: "Hoisting."
Hoisting means "lifting or moving something above."
JavaScript moves all declarations — not values — to the top of the scope.

Hoisting in Global Scope

Let's first understand the difference between Declaration and Initialization.

Declaration is when you tell JavaScript that a variable exists.
Initialization is when you assign a value to it.

console.log(coffee); // 👉 undefined
var coffee = 'Latte';

Check the example above. Here, we have declared a variable called coffee and assigned its value to 'Latte'.
So var coffee — is the declaration, and coffee = 'Latte' is the initialization.

When we run this code, we see undefined — not an error!

Because behind the scenes, JavaScript rewrote the code like this:

var coffee;
console.log(coffee); // still undefined
coffee = 'Latte';

So var is hoisted and initialized as undefined.
Only the declaration part (var x) is lifted or hoisted to the top of the scope.
This is called "Hoisting"! It only affects declarations — initializations stay where they are.
That's why coffee = 'Latte' — this remains in the same place or line.

👉 This is the first rule you have to remember.

We saw the use case with var.
What about let?
Now we will see how let and const behave. See this example:

console.log(tea); // ❌ ReferenceError!
let tea = 'Green Tea';

Here, we tried to log the value of tea before it was declared and initialized — but this time, we get a ReferenceError!
That means JavaScript has no reference to the tea variable at that point.

Surprising, right?
It shows that let behaves differently from var!
Let's take a closer look to understand what's really going on.

Because variables declared with let and const are also hoisted — but they are kept in something called the "Temporal Dead Zone" or TDZ.

What does that mean?
Well, TDZ is the time between when the scope starts and when the variable is declared.

// → scope starts here
console.log(tea); // ❌ ReferenceError!
// ↓ variable is declared here
let tea = 'Green Tea';

During this time, the tea variable is in the Temporal Dead Zone,
which means — in this period — the variable exists, but you're not allowed to touch it!

Think of it like this:

You're at an event.
There's a gift with your name on it.
But the host says: "Don't touch it until I officially hand it to you."

If you touch it too early — boom!!! — ReferenceError!!

Let's summarize this in one simple table:

So yes — hoisting happens for all.
But only var is accessible before the line where it's declared — not let and const.

👉 This is the second rule you need to remember.

Hoisting in Block Scope

So far, we have seen hoisting in Global Scope. Now let's check what happens inside Block Scope.

Check the code example shown below:

{
  console.log(msg); // ❌ ReferenceError
  let msg = 'Hello';
}

Here, the rule is also the same.
Block-scoped variables like let and const hoist within that block only — will not go out of the block — and are still in the "Temporal Dead Zone".

{
  console.log(num); // ✅ undefined
  var num = 10;
}

And var is function-scoped, not block-scoped.
So it still works — badly — even inside a block.
Simple!

Now see what happens for functions:

greet(); // ✅ Works
function greet() {
  console.log('Good morning!');
}

Function declarations are fully hoisted — including the body.
So you can call greet() before it's declared, and it works fine.

sayBye(); // ❌ TypeError
const sayBye = function() {
  console.log('Bye!');
};

But this doesn't work. Because sayBye is a const.
So it follows the "Temporal Dead Zone" rule — not the function rule.

Same rule applies to the arrow functions as well!

So: Function declarations and function expressions work differently!

Here are my tips or best practices to avoid hoisting confusion:

✅ Always declare variables at the top of their scope
✅ Use let and const — avoid var
✅ Don't rely on hoisting — it's a behavior, not a feature
✅ Structure your functions to read top-down
✅ Use linters like ESLint — they can catch "Temporal Dead Zone" bugs

Here's the mindset tip I promised:

Think of Hoisting as JavaScript's pre-processing stage.
It scans your code before running it — pulling up declarations, but not their values.

So next time your code acts weird — don't panic.

✅ Check for Hoisting
✅ Check for Temporal Dead Zone

And write your code like you respect the timeline.

Thanks for reading this complete guide to JavaScript Hoisting!

If this helped you:

👍 Like the article
💬 Comment: "Hoisting makes sense now!"
🔔 Follow me for more clear JS lessons

Keep learning, and keep building. See you next time!

Learn Next.js 15 the Fast Way — Build a Recipe Sharing App from Scratch in 10 Minutes

Sumit Saha — Wed, 28 May 2025 09:12:19 +0000

Let’s say you’re a React developer. You love building stuff — but juggling routing, API endpoints and SEO - feels like cooking with too many stoves at once. What if you had just one pan that does it all? That’s where Next.js comes in. It’s packed with powerful new features that make building modern web apps faster and more efficient than ever. In this article, I’ll give you a quick yet comprehensive overview of what’s new and how it fits into your development workflow — all by building a simple and quick Recipe Sharing App.

If you prefer watching over reading, I’ve also created a video tutorial with animated explanations and a live coding demo. Feel free to check it out below before diving into the details:

If you prefer reading over watching video, let's continue. Next.js is a React framework that turns you into a full-stack developer — even if you don’t want to be. And in this article, we’re building a Recipe Sharing App to explore how Next.js works and why it makes React - feel complete.

Installation

We’ll start with a blank kitchen. Open up your terminal and type:

npx create-next-app@latest recipe-app

Go with the default options — no TypeScript, no strict mode — just hit enter a few times. Once it’s done, head into the folder cd recipe-app and start the development server:

npm run dev

Your app is live on localhost:3000.

App Router & File-based Routing

That default page you see? That’s coming from a file called app/page.js. Yes — in Next.js, routing is file-based. If you create a file, you create a page.

So let’s make our homepage say something like: "Welcome to Recipe App!" — feel free to add some Tailwind CSS classes if you want it to look slightly less boring.

// app/page.js
export default function Page() {
  return <h1 className="text-center font-bold p-20">Welcome to Recipe App!</h1>;
}

Now we need an "Add Recipe" page. Just make a new folder named add, and inside it, a file called page.js. Return any JSX you want — maybe just a form placeholder for now.

// app/add/page.js
export default function Add() {
  return <form className="text-center font-bold p-20">Add recipe</form>;
}

Visit /add in your browser. Next.js has already mapped the route. That’s it. No router setup! No config files! You just build!

Let’s make it dynamic. Say we want a page for each recipe — like /pizza or /sushi. We’ll create a folder called [recipeId] with a page.js file inside. Yes, square brackets. They turn it into a dynamic route.

Now when someone visits /burger, the component inside this page will receive a params object where recipeId is 'burger'. You can fetch the recipe from a database, or just mock it for now. It works like URL magic!

// app/[recipeId]/page.js
export default async function Recipe({ params }) {
  const { recipeId } = await params;

  return (
    <h1 className="text-center font-bold p-20">{recipeId}</h1>
  );
}

Layouts & SEO

But our app needs a consistent layout — maybe a navbar that shows up on every page. That’s what app/layout.js file is for. This file wraps your entire app.

Add a nav section with two links — one to /, and one to /add. But don’t use regular anchor tags — use Next.js’s built-in <Link> component instead. It enables client-side navigation without full page reloads. Fast and smooth, like flipping through a cookbook.

// app/layout.js
import Link from "next/link";

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        <nav className="text-sm flex justify-center space-x-8 p-20">
          <Link href="/">Home</Link>
          <Link href="/add">Add Recipe</Link>
        </nav>
        {children}
      </body>
    </html>
  );
}

While we’re in layout.js, let’s do some SEO. Next.js lets you export a metadata object. Just add it with page title and description:

// app/layout.js
export const metadata = {
    title: "Recipe World",
    description: "Discover and share recipes from around the world.",
};

Each page can have its own SEO data. In dynamic routes like [recipeId]/page.js, use the generateMetadata function. Grab the recipeId from params, and return a custom title and description based on it. Now every page is SEO optimised without any extra plugin.

// app/[recipeId]/page.js
export async function generateMetadata({ params }) {
  const { recipeId } = await params;

  return {
    title: `${recipeId} title`,
    description: `${recipeId} description goes here`,
  };
}

Server vs Client Components

Time to talk rendering. In Next.js, there are two types of components: Server and Client. By default, everything inside the app folder is a Server Component. That means it's rendered on the server, then sent as HTML. Fast and SEO-friendly.

But if you need interactivity — like a form — just add the directive "use client" at the top of the file. Now you can use hooks like useState, useEFfect etc. Think of it like this: the server cooks the meal, and the client sprinkles the garnish!

// app/add/page.js
"use client";
import { useState } from "react";

export default function Add() {
  const [title, setTitle] = useState("");

  const handleSubmit = async (e) => {
    e.preventDefault();
    console.log(`Form submitted with recipe title: ${title}`);
  };

  return (
    <div>
      <form
        onSubmit={handleSubmit}
        className="text-center font-bold p-20 flex flex-col gap-10"
      >
        <input
          className="border border-slate-800 outline-0 px-4 py-2 rounded"
          placeholder="Enter recipe title"
          type="text"
          value={title}
          onChange={(e) => setTitle(e.target.value)}
        />

        <input
          type="submit"
          value="Submit"
          className="bg-gray-800 py-2 rounded"
        />
      </form>
    </div>
  );
}

Data Fetching: SSR, SSG, ISR

Let’s fetch some data. In app/page.js, make your component async. Inside it, fetch some recipes from a fake API — or just return a hardcoded array. Because it’s a Server Component, the fetch happens on the server. The page is pre-rendered and delivered with data.

// app/page.js
import Link from "next/link";

export default async function Home() {
  const res = await fetch("https://dummyjson.com/recipes");
  const recipes = await res.json();

  return (
      <ol className="ml-auto text-center">
        {recipes.recipes.map((recipe) => (
          <li key={recipe.id}>
            <Link href={`/${recipe.id}`}>{recipe.name}</Link>
          </li>
        ))}
      </ol>
  );
}

For dynamic pages like [recipeId], use the params object to get the ID and fetch that specific recipe.

// app/[recipeId]/page.js
export default async function Recipe({ params }) {
  const { recipeId } = await params;

  const res = await fetch(`https://dummyjson.com/recipes/${recipeId}`);
  const recipe = await res.json();

  return (
    <div className="flex flex-col justify-center items-center">
      <h1 className="text-center font-bold p-5">{recipe.name}</h1>
    </div>
  );
}

Everything renders ahead of time in build-time — or "on request" — depending on how you configure it. Speaking of which, let’s talk SSG, SSR, and ISR techniques - Three ways to render a page.

Static Site Generation (SSG) means, the page is built at build time. Perfect for your homepage — just fetch the data once and ship the HTML.

Server-Side Rendering (SSR) means, it’s rendered on every request. Use this for pages that need to stay fresh — like individual recipes.

But there's a hybrid mode called Incremental Static Regeneration (ISR). It works like SSG, but regenerates in the background after a set time. Just add a revalidate option to your fetch logic. It keeps things fast — and up to date.

// app/page.js
const res = await fetch("https://dummyjson.com/recipes", {
  next: {
    revalidate: 60, // seconds
  },
});
const recipes = await res.json();

For dynamic routes, if you already know which pages to pre-build, export a generateStaticParams() function. Return an array of known recipe IDs. Now those pages will be statically generated too.

// app/[recipeId]/page.js
export async function generateStaticParams() {
  const recipes = await fetch("https://dummyjson.com/recipes").then((res) =>
    res.json(),
  );

  return recipes.recipes.map((recipe) => ({
    recipeId: recipe.id.toString(),
  }));
}

API Routes in App Directory

Let’s accept user input. In app/api/recipes/route.js file, export a POST handler that takes "form data" and responds with a success message. That’s your API endpoint — right there in the app folder.

// app/api/recipes/route.js
import { NextResponse } from "next/server";

export async function POST(request) {
  const { title } = await request.json();

  // ← here you could insert into a database, etc.
  console.log("New recipe title:", title);

  return NextResponse.json(
    { message: "Recipe added successfully!", recipe: { title } },
    { status: 201 },
  );
}

On the Add Recipe page, when the user submits the form, send a fetch request to ('/api/recipes') route with the form data. You now have full-stack functionality without writing any Express JS code.

Styling

Time to make things look good. Next.js supports any styling method, but Tailwind CSS makes it stupid easy. Add some classes like text-center, bg-gray-100, p-4 etc. You can also create CSS Modules or edit globals.css if you want more control.

Loading & Streaming

Let’s polish the user experience with a loading state. Inside [recipeId] folder, create a file called loading.jsand return a skeleton loader:

// app/[recipeId]/loading.js
export default function Loading() {
  return (
    <div className="max-w-lg m-auto">
      <div className={`animate-pulse space-y-4`}>
        <div className="h-4 bg-gray-200 rounded w-3/4"></div>
        <div className="space-y-2">
          <div className="h-4 bg-gray-200 rounded"></div>
          <div className="h-4 bg-gray-200 rounded w-5/6"></div>
        </div>
      </div>
    </div>
  );
}

When the page is loading, Next.js will automatically show this.

Next.js also supports streaming — meaning parts of the page can show up while others are still rendering. You can wrap components in <Suspense> boundary with a fallback for loading states.

// app/page.js
import { Suspense } from "react";
import dynamic from "next/dynamic";

// Dynamically import any HeavyComponent component with suspense support
const HeavyComponent = dynamic(() => import("./components/heavy-component"), {
  suspense: true,
});

export default async function Home() {
  return (
    <div>
      <h1>Recipe App</h1>
      {/* Suspense boundary with a fallback */}
      <Suspense
        fallback={
          <h1 className="text-center font-bold pb-20">
            Loading user profile...
          </h1>
        }
      >
        <HeavyComponent />
      </Suspense>
    </div>
  );
}

In this example, the page and heading load instantly, while HeavyComponent streams in once it’s ready.

Error handling

Now let’s handle errors. If a recipe doesn't exist, you can throw a notFound() method. Next.js will show the not-found.js page in your app folder.

// app/[recipeId]/page.js
export default async function Recipe({ params }) {
  const { recipeId } = await params;

  // throw new Error("Something went wrong");

  const res = await fetch(`https://dummyjson.com/recipes/${recipeId}`);
  const recipe = await res.json();

  if (!recipe.id) notFound();

  return (
    <div className="flex flex-col justify-center items-center">
      <Image alt={recipe.name} src={recipe.image} width={200} height={200} />
      <h1 className="text-center font-bold p-5">{recipe.name}</h1>
    </div>
  );
}

// app/not-found.js
export default async function NotFound() {
  return (
    <h1 className="text-center p-20 font-bold">
      The requested resource was not found!
    </h1>
  );
}

If you want route-specific error handling, drop an error.js file inside [recipeId] folder. It catches any rendering errors on that route. No white screens. No crashes.

// app/[recipeId]/error.js
"use client"; // Error boundaries must be Client Components

import { useEffect } from "react";

export default function Error({ error, reset }) {
  useEffect(() => {
    // Log the error to an error reporting service
    console.error(error);
  }, [error]);

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

Image & Font optimization

Next.js is optimised by default. Use the <Image> component for automatic image optimisation. It serves responsive images with lazy loading.

// app/[recipeId]/page.js
import Image from "next/image";

export default async function Recipe({ params }) {
  // ... fetch recipe code

  return (
    <div className="flex flex-col justify-center items-center">
      <Image alt={recipe.name} src={recipe.image} width={200} height={200} />
      <h1 className="text-center font-bold p-5">{recipe.name}</h1>
    </div>
  );
}

For fonts, import them in layout.js using the next/font utility. You can see the font usage in the default layout.js file already!

Route groups & Parallel Routes

Let’s level up the routing. Create a folder like (admin)/dashboard/page.js. This groups it logically but doesn’t affect the URL — so the path is still /dashboard, but now you can separate admin-only stuff. These are route groups.

Want parallel routes? Inside the dashboard folder, create folders like @myRecipes and @favorites, each with their own page.js file. Both will render side-by-side inside a shared layout. It’s like two sections of your dashboard, loading independently.

// app/(admin)/dashboard/layout.js
export default function AdminLayout({ children, favorites, myRecipes }) {
  return (
    <div>
      {children}

      <div className="grid grid-cols-2 gap-10 px-10">
        {favorites}
        {myRecipes}
      </div>
    </div>
  );
}

Authentication with NextAuth

Time to lock it down. Use Auth.js — formerly known as NextAuth — to set up authentication. Add Google login, and protect routes like /add or /admin by checking if the user is signed in. You now have a secure recipe app.

Middleware

Want more power? Use Middleware. Create a middleware.js file to intercept requests, redirect users, rewrite URLs, or block access. You can also add internationalization with built-in i18n support to make your app multilingual.

// ./middleware.js
export { auth as middleware } from "@/auth";
import Google from "next-auth/providers/google";

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [Google],
});

export function middleware(request) {
  return new Response("Access Denied", {
    status: 403,
    statusText: "Forbidden",
    headers: { "content-type": "text/plain" },
  });
}

// matching paths
export const config = {
  matcher: "/about/:path*",
};

Deploy to Vercel

Finally — let’s deploy. Push your code to GitHub, then connect it to Vercel - the company who built Next.js. Click deploy. You’re live in seconds. You can also run npm run build and host it anywhere — Netlify, VPS, whatever you want.

Wrap-up

And that’s a wrap. We built a full Recipe App with routing, layouts, API routes, SEO, authentication, and advanced rendering — all using just one framework: Next.js.

The full code is on GitHub. Check out the Next.js official documentation to dive deeper into this powerful React Framework.