JavaScript Codewars Kata: European Floor Conversion

Understanding encapsulation beyond the textbook definition has made OOP much clearer to me. Encapsulation isn’t about hiding everything. It’s about protecting internal state and controlling how an object is used. In modern JavaScript, we now have true private class fields using #. The properties and methods we write using #, cannot be accessed outside the class. It forces anyone using the object to interact with it only through the methods we expose. That’s where public methods come in. Public methods define the safe interface of the object. They’re like the “buttons” we’re allowed to press. Also there are static methods and fields. These methods and fields belong to the class itself, not to individual instances. They’re useful for helper functions or class-level logic that doesn’t depend on a specific object. What really clarified everything for me was understanding the difference between encapsulation and abstraction. Encapsulation is about protecting and structuring data inside a class. Abstraction is about hiding complexity and exposing only what’s necessary to the user. Encapsulation protects the inside, while, abstraction simplifies the outside. All of these helps refine how I think about my code. #JavaScript #WebDevelopment #TechJourney #SoftwareEngineering #Growth

𝗪𝗲𝗹𝗰𝗼𝗺𝗲 𝘁𝗼 𝗗𝗮𝘆 𝟭𝟬 Let's understand 𝗧𝗲𝗺𝗽𝗼𝗿𝗮𝗹 𝗗𝗲𝗮𝗱 𝗭𝗼𝗻𝗲 (𝗧𝗗𝗭) Creation Phase • scope is created • variable names are registered • memory is allocated Execution Phase • code runs line by line • values are assigned 𝙒𝙝𝙖𝙩 𝙝𝙖𝙥𝙥𝙚𝙣𝙨 𝙩𝙤 𝙫𝙖𝙧𝙞𝙖𝙗𝙡𝙚𝙨? 𝚟𝚊𝚛 𝚊 = 𝟷𝟶; • hoisted • initialized as undefined • accessible immediately 𝚕𝚎𝚝 𝚋 = 𝟸𝟶; • hoisted • not initialized • stored in a separate memory slot This uninitialized window is called the Temporal Dead Zone. 𝙒𝙝𝙚𝙣 𝙙𝙤𝙚𝙨 𝙏𝘿𝙕 𝙨𝙩𝙖𝙧𝙩 𝙖𝙣𝙙 𝙚𝙣𝙙? • TDZ starts when the scope is entered • TDZ ends when the variable is initialized The length of TDZ depends on when the declaration is executed, not where it is written. 𝙒𝙝𝙮 𝙙𝙤𝙚𝙨 𝙅𝙖𝙫𝙖𝙎𝙘𝙧𝙞𝙥𝙩 𝙩𝙝𝙧𝙤𝙬 𝙍𝙚𝙛𝙚𝙧𝙚𝙣𝙘𝙚𝙀𝙧𝙧𝙤𝙧? Because: • the variable exists • but its value is unavailable TDZ is designed to: • prevent silent bugs • fail fast instead of returning undefined • enforce predictable execution order 𝙏𝘿𝙕 𝙞𝙨 𝙖𝙗𝙤𝙪𝙩 𝙩𝙞𝙢𝙚, 𝙣𝙤𝙩 𝙨𝙘𝙤𝙥𝙚 A variable can be in the same scope and still be inaccessible if it is accessed before initialization. TDZ is enforced strictly based on execution timing. 𝙏𝘿𝙕 𝙬𝙞𝙩𝙝 𝙘𝙤𝙣𝙨𝙩 const is intentionally stricter: • it must be initialized immediately • reassignment is disallowed • TDZ enforces immutability rules 𝙆𝙚𝙮 𝙞𝙣𝙨𝙞𝙜𝙝𝙩 Temporal Dead Zone is not about hoisting being absent. It exists because initialization is delayed. let and const are hoisted — but safely. #JavaScript #TemporalDeadZone #JavaScriptHoisting #LetAndConst #JavaScriptFundamentals #JSConcepts #FrontendDevelopment #WebDevelopment #FrontendDeveloper #SoftwareEngineering #LearningInPublic #100DaysOfJavaScript

I once thought extending JavaScript built-in prototypes was a power move. So I did it. I added: • String.prototype.toTitleCase() • String.prototype.toStdNumber() • Number.prototype.toStd() And honestly? It felt amazing. Suddenly I could write: price.toStd(2) instead of formatNumber(price, 2) Cleaner. Shorter. Elegant. ✨ Until I realized what I had actually done… I hadn’t improved my code. I had modified JavaScript itself. That means: ⚠ Every string now had my methods ⚠ Every number everywhere inherited them ⚠ Any library could conflict with them ⚠ Bundle order could break them ⚠ Future JS specs could override them It’s not just a helper. It’s a global mutation. That’s when it hit me: Prototype extension isn’t a shortcut. It’s a hidden global side effect. Senior engineers don’t avoid it because it’s impossible. They avoid it because it’s unpredictable. Now my rule is simple: ✔ Utilities ✔ Pure functions ✔ Explicit imports ❌ Prototype hacks Just because JavaScript lets you do something… doesn’t mean production should. 😉 #JavaScript #CleanCode #Programming #SoftwareEngineering #WebDevelopment

𝐀𝐭 𝐟𝐢𝐫𝐬𝐭, { } 𝐥𝐨𝐨𝐤𝐞𝐝 𝐥𝐢𝐤𝐞 𝐣𝐮𝐬𝐭 𝐬𝐲𝐧𝐭𝐚𝐱. Then I realized it actually defines 𝐡𝐨𝐰 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐜𝐨𝐧𝐭𝐫𝐨𝐥𝐬 𝐚𝐜𝐜𝐞𝐬𝐬. The confusion started when variables behaved differently inside and outside blocks. Some were accessible, some weren’t — even though they were declared only a few lines apart. That’s when 𝐛𝐥𝐨𝐜𝐤 𝐬𝐜𝐨𝐩𝐞 and 𝐬𝐡𝐚𝐝𝐨𝐰𝐢𝐧𝐠 started to make sense. In JavaScript, a 𝐛𝐥𝐨𝐜𝐤 (also called a 𝐜𝐨𝐦𝐩𝐨𝐮𝐧𝐝 𝐬𝐭𝐚𝐭𝐞𝐦𝐞𝐧𝐭) is a group of statements wrapped in { }. Blocks exist so multiple statements can be used where JavaScript expects a single one — like in if, for, or while. This grouping directly affects scope. What clarified it for me: A 𝐛𝐥𝐨𝐜𝐤 𝐬𝐜𝐨𝐩𝐞 allows access only within its { }. let and const are 𝐡𝐨𝐢𝐬𝐭𝐞𝐝 𝐢𝐧𝐬𝐢𝐝𝐞 𝐭𝐡𝐞 𝐛𝐥𝐨𝐜𝐤 𝐬𝐜𝐨𝐩𝐞. They get 𝐬𝐞𝐩𝐚𝐫𝐚𝐭𝐞 𝐦𝐞𝐦𝐨𝐫𝐲 𝐬𝐩𝐚𝐜𝐞 limited to that block. var is hoisted to the 𝐠𝐥𝐨𝐛𝐚𝐥 (𝐨𝐫 𝐟𝐮𝐧𝐜𝐭𝐢𝐨𝐧) 𝐬𝐜𝐨𝐩𝐞. After the block ends, let and const are inaccessible, but var is not. 𝐒𝐡𝐚𝐝𝐨𝐰𝐢𝐧𝐠 𝐡𝐚𝐩𝐩𝐞𝐧𝐬 𝐰𝐡𝐞𝐧 𝐚 𝐯𝐚𝐫𝐢𝐚𝐛𝐥𝐞 𝐢𝐧𝐬𝐢𝐝𝐞 𝐚 𝐛𝐥𝐨𝐜𝐤 𝐨𝐯𝐞𝐫𝐫𝐢𝐝𝐞𝐬 𝐚 𝐯𝐚𝐫𝐢𝐚𝐛𝐥𝐞 𝐰𝐢𝐭𝐡 𝐭𝐡𝐞 𝐬𝐚𝐦𝐞 𝐧𝐚𝐦𝐞 𝐨𝐮𝐭𝐬𝐢𝐝𝐞 𝐢𝐭. With let and const, this is intentional and scoped. With var, things get risky. 𝐈𝐥𝐥𝐞𝐠𝐚𝐥 𝐬𝐡𝐚𝐝𝐨𝐰𝐢𝐧𝐠 occurs when a let variable is shadowed by var, because var ignores block boundaries. What changed my thinking is realizing that block scope still follows 𝐥𝐞𝐱𝐢𝐜𝐚𝐥 𝐬𝐜𝐨𝐩𝐢𝐧𝐠 . Scopes are determined by where the code is written — not how it runs. Once that clicks, shadowing stops being mysterious and starts being predictable. #JavaScript #SoftwareEngineering #ProblemSolving #DeveloperJourney #LearningInPublic #TechCommunity #ContinuousLearning

Think JavaScript just reads your code line-by-line? Think again. 🧠 We often hear that JavaScript is a single-threaded interpreted language. It reads code, executes a task, and moves on. Simple, right? But actually, a lot happens before that execution phase kicks in. The JS Engine (like V8) doesn't just look at var a = 10; and run it. It has to understand it first. Here is the 3-step compilation pipeline that happens behind the scenes: 1️⃣ Tokenization (Lexing): The engine breaks code into small "tokens" (keywords, variables, operators). 2️⃣ Parsing: It arranges these tokens into a tree structure called an AST (Abstract Syntax Tree). 3️⃣ Code Generation: Finally, it converts that AST into executable machine code. Only then does your code actually run. It’s fascinating how much engineering goes into processing even a single line of JavaScript! Have you looked into the V8 engine architecture lately? It’s a rabbit hole worth going down. 👇 #JavaScript #WebDevelopment #Frontend #Engineering #TechTips

Proof of Code #1: BMI Calculator (Vanilla JavaScript) I just completed the first project from the 38 “Proof of Code” challenge in our ongoing Dev and Design Frontend Engineering bootcamp led by Joseph Brendan. This project looks simple on the surface but the real goal was not complexity. The goal was thinking like an engineer. Here’s what I focused on: 1. Turning a real-world formula into functional logic 2. Writing clear pseudocode before touching JavaScript 3. Using conditional logic to categorize outcomes 4. Accepting user input dynamically using prompts 5. Returning structured, readable output How it works: User enters weight, height, and age, The program calculates BMI using the standard formula, Logic checks the BMI range, A final health category is returned and logged. Key lesson: Coding is less about syntax and more about breaking problems into steps. Before writing the function, I defined: Inputs Process Decision rules Expected output That small planning step made the implementation straightforward. This is project 1 of 38, and each challenge is designed to strengthen core JavaScript fundamentals not shortcuts, not frameworks, just solid problem-solving skills. Sometimes the simplest projects teach the deepest lessons. watch the video illustration: https://lnkd.in/dM44Fre4 Github link to code: https://lnkd.in/ddh8M9GW

𝐂𝐥𝐨𝐬𝐮𝐫𝐞𝐬 𝐞𝐱𝐩𝐥𝐚𝐢𝐧 𝐰𝐡𝐲 𝐟𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐬 𝐢𝐧 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐝𝐨𝐧’𝐭 𝐟𝐨𝐫𝐠𝐞𝐭 𝐭𝐡𝐞𝐢𝐫 𝐨𝐫𝐢𝐠𝐢𝐧𝐬. For a long time, I knew that functions could be assigned to variables, passed into other functions, and even returned — yet they continued to work correctly long after their outer function had finished executing. That behavior felt counterintuitive at first. The clarity came from understanding 𝐥𝐞𝐱𝐢𝐜𝐚𝐥 𝐬𝐜𝐨𝐩𝐢𝐧𝐠. In JavaScript, a 𝐜𝐥𝐨𝐬𝐮𝐫𝐞 is created when a function is bundled together with its 𝐥𝐞𝐱𝐢𝐜𝐚𝐥 𝐞𝐧𝐯𝐢𝐫𝐨𝐧𝐦𝐞𝐧𝐭. When a function is returned from another function, it doesn’t lose access to the variables it needs. Instead, it retains references to the scope where it was originally defined. What made this click for me: • Functions can be 𝐚𝐬𝐬𝐢𝐠𝐧𝐞𝐝 𝐭𝐨 𝐯𝐚𝐫𝐢𝐚𝐛𝐥𝐞𝐬 and 𝐩𝐚𝐬𝐬𝐞𝐝 𝐚𝐬 𝐚𝐫𝐠𝐮𝐦𝐞𝐧𝐭𝐬 • Returned functions 𝐩𝐫𝐞𝐬𝐞𝐫𝐯𝐞 𝐭𝐡𝐞𝐢𝐫 𝐥𝐞𝐱𝐢𝐜𝐚𝐥 𝐬𝐜𝐨𝐩𝐞 • Closures maintain 𝐬𝐭𝐚𝐭𝐞 𝐚𝐜𝐫𝐨𝐬𝐬 𝐞𝐱𝐞𝐜𝐮𝐭𝐢𝐨𝐧𝐬 • This behavior holds true even in 𝐚𝐬𝐲𝐧𝐜𝐡𝐫𝐨𝐧𝐨𝐮𝐬 𝐜𝐨𝐝𝐞 This shifted how I think about real-world JavaScript patterns. Closures form the backbone of: • 𝐌𝐨𝐝𝐮𝐥𝐞 𝐝𝐞𝐬𝐢𝐠𝐧 𝐩𝐚𝐭𝐭𝐞𝐫𝐧𝐬 • 𝐂𝐮𝐫𝐫𝐲𝐢𝐧𝐠 𝐢𝐧 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 • Utility functions like 𝐨𝐧𝐜𝐞 • Managing state in the 𝐚𝐬𝐲𝐧𝐜 𝐰𝐨𝐫𝐥𝐝 (setTimeout, callbacks) Once closures are seen as a natural outcome of lexical scoping, they stop feeling mysterious — and start feeling intentional. #JavaScript #SoftwareEngineering #ProblemSolving #DeveloperJourney #LearningInPublic #TechCommunity #ContinuousLearning Picture Credit :- Ayush Verma

🚀 Optimizing Array Manipulation: The Two-Pointer Strategy 💡 Yesterday, I tackled the "Move Zeroes" challenge on LeetCode using JavaScript! 👨💻 The mission? Move all 0s to the end of an array while preserving the relative order of non-zero elements—all without creating a copy of the array. 🚫📋 Initially, a common approach is to filter and join arrays, but that results in $O(n)$ space complexity. To keep the solution professional and memory-efficient, I implemented the Two-Pointer technique. 🎯 🧠 The Logic: Pointer A (Slow): 🐢 Tracks the position where the next non-zero element belongs. Pointer B (Fast): 🐇 Iterates through the entire array to find non-zero values. The Swap: ✨ Whenever Pointer B encounters a non-zero element, we swap the values and increment Pointer A. 📊 The Result: ✅ Time Complexity: $O(n)$ (Clean, single-pass efficiency) ✅ Space Complexity: $O(1)$ (Optimized in-place manipulation) Mastering these "in-place" constraints is a game-changer for writing scalable, production-ready code. It’s not just about solving the problem; it’s about solving it efficiently. 💪 #JavaScript #WebDevelopment #LeetCode #Algorithms #CodingInterview #SoftwareEngineering #ProblemSolving #100DaysOfCode

🚀 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗛𝗼𝗶𝘀𝘁𝗶𝗻𝗴 – 𝗧𝗵𝗲 𝗥𝗶𝗴𝗵𝘁 𝗪𝗮𝘆 Most developers say “𝘑𝘢𝘷𝘢𝘚𝘤𝘳𝘪𝘱𝘵 𝘪𝘴 𝘩𝘰𝘪𝘴𝘵𝘦𝘥.” But very few truly understand what actually happens under the hood during execution. I just published a deep-dive video where I visually break down 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗛𝗼𝗶𝘀𝘁𝗶𝗻𝗴 step-by-step — not just the definition, but the actual internal working with execution context. In this video, we explore: ✅ What hoisting 𝘳𝘦𝘢𝘭𝘭𝘺 means ✅ How JavaScript creates the 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 ✅ The 𝗠𝗲𝗺𝗼𝗿𝘆 𝗖𝗿𝗲𝗮𝘁𝗶𝗼𝗻 𝗣𝗵𝗮𝘀𝗲 vs 𝗖𝗼𝗱𝗲 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗣𝗵𝗮𝘀𝗲 ✅ How var, let, and const are hoisted internally ✅ Why var is initialized with undefined ✅ Why let and const live in the 𝗧𝗲𝗺𝗽𝗼𝗿𝗮𝗹 𝗗𝗲𝗮𝗱 𝗭𝗼𝗻𝗲 (𝗧𝗗𝗭) ✅ Function Declarations vs Function Expressions vs Arrow Functions ✅ Why accessing let and const before declaration throws an error ✅ Common JavaScript hoisting interview questions This video is especially helpful for: • JavaScript beginners • Frontend developers • Developers preparing for interviews • Anyone who wants to truly understand how JavaScript works internally If you’ve ever memorized hoisting rules without understanding the why, this will change that. Let me know your thoughts after watching 👇 https://lnkd.in/dStfuxvq #JavaScript #WebDevelopment #Frontend #Programming #Coding #JS #SoftwareDevelopment #InterviewPreparation

I thought I understood map(), filter() and reduce()… until I wrote their polyfills. We use these methods daily in JavaScript. But I wanted to understand what actually happens behind the scenes. Building polyfills is one of the best ways to master: 1️⃣ Prototypes: How inheritance actually works in JS. 2️⃣ Execution Context: Mastering the behavior of this. 3️⃣ Edge Cases: Handling reduce() accumulators without an initial value. I’ve put together a deep dive into these internals. What’s inside: The logic behind Array.prototype. Step-by-step custom implementations. The "hidden" index logic in .reduce(). Which polyfill was the hardest for you to learn? Let’s discuss below! #Javascript #Chai aur Code #Polyfills