How TypeScript changed my coding habits

Over the last few posts, I talked about how TypeScript infers types, how we can override them, and how we can validate them. Now it’s time to connect the dots. There are three main approaches - 1. Type Annotation 2. Type Assertion (as) 3. 'satisfies' operator 1. Type Annotation - You’re telling TypeScript what the type should be. This is something you should use when - 1. You want to define the shape of something upfront. 2. You’re working with function signatures, public APIs, data models, interfaces, etc. 3. You want clarity and explicitness. The downside here is that if you annotate something like an object literal too broadly (e.g., Record<string, ...>), you can lose type inference, especially for literal key names. 2. Type Assertion - You’re overriding TypeScript’s inference and saying - 'Trust me.' This is something you should use when - 1. TypeScript can’t figure out the type, but you know what it is. 2. You’re working with DOM elements or events. 3. You’re dealing with external data (like JSON or API responses). But remember that type assertion does not perform any runtime validation. If you’re wrong, TypeScript won’t save you. 3. 'satisfies' operator - You want to validate and preserve inference. 'satisfies' checks that a value conforms to a given type, without changing the inferred type. This means, Literal keys stay literal, values stay precise, and extra properties are caught as errors. So, we get the best of both worlds, meaning the object must match a required shape but inference stays as detailed as possible. This is a good option for things like configuration objects, constant maps, enum-like value objects etc. The bottom-line is that TypeScript gives you these tools for a reason. The real skill is in knowing which one to reach for depending on the situation. #TypeScript #Coding #JavaScript #WebDevelopment #Programming #SoftwareEngineering

🧠 Understanding the Core Type Differences in TypeScript TypeScript provides several special types that describe different states of data — and understanding them well is key to writing predictable, safe code. -(undefined): represents a variable that has been declared but not yet assigned a value. It means “missing” or “not initialized.” -(null): represents the intentional absence of a value. It means “we know there’s nothing here.” While undefined often happens naturally, null is explicitly set. -(any): disables all type checking. It’s the most flexible — and the most dangerous — type. It says “this could be anything,” which removes TypeScript’s safety guarantees. -(unknown): is the safer alternative to any. It can hold any value, but you must verify the type before using it. It enforces caution when working with dynamic data. -(void): indicates the absence of a return value, commonly used for functions that don’t return anything. It tells the developer that “this function performs an action, not a computation.” -(never): represents a state that can never occur. It’s used for functions that never return (like those that throw errors or run infinitely). It signals that a certain path in the code should be unreachable. In TypeScript’s type hierarchy, (any) and (unknown) sit at the top — they can represent any value. (never) sits at the bottom — it represents no value at all. Mastering these distinctions helps you reason more clearly about your data, enforce intent in your code, and leverage TypeScript for what it truly is: a language for clarity and correctness. #TypeScript #SoftwareEngineering #WebDevelopment #CodingBestPractices #JavaScript

Let's talk about something quite interesting in TypeScript - 'Indexed Access Types.' In TypeScript, 'Indexed Access Types' let us look up a type by indexing another type. This is similar to how we access a property on an object or an array at runtime. Let’s say we have an 'as const' object, and we want our types to stay perfectly in sync with the values inside it. That’s where 'Indexed Access Types' shine. This means if the original object changes, your derived types update automatically. You can even use 'keyof' with it to extract all possible value types or combine specific keys to build flexible unions. And yes, this is why 'as const' is so useful because it ensures those values are literal types, not widened ones like 'string.' If you try to access a key that doesn’t exist, TypeScript immediately warns you, giving you both type safety and consistency. So far, I talked about ' as const' objects in TypeScript. What if instead of an object, we have an ‘as const’ array? Using 'as const', this array becomes a 'readonly tuple,' and we can use 'Indexed Access Types' to extract types from it the same way we do with objects. We can get the type of a specific element by its index or even create a union type of all the values in the array. Here’s where it gets interesting. If we use 'number' as the index type, TypeScript interprets that as 'all numeric indices', effectively giving us a union of all the element types in the array. That means if our array changes or if elements are added or removed, the derived type automatically reflects those changes. This pattern is incredibly powerful for defining value-driven types that evolve with your code. In short, Indexed Access Types help you create types that truly evolve with your data. #TypeScript #JavaScript #Programming #Development #Coding #WebDevelopment

“Frameworks come and go, focus on fundamentals.” We’ve all heard this sentence so many times… and yes, fundamentals matter. But here’s something I’ve learned as a Software Engineer Knowing only the language is not enough. You can be great at JavaScript, understand scopes, closures, the event loop all the core stuff. But when you sit down to build a real, scalable, maintainable product, pure language knowledge won’t carry you very far. That’s because projects don’t run on syntax they run on architecture. And architecture doesn’t magically come from “just knowing code.” You need patterns, structure, conventions, and ways to organize your logic. This is where frameworks actually help you grow. 1- Nest.js teaches you modular and layered architecture. 2- Next.js teaches you routing, rendering strategies, caching. 3- Laravel teaches you service containers, middleware pipelines, repos. 4- Django teaches you MVC + ORM discipline. These frameworks aren’t “just tools.” They’re practical guides to software design. They expose you to patterns like dependency injection, singletons, repositories, adapters, modules, things you won’t naturally invent by writing plain Node.js scripts. So yes… fundamentals matter. But frameworks shape your thinking. They teach you how to write clean, maintainable, and scalable code. Anyone can write code. Not everyone can build systems. And frameworks help bridge that gap. By the way, what’s your current tech stack? #SoftwareEngineering #WebDevelopment #Programming #Frameworks #Architecture #DesignPatterns #JavaScript #DeveloperLife #TechLeadership #FullStackDev

Building a JavaScript Engine from Scratch Ever wondered how JavaScript engines actually work under the hood? I did too, so I built one from scratch to find out. What I Built A complete TypeScript-based interpreter and transpiler with all the core components: Core Architecture: Lexer/Tokenizer > Converts source code into tokens Parser > Builds Abstract Syntax Trees using recursive descent Semantic Analyzer > Type checking, scope validation, const enforcement Interpreter > Tree-walking execution engine Code Generator > Transpiles to clean JavaScript The Journey Starting from zero knowledge of compiler design, I implemented: ✅ Operator precedence climbing ✅ Short-circuit evaluation for logical operators ✅ Control flow with break/continue/return ✅ Function declarations, calls, and recursion ✅ Block scoping with environment chains ✅ 409 comprehensive tests across all components Key Learnings 1. How tokens become executable code Understanding the transformation pipeline from raw text to running code 2. The complexity behind "simple" features Variable scoping alone requires careful environment chain management 3. Why semantic analysis is crucial Catching errors before execution saves countless runtime headaches 4. How interpreters and transpilers differ at their core Different execution strategies, same parsing foundation What Surprised Me Most The sheer complexity hidden behind simple syntax. A single const x = 5 triggers: Lexical analysis Syntax parsing Semantic validation Symbol table updates Type checking Runtime execution Each layer depends on the previous one miss one detail and the entire engine breaks. GitHub: https://lnkd.in/d8r3Tdyb #CompilerDesign #Interpreters #Transpilers #AbstractSyntaxTree #AST #LexicalAnalysis #ParserDesign #CodeGeneration #JavaScript #TypeScript #NodeJS #Programming

🔥 𝐓𝐲𝐩𝐞𝐬 𝐢𝐧 𝐓𝐲𝐩𝐞𝐒𝐜𝐫𝐢𝐩𝐭: 𝐃𝐨 𝐘𝐨𝐮 𝐑𝐞𝐚𝐥𝐥𝐲 𝐊𝐧𝐨𝐰 𝐓𝐡𝐞𝐦 𝐀𝐥𝐥? TypeScript gives us superpowers, but how well do we really understand the types behind the magic? Let’s go beyond “number” and “string” and explore the real foundation of TypeScript’s type system. • Primitive types: number, string, boolean, bigint, symbol, null, undefined   • Object types: objects, arrays, functions, classes, interfaces   • Union types: combine multiple possible types into one flexible definition   • Intersection types: merge multiple types into a single, stronger contract   • Literal types: restrict values to a specific constant (like "on" or "off")   • Tuple types: define arrays with fixed positions and known element types   • Enum types: create a clear set of named constants   • Any, unknown, never: the “dark side” of typing, powerful but dangerous if misused  Here’s the key question: how do you decide which type to use when modeling real-world data?   Do you rely more on interfaces, or do you prefer type aliases?   Have you experimented with conditional or mapped types to make your code self-evolving? The beauty of TypeScript is not only in catching bugs early, but in shaping how we think about data and behavior. So next time you write a type, ask yourself:   “Am I defining this because the compiler needs it or because my future self will thank me for the clarity?” #TypeScript #JavaScript #WebDevelopment #SoftwareEngineering #Coding #DevCommunity #TypeSafety #Programming #TechLeadership #CleanCode

✨ Learning TypeScript Alias Syntax —> A Small Trick That Solves Big Problems Today I learned something simple but super powerful in TypeScript: aliasing imported names using the as keyword. Example: import { DialogConfig as DialogConfiguration } from "@/components/ui"; Earlier, I used to see this syntax and wonder why do people rename something that already has a name? But now it finally makes sense —> and it’s actually a smart practice in clean coding. 🔍 When to use alias syntax (as) in TypeScript? ✅ 1. When two modules export the same name Avoid conflicts like: import { Config } from "@/dialog"; import { Config } from "@/table"; // ❌ duplicate Fix: import { Config as DialogConfig } from "@/dialog"; import { Config as TableConfig } from "@/table"; ✅ 2. When the library’s name isn’t descriptive Sometimes imported names are too short, generic, or unclear. Aliasing makes them meaningful inside your project. ✅ 3. When your codebase follows a specific naming style If a project prefers longer, explicit names, you can alias the import to match that convention without changing the library. ✅ 4. During refactoring / migrations If the library changes its type name, aliasing helps you migrate gradually without breaking old code. 🎯 Why this matters Cleaner code Zero naming conflicts Better readability Smooth refactoring More predictable architecture 🚀 Final takeaway Sometimes the “small” syntax features are what make your code professional. Aliasing is one of those tricks that keeps your imports clean and your codebase easy to understand — especially in large TypeScript projects. Learning something new every day. 💙 #TypeScript #WebDevelopment #LearningInPublic #CleanCode #ProgrammingTips

Ever encountered a runtime error that took hours to debug? TypeScript can be a game changer in preventing those moments. TypeScript isn’t just JavaScript with types—it’s a powerful tool that introduces static typing, making your code more predictable and easier to maintain. One practical tip: start by gradually adopting TypeScript through `--allowJs` and `--checkJs` flags if you have an existing JavaScript codebase. This incremental approach helps catch errors early without a massive rewrite. For example, explicit interfaces for API responses can highlight mismatches before they reach production, saving time and frustration. Another insight: leveraging TypeScript's type inference reduces boilerplate while still providing robust type safety. This balance keeps development efficient but safe, especially when working with complex data structures. Ultimately, TypeScript encourages a mindset shift—from reactive bug fixing to proactive error prevention. For developers, this means writing clearer code that scales better and collaborates more smoothly across teams. Have you experienced the benefits of TypeScript in your projects? How has it changed your workflow? #TypeScript #JavaScript #WebDevelopment #StaticTyping #DeveloperExperience #CodeQuality

I got tired of writing backend boilerplate, so I built a tool to automate it. Here’s a 1.38Minute demo. 🚀 Ever finish a beautiful frontend and then sigh, knowing you have to manually build the entire backend to match? That's a problem I wanted to solve. I'm excited to share create-backlist, my new open-source CLI tool. It's a "polyglot" (multi-language) generator that analyzes your frontend code and auto-generates a ready-to-run backend for you in Node.js, C#, Java, or Python. Watch the video below 👇 to see how it takes a frontend project and generates a complete backend with: ✅ Matching API Routes & Controllers ✅ Full CRUD Logic ✅ JWT Authentication Boilerplate ✅ Docker Support It handles the repetitive grind, so you can focus on the features that matter. This was a deep dive into ASTs, code generation, and developer tooling, and I'm thrilled to finally share it. I would love for you to try it out and give me your feedback! Try it yourself with one command: npm create backlist@latest