JavaScript Compiled or Interpreted: Understanding the Preparation Phase

What To Know in JavaScript (2026 Edition) An overview of what's new in language features, frameworks, runtimes, build tools, testing, and more.

JavaScript in 2026 has a LOT going on — and most devs are sleeping on the language-level stuff. ECMAScript 2025 shipped Iterator Helpers, Set methods, and Promise.try(). ES2026 is bringing the Temporal API (finally, no more date libraries), Explicit Resource Management with the using keyword, and a TypeScript v6 that flips strict mode on by default — which will quietly break a lot of projects that think they’re “fine.” My hot take: the signal that matters most here isn’t the new syntax. It’s that TypeScript is now the #1 language on GitHub with 66% YoY growth, AND a Go-based compiler is coming in v7 that promises ~10x speed. The tooling race is accelerating faster than most teams are upgrading. Meanwhile npm had one of its worst years for supply chain security — multiple incidents, one hitting 796 packages with 20M+ downloads. If you’re not actively hardening your dependency pipeline, you’re hoping for luck. The JS ecosystem is consolidating fast around Vite+, React Server Components, and AI-assisted code. The devs who understand why the architecture decisions are being made will outlast the ones who just follow the changelog.

Day 6: Undefined vs Not Defined in JS Today I completed the next topic in my learning journey, focusing on a concept that confuses many beginners: the difference between undefined and not defined in JavaScript. While they sound identical, they mean very different things to the JavaScript engine. When you declare a variable but do not assign it a value, JavaScript allocates memory for it during the creation phase of the execution context and automatically assigns it a special placeholder called undefined. This means the variable definitely exists, but it just does not have a value yet. On the other hand, not defined means the variable has not even been declared in your code. If you try to access a variable that the JavaScript engine cannot find anywhere in the memory allocation phase, it will throw a ReferenceError telling you that the variable is not defined. This topic also highlights why JavaScript is known as a loosely typed or weakly typed language. You do not need to specify what kind of data a variable will hold. You can assign a number to a variable, and later change it to a string or a boolean without the engine throwing an error. One major mistake to avoid is manually assigning the value undefined to a variable to clear it or mark it as empty. While JavaScript will let you do this, it is highly discouraged by the developer community. The keyword undefined is meant to be used exclusively by the JavaScript engine as a default state. If you need to explicitly state that a variable is empty, you should use null instead. Understanding these small details makes a huge difference when debugging complex applications and tracing variable states in your code. What is your favorite method for handling empty or uninitialized variables in your projects? #JavaScript #WebDevelopment #NamasteJavaScript #JSFundamentals #CodingJourney #FrontendEngineer #UndefinedVsNotDefined #CleanCode

Understood Hoisting in a much deeper way — not just definition, but what actually happens inside the JavaScript engine 👇 🧸 Imagine JavaScript like a teacher in a classroom Before teaching, the teacher prepares a register (memory) and writes all names first. 👉 JavaScript does the same thing before running code. 🧠 Behind the scenes (Real Concept): JavaScript runs in 2 phases: 1️⃣ Memory Creation Phase 2️⃣ Execution Phase ⚙️ During Memory Creation Phase: JavaScript creates something called an Execution Context (inside the Call Stack) Inside it, memory is allocated: 1- var → stored as undefined 2- let & const → stored but not initialized (Temporal Dead Zone) 3- functions → stored with full definition 💡 Example: console.log(a); var a = 10; 👉 Memory phase: a = undefined 👉 Execution phase: prints undefined 💡 Another example: console.log(b); let b = 20; 👉 Memory phase: b exists but is not initialized 👉 Execution phase: ❌ ReferenceError (because of Temporal Dead Zone) 💡 Functions: sayHi(); function sayHi() { console.log("Hi"); } 👉 Works because functions are fully stored in memory before execution 🎯 So what is Hoisting REALLY? It’s NOT “moving code to the top” ❌ It’s the result of how JavaScript allocates memory inside the Execution Context before execution begins ✅ 💼 Interview Insight: Most people say: 👉 “JS moves variables to top” ❌ Better answer: 👉 “Hoisting is a JavaScript behavior that occurs during the creation phase of the execution context, where memory is allocated for variables and functions before code execution. Variables declared with var are initialized as undefined, while let and const remain uninitialized in the Temporal Dead Zone, and function declarations are stored with their full definition.” #JavaScript #FrontendDeveloper #WebDevelopment #CodingJourney

Something small but nice I recently came across in JavaScript 👨💻✨ : String.trimEnd(). Earlier, whenever I needed to remove only the trailing spaces from a string, I used to write a small regex for it or sometimes even used .trim(). But .trim() removes both leading and trailing spaces, which isn’t always what we want — especially when the leading indentation actually matters. For example, I used to do something like this: const message = " Action Required: Clear Cache "; // Earlier approach const cleaned = message.replace(/\s+$/, ""); It works, but the regex isn’t exactly the most readable thing 🤯. Recently I noticed there’s a much cleaner native way 👇 const message = " Action Required: Clear Cache "; const result = message.trimEnd(); Now it clearly expresses the intent: remove only the trailing whitespace while keeping the start intact ✅. Result: " Action Required: Clear Cache" Small things like this make code more readable and intentional ✨, and since it’s part of modern JavaScript (along with trimStart()), there’s no need for regex hacks anymore. Sometimes the language already has the cleaner solution, we just discover it a bit later 😄🚀 #JavaScript #CodingTips #CleanCode #WebDev #WebDevelopment

🚀 Day 10 of My JavaScript Journey ✨Today I explored how JavaScript actually works behind the scenes — and honestly, it changed the way I look at code completely 🤯 Here’s what I learned 👇 🧠 How JavaScript Code RunsJavaScript doesn’t just execute line by line — it first creates an Execution Context which manages everything. ⚙️ Execution Context Phases1️⃣ Memory Allocation Phase Variables get stored with undefined Functions are stored completely 2️⃣ Execution Phase Code runs line by line Values get assigned and functions execute 📦 Call Stack & Execution Flow JavaScript uses a Call Stack to manage function calls Each function creates its own execution context Stack follows LIFO (Last In, First Out) 💾 Stack vs Heap Memory Stack → Stores primitive values (fast ⚡) Heap → Stores objects (reference-based 🧩) 🤖 Interpreter BehaviorJavaScript reads and executes code step by step using an interpreter — not compiled like some other languages. ❓ Why undefined Appears?Because during memory phase, variables are declared but not initialized yet. ⬆️ Hoisting Explained var is hoisted with undefined Functions are fully hoisted let & const are hoisted but stay in Temporal Dead Zone (TDZ) ❌ 🚫 Temporal Dead Zone (TDZ)You can’t access let & const variables before initialization — it throws an error. ⚠️ Function Expressions vs Hoisting Function declarations → hoisted ✅ Function expressions → behave like variables ❌ 💡 Key TakeawayUnderstanding execution context, memory, and hoisting makes debugging WAY easier and helps write cleaner code 🔥 📌 Slowly moving from writing code → to understanding how it actually works inside #JavaScript #WebDevelopment #MERNStack #CodingJourney #LearnToCode #FrontendDevelopment #DeveloperLife

🧠 𝗪𝗿𝗶𝘁𝗶𝗻𝗴 𝗰𝗹𝗲𝗮𝗻𝗲𝗿, 𝘀𝗺𝗮𝗿𝘁𝗲𝗿 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝘄𝗶𝘁𝗵 𝗗𝗲𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗶𝗻𝗴 Destructuring is one of those features in JavaScript that can significantly improve code readability and enhances Developers Experience—yet it’s often underutilized or misunderstood. So I decided to break it down in a structured way. New Blog Published: “Mastering Destructuring in JavaScript” https://lnkd.in/gHAWq_sP 🔍 What’s covered in the blog: 🔹 Array & object destructuring fundamentals 🔹 Nested destructuring patterns 🔹 Default values cases 🔹 Practical use cases for writing cleaner, maintainable code Hitesh Choudhary Piyush Garg Akash Kadlag Suraj Kumar Jha Chai Aur Code Nikhil Rathore Jay Kadlag DEV Community #JavaScript #WebDevelopment #TechnicalWriting #CleanCode #LearningInPublic #Chaicode #Cohort

🚀 JavaScript Hoisting — what it actually means (with a simple mental model) Most people say: “Variables and functions are moved to the top". Even the educators on youtube (some of them) are teaching that and even I remember answering that in my first interview call. That’s not wrong… but it’s also not the full picture. Then Priya what’s really happening? JavaScript doesn’t “move” your code. Instead, during execution, it runs in two phases: 1️⃣ Creation Phase Memory is allocated Variables → initialised as undefined Functions → fully stored in memory 2️⃣ Execution Phase Code runs line by line Values are assigned 🎨 Think of it like this: Before running your code, JavaScript prepares a “memory box” 📦 Creation Phase: a → undefined sayHi → function() { ... } Execution Phase: console.log(a) → undefined a = 10 🔍 Example 1 (var) console.log(a); // undefined var a = 10; 👉 Why? Because JS already did: var a = undefined; ⚡ Example 2 (function) sayHi(); // Works! function sayHi() { console.log("Hello"); } 👉 Functions are fully hoisted with their definition. 🚫 Example 3 (let / const) console.log(a); // ❌ ReferenceError let a = 10; 👉 They are hoisted too… But stuck in the Temporal Dead Zone (TDZ) until initialised. 🧩 Simple rule to remember: var → hoisted + undefined function → hoisted completely let/const → hoisted but unusable before declaration 💬 Ever seen undefined and wondered why? 👉 That’s hoisting working behind the scenes. #javascript #webdevelopment #frontend #reactjs #programming #100DaysOfCode

After understanding how JavaScript runs inside the engine (V8, JIT, etc.), today I moved one layer deeper into how JavaScript actually executes code internally. 🔹 Execution Context (EC) JavaScript runs code inside something called an Execution Context, which is basically the environment where code is evaluated and executed. There are two main types: 1. Global Execution Context (GEC) → created once when the program starts 2. Function Execution Context (FEC) → created every time a function is called Each execution context goes through two phases: 1. Creation Phase (Memory Setup) - Variables (var) are initialised as undefined - let/const are in the Temporal Dead Zone - Functions are fully stored in memory - Scope chain is determined 2. Execution Phase - Code runs line by line - Variables get actual values - Functions are executed 🔹 Call Stack (Execution Stack) JavaScript uses a call stack (LIFO) to manage execution: - When a function is called → pushed to stack - When it finishes → popped from stack - This helps track exactly what is running at any moment 🔹 Hoisting During the creation phase: - var → hoisted as undefined - let/const → hoisted but not initialised (TDZ) - Functions → fully hoisted 🔹 Lexical Scope Scope is determined by where code is written, not where it is called. This is why inner functions can access outer variables. 🔹 Closures Closures allow a function to remember variables from its outer scope, even after the outer function has finished execution. This is a powerful concept used in: - Data privacy - State management - Real-world application logic 💡 Big realisation from today: Understanding execution context and the call stack makes JavaScript feel much less “magical” and much more predictable. Instead of guessing what the code will do, I can now trace exactly how it runs step by step. On to Day 3 tomorrow 🔥 #javascript #webdevelopment #programming #softwareengineering #learning #developers

I’ve now wrapped up my current deep dive into JavaScript coercion, ending with one of the most misunderstood parts of the language: "==" vs "===" My biggest takeaway is that the right way to understand equality in JavaScript is not by memorising strange examples like: - 5 == "5" - false == 0 - "" == 0 - null == undefined Instead, it is by understanding the actual rules behind them. What I learned is that === and == are backed by different abstract operations in the ECMAScript spec: 1. === → IsStrictlyEqual(x, y) 2. == → IsLooselyEqual(x, y) For ===, the mental model is simple: - if the types differ, the result is false - no cross-type coercion happens But == is not just “convert both sides to numbers”. It follows a case-by-case algorithm. Depending on the values involved, JavaScript may: 1. convert strings to numbers 2. convert booleans to numbers 3. convert objects to primitives 4. apply the special null / undefined rule 5. compare BigInt and Number in a specific way That is why: - 5 == "5" is true - false == 0 is true - null == undefined is true - but null == 0 is false The best part of learning this topic is that JavaScript now feels much less random. I also feel more confident reading the ECMAScript spec now. I do not need to learn every abstract operation in depth, but I know how to navigate the spec when I want to understand why JavaScript produced a certain result. I’ve been maintaining detailed notes on everything I learned here: GitHub repo: https://lnkd.in/ephuZ-w6 #JavaScript #TypeScript #WebDevelopment #SoftwareEngineering #ECMAScript