Gabriele Ferreri’s Post

𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝘁 𝗲𝘃𝗼𝗹𝘃𝗲𝗱 𝗾𝘂𝗶𝗲𝘁𝗹𝘆. 𝗧𝗵𝗲𝗻 𝗲𝘅𝗽𝗹𝗼𝗱𝗲𝗱. 💥 Three releases. One rewrite. A new era. Here's what happened in TypeScript 5.6 → 5.8+ ━━━━━━━━━━ 𝗧𝗵𝗲 𝗚𝗼 𝗥𝗲𝘄𝗿𝗶𝘁𝗲 — 𝟭𝟬𝘅 𝗙𝗮𝘀𝘁𝗲𝗿 𝗖𝗼𝗺𝗽𝗶𝗹𝗲𝗿 🚀 Microsoft is rewriting TypeScript in Go. Not a typo. Go, not Rust. → tsc and tsserver ported to native code → Shared-memory multi-threading → 10x faster builds in early tests → TypeScript 7.0 = Go-based compiler TS 6.0 will be the last JS-based version. Your builds are about to get very fast. ━━━━━━━━━━ 𝗡𝗼𝗱𝗲 𝗡𝗮𝘁𝗶𝘃𝗲𝗹𝘆 𝗥𝘂𝗻𝘀 𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝘁 🟢 Node.js 22+ runs .ts files directly. No build step. No ts-node. ```bash node --experimental-strip-types app.ts ``` TypeScript syntax gets stripped at runtime. Result: valid JavaScript. Zero transpilation. ━━━━━━━━━━ 𝟱.𝟲 — 𝗧𝗿𝘂𝘁𝗵𝘆 𝗖𝗵𝗲𝗰𝗸𝘀 🔍 TypeScript now catches always-truthy conditions. ```ts // TS 5.6 catches this: function process(value: string[]) { if (value) { // ❌ Error! // Arrays are always truthy, // even when empty } if (value.length) { // ✅ Correct // Check the actual condition } } ``` Dead code detection. Logic bug prevention. Catches mistakes at compile time. ━━━━━━━━━━ 𝟱.𝟳 — 𝗘𝗦𝟮𝟬𝟮𝟰 𝗧𝗮𝗿𝗴𝗲𝘁 🎯 New compile target: --target es2024 New APIs available: ```ts const inventory = [ { name: "apples", type: "fruit", qty: 50 }, { name: "fish", type: "meat", qty: 2 }, { name: "bananas", type: "fruit", qty: 30 }, ]; // Object.groupBy — native! const grouped = Object.groupBy( inventory, (item) => item.qty > 5 ? "enough" : "restock" ); // { enough: [...], restock: [...] } ``` Plus: better uninitialized variable detection. ━━━━━━━━━━ 𝟱.𝟴 — 𝗘𝗿𝗮𝘀𝗮𝗯𝗹𝗲 𝗦𝘆𝗻𝘁𝗮𝘅 & 𝗦𝗺𝗮𝗿𝘁𝗲𝗿 𝗥𝗲𝘁𝘂𝗿𝗻𝘀 🧹 ```ts // --erasableSyntaxOnly flag // Ensures TS syntax can be stripped cleanly. // Required for Node.js native execution. // ❌ Not erasable: enum Direction { Up, Down } namespace Foo { export const x = 1; } // ✅ Erasable: type Direction = "up" | "down"; const Foo = { x: 1 } as const; ``` Plus: smarter return type checking. Each conditional branch validated separately. ━━━━━━━━━━ 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 ⚡ → Path normalization: zero array allocations → Watch mode: skip unchanged file re-checks → Project validation: skip when structure unchanged Faster builds. Faster editor experience. Every version incrementally quicker. ━━━━━━━━━━ 𝗪𝗵𝗮𝘁 𝘁𝗵𝗶𝘀 𝗺𝗲𝗮𝗻𝘀 💡 TypeScript is splitting in two. The language stays the same. The compiler goes native. Today: stricter, smarter, faster. Tomorrow: 10x faster everything. ━━━━━━━━━━ 📌 This is post [3/6] in my Frontend 2026 series. Next: CSS 2026 — the features you missed. What excites you most — Go rewrite or native Node.js support? 👇 #typescript #javascript #webdev #frontend #programming #nodejs #webdevelopment #coding #react #developer

Aaj thoda Node.js internals me deep dive kar raha tha… aur honestly mujhe pehle lagta tha Node.js matlab bas JavaScript run ho rahi hai. Lekin actually story thodi different hai. Node.js basically V8 engine + libuv + thoda C++ magic hota hai. Matlab jo JavaScript hum likhte hain na… wo sirf upar ka layer hai. Andar ka system kaafi powerful chal raha hota hai. Sabse pehle V8 engine. Ye Google ka engine hai jo JavaScript ko machine code me convert karta hai. Simple sa example lo. Agar hum likhte hain: console.log("Hello") toh V8 usko machine language me convert karta hai aur run kar deta hai. Yaha tak sab simple lagta hai. Lekin problem yaha aati hai… JavaScript single threaded hoti hai. Matlab ek time pe ek hi kaam. Toh theoretically agar ek heavy kaam aa gaya — jaise file read karna ya network request… toh program ruk jana chahiye. But Node.js rukta nahi. Yaha entry hoti hai libuv ki. libuv ek library hai jo Node.js ke andar hoti hai. Aur ye handle karti hai: event loop thread pool async operations Matlab agar koi heavy kaam aa gaya… file read, encryption, network request… Node.js usko background me bhej deta hai. JavaScript free ho jati hai next kaam karne ke liye. Aur yahi reason hai ki Node.js servers me itna fast hota hai. Kyuki JS bolti hai: “ye async kaam hai bhai” aur libuv bolta hai: “tum tension mat lo, background me ho jayega.” 😄 Ab sabse important part aata hai… Event Loop. Event loop basically ek loop hai jo continuously check karta rehta hai: koi timer ready hai? koi IO complete hua? koi callback run karna hai? Agar kuch ready hota hai toh event loop us callback ko execute kar deta hai. Aur ye process chalta rehta hai. Ek small example dekh lo. console.log("Top Level") setTimeout(() => { console.log("Timer") },0) setImmediate(() => { console.log("Immediate") }) Yaha interesting cheez ye hai ki event loop decide karega kaun pehle run hoga. Aur ye depend karta hai event loop phases par. Aur ek aur difference hota hai. Browser me async kaam handle karte hain: DOM APIs fetch timers Node.js me DOM hota hi nahi. Yaha libuv + event loop async kaam handle karte hain. Toh jab tum run karte ho: node filename.js tab actually ye ho raha hota hai: Top level code run hota hai async tasks background me jate hain event loop callbacks execute karta hai aur jab kuch pending nahi hota… Node.js process exit kar deta hai. Honestly… Aaj mujhe samajh aaya ki Node.js sirf JavaScript nahi hai. Ye actually V8 + libuv + event loop ka combo hai. Aur agar event loop samajh aa gaya… toh Node.js ka half game clear. Baaki half… debugging sikha degi. 😅 Chai Aur Code Hitesh Choudhary Piyush Garg Akash Kadlag

Solving the Maze Problem using Recursion in JavaScript While practicing Data Structures & Algorithms, I implemented a simple yet powerful problem — finding all possible paths in a maze using recursion. Imagine a grid where you can only move: Down (D) ⬇️ Right (R) ➡️ The goal is to print all possible paths from the top-left corner to the bottom-right corner while we can move only in right or down direction. Here’s the JavaScript implementation: const mazeProblem = (path, down, right) => { if (down === 0 && right === 0) { console.log(path); return; } if (down > 0) { mazeProblem(path + "D", down - 1, right); } if (right > 0) { mazeProblem(path + "R", down, right - 1); } } 💡 How it works: 1️⃣ The function keeps track of the current path string (path). 2️⃣ If both down and right become 0, we reached the destination — so we print the path. 3️⃣ If we can move down, we recursively call the function adding "D" to the path. 4️⃣ If we can move right, we recursively call the function adding "R" to the path. 📌 Example: mazeProblem("", 2, 2); Output paths could be: DDRR DRDR DRRD RDDR RDRD RRDD Each string represents a unique path to reach the destination. This problem is a great way to understand: Recursion Path generation problems in grids I’m currently practicing DSA alongside my work as a React / Next.js developer to strengthen my problem-solving skills. Would love to hear how others approach similar problems! 💬 #JavaScript #DSA #Recursion #ProblemSolving #Coding #WebDevelopment

Anthropic leaked *some* source code via a Javascript source map in their npm repository. 513,000 lines of unobfuscated TypeScript across 1,906 files, revealing the complete client-side agent harness. Downloaded from various places thousands of times. The code reveals some new features, and potential names and versions for new models, but it's not the keys to the kingdom. Here's a quick summary from reddit discussions: Okay, let's break down this whole "leak" situation. The consensus is that while this is a pretty embarrassing slip-up for Anthropic, it's not the keys to the kingdom. The main takeaway is that this is the client-side code for the Claude Code CLI, not the actual model weights or backend secret sauce. So no, you can't run your own private Opus 4.5 just yet. The community is mostly having a laugh at Anthropic's expense ("forgot to add 'make no mistakes'") and getting excited about forking the code. However, digging through the leaked TypeScript files has revealed some absolute gold about what's going on behind the curtain: Roadmap Spoilers: We've got codenames! "Capybara" is a new model (possibly Mythos), and the code references internal versions like Opus 4.7 and Sonnet 4.8, confirming they're in development. Hidden Features Galore: Anthropic is sitting on a pile of unreleased features, including Agent Teams, a planning system called ULTRAPLAN, and even a Tamagotchi-like "/buddy" mode. They're Watching (Your Frustration): The code includes telemetry to track when users swear at Claude to measure frustration, and also tracks how often you type "continue" to see when the model is cutting off. Ghost in the Machine: Anthropic is systematically "ghost-contributing" AI-written code to open-source projects without attribution via an "Undercover Mode." Security Paranoia: The code shows they're actively trying to prevent token theft from your local machine and are using a DRM-like system to verify requests are coming from legit clients. Basically, someone left the blueprints for the car on the passenger seat, not the keys to the engine. It's a fascinating look into Anthropic's internal workings, future plans, and engineering priorities. The code is already forked all over GitHub, with people trying to build more efficient versions.

🚀 JavaScript Promises: Your Code's Reliable Sidekick Ever felt like async code in JS is a waiting game? Enter Promises – the elegant way to handle asynchronous operations without callback hell! --- 🤔 What's a Promise? A Promise is an object representing the eventual completion (or failure) of an async operation and its value. It has 3 states: State Description ⏳ Pending Initial state, neither fulfilled nor rejected ✅ Fulfilled Operation succeeded with a value ❌ Rejected Operation failed with a reason --- 🍛 Think of it like ordering food delivery: · Pending: Waiting for your biryani 🍛 · Fulfilled: Food arrives hot & fresh! ✅ · Rejected: Restaurant closed – get error msg. ❌ --- 💻 Real-World Example: Fetching User Data With Promises: ```javascript fetchUserData() .then(user => { console.log(`Welcome, ${user.name}!`); // Fulfilled 🎉 }) .catch(error => { console.error('Oops, login failed:', error); // Rejected 😞 }); ``` Or modern async/await: ```javascript try { const user = await fetchUserData(); console.log(`Welcome, ${user.name}!`); } catch (error) { console.error('Login failed:', error); } ``` --- 📚 Types of Promises 1. Promise.all(): Fulfills when all of the promises fulfill; reject when any of the promises rejects. 2. Promise.race(): Fulfills when any of the promises fulfills; rejects when any of the promises rejects. 3. Promise.any(): Fulfills when any of the promises fulfills; rejects when all of the promises reject. 4. Promise.allSettled(): Fulfills when all promises settle. Quick Example: ```javascript // Promise.all() - All must succeed const [user, posts] = await Promise.all([ fetchUser(), fetchPosts() ]); // Promise.race() - First to finish const result = await Promise.race([ fetchData(), timeout(5000) ]); // Promise.any() - First successful const data = await Promise.any([ fetchFromAPI1(), fetchFromAPI2(), fetchFromAPI3() ]); // Promise.allSettled() - Get all results regardless const results = await Promise.allSettled([ fetchUser(), fetchPosts(), fetchComments() ]); ``` --- ✨ Why Promises? · 🔗 Chain beautifully with .then() · 🛡️ Handle errors gracefully with .catch() · 📖 Make your code readable and maintainable · ⚡ Multiple methods for different use cases (all, race, any, allSettled) --- 🔥 Pro Tip Always add .catch() to avoid silent failures! --- 💬 Let's Discuss! What's your go-to async pattern – Promises, async/await, or something else? Which Promise method do you use most? Drop your thoughts below! 👇 --- #JavaScript #Promises #WebDevelopment #Frontend #CodingTips #ReactJS #AsyncProgramming

🚀 JavaScript Simplified Series — Day 3 Programming me kabhi kabhi aisa hota hai ki **data ka type change karna padta hai.** Example: User form me age likhta hai → "25" Lekin JavaScript ise **string** samajhta hai. Agar hume calculation karni ho to? Tab hume string ko **number me convert** karna padega. Isi concept ko kehte hain: **Type Conversion** Example: ```javascript let age = "25" let convertedAge = Number(age) console.log(convertedAge + 5) ``` Output 30 Yaha kya hua? "25" (string) → 25 (number) JavaScript me type conversion do tarah se hota hai: 1️⃣ **Implicit Conversion** JavaScript automatically type change kar deta hai. Example: ```javascript "5" + 2 // "52" ``` 2️⃣ **Explicit Conversion** Hum khud manually convert karte hain. Example: ```javascript Number("10") String(20) Boolean(1) ``` Ab aata hai next important concept. **Operators** Operators wo symbols hote hain jo values par operations perform karte hain. Example: ```javascript let a = 10 let b = 5 console.log(a + b) // Addition console.log(a - b) // Subtraction console.log(a * b) // Multiplication console.log(a / b) // Division ``` JavaScript me mainly operators hote hain: ➤ Arithmetic Operators (+ - * / %) ➤ Comparison Operators (== === > <) ➤ Logical Operators (&& || !) Simple words me: Type Conversion → Data type change karta hai Operators → Data par operations perform karte hain Agar aap JavaScript ko **Hindi me deeply samajhna chahte ho**, to YouTube par in channels ko follow kar sakte ho: • ** Rohit Negi ** • ** Hitesh Choudhary (Chai aur Code)** Waha concepts **simple aur practical way** me explain kiye gaye hain. 📌 Series Progress Day 1 → What is JavaScript Day 2 → Variables & Data Types Day 3 → Type Conversion & Operators Day 4 → Truthy vs Falsy Values Follow karo agar tum **JavaScript ko scratch se master karna chahte ho.** #JavaScriptSimplified #javascript #webdevelopment #coding #programming #learninpublic #100DaysOfCode #frontenddevelopment #devcommunity #codingjourney

THIS! 💯 I’ve been sounding the alarm on this architectural trend for over half a decade, but it seems like a lot of newer developers have just accepted it as the gold standard because they simply haven't experienced anything else. Look, I understand the primary selling point. The “no context switching” argument is entirely valid. Jumping between a robust, dedicated backend language and frontend JavaScript can be mental whiplash, and the dream of a unified, single-language stack is appealing. I've been there and felt that pain. But that convenience comes at an incredibly high cost. We've force-fed a language into an environment it was never built to operate in. Here is the reality of the Node.js ecosystem: • It’s fundamentally the wrong tool for the job: Let's not forget history. JavaScript was designed in a matter of days as a lightweight scripting language to manipulate the DOM and make browsers interactive. It was never architected for heavy-lifting, concurrent server-side processing, or enterprise-grade backend stability. We are pounding a square peg into a round hole and calling it "modern." • A Fractured Ecosystem & Dependency Hell: The Node environment is famously disjointed. Instead of robust standard libraries, you are forced to rely on a gazillion third-party dependencies, which themselves rely on a gazillion sub-dependencies. It's a fragile house of cards where executing a simple task requires downloading half the internet into a bloated `node_modules` black hole. • An Ongoing Security Nightmare: Because of this sprawling, infinitely nested dependency tree, NPM has become a playground for bad actors. It feels like the registry is compromised, or a popular package falls victim to a supply-chain attack, every other day. You aren't just deploying your code; you are blindly trusting thousands of unknown, unvetted third-party authors with your server's security. Backend architecture used to be about robust, battle-tested stability. Now, it's about hoping your latest `npm install` doesn't secretly pull in a crypto-miner or break your entire build. We traded solid engineering for the convenience of not having to learn a second syntax.

I once spent a lot of energy trying to fix a Node.js + Express backend, after not being able to convince the customer to move elsewhere, at least for some core services. The customer knew nothing about software development and they previously hired an infrastructure engineer with no solid development experience who convinced them that JavaScript on the server was a good idea.  😭 The codebase was a mixture of badly written, untyped JavaScript and some decent TypeScript, signal that the previous development team had no coordination: every developer was randomly putting his/her personal style into the code. Not to mention, the backend was impossible to debug because it did not contain a single log statement "because logging consumes resources" 🤦♂️ Some part of the code was meant to perform massive monetary calculations with very high precision and they were using plain floating point. Using floating-point numbers for money is dangerous, requires specialized libraries for that. Even if you fix precision, Node may still struggle with extreme throughput + heavy CPU math. But nobody of them was aware of the issue and they wondered why numbers in the general ledger did not add up. Of course, they where accumulating massive rounding errors. Needless to say, the system was very slow under concurrent load. Below a quite comprehensive list of reasons why JavaScript on the backend is a popular but often wrong idea.