So here's the thing - I got tired of the same old portfolio websites. You know the ones: scroll, read, click, repeat. Boring.

I wanted something different. Something that would make people go "wait, what?" when they landed on my site. That's when I had this wild idea: what if people could just... talk to my portfolio? Like, actually have a conversation with it?

Fast forward a few weeks of research, and boom - I built a voice-interactive digital twin. Visitors can now chat with an AI version of me that knows everything about my projects, experience, and skills. No typing, no clicking buttons to record - just pure conversation.

In this article, I'll show you exactly how I built this thing, from the voice detection magic to the trippy visual effects that react to your voice. Spoiler alert: it involves machine learning, AI APIs, and some shader wizardry that would make your GPU sweat.

What you're about to learn:

• How Voice Activity Detection works (and why it's cooler than it sounds)

• Building a complete voice conversation pipeline without losing your sanity

• Making WebGL shaders dance to your voice

• Real problems I ran into and how I fixed them

• Why my API bills went up (worth it though)

Wait, What's Voice Activity Detection?

Before we dive in, let me explain VAD (Voice Activity Detection) because it's the secret sauce that makes everything work.

Imagine you're on a Zoom call and the app knows exactly when you're talking. It's not just listening for "loud noises" - it's actually smart enough to tell the difference between you saying "hello" and your dog barking in the background. That's VAD in action.

VAD uses machine learning models trained on tons of audio data to detect actual human speech vs everything else:

• Your mechanical keyboard clicking away

• The ambulance siren outside

• That Spotify playlist you forgot to pause

• Your roommate yelling at their video game

Why This Matters

Here's the problem with traditional voice interfaces: they're annoying. You have to:

1. Click a button to start recording

2. Say your thing

3. Click another button to stop

4. Hope you didn't forget to click

It's like having to knock on someone's door, wait for them to answer, then knock again when you're done talking. Weird, right?

With VAD, the app just... knows. It hears you start talking, listens to what you say, and processes it when you're done. Hands-free. Magical. Just like talking to Alexa, but on a website.

The Tech Stack (AKA What I Glued Together)

Alright, let me show you the pipeline I built. It's basically a Rube Goldberg machine for voice, but it works beautifully:

The Tools I Used (And Why)

Building The Thing (The Fun Part)

Step 1: Getting VAD to Work
Setting up VAD was easier than I expected. Here's the basic setup:

import { useMicVAD } from '@ricky0123/vad-react';

const vad = useMicVAD({
  startOnLoad: false, // Don't be creepy, wait for permission

  // These CDN links load the ML models
  baseAssetPath: "https://cdn.jsdelivr.net/npm/@ricky0123/vad-web@0.0.27/dist/",
  onnxWASMBasePath: "https://cdn.jsdelivr.net/npm/onnxruntime-web@1.22.0/dist/",

  // Fine-tuning the detection
  positiveSpeechThreshold: 0.5,   // "Yep, that's definitely speech"
  negativeSpeechThreshold: 0.35,  // "Nope, not speech anymore"

  // The cool part - event callbacks
  onSpeechStart: () => {
    setConversationState('listening');
    // Time to pay attention!
  },

  onSpeechEnd: (audio: Float32Array) => {
    setConversationState('thinking');
    // Got your audio, now let me process it
    const audioBlob = float32ArrayToWavBlob(audio, 16000);
    processSpeechAudio(audioBlob, 'vad');
  },

  onVADMisfire: () => {
    setConversationState('idle');
    // False alarm, my bad
  },
});

The threshold thing: I set it to 0.5 to start listening and 0.35 to stop. This gap prevents the annoying flicker between "is talking" and "not talking" when you pause mid-sentence. Without it, every breath would trigger a stop. Trust me, I learned this the hard way.

Step 2: Making Visual Feedback That Actually Responds

One of the coolest parts was making the UI react to your voice in real-time. I built a custom hook that calculates how loud you're talking:

export function useVadEnergy() {
  const [vadEnergy, setVadEnergy] = useState(0);
  const [smoothedEnergy, setSmoothedEnergy] = useState(0);

  const vad = useMicVAD({
    startOnLoad: false,
    onSpeechEnd: (audio: Float32Array) => {
      // Math time! Calculate how loud the audio is
      let sum = 0;
      for (let i = 0; i < audio.length; i++) {
        sum += audio[i] * audio[i];
      }
      const rms = Math.sqrt(sum / audio.length);
      setVadEnergy(rms);
    },
    onVADMisfire: () => setVadEnergy(0),
  });

  // Smooth out the values so animations don't look jerky
  useEffect(() => {
    const interval = setInterval(() => {
      setSmoothedEnergy(prev => prev + (vadEnergy - prev) * 0.2);
    }, 50); // Update 20 times per second
    return () => clearInterval(interval);
  }, [vadEnergy]);

  return { vadEnergy: smoothedEnergy, vad };
}

This calculates something called RMS (Root Mean Square) energy, which is a fancy way of saying "how loud is this audio?" The smoothing part makes sure the animations don't spaz out when your voice volume changes suddenly.

Step 3: Audio Format Hell (Fun Times)

Okay, this part wasn't actually fun. It was terrible. But I figured it out!

The VAD library gives you audio as a Float32Array (basically an array of decimal numbers), but Google Gemini wants a WAV file. So I had to write a converter:

function float32ArrayToWavBlob(float32Array: Float32Array, sampleRate: number): Blob {
  // Create a buffer for the WAV file (44 bytes for header + audio data)
  const buffer = new ArrayBuffer(44 + float32Array.length * 2);
  const view = new DataView(buffer);

  // Helper to write strings into the buffer
  const writeString = (offset: number, string: string) => {
    for (let i = 0; i < string.length; i++) {
      view.setUint8(offset + i, string.charCodeAt(i));
    }
  };

  // WAV header stuff (this is standard WAV format)
  writeString(0, 'RIFF');
  view.setUint32(4, 36 + float32Array.length * 2, true);
  writeString(8, 'WAVE');
  writeString(12, 'fmt ');
  view.setUint32(16, 16, true);
  view.setUint16(20, 1, true);  // PCM format
  view.setUint16(22, 1, true);  // Mono
  view.setUint32(24, sampleRate, true);
  view.setUint32(28, sampleRate * 2, true);
  view.setUint16(32, 2, true);
  view.setUint16(34, 16, true); // 16-bit
  writeString(36, 'data');
  view.setUint32(40, float32Array.length * 2, true);

  // Convert the float samples to 16-bit integers
  for (let i = 0; i < float32Array.length; i++) {
    const s = Math.max(-1, Math.min(1, float32Array[i]));
    view.setInt16(44 + i * 2, s < 0 ? s * 0x8000 : s * 0x7FFF, true);
  }

  return new Blob([buffer], { type: 'audio/wav' });
}

Yeah, I know. It looks painful. Basically, I'm manually creating a WAV file header and converting floating-point audio to 16-bit integers. Took me way too long to get this right, but now it works perfectly.

Step 4: The Three-Stage Conversation Pipeline

Once I have the audio, it goes through three APIs:

Stage 1: Speech → Text

export async function POST(req: Request) {
  const formData = await req.formData();
  const audioFile = formData.get('audio') as File;

  try {
    // Try Gemini first (it's faster)
    const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY!);
    const model = genAI.getGenerativeModel({ model: "gemini-2.5-flash" });

    const audioData = await audioFile.arrayBuffer();
    const base64Audio = Buffer.from(audioData).toString('base64');

    const result = await model.generateContent([
      {
        inlineData: {
          mimeType: 'audio/wav',
          data: base64Audio
        }
      },
      'Transcribe this audio to text. Return only the transcription.'
    ]);

    return NextResponse.json({ transcript: result.response.text().trim() });

  } catch (error) {
    // Gemini failed? No problem, Whisper to the rescue
    const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
    const transcription = await openai.audio.transcriptions.create({
      file: audioFile,
      model: 'whisper-1',
    });
    return NextResponse.json({ transcript: transcription.text });
  }
}

I use two providers because sometimes APIs have bad days. Gemini is faster, but if it fails, Whisper is super reliable.

Stage 2: AI Chat Response

This is where the "digital twin" part comes in. I built a knowledge base with all my info:

export async function POST(req: Request) {
  const { message, sessionId } = await req.json();

  // Search my knowledge base for relevant info
  const relevantInfo = searchKnowledge(message);

  const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY!);
  const model = genAI.getGenerativeModel({
    model: "gemini-2.5-flash",
    systemInstruction: `You are Sobit, a full-stack developer...

    VOICE MODE RULES (because nobody wants to hear a 5-minute response):
    - Keep it short - 2-4 sentences max
    - Aim for 15-30 seconds when spoken out loud
    - Be conversational, like you're chatting with someone
    - No bullet points (they sound weird when spoken)

    HERE'S WHAT'S RELEVANT:
    ${relevantInfo}`
  });

  const result = await model.generateContent(message);
  return NextResponse.json({ response: result.response.text() });
}

The knowledge base (portfolio-knowledge.ts) is just a big JSON object with everything about me - projects, skills, experience, etc. When someone asks about my projects, the AI gets that context and can answer accurately.

Stage 3: Making It Sound Human

Finally, I turn the AI response into speech using ElevenLabs:

export async function POST(req: Request) {
  const { text } = await req.json();

  const client = new ElevenLabsClient({
    apiKey: process.env.ELEVENLABS_API_KEY
  });

  const audio = await client.textToSpeech.convert(
    process.env.ELEVENLABS_VOICE_ID!,
    {
      text,
      model_id: "eleven_turbo_v2_5",
      voice_settings: {
        stability: 0.5,        // Not too robotic, not too wild
        similarity_boost: 0.5,  // Keep it consistent
        style: 0.0,            // Neutral tone
        use_speaker_boost: true // Make it clear
      }
    }
  );

  // Convert the audio stream to base64
  const chunks: Uint8Array[] = [];
  for await (const chunk of audio) {
    chunks.push(chunk);
  }
  const audioBuffer = Buffer.concat(chunks);
  const base64Audio = audioBuffer.toString('base64');

  return NextResponse.json({
    audio: base64Audio,
    mimeType: 'audio/mpeg'
  });
}

The voice settings took some tweaking. Too much stability and it sounds like a robot. Too little and it sounds drunk. 0.5 is the sweet spot.

Step 5: State Management (Keeping Track of What's Happening)

I use a simple state machine to track the conversation:

type ConversationState = 'idle' | 'listening' | 'thinking' | 'speaking';

The flow looks like this:

idle ──[you start talking]──► listening listening ──[you stop talking]──► thinking thinking ──[AI responds]──► speaking speaking ──[audio ends]──► idle (and back to listening)

Each state changes the UI colors, animations, and that glowing effect around the avatar. Makes it feel alive.

The Visual Magic (AKA The Fun Stuff)

The boring version would've been a static page with a microphone icon. But I wanted something that felt reactive - like the page was actually listening to you.

1. The Trippy Background Shader

I built a WebGL shader that creates this cloud-like effect that literally moves with your voice:

const fragmentShader = `
uniform float u_time;
uniform float u_voice_intensity;  // How loud you're talking (0-1)
uniform int u_conversation_state;  // What state we're in

// This creates organic, cloud-like patterns
float noise(vec2 p) {
  return fract(sin(dot(p, vec2(12.9898, 78.233))) * 43758.5453);
}

// Layer multiple noise patterns for complexity
float fbm(vec2 p) {
  float value = 0.0;
  float amplitude = 0.5;
  for(int i = 0; i < 5; i++) {
    value += amplitude * noise(p);
    p *= 2.0;
    amplitude *= 0.5;
  }
  return value;
}

void main() {
  vec2 uv = vUv;
  vec2 p = uv * 3.0 + u_time * 0.1;

  // HERE'S THE COOL PART - your voice distorts the pattern
  float distortion = u_voice_intensity * 0.3;
  p.x += sin(p.y * 10.0 + u_time) * distortion;
  p.y += cos(p.x * 10.0 + u_time) * distortion;

  float clouds = fbm(p);
  float voiceReaction = smoothstep(0.3, 0.7, clouds + u_voice_intensity * 0.5);

  // Pick colors based on what's happening
  vec3 baseColor;
  if(u_conversation_state == 0) baseColor = u_color_idle;
  else if(u_conversation_state == 1) baseColor = u_color_listening;
  else if(u_conversation_state == 2) baseColor = u_color_thinking;
  else baseColor = u_color_speaking;

  // Add a glow in the center that gets brighter when you talk
  float centerGlow = 1.0 - length(uv - 0.5) * 2.0;
  centerGlow = pow(centerGlow, 2.0) * u_voice_intensity;

  vec3 finalColor = mix(baseColor, baseColor * 1.5, voiceReaction);
  finalColor += vec3(centerGlow * 0.3);

  gl_FragColor = vec4(finalColor, 1.0);
}`
;

Every frame, I update the u_voice_intensity value based on your voice volume. The shader uses that to distort the cloud pattern. Louder voice = more distortion. It's mesmerizing to watch.

2. Pulsing Circles Around the Avatar

Three concentric circles that pulse and rotate:

const circles = [
  { delay: 0, scale: 1 },
  { delay: 3, scale: 1.1 },
  { delay: 6, scale: 1.2 },
];

return circles.map((circle, i) => (
  <motion.div
    key={i}
    className="absolute rounded-full border-2"
    animate={{
      scale: [1, 1.05 + (micVolume * 0.4), 1],  // Breathes with your voice
      opacity: [0.25, 0.5 + (micVolume * 0.5), 0.25],  // Pulses
      rotate: 360,  // Spins continuously
    }}
    transition={{
      duration: 8 + i * 3,  // Each circle rotates at different speeds
      repeat: Infinity,
      ease: 'easeInOut',
      delay: circle.delay,
    }}
  />
));

When you talk, they scale up. When you're quiet, they shrink. The colors change based on the conversation state:

• Green when listening

• Yellow when thinking

• Purple when speaking

3. The Avatar Itself

The profile picture scales and glows:

<motion.div
  animate={{
    scale: conversationState === 'listening' ? 1.05 :
           conversationState === 'speaking' ? 1.02 : 1,
    boxShadow: conversationState === 'listening'
      ? '0 0 50px rgba(59, 130, 246, 0.3)'  // Blue glow
      : conversationState === 'speaking'
      ? '0 0 50px rgba(168, 85, 247, 0.3)'  // Purple glow
      : conversationState === 'thinking'
      ? '0 0 50px rgba(234, 179, 8, 0.3)'   // Yellow glow
      : 'none',
  }}
>
  <Image src="/sobit.jpg" alt="Avatar" />
</motion.div>

Simple but effective. The glow color tells you exactly what's happening without reading any text.

Problems I Ran Into (And Fixed)

Problem 1: "Can I Use Your Mic?" Popup Hell

Modern browsers won't let you access the microphone without a user action (good for privacy, annoying for UX). I had to add a big "Start Conversation" button that triggers the mic request:

const handleStart = async () => {
  try {
    await vad.start();
    setIsListening(true);
  } catch (error) {
    // User said no or browser blocked it
    console.error('Microphone access denied:', error);
  }
};

Problem 2: "Why Is There A 5 Second Delay?"

At first, the response time was terrible. Like 7-10 seconds bad. I fixed it by:

• Using Gemini 2.5 Flash (way faster than the regular model)

• Telling the AI to keep responses short (2-4 sentences)

• Using ElevenLabs Turbo v2.5 for faster voice generation

Now it's 2-4 seconds from when you stop talking to when you hear the response. Much better.

Problem 3: Conversation Context

APIs are stateless, which means each request is treated like a brand new conversation. The AI would forget what we just talked about. I fixed this with session-based caching:

const conversationCache = new Map<string, Message[]>();

export async function POST(req: Request) {
  const { message, sessionId } = await req.json();

  // Load previous messages
  const history = conversationCache.get(sessionId) || [];

  history.push({ role: 'user', content: message });
  const response = await generateResponse(history);
  history.push({ role: 'assistant', content: response });

  // Save for next time
  conversationCache.set(sessionId, history);

  return NextResponse.json({ response });
}

Now the AI remembers the whole conversation. In production, I'd use Redis or a database, but for now this works.

Problem 4: Mobile Phones Hate Me

Running ONNX models and WebGL shaders on a phone made it laggy. Solution: detect mobile devices and simplify the effects:

const isMobile = /iPhone|iPad|iPod|Android/i.test(navigator.userAgent);
const shouldUseShaders = !isMobile && window.WebGL2RenderingContext;

Mobile users get simpler animations, desktop users get the full visual experience.

How It Performs in the Real World

After launching this thing:

VAD Accuracy:

• 95%+ accuracy detecting speech

• Less than 5% false positives (usually from very loud noises)

Speed:

• Speech end → Transcript: 1-2 seconds

• Transcript → AI response: 0.5-1 second

• Response → Audio playback: 1-2 seconds

• Total: 2.5-5 seconds (feels pretty instant)

User Engagement:

• People stay 3x longer than on my old static portfolio

• 70% of visitors try the voice feature

• Average 4-5 questions per session

Browser Support:

• Works perfectly on Chrome, Firefox, Safari, Edge (desktop)

• Works well on mobile Chrome and Safari (with reduced visuals)

What I'd Add Next

I've got some ideas for v2:

1. Actual 3D Avatar with Lip Sync

   • Use Ready Player Me for a 3D model

   • Make it actually mouth the words

   • Add facial expressions

2. Emotion Detection

   • Analyze the tone of your voice

   • Adjust the AI's personality (sympathetic, excited, etc.)

   • Change the visual vibe to match

3. Multi-Language Support

   • Auto-detect what language you're speaking

   • Respond in the same language

   • ElevenLabs supports 29+ languages

4. Conversation Analytics

   • Track what people ask about most

   • See which projects get the most interest

   • Use it to improve the knowledge base

5. Voice Options

   • Let users pick from different voice styles

   • Adjust speed and personality

   • Make it more personalized

Final Thoughts

Building this was one of the most fun projects I've done. It combines so many cool technologies - machine learning for VAD, AI for conversation, voice synthesis for speech, and WebGL for visuals.

A few years ago, this would've been impossible (or at least required a massive backend infrastructure). Now? Everything runs in the browser using modern web APIs and cloud services. The entire pipeline - from detecting your voice to playing a response - happens in seconds.

The craziest part? Most visitors don't even realize how complex it is. They just click "Start," ask a question, and get an answer. That's the dream - complex tech that feels simple and magical.

If you're thinking about adding voice features to your projects, I hope this gives you a starting point. VAD libraries like @ricky0123/vad-web make it way easier than building from scratch, and modern AI APIs are fast enough for real-time conversation.

The future of web interaction is conversational. The tools are ready. Go build something cool.

Resources & Links

Try it yourself: sobitprasad.com/chat

Tech I used:

• @ricky0123/vad-web - VAD library

• Google Gemini - AI brain

• ElevenLabs - Voice synthesis

• Three.js - Graphics

• Next.js - Framework

• Framer Motion - Animations

Useful reads:

• WebRTC getUserMedia docs

• ONNX Runtime Web

• The Book of Shaders

If you are an aspiring JavaScript developer, you will likely be asked whether JavaScript is synchronous or asynchronous.

And when you look around for the answers, you might get mixed answers for it. Some considered that JavaScript is synchronous while others say that it is asynchronous.

Then, what is the correct answer? Is it synchronous or asynchronous? Well, at its base JavaScript is synchronous but somehow it can be manipulated to work asynchronously.

But, how does it all happens? So, In this blog, we will dive deep and will try to understand how JavaScript is executed under the hood asynchronously.

Understanding Synchronous and Asynchronous

In JavaScript, both synchronous and asynchronous are different ways of executing the code.

Synchronous

Synchronous codes are executed in order, one statement at a time. Each statement must finish its execution before the next one is executed.

Think of it as a running race track, but only with one single track for all the athletes. Once the athlete at the very first reaches the finish line, then only the next athlete can start the race and so on.

Asynchronous

Asynchronous codes are executed out of order, multiple statements at a time. All the statements can be executed parallelly.

Think of it as a regular running race track, each track for each athlete. Here, the athletes don't have to wait for the other athletes to start the race.

Understanding JavaScript Engine

JavaScript engines are programs that help in executing the JavaScript code. They are typically responsible for compiling the JavaScript code from human-readable to machine-readable instructions.

There are several JavaScript Engines. Some of the most popular ones are :

• V8: It was developed by Google for use in the Chrome browser and is also used in Node.js.

• SpiderMonkey: It was developed by Mozilla for use in Firefox.

• Chakra: It was developed by Microsoft for use in the Edge browser.

How JavaScript Engine Compiles the Code?

JavaScript Engines have to go through multiple phases to compile the code from human-readable format to machine-readable format. So that, the computer can understand and executes the code.

When we give our code to JavaScript Engines, it has to go through - parsing, compilation and execution.

Every JavaScript Engine might have different algorithms to execute the code. However, the fundamentals of how JavaScript code is parsed, compiled, and executed are generally the same across different JavaScript engines.

Parsing Phase

During parsing, JavaScript Engines break down the code into its tokens such as keywords, identifiers, or operators. These tokens are used to form the Abstract Syntax Tree(AST) which is the high-level representation of the source code.

Let's take an example and see how it looks when it gets converted to Abstract Syntax Tree.

const hw = 'hello world';
console.log(hw);

The above code will be broken into individual tokens during a process called tokenization.

These tokens and the source code are then used to generate the Abstract Syntax Tree(AST).

See Abstract Syntax Tree in JSON format below.

open GitHub Gist

Compilation Phase

During compilation, JavaScript Engine takes the Abstract Syntax Tree(AST) and turns it into low-level bytecode that the computer understands. Let's see how it does.

In the beginning, JavaScript Engines uses interpreters to compile the code. The interpreter makes debugging easier because it stops and updates whenever it finds an error. But the interpreter works slower as it has to translate the code line-by-line.

An interpreter reads and executes the code line by line. As each line gets interpreted, it is executed by the computer, and the interpreter proceeds to the next line and so on.

To overcome the interpreter's inefficiency, JavaScript Engines started using compilers along with interpreters. Compilers are fast but debugging the code was slower.

A compiler translates the entire source code into machine language before it is executed.

And this is what we called a Just-in-Time(JIT) compilation. JIT uses the best of both interpreter and compiler. JIT compilers make debugging easier because of the interpreter and faster because of compilers.

Execution Phase

In most JavaScript engines, the compilation and execution of code happen concurrently and hand-in-hand, rather than in a strict sequential order.

As the code gets compiled, the JavaScript engine starts the execution before it has finished compiling the entire program and this is possible because of the JIT compiler.

In the execution phase, we have three important components - the call stack, the memory heap and the garbage collector. Let's understand each of them in the next section.

Understanding CallStack and Memory Management

When the code reaches the execution phase, it is the job of the call stack, memory heap and garbage collector to ensure that the programs run smoothly and efficiently.

So, what are their jobs, let's understand each of them.

Understanding Call Stack

When we say JavaScript is a single-threaded language, it means that it has only one call stack. The call stack can do only one thing at a time.

The job of the call stack is to track the execution context of a running program and it does by keeping track of all the functions that currently running.

It is based on Last-In-First-Out(LIFO) data structure, which means that the most recently called function is the first to be executed and the last to be completed.

So, whenever there’s a function call it gets pushed to the top of the stack. After it finishes executing it is removed from the top of the stack.

Understanding Memory Management

JavaScript Engines manage the memory for us, removing the burden of explicitly allocating and deallocating memory unlike we do in other programming languages like C or C++. Let's understand in brief how JavaScript Engines manage memory.

The three phases of the memory life cycle are allocation, utilization, and deallocation.

• allocation: reserving memory for a particular object or data structure.

• utilization: use of that memory by the program, which may involve reading from or writing to the memory.

• deallocation: releasing the memory when it is no longer needed, to make it available for other uses.

JavaScript Engines can allocate memory in two places, either on the stack or a memory heap.

Stack

All the primitive values like strings, numbers, booleans, undefined, and null are stored on the stack.

When we pass a variable having primitive values as a reference to a new variable, a copy of the value is passed to the new variable. So, changing the value of the new variable will not affect the one that is passed as a reference.

In the above example,

• We have assigned buy vegetables (a primitive value) to variable todoOne.

• Then we created another variable todoTwo and assigned it with the variable todoOne.

• Here, the copy of the value of the variable todoOne i.e. buy vegetables is assigned to the variable todoTwo.

• Then, we redeclared the variable todoTwo with exercise : 500 skipping. Here, re-declaring the variable todoTwo will not affect the variable todoOne.

• So, when we consoled the variable todoOne, its value remained the same.

Memory Heap

All non-primitive values like arrays, objects or functions are first stored on the heap and then passed as a reference to the stack.

When we pass a variable having non-primitive values as a reference to a new variable, the reference of the memory location is passed to the new variable. So, changing the value of the new variable will also affect the one that is passed as a reference.

In the above example,

• We have assigned an object (a non-primitive value) to variable userOne.

• Then, we created another variable userTwo and assigned it to variable userOne

• Here, the reference of the variable userOne will be assigned and not a copy of it.

• So, when we changed the property name of the variable userTwo , the property(name) of variable userOne also got changed.

Now, we also need to de-allocate the memory that is not in use, and this is done by Garbage Collector. It works by periodically finding and removing the objects that are no longer referenced by the program.

Till now, we have only understood how JavaScript Engine works under the hood from parsing, compiling, and executing to memory management. But where does it all happen? And that's what we will be learning in the next section.

Understanding JavaScript Runtime Environment

As human beings, we need some environment to work effectively. For example, to study, we need a quiet environment, books, etc. To cook food we need a kitchen provided it has all the necessary items to cook food like gas stoves, groceries, water, etc.

It also applies to JavaScript Engine as well. JavaScript Engine cannot work independently, it needs some environment. And that environment is called JavaScript Runtime Environment(JRE) for JavaScript Engines.

JavaScript Runtime Environment(JRE) provides all the necessary components to JavaScript Engine so that it can work effectively. And you know what, it's the JRE only that manipulates JavaScript to work asynchronously.

First, let's discuss the important components of the JavaScript Runtime Environment and then we will discuss how these components work together with JavaScript Engine.

Core Components of JavaScript Runtime Environment

The core components of the JavaScript Runtime Environment(JRE) are JavaScript Engine itself, which we have discussed earlier and the Web APIs, microtask queue, callback queue, and the event loop. Let's discuss each of them.

Web APIs

Web APIs are a set of built-in interfaces and functionalities provided by the Javascript Runtime Environment(JRE) to interact with external systems like servers, databases and other web services.

These Web APIs help in handling asynchronous operations like making a network request, processing large amounts of data, animating elements on a web page, etc.

There are several built-in interfaces and functionalities, let's discuss some of them.

• DOM API: Document Object Model(DOM) API helps in accessing and manipulating the elements and attributes of an HTML or XML document in real-time.

• Console API: Console API helps in performing debugging tasks, such as logging messages or the values of variables at set points in your code, etc.

• Fetch API: Fetch API helps in making HTTP requests to retrieve resources from servers without blocking the main thread.

• setTimeOut: This method allows us to schedule the execution of a function after a certain amount of time has passed.

Callback Queue and Microtask Queue

A callback queue is a data structure that stores a queue of callback functions waiting to be executed. It is based on First-In-First-Out(FIFO) data structure which means the first in the queue will be the first to execute.

A microtask queue also stores a queue of callback functions waiting to be executed but the one with the higher priority. The callback functions with higher priority are the ones that came through Promises, mutation observer, queueMicrotask, etc.

Event Loop

Event Loop helps in executing the callback functions that are waiting on the callback queue. It does this by constantly checking the call stack and the event queues(callback queue and microtask queue).

The event loop checks if the call stack is empty or not and if it is then it checks if any callback functions are waiting to be executed in the callback queue or microtask queue.

And if there are any callback functions to be executed, it takes the first callback function from the queue and pushes it to the call stack.

The event loop then waits for the call stack to be emptied again so that it can push the next callback function in the queue. It does until all the callback functions are executed.

How JavaScript Runtime Environment Works?

So far, we have discussed and understood the JavaScript Engine and the core components of the JavaScript Runtime Environment(JRE). But how do all these work together? Let's find out with the help of an example.

Remember:

1. When the JavaScript Engine goes through the code, it first creates a Global Execution Context(GEC) and put it on the Call Stack. The global execution context includes information about the global scope, such as global variables and functions.

2. And whenever a function is invoked it creates a new Execution Context(FEC) for that function and put it on the Call Stack. The function execution context includes information about the local scope of the function, such as its arguments and local variables.

3. All synchronous operations must complete their execution before the asynchronous operation gets executed.

In the example below, we have defined four functions greetUser(), delayedBy20ms(), getMovie() and letMeRun().

• greetUser() function has a variable message assigned with hello user! welcome to moviehub and simply consoling the value.

• delayedBy20ms() function returning setTimeOut method to delay the execution by 20 milliseconds.

  Syntax of setTimeout:

  setTimeout(callbackFunction, delayInMilliseconds);

  • callbackFunction- a function containing a block of code

  • delayInMilliseconds- the time after which the function is executed

• getMovie() function is returning a promise that fetches some movies from the server.

• greetUser() function has a variable runassigned with value let me run please!! and it also simply consoling the value.

function greetUser(){
     const message = 'hello user! welcome to moviehub';                              
     console.log(message); 
};

function delayedBy20ms(){    
    return setTimeout(() => {    
        console.log('I will be print at least after 20 milliseconds!!')
    }, 20);
};

function getMovie(movieName){
    return new Promise((resolve, reject) => {
        if(movieName === 'inception'){
            resolve({data : 'here is your movie from the server!'})
        }else{
            reject({message : 'movie not found!!'})
        }
    });
};

function letMeRun(){
    const run = 'let me run please!!';
    console.log(run);
};


greetUser();

delayedBy20ms();

getMovie('inception')
.then((response) => console.log(response.data))
.catch((error) => console.log(error.message));

letMeRun();

Phase 1: When programs execute for the first time

Do you remember what will happen when JavaScript Engine goes through the code? Let's find out.

1. So first, a Global Execution Context(GCE) is created and pushed in the Call Stack.

2. The Global Execution Context will hold information about all the functions' definitions and variables.

3. Also for each function, a function object is created and stored in the memory heap. This function object will contain the function's code and any variables declared within that function.

Phase 2 : When greetUser() function is invoked

After defining all the functions in the global execution context, now all these functions will execute when they are invoked. So, first, we are invoking greetUser. Let's understand what will happen when it gets invoked.

1. First, an execution context of greetUser function will be created and pushed to the call stack. The execution context includes the variable message and value hello user! welcome to moviehub.

2. greetUser function is consoling the variable message. It will be pushed into the call stack and tries to find the value of the variable in the execution context.

3. When it gets the value of message, it simply prints in the console.

4. Since greetUser function finishes its execution, its execution context will be destroyed.

5. Then, greetUser function is popped off from the call stack.

Now the program moves to the next line of code.

Phase 3: When delayedBy20ms() is invoked

1. When delayedBy20ms function is invoked, a new execution context is created and it will be pushed to the call stack. It is returning a setTimeout method.

2. When setTimeoutmethod is invoked a new execution context for setTimeout is created and will also be pushed in the call stack. Inside the setTimeout execution context, we have a callback function and a timer of 20 milliseconds, which says that the setTimeout method will be executed at least after 20 milliseconds.

3. Since setTimeout is an asynchronous operation provided by Web APIs, it will not execute immediately. So, the callback function and timer (20 ms) will be moved to Web APIs.

4. Meanwhile, the execution context of setTimeout will be destroyed.

5. Then setTimeout method will be popped off from the call stack.

6. Then the execution context of delayedBy20ms function will be destroyed.

7. And finally, delayedBy20ms pops off from the call stack.

8. Now, when the timer of 20ms expires the callback function moved to the callback queue

9. The event loop is continuously checking if there is any function in the callback queue ready to be executed. But the call stack is not emptied yet, so the callback function will wait in the callback queue till the call stack is empty.

Phase 4: When getMovie() function is invoked

1. Now getMovie() the function is invoked, a new execution context for it will be created and it will be pushed into the call stack. It holds the argument movieName and value inception and also it is returning a promise.

2. Since getMovie function is returning a promise, so when the promise executes a new execution context will be created and it will be pushed into the call stack. The execution context includes value which is initially undefined, status which is pending and function definitions when the promise is resolved and rejected.

3. As Promise is an asynchronous operation, it will be moved to Web API.

4. The execution context of Promise will be destroyed

5. And it will be popped off from the call stack.

6. Now the execution context of getMovie function will also be destroyed.

7. And then popped off from the call stack.

8. The Promise waits in the Web API till it gets a response from the server.

9. When it gets the response from the server value will be the data returned from the server, status changes to resolved from pending.

10. Based on whether the promise is resolved or rejected, a callback function is pushed into the microtask queue. In this case, the callback function is (response) => console.log(response.data).

    Q. Why Promise is pushed into the microtask queue and setTimeout into the callback queue?

    A. Because Promise has higher priority than setTimeout.

11. The event loop is still checking if there is any task to be executed from the microtask or callback queue and also if the call stack is empty or not. Since the call stack is not emptied yet it cannot execute the callback functions that are ready to be executed.

Phase 5: When letMeRun() function is invoked

1. When letMeRun() is invoked a new execution context will be created and pushed into the call stack. The execution context includes the variable run and its value let me run!!.

2. letmMeRun function calling the console.log(run). So it will be pushed into the call stack and tries to find the value of the variable run in the execution context.

3. When it gets the value from the execution context, the value will be printed on the console.

4. Now, the execution context of letMeRun function will be destroyed.

5. Then letMeRun function will be popped off from the call stack

6. Since there is nothing to execute anymore the global execution context will also be popped off from the call stack.

Phase 6: When the microtask queue executes

Now we have one callback function(Promise) in the microtask queue and one callback function(setTimeout) in the callback queue.

1. The event loop finds that the call stack is empty and also there is one callback function in the microtask queue and one callback function in the callback queue is ready to be executed.

2. Since the callback function(Promise) resides in the microtask queue have higher priority, therefore it will execute first.

3. When the callback function executes, a new execution context is created and pushed into the call stack. The execution context includes arguments response and value {data : 'here is your movie from the server!'}.

4. Now console.log(response.data) is invoked, it gets the value from the execution context.

5. The value here is your movie from the server! is printed on the console.

6. The execution context of the callback function is destroyed.

7. And finally popped off from the call stack.

Phase 7: When the callback queue executes

1. Again event loop finds that the call stack is empty and there is a task in the callback queue ready to be executed.

2. The callback function gets executed.

3. So, a new execution context is created. Then it is pushed into the call stack. The execution context includes an argument 1 and value i will be print at least after 20 milliseconds!!.

4. Now, console.log() is called, it gets the value from the execution context.

5. Then the is printed on the console.

6. The execution context of the callback function is destroyed.

7. And finally, the callback function is popped off from the call stack.

The output

After executing all the programs we get the output as :

hello user! welcome to moviehub
let me run please!!
here is your movie from the server!
i will be print at least after 20 milliseconds!!

Even though we have executed the code in the order below, we get the output in a different order, and this is how the JavaScript Runtime Environment gives an illusion of asynchronicity.

I hope now it makes sense to you whenever you get the output as the above one.

// ORDER OF INVOCATION OF THE FUNCTIONS
greetUser(); //1

delayedBy20ms(); //2

getMovie('inception') //3
.then((response) => console.log(response.data))
.catch((error) => console.log(error.message));

letMeRun(); //4

Conclusion

I know this was a long article but I hope you have read all the sections carefully. We learned a lot of things, aren't we? So let's quickly recap what we have learned so far.

• JavaScript at its base is synchronous, but with the help of JavaScript Runtime Environment(JRE), it can work asynchronously.

• Every browser has a JavaScript Engine, and the runtime environment is the browser itself.

• JavaScript Engine helps in parsing, compiling and executing the code.

  • During parsing, code breaks down into small tokens and it gets converted to Abstract Syntax Tree(AST).

  • During compilation, the AST is converted into the bytecode.

  • During execution, JavaScript Engine executes the code as the code gets compiled.

• We don't need to worry about memory management in JavaScript.

  • JavaScript Engine takes care of all these, from allocation to utilization to de-allocation.

  • All the primitive values like strings, numbers, booleans, undefined, and null are stored on the stack.

  • All non-primitive values like arrays, objects or functions are first stored on the heap

• The core components of the JavaScript Runtime Environment are:

  • Web APIs: it helps in interacting with external systems like servers, databases, etc.

  • Microtask Queue: it stores a queue of callback functions waiting to be executed with a higher priority.

  • Callback Queue: it stores a queue of callback functions waiting to be executed after the microtask queue becomes empty.

  • Event Loop: it helps in executing the callback functions that are waiting on the callback queue by constantly checking if the call stack is empty or not.

While writing this article I came to know about so many amazing things and my love for JavaScript increases even more. I hope this article helped you too to understand how Asynchronous JavaScript works under the hood.

Additionally, I welcome your feedback. If you come across any areas that require correction or you just want to connect, feel free to contact me via email at sobitwrites@gmail.com.

References and Useful Resources:

• JavaScript the Hard Parts by CodeSmith

• JavaScript Web APIs

• JIT Compiler by Programming With Avelx

• JavaScript's Memory Management Explained by Felix Gerschau

• Abstract Syntax Tree(AST) viewer

Unlike other programming languages, like Java and C++ where we need to specify the type of variables while declaring, it is somewhat different in JavaScript.

JavaScript limits us to declare variables only using these three keywords - the var, the let and the const. Also, we do not need to specify the type of variables while declaring it.

And even though, having only three ways of defining variables most beginners find it difficult to digest them.

In this blog, we'll explore var, let, and const through various examples and will try to understand the differences between them.

A Brief History of Variables in JavaScript

Until EcmaScript2015(ES6), we were only declaring variables using the var keyword.

With the introduction of ES6 in June 2015, the let and const came into existence and were considered the best practice to declare variables in modern JavaScript.

What is a Variable?

A variable is a named storage location that holds some value pointing to some memory location in the computer's memory, that we can use later to manipulate our programs.

Think of it like you are giving a name to some location in the computer's memory. This memory location can be used to store the value you wanted.

Later, if you need the value you have stored, you can simply use the name you have given to that memory location.

From the above figure, you can see we have three variables var1, var2 and var3 stored in memory locations 1, 3 and 5 with assigned values of hello world, {....} and 121432 respectively.

Now, whenever we need these values we can simply use the names we have assigned to those memory locations.

Understanding Var and Let

We know that both var and let are used to declare variables, but there are some important differences that we need to consider.

We will measure the differences in terms of their declaration, scoping and hoisting. So, let's discuss each of them in detail with examples.

var is re-declarable while let is not

When we declare a variable using var, we can re-declare that variable in the same scope multiple times.

re-declaration refers to declaring a variable with the same name multiple times within the same scope.

var greetUser = 'good morning!';
var greetUser = 'good afternoon!';
console.log(greetUser); // good afternoon!

In the above example, you can see we have two variables greetUser with the same name. The second greetUser overwrites the value of the first, so we get the output as good afternoon! .

This is not in the case of variables declared with let. This means, re-declaration is not allowed for variables declared using let. We will get a syntax error if we do so.

let greetUser = 'good morning!';
let greetUser = 'good afternoon!';
console.log(greetUser); 
// SyntaxError: Identifier 'greetUser' has already been declared

However, we can re-initialize a variable declared using both with var and let multiple times in the same scope.

re-initialization refers to assigning a new value to a variable that has already been declared and initialized within the same scope.

var greetUser = 'good morning!';
greetUser = 'good afternoon!';
console.log(greetUser); // good afternoon!

let greetUser = 'good morning!';
greetUser = 'good afternoon!';
console.log(greetUser); // good afternoon!

Also, even if we remove the keywords var and let from the above examples, we will get the same output.

greetUser = 'good afternoon!';
console.log(greetUser); // good afternoon!

This is because when we use a variable without explicitly declaring with keywords var or let, it is automatically created as a global variable. However, it is not possible in strict mode, we will get a reference error.

"use strict";
greetUser = 'good afternoon!';
console.log(greetUser);
// ReferenceError: greetUser is not defined

var is function-scoped while let is block-scoped

In JavaScript, scoping is used to determine the availability or visibility of a variable in a particular part of a program, based on where it is declared.

There are primarily four types of scopes in JavaScript - global, functional, block and module scope. We will discuss only the first three.

• global scope - a variable declared outside any function or block(inside curly braces {}) can be said to be in the global scope. It is visible or accessible throughout the whole program.

  

    var varA = 'I am in global scope';
    let letA = 'hey, I am too in global scope';
  
    function printData(){
        console.log(varA);
        console.log(letA);
    };
    printData();
    // I am in global scope
    // hey, I am too in global scope
  

  In the above code, variables varA and letA both are in the global scope and can be accessed inside any function and block.

• function scope - variables declared using the var keyword are functionally scoped. This means, if we declare a variable inside a function it will be accessible inside that function only.

  The accessibility of variables declared using var inside a function is limited to that function only.

  

    function printData(){
        var favoriteBook = 'the happiness hypothesis';
        console.log(favoriteBook); 
    };
    printData(); // the happiness hypothesis
    console.log(favoriteBook); // ReferenceError: favouriteBook is not defined
  

  We will get a reference error from the second console because we are trying to access the variable favouriteBook, which is defined inside the function printData.

• block scope - variables declared using the let keyword have block scope. This means that if we declare a variable inside any block(block refers to curly braces {}), we will not be able to access that variable outside that block.

  The accessibility of variables declared using let inside a block is limited to that block only.

  

     function printSomething() {
        let x = 10;
        if (true) {
          let y = 20;
          console.log(x); // 10
          console.log(y); // 20
        }
        console.log(x); // 10
        console.log(y); // ReferenceError: y is not defined
    };
    printSomething();
  

  In the above example, we have declared two variables, x inside function printSomething and y inside the if block which again is inside the printSomething function only.

  The scope of the variable x is the whole printSomething function, while the scope of the variable y is limited only to the if block.

  So, when we tried to access the variable y (console.log(y);) at the very end of the function printSomething we get a reference error.

var and let both are hoisted?

Hoisting is a mechanism that is used to move the variable and function declarations to the top of their respective scope before the code is executed.

However, the code doesn't actually re-arrange, but the JavaScript Engine finds the variables and functions and reserves memory for them before the code gets executed.

By default, variables get initialized with a value of undefined and in the case of functions, an actual copy of the functions is allocated.

And that's the reason when we run the code below, we get undefined and the function gets executed without any error.

console.log(varA);
print();

var varA = 'hello shipper!'
function print(){
    console.log('hello builder!')
};
// undefined
// hello builder!

Till now, we have been only discussing the functions and variables declared using var. But, what if we declared it using let? Will we get undefined or it will be an error? Are the variables declared using let hoisted?

And many questions might come to your mind. So, let's try to find the answers to all the questions above.

First, let's try to find whether variables declared using let are hoisted or not. Well, some say that let is hoisted while others deny it. This argument is fine since hoisting is not a globally agreed term.

However, variables declared using let show behavioural characteristics of hoisting. It's too get allocated with a default value of undefined in the memory.

console.log(letA);
let letA = 'hello shipper!';
//ReferenceError : Cannot access 'letA' before initialization

If it is already allocated with a default value of undefined, then why did we get the error? And this is where Temporal Dead Zone comes in.

A variable declared using let is said to be in a "temporal dead zone" (TDZ) from the start of the block until code execution reaches the line where the variable is declared and initialized.

console.log(letA); // I am in Temporal Dead Zone

let letA = 'hello shipper!'

if(true){
    console.log('hello batman!');
    console.log('hello spiderman!');
    console.log('hello superman!');

    console.log(shaktiman); // I am too in Temporal Dead Zone
    let shaktiman = 'hello shaktiman';
}

In the above example, both console.log(letA); and console.log(shaktiman); are in the temporal dead zone.

The TDZ for variable letA starts from the very top and ends on the line where it is declared and initialized. While the TDZ for the variable shaktiman starts from the top of the if block and ends where it is declared and initialized.

If we will try to access those variables in their temporal dead zone(TDZ) then it will result in a reference error.

Understanding Const

The reason I didn't talk about variables declared using const earlier was that it works almost like variables declared using let, with some slight key differences. So, let's discuss each of them.

Initialization

We can declare a variable with let without an initial value and can assign it later. But it is not possible with variables declared using const. It must be initialized with a value when they are declared.

// Allowed ✅
let letA;
letA = 'hello shipper!';

// Not Allowed ❌
const constA;
constA = 'hello builder';
// SyntaxError: Missing initializer in const declaration

Mutability

We can mutate a variable declared using let while variables declared using const are immutable, meaning that their values cannot be changed after they are initialized.

// Allowed ✅
let letA = 'hello shipper!';
letA = 'hello earth!';

// Not Allowed ❌
const constA = 'hello builder';
constA = 'hello mars!';
// TypeError: Assignment to constant variable.

Scope

Variables declared using const have the same block scope as variables declared using let. However, variables declared using const have a more restrictive scope than variables declared using let.

We can neither redeclare nor we can re-assign variables declared using const within the same block, although variables declared using let can be re-assigned but cannot be re-declared within the same block.

if(true){
    let iWantToBe = 'an astronaut';
    iWantToBe = 'a web developer'; // Allowed ✅

    const youWantToBe = 'a doctor';
    youWantToBe = 'a soldier'; // Not Allowed ❌
}

Reason for introducing let and const

We have been declaring variables using var for almost 20 years, then why there was a need of introducing let and const? Some of them we have already discussed above by comparing with var. Let's discuss a few more and then we can conclude this post.

Naming collision

As we know that variables declared using var are re-declarable in the same scope, which leads to naming collision. This can be prevented if we will use let or const as re-declaration is not allowed with let and const is even stricter than let.

// Allowed ✅
var favoriteAnimeName = 'naruto';
var favoriteAnimeName = 'deathnote'; 

// Not Allowed ❌
let favoriteAnimeName = 'naruto';
let favoriteAnimeName = 'deathnote'; 

// Not Allowed ❌
const favoriteAnimeName = 'naruto';
const favoriteAnimeName = 'deathnote';

Memory save

If we declare variables using let and const they can help to save memory by limiting the scope of variables to only the blocks where they are needed, and by allowing for the re-use of variable names within different blocks of code.

This can help to ensure that memory is used efficiently and not wasted on variables that are no longer needed.

function calculate(numbers1, numbers2) {
    let total = 0; // declare and initialize ⚡ 'total' variable

    for (let number of numbers1) {
      total += number;
    }
    console.log(total);

    {
      let total = 0; // declare and initialize new ✨ 'total' variable
      for (let number of numbers2) {
        total += number;
      }
      console.log(total);
    }
}

calculate([1,2,3,4],[10,11,12, 13]);
// 10
// 46

Summary

In this blog, we tried to understand the three ways of declaring variables using var, let and const.

Variables declared using var are more flexible but it leads to more confusion and bugs due to its function-level scoping and hoisting behaviour.

On one hand, let allows the re-assignment, making it useful for situations where variable values may change over time.

On the other hand, const doesn't allow re-assignment, making it useful for situations where variable values should not be changed.

While I cannot say that you should completely stop using var and only use let and const from now on. Choosing between var, let and const will depend on the specific needs of our program.

If we understand the differences and trade-offs between these three variable declaration methods, we can write more efficient and bug-free code.

Conclusion

I hope this article helps you to understand the differences and use cases of variables declared using var, let and const.

Share this with your friends and provide feedback to me at sobitp59@gmail.com. If you come across any incorrect information, please don't hesitate to reach out. I'm open to hearing your thoughts!

And also, I am doing the #151DaysOfCode challenge on Twitter, connect with me if you wanna join too and let's get started!

As web developers, we are blessed with consoles in the browsers to interact and debug our web pages and applications.

The most common type of console is the JavaScript console, which is found in most modern web browsers.

These consoles are built into the web browser that provides a command-line interface(CLI) for executing JavaScript commands and inspecting and debugging the state of our web pages.

In this blog, we will try to find the answer to "Why browser console returns undefined?".

The Browser Console

The first time I interacted with the console(press F12) was during following a course on JavaScript on Udemy.

I performed a lot of operations and getting the results in real-time in the console felt so convenient.

But, one thing that constantly bothered me was in some operations it returns the result as expected like adding two numbers 10 + 39 gives 49, while in other cases like after defining a function or variable it gives undefined.

So, let's understand the reason behind getting undefined. But, before that, we have to know what `undefined` actually is.

Understanding Undefined

In JavaScript, undefined is a primitive value that is assigned to variables that have been declared but have not been initialized with a value, or to function parameters that have not been provided with an argument.

We can say that undefined is like a placeholder for the variables and functions' arguments in the memory space until it's not get assigned with any value or passed with any arguments in functions.

Understanding the working of REPL and Console

The way code is executed in the console of a web browser is similar to the Read-Eval-Print Loop (REPL) methodology that is commonly used in interactive programming environments.

However, the console of a web browser is not strictly a REPL environment but it does share some similarities in terms of how code is entered, executed, and displayed.

This is different from how we code in a traditional programming environment, where we typically have to save our code to a file, compile it (if necessary), and then run it.

Now first, let's understand what each part of the abbreviation of REPL tells us:

• Read: Hey! I am Read and I help in reading the input(code) that you enter. If your input is not correct(syntactically), I will not be able to pass your input to Eval.

• Eval: Heya! I am Eval(not evil) and I help in evaluating the input that you gave me via Read so that I can determine the results for your input.

• Print: Helloo! I am Print and I help in displaying the result of the evaluation provided by the Eval on the console.

• Loop: Hello! I am Loop and I help in taking you back to the Read so that you continue your chit-chat(giving input) with Read.

So basically, it is a type of interactive programming environment that reads the code, evaluates it, prints the result (if there is one), and then waits for us to enter more code.

Understanding the Reason Behind Undefined

We know that because of the REPL methodology, the codes get executed immediately after we press ENTER.

We also know there are three steps( Read, Evaluate and Print ) in between before it gets ready to read our code again (basically before Loop ).

At the Print stage, it is decided what should be printed in the console by JavaScript Console.

So, let's understand the different scenarios that probably might help us to understand when the JavaScript console decides to print undefined, and when not.

the console.log()

In JavaScript, every function returns a value, even if there is no explicit specification of one using the return keyword. If no return statement is used, the function automatically returns undefined by default.

When we call console.log() with a value as an argument, the value is printed to the console and then undefined is printed because console.log() itself does not have a return value.

console.log('hello world!')
// hello world!
// undefined

It is designed to output messages to the console, but it doesn't return a value that could be used elsewhere in the code.

So, after the value is printed to the console, the function returns undefined as its default return value.

the explicit return type

Since we know that every function in JavaScript returns something. If there will be nothing, then it will be undefined by default.

So, let's tell the browser console explicitly what we want to return and see how it responds to us.

function animeLists(){
    return ['naruto','attack on titans', 'one piece']
}
// undefined
// animeLists()
// ▸(3) ['naruto', 'attack on titans', 'one piece']

When we run the above code in the console, at first we will get undefined. This is because just defining a function does not produce a return value, so the console does not have anything to display as a result of the function definition.

The function definition is just stored in memory somewhere and is not executed until we call it.

In the next line, when we called the function animeLists and since we are explicitly telling the console to return the ['naruto', 'attack on titans', 'one piece'] using return keyword, we will only get the output and not undefined.

the expressions

An expression in JavaScript is a combination of values, variables, and operators that can be evaluated to a single value.

It can be as simple as a single value or it can be as complex as a combination of multiple expressions.

//01: Arithmetic Expression
2 + 3 * 4 // returns 14

//02: Function call Expression
Math.max(1, 2, 3) // returns 3

//03: Ternary operator Expression
x > y ? "x is greater" : "y is greater" // returns the greater one

//04: Boolean Expression
true === 1 // returns false

In all the examples above, the console does not display the value undefined because after reading the expression, it gets evaluated and the result is immediately printed on the console.

After printing the result, it loops back to Read so that it starts taking more inputs from us.

the final example

Till now if you have got a little idea about how all these work from the examples above, then let's finally conclude this, understanding the example below step by step.

Before that, let's give aliases to "Read", "Eval", "Print "and "Loop" as "Mr. Read", "Mr. Eval", "Mr. Print" and "Mr. Loop" respectively.

// Run this code in console
function greetUser(){
    const message = 'hey user! welcome to console';
    console.log(message);
    console.log('your total cost for the stay is : ');
    return 2100 - 100;
}

• Step 1: When we enter this input in the console and press ENTER, Mr. Read will look into our code and finds everything fine. So, he tells Mr. Eval to look into it.

• Step 2: Now, when Mr. Eval looks into the code, he finds that it is just a function definition because the function hasn't been called yet. Since there is nothing to return, Mr Eval returns undefined and sends it to Mr. Print.

• Step 3: The job of Mr. Print is to display whatever is received by Mr. Eval on the console. This time it was undefined, so he prints the same on the console.

• Step 4: Since the final result is printed for the execution of code till now, Mr. Loop will tell Mr. Read, "hey Mr. Read! you can now take another input from the user". And this process continues.

Till now, we have only gotten the undefined because we haven't called the function yet, so let's finally call the function greetUser() .

greetUser(); // calling the function

The same process will be followed this time as well, let's understand this one as well.

• Step 1: After we call the function greetUser, Mr. Read will look into our code and reads the various commands we have given.

• Step 2: Now, Mr. Loop will evaluate our code and since we are explicitly returning with the return keyword, we will not get undefined. After evaluation, Mr. Loop sends the result to Mr. Print.

• Step 3: Now, Mr. Print displays the final result on the console.

    hey user! welcome to console
    your total cost for the stay is : 
    2000
  

• Step 4: Again, Mr. Loop will tell Mr. Read, "hey Mr. Read! you can now take another input from the user". And this process continues.

Summary

• A console is a built-in tool in modern web browsers that provides a command-line interface for debugging and interacting with web pages.

• It is similar to the Read-Eval-Print Loop (REPL) methodology used in interactive programming environments where,

  • Read: It reads the input we enter

  • Eval: It evaluates and determines the results of the input.

  • Print: It prints the result on the console.

  • Loop: It loops back to Read so that Read can take another input.

• In JavaScript, every function returns a value, by default it is undefined. And since console.log() does not have a return value so it prints undefined.

• If we explicitly state the return value in the code then it resolves the issue of getting "undefined" as output.

I hope this blog helps you to understand at least the basic concept behind returning undefined to the console. If it does, do share it and if you want to connect with me, say Hi! here.

Hello everyone, this article is going to be very short but also important. Before reading this blog, please read my previous blog on Scope, Scope-Chain, and Lexical Environment in JavaScript. So, in this blog we will talk on shadowing in javascript, what is illegal shadowing. So, please read this blog carefully, because it will help you in your web dev journey. So, let's start.

Variable Shadowing in JavaScript 👀

In my previous blog, we have talked a lot about scopes in javascript like global, local, and block scope. Now, let's understand shadowing with the help of an example. We will use the var and let keywords, as let and const behave the same in variable shadowing so we will skip const here.

variable shadowing with var keyword 🦉

var a = 10; // variable declared in global scope
{
    var a = 100; // variable declared inside a block
}
console.log(a);

So, what will be the output here 🤔? Before answering, let's understand the above code. We have declared two variables with the same name a one in the global space and one inside the block, and we are consoling a in the global scope. So, now you can tell me your answer. If your answer is 100, congratulations 🥳, it's the right answer. But why we are getting 100 even though we have written console.log(a); in the global scope. This is because, both the variables are pointing to the same memory location i.e. both are pointing to the Global Memory Scope.

So, what is variable shadowing here? Here, the variable inside the block is shadowing the variable in the global scope. In simpler terms you can say, a variable in block scope is hiding the value of the variable in global scope with its shadow and printing its own value. But what if we write the variable declared inside the block, in a function. Let's see

var a = 10; // variable declared in global scope
func();
function func(){
    var a = 100; // variable declared inside a function
}
console.log(a);

So, here output will be 10, Why? Because both the variables are stored in different memory spaces. As keyword var is a function/local scoped i.e. variable declared inside the function can be accessed inside that function only, we will not be able to access it outside its boundary. And here, the variable a inside function fails to shadow the variable a in the global scope.

variable shadowing with let keyword 🦚

Let's understand this with the above example only.

let  a = 10; // variable declared in global scope
{
   let a = 100; // variable declared inside a block
}
console.log(a);

So, here our output will be 10, we should print 100 are you saying? No, it's not like that in the case of let, because let is a block-scope type i.e. if we declare a variable with let inside any block whether inside a function, inside an if-else, or inside a while/for loop, we will never be able to access let outside that block. As let is a block-scope type, in the above example both the variables have different memory spaces and the variable inside the block is not able to shadow the variable in the global space.

Illegal Shadowing in JavaScript 🧛‍♀️

To understand illegal shadowing we will use var and let keywords in our example. So, let's try to understand illegal shadowing.

    let a = 10; // variable declared in global scope using `let` keyword
    {
      var a = 100; // variable declared inside a block using `var` keyword
    }
   console.log(a);

Now, here we will get an error Uncaught SyntaxError: Identifier 'a' has already been declared. Although here both the variables are pointing to the global memory space, the variable a inside the block fails to shadow the variable a from the global space. This is said to be illegal shadowing.

But what if we swap the keywords let and var or write the var a in a function instead in a block. So, let's see.

Example 1: Swapping variables let and var in the above example

var a = 10; // variable declared in global scope using `var` keyword
    {
      let a = 100; // variable declared inside a block using `let` keyword
    }
  console.log(a);

Here, we will get 10 in the console and not an error, but why? Because, both the variables are pointing to separate memory spaces. Although, the variable inside the block will not shadow the variable in the global space, because let has its own separate memory space.

Example 2: Writing variable var inside a function in the above example

    let a = 10; // variable declared in global scope using `let` keyword
    func();
    function func(){
      var a = 100; // variable declared inside a block using `var` keyword
    }
   console.log(a);

Here, we will also get 10 in the console because variable a inside the function and variable a outside the function is pointing to the different memory location,s and here also var a inside the function will not shadow the variable declared with let keyword.

So, that's it guys for this blog. I will be very glad if you let me know any suggestions/corrections in any of my blog articles. If you find this article helpful, say hi to me on LinkedIn 🌸

What comes to your mind when you heard the term "scope"? It probably might be a "binocular" or if you play any battle-royale game (like PUBG, Fortnite, etc), then it might be a 2X, 3X, 4X scopes, etc, Right? Whatever it might be, let's see scope from the perspective of a battle royale game. So, from the perspective of a battle-royale game, the scope is used to see/find enemies that fall in the range of the scope, isn't it? And in JavaScript, the scope works something like this.

Namaste everyone, in this blog article we are going to explore a bunch of things like scope, scope-chain, lexical environment, etc. But, before reading this article I will recommend you to read my blog on JavaScript Behind The Scene so that you got familiar with how JavaScript works behind the scene. So, let's explore.

Scope in JavaScript

Scope in JavaScript is the range where we can access specific variables and functions or you can say, scopes tell us where we can access particular variables and functions in our code. So, there are basically three types of scopes in JavaScript :

1. Global Scope
2. Local/Function Scope
3. Block Scope

Let's explore all these scopes one by one and see how it works.

Global Scope in JavaScript

When we declare variables or functions at the top of our code i.e. in the global space then those variables or functions are said to be in the Global Scope. We can access these variables or functions from anywhere inside our code. Let's understand this with the help of an example -

// variables and functions declared in the global space
var globalScopeVariable = `variable "globalScopeVariable" declared in Global space`;
            console.log(globalScopeVariable);

function globalScopeFunction(){
            console.log(`function "globalScopeFunction()"" declared in Global space and accessing 
            "globalScopeVariable" below : `);
           // accessing variable "globalScopeVariable" 
            console.log(`Accessed "globalScopeVariable" : ${globalScopeVariable}`);
        }
 globalScopeFunction();

function callingGlobalScopeFunction(){
            console.log(`an another function "callingGlobalScopeFunction()" declared in Global space and 
            accessing "globalScopeFunction" below : `);
            // accessing function "globalScopeFunction()"
            console.log(`Accessed "globalScopeFunction()" : `);
            globalScopeFunction();
        }
 callingGlobalScopeFunction();

The above code might overwhelm you, but don't worry we will understand each and every line of code. In the above example, we have declared a variable globalScopeVariable and two functions globalScopeFunction() and callingGlobalScopeFunction() all in the global space. And function globalScopeFunction() is accessing the variable globalScopeVariable and function callingGlobalScopeFunction() is accessing the function globalScopeFunction(), we can also access function callingGlobalScopeFunction() inside an another function.

But how are we able to access the variable globalScopeVariable inside function globalScopeFunction() and function globalScopeFunction() inside function callingGlobalScopeFunction() which are not physically present inside that code. The answer is very simple, it's because we have declared all the variables and functions in the global space and thus we are able to access these variables and functions.

But what if we reverse the situation, i.e. what if we declare a variable or function inside a function and try to access that, outside the code or in the global space. What do you think? And here ladies and gentlemen come the term Local/Function scope, so let's explore this one as well.

Local/Function Scope in JavaScript

First, let's understand this term, and later we will understand more deeply with the help of examples.

If we declare a variable or a function inside a function then, the scope of that variable and function is said to be Local/Function scope i.e., we can't access those variables and functions outside that function. Let's understand this with the help of an example -

1   function funcOne()
2    { // start of scope of variable "varOne"
3      var varOne = `I am inside function "funcOne()"`;
4      console.log(varOne);
5
6      funcTwo();
7      function funcTwo()
8       { // start of scope of variable "varTwo"
9            var varTwo = `I am inside function "funcTwo()."`;
10           console.log(varOne);
11           console.log(varTwo);
12           
13          funcThree();
14          function  funcThree()
15           { // start of scope of variable "varThree"
16                var varThree = `I am inside function "funcThree()".`;
17                 console.log(varOne);
18                 console.log(varTwo);
19                 console.log(varThree); 
20           } // end of scope of variable "varThree"
21
22        }  // end of scope of variable "varTwo"
23 
24    } // end of scope of variable "varOne"
25        
26     funcOne();

In the above example, we have three functions funcOne(), funcTwo() and funcThree(), and also we have three variables namely varOne, varTwo and varThree.

funcOne() is declared inside funcTwo(), funcTwo() is declared inside funcThree, and funcThree() is declared in the global space. And variables varOne, varTwo, and varThree are declared inside functions funcOne, funcTwo, and funcThree respectively.

The scope of these variables starts with the opening curly brace { and ends with the closing curly brace } of their respective functions, i.e. we cannot access these variables outside that function. And same in the case of functions, in the above example, if we will try to invoke/call function funcOne() outside the function funcOne() we will get ReferenceError.

But, have you noticed that inside function funcTwo() we are trying to access variable varOne and inside function funcThree we are trying to access variables varOne and varTwo which are physically not present there. But how are we able to do it? Why we are not getting any errors? All these are possible because of the Lexical Scope/Environment.

And here we will need the concept of Global Execution Context and Callstack, that's why I recommended reading that blog at the beginning of this article. So guys, let's explore this one as well.

Lexical Scope/Environment in JavaScript

We know that when we run our code, a Global Execution Context is created, and with every invocation of a function another Execution Context gets created and all these are pushed to the Callstack in order of their invocation.

But what is Lexical Scope/Environment? Don't worry we will understand this more deeply. First, let's understand how lexical scope/environment is created. So, when Global Execution Context is created, a lexical scope/environment is also created i.e. with every Execution Context there is something called lexical scope/environment is present with it. Let's understand this with the help of the figure below by taking the example of the code above.

So, when we will run the above code a Global Execution Context is created, and funcOne will be assigned with whole code inside the { .. } curly braces and varOne will be assigned with undefined in the memory component and when the code runs in the code component varOne will be assigned with its actual value i.e. I am inside function "funcOne() and another Execution Context is created for funcTwo and funcThree as well.

Now remember this paragraph we have discussed above

But, have you noticed that inside function funcTwo() we are trying to access variable varOne and inside function funcThree we are trying to access variables varOne and varTwo which are physically not present there. But how are we able to do it? Why we are not getting any errors? All these are possible because of the Lexical Scope/Environment.

So, here is the answer. The lexical environment is the local memory along with the lexical environment of its parent. Didn't understand? Let's go deep and understand this with the help of the code above.

In function funcThree, we have only declared variable varThree. So, when funcThree executes, JavaScript Engine will assign undefined to all the variables i.e. to varOne, varTwo, and varThree in the memory component. But, varOne, and varTwo are not initialized inside funcThree. So, the lexical environment of funcThree will start looking for the values of its parent i.e. inside function funcTwo and here we will find the value of varTwo. But again, the value of varOne is not inside function funcTwo(), so the lexical environment of funcTwo will start searching for the value of varOne of its parent i.e. inside funcOne() and when the value is found it is assigned to its respective variables. The chain of these lexical environments is known as Scope Chain.

NOTE: the lexical environment of global or window object is null. If we will try to access a variable or function which is not declared anywhere, then of course it will not be present in any of the lexical environments and we will get a beautiful error.

It's enough for the lexical environments, now let's head to our final destination of this article i.e. the block scope in JavaScript.

Block Scope in JavaScript

Before learning block scope in JavaScript, first, let's understand what a BLOCK is? So, a block in JavaScript is defined by the curly braces { }, also known as the compound statement. Now, you might be wondering what is the use of block, Right? So, a block is used to combine multiple JavaScript statements into a group. Now, you might have another question why do we need to group multiple JavaScript statements into a group? So, here is the answer, we need to group multiple JavaScript statements in a block so that we can use that block where JavaScript expects only one statement. If it sounds confusing don't worry, let's understand this by creating a block of statements step by step.

Step 1:We can start our block with this { } curly braces. This curly braces { } below is a block and a valid JavaScript code.

{
// I am a block
}

Step 2: Now, we can write multiple JavaScript statements inside this block { }.

{
console.log('I am inside a block');
console.log('I am also inside a block');
}

Step 3: Let's used the above block with the if where JavaScript expects only one statement, i.e. we can write an if statement as if (true) console.log('I am not inside a block'); when we need a single statement, but when we need multiple statements we can use block as shown below in the code.

if(true){
console.log('I am inside a block');
console.log('I am also inside a block');
}

//Output : 
//I am inside a block
//I am also inside a block

Now, as we have understood block, let's dive into block scope in JavaScript. To understand block scope, let's declare three variables using var, let, and const.

{
var a = 'I am var a';
let b = 'I am let b';
const c = 'I am const c';

// inside block
console.log(a);
console.log(b);
console.log(c);
}

// outside block
console.log(a);
console.log(b);
console.log(c);

//Output : 
//I am var a
//I am let b
//I am const c
//I am var a
//Uncaught ReferenceError: b is not defined

Now, when we run the above code we will get the error Uncaught ReferenceError: b is not defined i.e. while accessing the variable b outside the block. This is because the scope of variables b and c is inside that block only i.e. these variables are stored in the separate memory space, we cannot access variables declared with let and const outside that block. And thus, let and const is said to be block-scoped.

But, if we have written the same code inside a function, we will not be able to access a single variable outside the block i.e.

func();
function func(){
var a = 'I am var a';
let b = 'I am let b';
const c = 'I am const c';

// inside block
console.log(a);
console.log(b);
console.log(c);
}

// outside block
console.log(a);
console.log(b);
console.log(c);

//Output : 
//I am var a
//I am let b
//I am const c
//Uncaught ReferenceError: a is not defined

And thus, var is said to be function/local scoped i.e. if we declare a variable using the var keyword inside a function, we will not be able to access that variable outside that function.

So, that's it guys for in this blog. I will be very glad if you let me know any suggestions/corrections in any of my blog articles. If you find this article helpful, say hi to me on LinkedIn 🌸

Introduction

When we run our code in JavaScript, a Global Execution Context (GBE) is created. But, along with GBE, a global object and this keywords also get created. But, what are Global Object and this keyword we are talking about here? So, let's explore, here Global Object refers to the window object and this is a keyword that refers to this window object at the global space i.e., in the global space window === this. So, if we will type window === this in the console we will get true as the output. But, the behavior of this changes according to where it is being invoked. So, let's explore how it behaves at different places.

invoking this in global space or alone

When you write console.log(this) in your javascript program and inspect it in the console, you will see that this is referring to the Window object. So, in the global space this refers to Window.

invoking this inside an function

So, what do you think if we invoke this inside a function? So, let's write a few lines and see

function func(){
console.log(this);
}
func();

Here, this also refers to the Window object, but why? Because here function func is a property of Global i.e. Window object. So, here we can also say if we call this in a function as - this refers to the object of which this function is a property of. Don't worry if you didn't get it yet, believe me, you will understand it in the next section.

invoking this in an object

So, let's make an object and invoke this inside that.

const data = {
firstName : 'Sobit',
lastName : 'Prasad',
fullName : function(){
     return this.firstName + " " +this.lastName;
     }
}
console.log(data.fullName());

// Output : Sobit Prasad

So, here output will be Sobit Prasad. Here, inside object data we have invoked this inside function fullName and function fullName is a property of object data and that's why here this refers to data object and not the Window object. Let's understand more deeply with the help of an another example.

 const data1 = {
            firstName: 'Sobit',
            lastName: 'Prasad',
            fullName: function () {
                return this.firstName + " " + this.lastName;
            }
        }
 const dataOne = data1.fullName;
 const data2 = {firstName: 'Mohit', lastName: 'Sharma', dataOne };
 console.log(data2.dataOne());

//Output : Mohit Sharma

In the above program, in spite of declaring function fullName inside object data1, we get output as Mohit Sharma, because at the time of invoking dataOne is the property of object data2.

this under use strict

 "use strict"
        function data(){
            console.log(this);
        }
        data();

//Output : undefined

When we includeuse strict in our program it doesn't allow default binding and thus we get undefined.

So, that's it guys for in this blog. I will be very glad if you let me know any suggestions/corrections in any of my blog articles. If you find this article helpful, say hi to me on LinkedIn 🌸

And as I promised in my previous blog that we have a trip with Temporal Dead Zone, and here it is. So, if you haven't understood Temporal Dead Zone and how to play with variables using keywords let and const yet. Don't worry, this blog is totally dedicated to let, const, and temporal dead zone, and believe me if you will read this blog with the whole heart, this is going to be very beneficial for you in your future interviews. So without any further due let's start our trip.

Starting with basics: var, let, and const

As let and const are almost similar I will explain this only with the help of var and let. So, below is our program with the same code but using variable keywords var and let. So, what do you think, what will be the answer?

//using `var` keyword
console.log(food);
var food = 'cooking';

//using `let` keyword
console.log(food);
let food = 'cooking';

In our first program (using var), of course, we will get undefined and why is that, because of hoisting, Right? If you don't know what hoisting is, please read my previous blog. Now, let's move to our next program i.e. using the let keyword for variable declaration. Here, we will get an error as Uncaught ReferenceError: Cannot access 'food' before initialization. Now let's understand why this error occurs with let(and const).

First thing first, let and const are block-scoped unlike var which is function-scoped . Now, let's understand the term function-scoped and block-scoped.

• Function-Scoped: var is a function-scoped which means if we declare a variable inside a function, we will not be able to access it from outside the function. So, var is only limited to function i.e. if we declare variables inside if and for, we can access it from outside of if as well as of for. Let's understand this with the help of an example -

var food = 'cooking';
console.log(food);

// function
function funcOne(){
    var food;
    console.log(food);
}
funcOne();

// if
if(true){
    var food;
    console.log(food);
}

// for-loop
for(var i = 1; i <= 3; i++){
    var food;
    console.log(food);
}

//OUTPUT : 
//cooking
//undefined
//cooking
//cooking
//cooking
//cooking

In the above program, we have declared four variables with the same name food, one in the global scope, one inside function funcOne, one inside if, and the last one inside a for loop. Also, we have initialized with value cooking only at the top i.e. at Global Scope. Now, when we run this code we will get undefined only when function funcOne is invoked because the scope of variable food inside function fucnOne lies only inside the { } curly braces of the function funcOne. So, it cannot access the value cooking we initialized at the top. And that's why it is known as function-scoped.

• Blocked-Scoped: let and const are blocked-scoped which means if we declare a variable using let or const inside any block( block means inside any { } braces), whether it is a function, an if or a for loop, we will not be able to access it outside its scope. Now, let's understand this with the help of an example. Below we have the same program as above but replaced it with let to var.

let food = 'cooking';
console.log(food);

// function
function funcOne(){
    let food;
    console.log(food);
}
funcOne();

// if
if(true){
    let food;
    console.log(food);
}

// for-loop
for(let i = 1; i <= 3; i++){
    let food;
    console.log(food);
}

//OUTPUT :
//cooking
//undefined
//undefined
//undefined
//undefined
//undefined

Now you see we get undefined to all the variables we have declared with let inside function funcOne, inside if, and also inside for loop. This is because, when we declare variables using let and const, JavaScript Engine assigns memory to it in a separate scope i.e. the variable is only accessible inside { } curly braces. And here also comes the concept of **TEMPORAL DEAD ZONE**, so let's get immersed into it.

The Temporal Dead Zone

So, what is Temporal Dead Zone? Here is the answer, Temporal Dead Zone is the time that starts from the beginning of its(variable) scope till the variable is declared. This is the time when a variable is dead i.e. if you try to access a variable in this time zone, you will find it useless, you will not be able to access it. But you will find Temporal Dead Zone only when you declare variables using let and const. So, let's understand this concept with the help of an example -

// **********************************************************************
// ******************** Temporal Dead Zone *****************************
// *************************** for ***************************************
// ************************* variable ************************************
// ************************** `food1` ************************************
// ********************************************************************** 
let food1 = 'food is cooking at top';
console.log(food1);


function funcOne(){
    // **********************************************************************
    // ******************** Temporal Dead Zone *****************************
    // *************************** for ***************************************
    // ************************* variable ************************************
    // *************************  `food2`  ***********************************
    // **********************************************************************
    let food2 = 'food is cooking inside funcOne';
    console.log(food2);
}
funcOne();

Note : *(asterisks) are given to visualize how (temporal dead zone)TDZ looks.

Here we have two variables food1 and food2 declared at top-level and inside function funcOne respectively. The scope of variable food1 is Global because it is declared at the very top level. So, its temporal dead zone starts from the very beginning and ends when it is being declared. And variable food2 is declared inside function funcOne so its scope will be only inside the curly braces { } of the function funcOne. Now, its temporal dead zone starts from the start of curly brace { and ends when it is being declared.

Now, when we try to access variables declared with let and const inside this temporal dead zone, you will not be able to access it, you are going to get a bunch of errors instead. Don't believe in me? let's do it then. Just move the console.log() in the temporal dead zone and see what happens.

// **********************************************************************
// ******************** Temporal Dead Zone *****************************
// *************************** for ***************************************
// ************************* variable ************************************
// ************************** `food1` ************************************
console.log(food1); // OMG! inside TDZ
// ********************************************************************** 
let food1 = 'food is cooking at top';



function funcOne(){
    // **********************************************************************
    // ******************** Temporal Dead Zone *****************************
    // *************************** for ***************************************
    // ************************* variable ************************************
    // *************************  `food2`  ***********************************
    console.log(food2);  //OMG! it is also inside TDZ
    // **********************************************************************
    let food2 = 'food is cooking inside funcOne';

}
funcOne();

 Uncaught ReferenceError: Cannot access 'food1' before initialization

You will get an error at the very first line because the variable is not accessible there. That's why it is preferred to use let and const in place of var to avoid bugs. And now to save our variables from the TEMPORAL DEAD ZONE, we must always try to declare it at the very top-level of its scope.

So, that's it guys for in this blog. I will be very glad if you let me know any suggestions/corrections in any of my blog articles. If you find this article helpful, say hi to me on LinkedIn

First of all, let's understand the term 'HOISTING'. Hoisting means lifting up. For example, when we hoist our flag or when a crane lifts something, it's hoisting(lifting up) that thing, Right? Now, before proceeding further, I will recommend you to read my previous blog, because both the blogs are connected to each other and it will help you to understand the concept of this blog very easily. But let's revise a few concepts from the previous blog.

In the previous blog, we have understood that whenever we run our code an Execution Context is created and inside that context, we have two phases - Memory Creation Phase and Code Execution Phase. Memory Creation Phase runs first and allocates memory/space to all the variables and functions and after that Code Execution Phase runs and it assigns the actual values to its corresponding variables. But why I am saying here variables only, don't worry we will understand it later in this blog.

Variable Hoisting In JavaScript

Now coming back again to the Memory Creation Phase. We know that when we run our code Javascript Engine scans the whole code and allocates memory to all the variables and functions. But, in the case of variables, it assigns with a default value of undefined in Memory Creation Phase only, even before the execution of our code. Now let's understand all these concepts with the help of examples.

Variable Hoisting: using the keyword var

var exOne =  'I am learning Hoisting in Javascript';
console.log(exOne);
// Output : I am learning Hoisting in Javascript

What do you think, what will be the output? It's simple, Right? It will give I am learning Javascript in the console. Now let's move to the next program.

console.log(exTwo);
var exTwo = 'Programming is fun';
console.log(exTwo);

Now, what do you think, what will be the output? But before giving you the answer I want to remind you of something and that is 'Memory Creation Phase'. We know in Memory Creation Phase, Javascript Engine will allocate memory and the default value undefined to its variable before executing the program. So, let's find out the answer.

First, let's see the code above, here Javascript Engine will go to line 1 and find console.log(exTwo);. Now, it finds the variable exTwo but till now we haven't assigned any values to it and also trying to console log exTwo, Right? So, it will assign the default value i.e. undefined to exTwo. Now, JS Engine will move to line 2. Here, we are assigning 'Programming is fun' to variable exTwo, so it will hold this value. Now, JS Engine will move to line 3, here we are again trying to console log variable exTwo. Now, it will print 'Programming is fun', because here we have assigned 'Programming is fun ' to variable exTwo. So our output will look something like this,

//Output : 
// undefined
// Programming is fun

In the above program, we tried to console log variable exTwo before declaring it. But, what if we try to console log the variable exTwo without declaring it. So, what do think, what will be the output when we run the below code?

console.log(exTwo);

So, here also JS Engine will scan the whole program and it finds exTwo but there is no declaration for exTwo, so JS Engine will not assign any memory to it and throws an error.

 Uncaught ReferenceError: exTwo is not defined

Difference between undefined and not defined. undefined: we will get undefined as an output when we try to access the variable before its being initialized or without initializing the variable. On the other hand, not defined is an error, we will face when we try to access the variable before declaring it.

Think it of as a stranger whom you don't know, will you let him/her in your house, No!, Right? Now let's understand hoisting through the 'let' and 'const' keywords.

Variable Hoisting: using the keywords let and const

console.log(exThree);
let exThree = 'I love programming';

console.log(exFour);
const exFour = 'Javascript is a weird language';

When we declare variables using keywords let and const, it will work as same as the keyword var. But when we try to access the variable declared with keywords let and const before initializing it, it will throw an error.

 Uncaught ReferenceError: Cannot access 'exThree' before initialization

 Uncaught ReferenceError: Cannot access 'exFour' before initialization

But why do these happen? In the case of the keyword var, when we try to access the variable before initializing it we get undefined, but with keywords let and const we get an error. This happens because of the 'Temporal Dead Zone'. I will not cover this topic in this blog but don't worry we are going to play more with let and const and Temporal Dead Zone in the next blog. Now let's understand hoisting from the eyes of function.

Functional Hoisting In JavaScript

funcOne();
function funcOne(){
    console.log('hi! i am function one');
}
// Output  : hi! i am function one

What will be the output? Again, it's very simple, Right? We have used functions like it before so many times. But how does it possible to access a function even before declaring it. Have you remembered the last line of the second paragraph? So here is the answer, because in the case of functions, in Memory Creation Phase, JS Engine allocates the memory and the whole code inside that function as the value. Now when this function is invoked before or after the declaration of that function an Execution Context is created and in Memory Creation Phase inside this Execution Context, it will simply print the 'hi! i am function one' in the console and after that, this Execution Context will be deleted and the control will be transferred to Global Execution Context. Now if don't understand yet, just simply copy and paste the below code and open the console, you will find your answer.

console.log(funcOne);
function funcOne(){
    console.log('hi, i am function one');
}
console.log(funcOne);

You will get output in the console as :

ƒ funcOne(){
    console.log('hi, i am function one');
}
 ƒ funcOne(){
    console.log('hi, i am function one');
}

Now, you know how we are able to access the function even before declaring/initializing it. But, what if we write the same function using the fat arrow or anonymous function. So, let's find out our answer. We have our code below,

// Using fat arrow function
console.log(funcOne);
var funcOne = () => {
    console.log('hi, i am function one');
}
console.log(funcOne);
funcOne();

// Using anonymous function
console.log(funcOne);
var funcOne = function(){
    console.log('hi, i am function one');
}
console.log(funcOne);
funcOne();

And here I am asking for your answer again, so what will be your answer. Yes, you guessed it right, here funcOne will act as a variable and it will output in the console as :

undefined
ƒ (){
    console.log('hi, i am function one');
}
hi, i am function one

So, in both(using fat arrow and anonymous functions) the programs above, we have funcOne as a variable. So when JS Engine will scan these programs, it will allocate memory as well as the default value of undefined for line one. Now it will move to the next line and will assign the whole function to variable funcOne. In the second-last line, we are console logging the variable funcOne which holds the entire function in it, so it will print the whole code inside that function. Now, in the last line we are invoking funcOne which will now act as a function rather than a variable and again the whole cycle will repeat.

So, that's it guys in this blog. In the next blog, we will talk about the variable declared using keywords let and const, and also we will travel around the Temporal Dead Zone. Don't worry we will not die there. So, till then see you in the next blog.

I think we all like to watch BTS(Behind The Scene), whether it is a BTS of a movie or it could be BTS of your favorite show. But have you ever imagined if we could watch behind the scene of a programming language?

Yes, you heard it right we can see BTS of a programming language. So in this blog, we will see how JavaScript actually works behind the scene?

What happens when we run our JavaScript program?

So when you run your beautiful code in JavaScript, an Execution Context is created. So if you are wondering what the heck is this Execution Context, you can think it of like the movie set where all the shots of the movies are to be taken. So everything in JavaScript happens inside this Execution Context.

In the Execution Context, there are two main components.

1. Memory Component (also known as Variable Environment)
2. Code Component (also known as Thread of Execution)

Memory Component

In Memory Component, all the values of the variables are assigned in a key-value pair as simple as that.

Code Component

In Code Component, our code gets executed line by line in a specific order. We will understand it more deeply when we will talk about the phases that occur when we run our code. But for now, just keep in mind that when we run our code, an Execution Context is created and it has two components - memory and code component.

What after the Execution Context?

So far we know that when we run our code an Execution Context is created. Now, our code has to go through two beautiful phases and these phases are -

• PHASE 1: MEMORY CREATION PHASE

In this phase, our codes get scanned and all the variables are assigned with a value of undefined but in the case of function, it stores the whole code inside that function name. We will understand it later with the help of an example.

PHASE 2: CODE EXECUTION PHASE

In this phase, our codes run line by line in a specific order, and all the actual values of the variable get replaced by undefined which was held earlier as a placeholder.

EXAMPLE: Understanding Execution Context with the help of an example

I know it might be a little overwhelming, but don't worry let's understand the whole concept with the help of an example. Suppose this is the code we want to execute.

var a = 7;
function cube(n){
   var b = n*n*n;
   return b;
}
var c = cube(a);

Now when we run this code an Execution Context is created and inside the Execution Context it has to go through two phases - MEMORY CREATION PHASE and CODE EXECUTION PHASE. First, it will go through Memory Creation Phase and assign the memory to all the variables. It will assign undefined to variable a and c and also it will assign the whole code inside function cube to cube.

Now, here comes the Second Phase i.e. the Code Execution Phase. In this phase, our code will run line by line. So, when it goes to the first line, it will assign 7 to variable a. Now, it will move to the next line and founds that there is nothing to execute so it will jump to the sixth line. Now, the sixth line is invoking the function cube with parameter a which holds the value 7. Now, when a new function is invoked, another execution context is created inside the previous one and again it will follow the same procedure.

Now in this execution context (i.e. the execution context inside the Global Execution Context), again it has to go through Memory Creation Phase and Code Execution Phase. In Memory Creation Phase, it will assign undefined to variables n and b. Now, it will move to the next phase i.e. the Code Execution Phase. In this phase, variable n will be assigned with value a because it was the parameter of the function cube with variable c, now a will be replaced by 7 which is taken from the Global Execution Context. Now finally the output of variable b i.e 343 will be returned to variable c in the Global Execution Context. Now after that, firstly the Local Execution Context will be deleted and after returning the value of variable c, the Global Execution Context will be deleted.

Now, if you are wondering how JavaScript handles all this, I mean this is a lot. Suppose if we invoke a function inside another function and again inside another function, a number of 'Execution Context' will be created, but all this handles by JavaScript very beautifully. So how does it happen? Ladies and Gentlemen, give a big round of applauding to none other than our very dear CALLSTACK.

CallStack: The Game Changer

We know that JavaScript is a synchronous single-threaded programming language and thus it has only one CALLSTACK which means that it can perform only one command at a time in a specific order. So, what basically CALLSTACK does do?

CALLSTACK maintains the order of execution of EXECUTION CONTEXT which means that when we run our code the global execution context that is created at first will be pushed to the stack first and again if another function is invoked/called, it will be pushed at the top of CALLSTACK and again if another function is invoked it will be pushed to the top. Now when the task of the function at the top is completed it will be removed from the stack and at the end, the Global Execution Context is deleted.

This is how it looks Behind The Scene of JavaScript. Isn't it amazing? If you are reading till here, thank you so much for that, I appreciate it. Please give your suggestions/corrections below in the comment section, I will be very happy to know your ideas as well. Till then, see you in the next blog.