Type vs Interface in TypeScript: Practical Examples

🚀 Day 1/100 — Starting My 100 Days of JavaScript & TypeScript Today I’m starting a 100 Days of JavaScript & TypeScript challenge. The goal isn’t just to “learn JS again.” It’s to deeply understand how JavaScript works under the hood and apply it the way production systems and product engineers actually use it. Over the next 100 days I’ll be focusing on: • JavaScript fundamentals (execution context, event loop, closures)  • Advanced TypeScript for scalable systems  • Real-world utilities used in production  • Performance & architecture patterns  • Building small product-ready systems Why this challenge? Because great product engineers don’t just write code — they understand how systems behave, scale, and fail. So each day I’ll share: ✔ What I built  ✔ The concept behind it  ✔ How it applies to real-world products 📌 Today’s Topic: JavaScript Execution Context Before any JavaScript code runs, the engine creates something called an execution context. Think of it as the environment where code is evaluated and executed. Each execution context contains: • Variable Environment – where variables and functions live  • Scope Chain – determines variable access  • this Binding – context of execution Example: var name = "Engineer"; function greet() {   var message = "Hello";   console.log(message + " " + name); } greet(); When this runs: 1️⃣ Global Execution Context is created  2️⃣ Variables and functions are stored in memory  3️⃣ A Function Execution Context is created when greet() runs Understanding this concept is key to mastering: • Closures  • Hoisting  • Async behavior 💡 Engineering Insight Many tricky JavaScript bugs come from misunderstanding execution context and scope, especially in async code and callbacks. Mastering this concept makes debugging far easier in large production codebases. ⏭ Tomorrow: How the JavaScript Event Loop Actually Works #100DaysOfCode  #JavaScript  #TypeScript  #SoftwareEngineering  #ProductEngineering

What to actually use instead of any in TypeScript. The problem is, any basically turns TypeScript back into JavaScript. It kills your autocomplete, disables type checking, and spreads through your codebase like a virus. So, what should you use when things get complicated? 1. Use unknown (The responsible sibling) Think of unknown as a safer any. You can assign anything to it, but TypeScript will strictly stop you from using its properties or methods until you explicitly check what it is (type narrowing). 2. Use Record<K, V> for dynamic objects Need an object where you don't know the exact keys yet? Don't just type data: any. Use Record<string, unknown>. You keep the flexibility of dynamic keys without losing your safety net. 3. Use Generics <T> for reusable logic Writing a helper function? Instead of accepting any and returning any, use a generic. It tells the compiler: "I don't know the exact type yet, but whatever goes in, comes out with the exact same shape." and Zod or Valibot for API responses If data is coming from the outside world, any is a ticking time bomb. Use a schema library at the boundary. It validates the data at runtime and automatically infers strict TypeScript types for you. TypeScript is an amazing tool, but you're paying a lot of setup tax just to write plain JavaScript if you abuse any. #TypeScript #WebDevelopment #Frontend #JavaScript #CleanCode #React #WebDev

JavaScript or TypeScript: Choose Your Pain JavaScript fails silently. That’s not a bug. That’s the design. • You pass the wrong data → it runs. • You access something undefined → it runs. • You forget a null check → it runs. • Everything runs. And that’s the problem. Because when everything runs, nothing is guaranteed to work. • You don’t get errors. • You get behavior. • Weird, inconsistent, hard-to-reproduce behavior. The kind that shows up: • only in production • only for some users • only when you’re not looking. JavaScript is optimistic. It assumes you know what you’re doing. That’s a dangerous assumption. Most bugs don’t come from complex systems. They come from simple assumptions that were never verified. • A missing property. • A wrong shape. • A value you thought would always be there. And JavaScript just shrugs and keeps going. No alarms. No warnings. No guardrails. Just vibes. At some point you realize: → The problem isn’t your code. → It’s that the system lets bad code exist without consequences. → That’s when you stop relying on runtime behavior and start enforcing correctness before the code even runs. TypeScript isn’t about types. Linters aren’t about style. They’re about forcing reality to match your assumptions. Because if the system doesn’t check your logic… Production will. #javascript #typescript #webdev #frontend #softwareengineering #coding #devlife

Stop Overthinking the Switch to TypeScript 🛑 When most JavaScript developers hear "TypeScript," they immediately think: ❌ Impossible learning curve ❌ Frustrating syntax errors ❌ Days of lost productivity But there is a "secret" way to transition that most people ignore. The Strategy: Start in TS, Write in JS. Don't wait until you "know" TypeScript to use it. Instead, follow this 3-step transition: 1️⃣ Initialize every new project in TypeScript. Set your environment up today. Even if you don't write a single interface yet, get the infrastructure in place. 2️⃣ Keep writing JavaScript. TypeScript is a superset of JavaScript. Valid JS is (mostly) valid TS. If you hit a complex logic block and don't know the proper types yet? Just keep moving. Use any as a temporary bridge or let the compiler infer what it can. 3️⃣ Add notions as you learn. As you understand the language better, go back and swap those any types for Interfaces. Add Enums where they make sense. Refactor your Functions to include Generics. Why this works: By maintaining your JavaScript flow where you're uncertain, you keep your velocity high. Over an extended period, you aren't "studying" TypeScript; you're living in it. Before you know it, you've gone from a JS dev to a certified TypeScript engineer without ever feeling the "weight" of the learning curve. The goal isn't 100% type safety on Day 1. The goal is progress. 🚀 How did you make the switch? Or what’s stopping you from starting today? Let’s talk below! 👇

“JS Fundamentals Series #1: Execution Context & Call Stack” Behind every line of JavaScript lies a hidden world of execution contexts and stacks — let’s uncover it 👇 Whenever a JavaScript program runs, the JS engine creates a Global Execution Context (GEC), a Global Object, and a special this variable. Think of the Execution Context as a big container with two parts: 1. Memory Component 2. Code Component 🔄 The whole JavaScript code gets executed in two phases:- 1. Memory creation phase: All the variables and functions are assigned memory in the form of "key: value" pairs inside the Memory Component. Variables are assigned a special keyword called "undefined" until their value is initialized. Functions are assigned their whole body as it is. 2. Code execution phase: Inside Code Component, each piece of code gets executed, only one command will get executed at a time and won't move onto the next until the current command is executed. Whenever a function is called/invoked, a new Local Execution Context is created inside the Code Component. 📚 Call Stack This is where all the Execution Contexts are executed in a particular order. It follows a principle known as LIFO - Last In First Out. 💡 Why this matters: Understanding the call stack helps me debug recursion errors, async issues, and write cleaner, more predictable code. 🚀 Next up: I’ll dive into Scope Chain & Lexical Environment. Stay tuned! #JavaScript #Frontend #WebDevelopment #NamasteJS #LearningJourney

Why I switched from js-joda to date-fns for Date and Time 🤔 📅 On my last project, we were using two different date and time libraries: js-joda and date-fns. This made the code harder to read and support: two different APIs, two ways to work with dates, extra conversions. I decided we should keep only one library and chose date-fns. Here’s why date-fns worked better for us: ▪️Simple, functional API With date-fns you just call functions like addDays(date, 3) or format(date, 'dd.MM.yyyy'). You work with the native Date object, which is familiar to any JavaScript developer. ▪️Easier for new developers New people don’t have to learn js-joda types like LocalDate or ZonedDateTime. It’s much faster to start writing code when you only use Date + small helper functions. ▪️Less boilerplate and conversions Before, we often had to convert between js-joda objects and Date. With date-fns everything stays in one format, so there is less extra code and fewer mistakes. ▪️Good for bundle size date-fns supports tree-shaking 🔥 You import only the functions you actually use, so the bundle stays smaller. ▪️Lots of examples and community It’s easy to find examples, answers, and snippets for date-fns online. That saves time when you need to solve common tasks with dates and time. After we switched fully to date-fns, the codebase became more consistent and easier to maintain. 👍 📝 Sometimes the best choice is not the "most powerful" library, but the one that keeps the project simple and clear for the whole team. #React #JavaScript #TypeScript #Frontend #Date #DateTime

𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝘁𝗵𝗲 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗘𝘃𝗲𝗻𝘁 𝗟𝗼𝗼𝗽 𝗖𝗵𝗮𝗻𝗴𝗲𝗱 𝗛𝗼𝘄 𝗜 𝗗𝗲𝗯𝘂𝗴 One of the biggest turning points in my frontend journey was truly understanding the JavaScript Event Loop. Most async bugs aren’t framework issues. They’re execution order issues. Let’s break something simple: Many developers expect: Start Timeout Promise End But the actual output is: Start End Promise Timeout Why? Because JavaScript has: • Call Stack • Web APIs • Microtask Queue (Promises) • Macrotask Queue (setTimeout, setInterval) Execution order: 1️⃣ Synchronous code runs first (Call Stack) 2️⃣ Microtasks (Promises) run next 3️⃣ Macrotasks (setTimeout) run after that Understanding this helps when: ✔ Debugging Angular async pipes ✔ Handling React state updates ✔ Managing Node.js API calls ✔ Preventing race conditions Async/await doesn’t change how JavaScript works. It just makes it easier to read. After 3+ years in development, I can confidently say: Strong JavaScript fundamentals reduce production bugs more than any framework knowledge. What async issue taught you the most? 👇 #JavaScript #EventLoop #AsyncProgramming #Angular #ReactJS #NodeJS

🚀 TypeScript vs JavaScript — 2026 Reality Check JavaScript builds fast. TypeScript builds safe. That’s the simplest way to explain it. But the real difference shows up when projects scale. 🔹 JavaScript Dynamic typing Flexible and quick to prototype Great for small projects Errors show at runtime 🔹 TypeScript Static typing Compile-time error detection Explicit contracts between components Better maintainability for large codebases When I started building backend systems, I realized something important: Speed matters. But predictability matters more. In small apps, JavaScript feels faster. In real-world backend systems with APIs, authentication, database models, and team collaboration — TypeScript reduces bugs before production. It forces you to think about: Data contracts Function signatures Return types Edge cases And that thinking improves architecture. 💡 My Take: If you are learning backend in 2026: 👉 Learn JavaScript deeply. 👉 Then move to TypeScript for serious projects. 👉 Don’t use TypeScript just for syntax — use it for design discipline. The best developers don’t just code fast. They build systems that don’t break. What do you prefer — speed or safety? #JavaScript #TypeScript #WebDevelopment #BackendDevelopment #MERN #NodeJS #SoftwareEngineering #Brototype #RemoteLife

🚀 Type vs Enum in TypeScript — What's the REAL Difference? Many developers confuse `type` and `enum` in TypeScript, but they serve very different purposes. Let’s break it down clearly 👇 🔹 1️⃣ type (Type Alias) `type` exists only during compilation. It is used by the TypeScript compiler for type checking and disappears completely in the generated JavaScript. Example: type Role = "admin" | "user" | "guest"; let userRole: Role = "admin"; After compilation to JavaScript: let userRole = "admin"; ✔ No extra JavaScript code   ✔ Compile-time safety only   ✔ Zero runtime cost 🔹 2️⃣ enum `enum` exists at runtime because TypeScript converts it into a JavaScript object. Example: enum Role {  Admin,  User,  Guest } let role = Role.Admin; Compiled JavaScript: var Role; (function (Role) {  Role[Role["Admin"] = 0] = "Admin";  Role[Role["User"] = 1] = "User";  Role[Role["Guest"] = 2] = "Guest"; })(Role || (Role = {})); ✔ Exists in JavaScript   ✔ Can be used at runtime   ✔ Useful for fixed sets of constants 🔑 The Key Difference type → Compile-time only   enum → Runtime + Compile-time `type` helps with type modeling and safety, while `enum` creates a real JavaScript object that exists at runtime. 💡 Modern TypeScript Tip Many teams today prefer union types instead of enums: type Status = "loading" | "success" | "error"; Why? ✔ Smaller bundle size   ✔ Cleaner JavaScript output   ✔ Simpler and more flexible 🔥 Rule of Thumb • Use `type` for type modeling   • Use `enum` when you need runtime constants #TypeScript #JavaScript #WebDevelopment #Programming #SoftwareEngineering #Frontend

Want insanely fast builds in your JavaScript projects? ESBuild vs SWC is a comparison every modern developer should understand. Most developers know both tools are blazing fast alternatives to traditional compilers like Babel. But they're built with different goals in mind. Choosing the right one can seriously impact your dev experience. Here's a simple breakdown: ✅ ESBuild: Speed First, Simplicity Wins - ESBuild is written in Go and designed to be extremely fast with minimal configuration. - Lightning-fast bundling and transpilation - Built-in support for TypeScript, JSX, and minification - Zero-config experience for most projects - Ideal for dev servers, small-to-medium apps, and tooling - The trade-off? It doesn't aim for full compatibility with every edge case or plugin ecosystem like Babel. ✅ SWC: Speed + Flexibility - SWC is written in Rust and focuses on being a fast, production-ready compiler with extensibility. - Comparable speed to ESBuild (sometimes faster in large projects) - Strong TypeScript and JSX support - Growing plugin ecosystem - Used by frameworks like Next.js under the hood - SWC is often a better fit when you need more control or are replacing Babel in larger, more complex setups. ✅ Key Differences - Language: ESBuild (Go) vs SWC (Rust) - Philosophy: ESBuild = simplicity, SWC = flexibility - Ecosystem: SWC is catching up fast with plugins - Use Case: ESBuild for speed and ease, SWC for scalability and customization The takeaway? If you want something that just works and is insanely fast, go with ESBuild. If you need a Babel replacement with room to grow, SWC is the better choice. Either way, both tools represent a big shift in the JavaScript ecosystem: performance is no longer optional, it's expected.