"any" isn't a type. It's you giving up. You write any and TypeScript stops helping you. Completely. It won't catch typos. It won't catch wrong methods. It won't catch anything. You basically paid the TypeScript tax (extra syntax, build step, config files) and got nothing back. With any: call any method, access any property, TypeScript says nothing. Code explodes at runtime. With unknown: TypeScript blocks you until you prove what it is. ts const data = parseJSON(str) // unknown 👏 if (typeof data === 'object' && data && 'name' in data) { console.log(data.name) // now it's safe } "But that's more code" Yes. That's the point. That code is the check you should have written anyway. TypeScript just forced you to not forget it. When to use unknown: → API responses → JSON parsing → User input → Any external data you don't control When to use any: → Never → Ok maybe when migrating JS to TS → But then fix it immediately Every any in your codebase is a bug waiting to happen. You just haven't found it yet. #typescript #javascript #frontend #webdev #programming #webdevelopment #react #cleancode #devtips #softwaredevelopment
Albert Em’s Post
More Relevant Posts
-
Why TypeScript is non-negotiable for Scalable APIs. The "510" error is why I stopped writing pure JavaScript for production. We’ve all seen it. You expect a sum of 5 + 10 = 15, but instead, you get "510" because JavaScript decided to concatenate a string instead of adding numbers. In a small script, that’s a "funny" bug. In a mission-critical backend service, that’s a production incident. This is why TypeScript is not "nice to have" in the NestJS ecosystem but it’s an essential requirement. When you use TypeScript, you’re not just adding types; you’re building a contract for your data. Why it matters for your team: - Compile-time safety: Catch the "510" error at 2:00 PM on your machine, not at 2:00 AM in your logs. - Self-Documenting Code: When you hover over a function, you know exactly what it needs and what it returns. No more guessing what data contains. IDE Superpowers: IntelliSense, safe refactoring, and auto-completion make your team 2x faster. - TypeScript moves your debugging to the earliest possible stage. As a Senior Engineer, my job isn't to write code faster; it's to write code that stays broken for the least amount of time. Do you still feel the "pain" of debugging runtime type errors in your current stack? Let's talk about how to solve it. #TypeScript #JavaScript #NestJS #SoftwareEngineering #CodeQuality #DeveloperExperience
To view or add a comment, sign in
-
-
Stop compiling TypeScript. I removed `tsc` from my dev workflow last month. Not as an experiment. Permanently. Here’s what changed: Node.js 22.18+ runs `.ts` files natively now. No `tsc`. No `ts-node`. No build step. You write this: node index.ts And it just works. Types get stripped at runtime. Line numbers stay accurate. No source maps needed. The trick? Node uses SWC under the hood to erase type annotations — it treats them as whitespace. Your code runs exactly as you wrote it. Minus the types. Startup went from ~120ms with ts-node to ~45ms. On a project with 200+ files, that adds up fast. But here’s what most people miss: This only works with “erasable” syntax. Enums, namespaces, parameter properties — won’t work. You need `--experimental-transform-types` for those. My `tsconfig.json` is now 6 lines: target: "esnext" module: "nodenext" erasableSyntaxOnly: true verbatimModuleSyntax: true rewriteRelativeImportExtensions: true noEmit: true And with TypeScript 6.0 Beta dropping 2 weeks ago (final release March 17), this is the last JS-based version. TypeScript 7.0 is being rewritten in Go. 10× faster builds. Strict by default. ES5 dropped. The TypeScript you know is about to change fundamentally. If you haven’t tried running: node index.ts yet, now is the time. The build step era is ending. What’s your current TS setup — still compiling or running native? #TypeScript #NodeJS #WebDevelopment
To view or add a comment, sign in
-
-
I built a full-stack framework. Here's why. Every time I started a new Go + React project, I'd spend days on the same boilerplate: → Setting up auth → Wiring API routes → Creating admin panels → Writing the same CRUD handlers → Syncing types between Go and TypeScript So I built Grit. Grit is a batteries-included framework that fuses Go (Gin + GORM) with Next.js in a monorepo. One command scaffolds everything — API, frontend, admin panel, auth, Docker, database browser. But the magic is in code generation: $ grit generate resource Product --fields "name:string,price:float,published:bool" That single command creates: ✅ Go model with GORM tags ✅ CRUD handler with pagination, search, sorting ✅ React Query hooks ✅ Zod validation schemas ✅ TypeScript types ✅ Admin panel page with data table + form ✅ All wired together automatically Change a Go struct → TypeScript types and Zod schemas stay in sync. Automatically. It ships with auth, file storage (S3/MinIO), email, background jobs, cron, Redis caching, AI integration, and a visual database browser. The whole stack: Go + Gin + GORM → Next.js 16 → Tailwind + shadcn/ui → PostgreSQL → Redis → Docker It's open source. 📖 Docs: https://lnkd.in/e9gme798 💻 GitHub: https://lnkd.in/eQBgh6_W 📖 Cheatsheet: https://lnkd.in/dfKA6R5P 🎬 Demo Video: https://lnkd.in/d5QCbMZd If you're tired of wiring the same boilerplate every project, give it a try. I'd love your feedback. #golang #react #nextjs #fullstack #webdevelopment #opensource #framework #grit #typescript #developer
To view or add a comment, sign in
-
𝗧𝗮𝗸𝗲 𝗖𝗼𝗻𝗧𝗿𝗼𝗹 𝗢𝗳 𝗬𝗼𝘂𝗿 𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝗧 You use TypeScript to make your code more robust. But do you use it to its full potential? When you migrate a JavaScript codebase to TypeScript, you may be tempted to use "any" to avoid errors. But "any" turns off TypeScript's greatest strength: type safety. Let's explore advanced type features that let you describe your data's shape and behavior with precision. You will learn about: - Union types that allow a value to be one of several types - Intersection types that combine multiple types into one - Generics that create components, functions, or interfaces that work with various types - Mapped types that create new types by iterating over existing type keys - Conditional types that introduce if-like logic at the type level These features make your code more robust, self-documenting, and maintainable. You will learn how to solve complex typing challenges without resorting to "any". Your challenge: Open your current TypeScript project, find an instance of "any", and try to define an interface, union type, or generic to describe the data. Replace theany and make your codebase more reliable. What's the most interesting type challenge you've solved recently? Share your solution in the comments below! Source: https://lnkd.in/g9tyXm-E
To view or add a comment, sign in
-
Day 47 of my #100DaysOfCodeChallenge (Delayed by power outage — but consistency continues.) Today I went deeper into the core architecture of Node.js, and things are starting to connect at a much deeper level. Here’s what I focused on: 🔹 REPL (Read–Eval–Print Loop) Understanding how Node executes JavaScript interactively from the terminal and how execution flows internally. 🔹 Working with Standard Input & Output Using the readline module to capture user input from the terminal. This helped me understand how CLI tools are built and how Node interacts directly with the system environment. 🔹 File System Module (fs) Explored reading and writing files both: Synchronously (blocking) Asynchronously (non-blocking) This was the major learning point. Key Concept Reinforced Today JavaScript is single-threaded Node.js uses a non-blocking, event-driven architecture Synchronous operations block the execution thread Asynchronous operations delegate tasks and continue executing the next line of code Callbacks control execution order in async operations Seeing "Reading File....." log before file data was returned made the event loop behavior much clearer to me. Understanding this execution model makes it obvious why mastering Node fundamentals is critical before going deeper into frameworks like Express. The goal isn’t just to write backend code — It’s to understand how the runtime actually works. On to Day 48. #NodeJS #BackendDevelopment #JavaScript #SoftwareEngineering #BuildInPublic #100DaysOfCode
To view or add a comment, sign in
-
-
dotenv-gad: type-safe, validated environment variables with zero runtime surprises. Define schemas once: TypeScript Get full IntelliSense, automatic .env.example generation, schema composition, sensitive value redaction, and a CLI that checks/fixes/types everything. Plus a Vite plugin that safely exposes only client variables without leaking secrets. It’s lightweight, works with Vercel/Railway/Docker/CI, and plays perfectly with TypeScript + modern stacks. If you’re done debugging env typos in production, give it a try: → https://lnkd.in/diZSQ7fG Feedback welcome especially if you’re using it in Next.js / Express / Nest / whatever! #TypeScript #NodeJS #DeveloperTools #EnvironmentVariables #OpenSource
To view or add a comment, sign in
-
𝗧𝗮𝗸𝗲 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 𝗼𝗳 𝗬𝗼𝘂𝗿 𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝘁 𝗖𝗼𝗱𝗲 You use TypeScript to add types to your JavaScript code. But do you use it to its full potential? When you integrate third-party APIs or parse dynamic JSON, you might use the "any" type. This can lead to bugs and maintenance issues. Instead, use the "unknown" type. It's safer and forces you to narrow down the type. Here are some tips to improve your TypeScript code: - Use discriminated unions to model finite states - Use template literal types for type-safe APIs and routing systems - Use conditional types to extract and manipulate type information - Ban "any" in your new code and use "unknown" for data entering your system You can start by refactoring one part of your codebase that uses "any" or nullable flags. Share your findings in the comments. Source: https://lnkd.in/gabup868
To view or add a comment, sign in
-
🚀 TypeScript is about to get 10x faster — and the last JS-based version just dropped its RC Big news this week for every TypeScript developer. 👀 TypeScript 6.0 RC landed on March 6. GA drops on March 17. But here's the real story - this is the last TypeScript version written in TypeScript. After 6.0, everything changes. 🔥 What's happening? Microsoft is rewriting the entire TypeScript compiler in Go (yes, Go 🐹) with promises: ~10x faster builds Near-instant incremental compilation ~50% memory reduction Much faster editor startup What's new in 6.0 itself? RegExp.escape - finally, safe regex escaping built-in New Temporal API types (ES2026 is coming 🎉) getOrInsert / getOrInsertComputed for Map & WeakMap Subpath imports starting with #/ asserts keyword deprecated → use with instead Better type inference for generic function expressions What should you do now? Install the RC → npm install -D typescript@rc Run with --deprecation flag to catch anything that'll break in 7.0 Start thinking about your build pipeline - things will change 6.0 is the bridge. 7.0 is the destination. The TypeScript team has been quietly heads-down on this rewrite for over a year. The speed gains are real - already tested on large codebases. Are you excited about the Go-powered future of TypeScript, or does rewriting a compiler in a different language make you nervous? 👇 #TypeScript #JavaScript #WebDevelopment #Frontend #SoftwareEngineering #DeveloperTools #NodeJS #Programming #TechNews #OpenSource
To view or add a comment, sign in
-
-
𝗧𝗮𝗸𝗲 𝗬𝗼𝘂𝗿 𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝘁 𝗧𝗼 𝗧𝗵𝗲 𝗡𝗲𝗫𝘁 𝗟𝗲𝘃𝗲𝗹 You know the basics of TypeScript. But are you using its type system to its full potential? Many developers use TypeScript as "JavaScript with types" without realizing they're missing out on its most powerful feature. Let's explore advanced TypeScript types that can transform how you structure and reason about your code. These include: - Discriminated unions to prevent entire categories of bugs - Template literal types for type-safe string manipulation - Conditional types to create types that depend on other types - Mapped types to transform existing types For example, consider a typical API response. You can use discriminated unions to make impossible states impossible to represent: ``` is not allowed, using plain text instead type ApiResponse = | { status: 'loading' } | { status: 'error'; message: string } | { status: 'success'; any }; ``` This pattern eliminates entire classes of bugs by making impossible states impossible to represent. You can also use template literal types to bring type safety to string manipulation: ``` is not allowed, using plain text instead type HttpMethod = 'GET' | 'POST' | 'PUT' | 'DELETE'; type ApiEndpoint = `/api/${string}`; ``` These are practical tools that can make your code more self-documenting and maintainable. Start incorporating these patterns gradually into your codebase. Identify opportunities to use discriminated unions, template literal types, and conditional types. Refactor existing classes to use mapped types for better type safety. Remember, TypeScript's type system is a tool for thinking, not just checking. By encoding more of your domain logic into the type system, you make your code more self-documenting and catch errors earlier. Challenge yourself this week: Take one complex function in your codebase and see if you can use advanced types to make its contracts more explicit. What's your favorite advanced TypeScript feature? Share your experiences or questions in the comments below! Source: https://lnkd.in/geS2WYag
To view or add a comment, sign in
-
Recently, I developed several tools for the TypeScript and JavaScript ecosystem, inspired by challenges I encountered as a developer. These tools may be beneficial for others, particularly those working with large codebases or migrating legacy code to newer frameworks. 1️⃣ Hardcoded Secret Scanner This tool scans your codebase for hardcoded API keys and secrets before they reach production. GitHub: https://lnkd.in/dyBqUY4w 2️⃣ Unused Code Finder It detects unused functions, variables, and exports across your project and can also clean them automatically. GitHub: https://lnkd.in/d5x33tyD 3️⃣ Dotenv Type Generator This tool reads your .env file and generates TypeScript types for process.env. GitHub: https://lnkd.in/dHquTsbT 4️⃣ TypeScript Mock Builder It creates fully typed mock objects from TypeScript interfaces to speed up testing. GitHub: https://lnkd.in/dMpXbt4N Additionally, I have included tools for complexity reports, naming checks, dependency graphs, and other project insights. Explore more here: https://lnkd.in/dW9r-UB6 If you have suggestions, ideas for improvements, or encounter any bugs, please feel free to open an issue on GitHub. #OpenSource #TypeScript #NodeJS #DeveloperTools
To view or add a comment, sign in
Explore related topics
- TypeScript for Scalable Web Projects
- Writing Clean Code for API Development
- Writing Clean, Dynamic Code in Software Development
- Coding Best Practices to Reduce Developer Mistakes
- Writing Functions That Are Easy To Read
- Clean Code Practices For Data Science Projects
- How to Add Code Cleanup to Development Workflow
- Best Practices for Writing Clean Code
- How to Write Clean, Error-Free Code
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development
That's a valid point!