Gabriele Ferreri’s Post

I saw the viral chart claiming optional chaining adds 300ms to your interaction time. That sounded impossible, so I decided to audit the code myself. I built a benchmark replicating the exact scenario with over 6,000 runtime checks. I tested both native modern JavaScript and older transpiled versions. Here is what I found: • The Claim: 300.00ms latency. • The Reality: 0.35ms latency. The original claim was off by a factor of 850x. Modern V8 engines optimize these checks down to nanoseconds. Even when transpiled to ES5, it is just a simple lightweight check. If your application is logging 300ms delays, it is not because of syntax. It is likely due to re-rendering heavy lists or architectural bottlenecks. Write clean, safe code. Do not let performance myths scare you away from useful features.

Are you accidentally re-allocating memory on every render? 🧠 When you define a utility function inside a React component, you aren't just writing code—you're telling JavaScript to create a new function object every time that component updates. Unless you specifically need closure (accessing variables inside the component scope), move those utility's to the top of the file or a dedicated utility folder. ⛔ The Cluttered Way function AccountBalance({ amount, currencyCode }) { // Logic mixed with UI: Re-created every render const formatBalance = (val, code) => { return new Intl.NumberFormat('en-US', { style: 'currency', currency: code, }).format(val); }; return <div>{formatBalance(amount, currencyCode)}</div>; } ✅ The Scalable Way // Pure logic: Easy to test, zero re-creations function formatBalance(val, code) { return new Intl.NumberFormat('en-US', { style: 'currency', currency: code, }).format(val); } function AccountBalance({ amount, currencyCode }) { return <div>{formatBalance(amount, currencyCode)}</div>; } The Benefits: 1️⃣ Cleaner Component Body: Focus only on hooks and JSX. 2️⃣ Readability: It separates "How things look" from "How data is processed." 3️⃣ Testability: Helpers outside the component can be exported and unit-tested in isolation. How do you organize your utility functions? Do you keep them in the same file or a separate directory? #React #SoftwareEngineering #CleanArchitecture #CodeQuality #ReactJS #CleanCode #CodingTips #CodingBestPractices #itsmacr8

𝐈𝐬 𝐲𝐨𝐮𝐫 𝐮𝐬𝐞𝐄𝐟𝐟𝐞𝐜𝐭 𝐝𝐞𝐩𝐞𝐧𝐝𝐞𝐧𝐜𝐲 𝐚𝐫𝐫𝐚𝐲 𝐬𝐞𝐜𝐫𝐞𝐭𝐥𝐲 𝐜𝐚𝐮𝐬𝐢𝐧𝐠 𝐢𝐧𝐟𝐢𝐧𝐢𝐭𝐞 𝐫𝐞-𝐫𝐞𝐧𝐝𝐞𝐫𝐬? This is a common gotcha: if you're putting an object or an array directly into your useEffect dependency array, you might be triggering unnecessary re-runs on every render. Why? JavaScript's referential equality means { prop: 'value' } === { prop: 'value' } is false. A new object/array is created on every render, so useEffect sees a "change" even if the data inside is the same. The Pitfall: ```typescript function MyComponent({ data }) { // `config` is recreated on every render const config = { itemId: data.id, version: 1 }; useEffect(() => { // This effect runs on every render! // Even if data.id doesn't change. api.fetchDetails(config); }, [config]); // 🚨 Problem here! } ``` The Fix: Use useMemo for referential stability. ```typescript import React, { useEffect, useMemo } from 'react'; function MyComponent({ data }) { // `config` is now memoized and only changes when `data.id` changes const memoizedConfig = useMemo(() => ({ itemId: data.id, version: 1 }), [data.id]); // Dependencies for useMemo itself useEffect(() => { // This effect now only runs when memoizedConfig (and thus data.id) actually changes api.fetchDetails(memoizedConfig); }, [memoizedConfig]); // ✅ Correct! } ``` This simple change ensures your useEffect runs only when truly necessary, saving you from performance headaches and unexpected behavior. How do you tackle complex object or array dependencies in your React useEffect hooks? Share your go-to strategies! #ReactJS #FrontendDevelopment #JavaScript #WebDev #Performance

⚡ Stop using .filter() and .map() together. Focus on iteration efficiency. I've seen this pattern in 100+ React codebases this year: const users = data .filter(user => user.active) .map(user => <UserCard {...user} />); Looks clean. Feels right. But here's the problem? Your code loops through that array TWICE. Your browser processes it twice. That's wasted computation. ━━━━━━━━━━━━━━━━━━━━━━━━━ The Issue: ❌ Two iterations over same array ❌ Creates intermediate arrays in memory ❌ Slows down large datasets ❌ Unnecessary extra passes ━━━━━━━━━━━━━━━━━━━━━━━━━ The Better Way: ✅ Use reduce() → Single loop ✅ One pass through data ✅ Better performance on large datasets ✅ Better edge case handling ━━━━━━━━━━━━━━━━━━━━━━━━━ Why This Matters: • Performance: Only loops once • Efficiency: Processes data in single iteration • Scalability: Handles 10K+ items smoothly • Optimization: No wasted computation Master the basics before reaching for optimization libraries. ━━━━━━━━━━━━━━━━━━━━━━━━━ 💬 Question for you: Do you prefer readability (.filter().map()) or performance (reduce())? Is there a middle ground I'm missing? Let's debate in the comments. 👇 #JavaScript #ReactJS #WebDevelopment #CodingTips #Performance #FrontendDevelopment #BestPractices #Coding #TechTips #DeveloperCommunity

The `this` keyword in JavaScript has confused developers for years. Arrow functions were supposed to simplify things, but they actually introduce a completely different behaviour that catches many off guard. Here's what I wish someone had told me earlier: **Regular functions are dynamic.** The value of `this` depends entirely on how you call them. Call `person.greet()` and `this` is the person object. Assign that same method to a variable and call it? Now `this` is undefined (or the global object). **Arrow functions are lexical.** They don't have their own `this` at all. They inherit it from wherever they were defined. This makes them perfect for callbacks and event handlers where you want to preserve context, but terrible for object methods. The classic gotcha: ```javaScript const person = {  name: "Alice",  greet: () => {   console.log(`Hello, ${this.name}!`);  } }; person.greet(); // "Hello, undefined!" ``` That arrow function doesn't see the person object as `this`. It sees whatever `this` was in the surrounding scope when it was created. But in a class with callbacks? Arrow functions shine: ```javaScript class Button {  handleClick = () => {   console.log(this.label); // 'this' always works  } } ``` **My rule of thumb:** Use arrow functions for callbacks, event handlers, and anywhere you need to preserve the outer context. Use regular functions for object methods and constructors where you want dynamic binding. Understanding this distinction has saved me countless debugging hours. What about you? Have you been bitten by unexpected `this` behaviour? Full breakdown with examples: https://lnkd.in/gdcyTibZ

Finally ready to share one of my best crafts 🚀 @mateosuarezdev/query – a query library I've been using internally, now released. The problem that drove me: I needed a query library with great DX, but every option had gaps. No built-in persistence. Manual offline-first setup. Type inference could be better. And forget about incremental sync – that was always a painful custom implementation. And as you know, I love to craft tech. So here we go. What you'd expect (all built-in): ✅ Smart caching & invalidation ✅ Automatic retries with exponential backoff ✅ Pattern-based query invalidation ✅ Network-aware behavior ✅ Full TypeScript inference ✅ Optimistic updates What sets it apart: 📦 Built-in Persistence • IndexedDB for web (React Native & others coming soon) • Debounced writes for optimal performance • True offline-first, no plugins needed 🔄 Built-in Incremental Sync • Fetch only what changed since last sync • Zero boilerplate with defaultMergeArray helper • Fully type-safe deltas Real-world impact: • Chat with 1000 messages? Sync only the 3 new ones • Feed with 500 posts? Update just the 5 that changed • 90% bandwidth savings 🎯 Observable-based (Legend State) • Fine-grained reactivity, fewer re-renders • Direct mutations for instant updates 🔒 Memory-safe by design • Event-driven architecture prevents leaks Built for: ✅ Real-time & collaborative apps ✅ Offline-first mobile experiences ✅ Large datasets that update frequently ✅ Teams using Legend State Getting Started: https://lnkd.in/dDpbcSCc The docs have examples, patterns, and migration guides. Free to use library. Feedback and issues are much welcome! #React #TypeScript #WebDevelopment #JavaScript #LegendState #Observables #Reactivity #Cache

𝗪𝗲𝗮𝗸𝗠𝗮𝗽 & 𝗪𝗲𝗮𝗸𝗦𝗲𝘁: 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁'𝘀 𝗛𝗶𝗱𝗱𝗲𝗻 𝗠𝗲𝗺𝗼𝗿𝘆 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗚𝗲𝗺𝘀 Ever wondered why your JavaScript app slowly eats up memory? Let me introduce you to two often-overlooked tools (𝘢𝘯𝘥 𝘰𝘧𝘵𝘦𝘯-𝘢𝘴𝘬𝘦𝘥 𝘪𝘯𝘵𝘦𝘳𝘷𝘪𝘦𝘸 𝘲𝘶𝘦𝘴𝘵𝘪𝘰𝘯!): WeakMap and WeakSet. 𝗪𝗵𝗮𝘁 𝗔𝗿𝗲 𝗧𝗵𝗲𝘆? Think of 𝘞𝘦𝘢𝘬𝘔𝘢𝘱 and 𝘞𝘦𝘢𝘬𝘚𝘦𝘵 as special collections that hold "weak" references to objects. Unlike their regular counterparts, they don't prevent objects from being garbage collected. When an object has no other references, it simply vanishes from these collections automatically. 𝗞𝗲𝘆 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀 𝗳𝗿𝗼𝗺 𝗠𝗮𝗽/𝗦𝗲𝘁  • Keys must be objects (no primitives!!!)  • Not iterable - you can't loop through entries or check their size  • Automatic cleanup - when objects are no longer referenced elsewhere, they're removed  • No memory leaks - perfect for scenarios where you don't control object lifecycles    𝗪𝗵𝗲𝗻 𝗦𝗵𝗼𝘂𝗹𝗱 𝗬𝗼𝘂 𝗨𝘀𝗲 𝗧𝗵𝗲𝗺? 𝗪𝗲𝗮𝗸𝗠𝗮𝗽 𝗶𝘀 𝗶𝗱𝗲𝗮𝗹 𝗳𝗼𝗿:  1. Storing private data associated with DOM elements  2. Caching computed values without preventing garbage collection  3. Creating metadata stores that shouldn't affect object lifetime 𝗪𝗲𝗮𝗸𝗦𝗲𝘁 𝘄𝗼𝗿𝗸𝘀 𝗴𝗿𝗲𝗮𝘁 𝗳𝗼𝗿:  1. Tracking objects without preventing cleanup  2. Marking objects as "processed" temporarily  3. Implementing object-based flags

🔁 JavaScript – Loops & Iterations Repeating Tasks Efficiently In real applications, we often need to perform the same task multiple times. Instead of writing the same code again and again, JavaScript gives us loops. Loops help write clean, efficient, and scalable code. 🔹 Why Loops Are Important Display lists of data Process user inputs Handle repetitive logic Improve performance and readability 🔹 for Loop Best when you know how many times to repeat. for (let i = 1; i <= 5; i++) { console.log(i); } Used for: Counters Fixed-length data UI rendering 🔹 while Loop Runs as long as a condition is true. let i = 1; while (i <= 3) { console.log(i); i++; } Used when: Number of iterations is unknown Condition controls execution 🔹 do…while Loop Runs at least once, even if the condition is false. let i = 5; do { console.log(i); i++; } while (i < 3); 👉 Useful when the task must execute once before checking the condition. 🔹 Looping Through Arrays Arrays often contain multiple values that need processing. let fruits = ["Apple", "Banana", "Mango"]; for (let i = 0; i < fruits.length; i++) { console.log(fruits[i]); } Used for: Displaying lists Processing data Applying logic to each item 🔹 break Statement Stops the loop immediately. for (let i = 1; i <= 5; i++) { if (i === 3) break; console.log(i); } 🔹 continue Statement Skips the current iteration and moves to the next one. for (let i = 1; i <= 5; i++) { if (i === 3) continue; console.log(i); } 🧠 Simple Way to Remember Loops → repeat work break → stop loop continue → skip one step Arrays + loops → real-world logic ✅ Key Takeaway If you understand loops well, you can: ✔ Handle data efficiently ✔ Write cleaner code ✔ Build real applications confidently Loops are a core skill every JavaScript developer must master. . . #JavaScript #WebDevelopment #ProgrammingBasics #LearningInPublic #FrontendDevelopment #FullStackJourney

💡 Immutable Data Structures in JavaScript I’ve been exploring ways to make objects persistent and safe to work with, where updates don’t mutate the original value. One approach is creating a persistent group: - A shared empty instance as a starting point - Methods like add and delete return new instances, leaving the original unchanged - Fully iterable for easy use with for…of loops This pattern allows you to write predictable, bug-resistant code, especially when working with collections that shouldn’t be mutated directly. It’s a small concept, but it can make a big difference in maintaining clean, maintainable code. #JavaScript #WebDevelopment #TechInsights #DeveloperLife #TechCommunity

🚀 JavaScript Objects & Destructuring — Cleaner Access, Cleaner Code Objects store structured data. Destructuring lets you extract values easily without repetitive dot notation. Less code. More clarity. 🧠 Why This Matters ✔️ Improves readability ✔️ Avoids repetitive object access ✔️ Common in API responses & React props ✔️ Makes code expressive and clean 📌 What’s Happening Here? ✔️ Objects group related data ✔️ Destructuring pulls values in one line ✔️ Nested data handled cleanly ✔️ Function parameters become readable 💡 Golden Rule: “Destructure what you need — not the whole object.” #JavaScript #Objects #Destructuring #Frontend #WebDevelopment #JSConcepts #InterviewPrep #ReactJS