Prince G.’s Post

Forced Synchronous Layout is one of those bugs that shows up as a long task in DevTools but is hard to pinpoint in the code. The pattern is deceptively simple: a class mutation followed immediately by a geometric property read (`scrollTop`, `getBoundingClientRect`…). The browser can't defer the layout — it recalculates right now, blocking the main thread. I've added a new snippet to WebPerf Snippets that detects it at runtime. Run it in DevTools, reproduce the interaction, and every FSL event gets logged with: - The property accessed and whether it was a read or write - The element descriptor (tagName + id/class) - Milliseconds since the last mutation - Full stack trace to locate the offending code One thing I had to work out while building it: MutationObserver fires asynchronously, so it can't catch mutations and geometric reads in the same synchronous block. The fix was intercepting `classList`, `setAttribute`, `setProperty`, and `cssText` directly at the prototype level, synchronously. Call `getFSLSummary()` for an aggregated report by property and element. Call `stopFSLDetector()` to restore all prototypes when you're done. https://lnkd.in/dhNciS5B #WebPerf #Performance #JavaScript #FrontEnd #WebPerfSnippets

where does that 'e' or 'event' come from?? If you have ever wondered why that object magically appears in your 'onClick' handler, the answer lies in how React coordinates the bridge between the browser and your code. It isn't just a standard browser event. It is a very specific system designed to keep your UI consistent. When you pass a function reference like 'onClick={handleClick}', React automatically injects a SyntheticEvent as the first argument. You do not have to do anything. It is just there. This is a cross-browser wrapper that ensures your event logic works the same in every environment. Under the hood, React is doing the heavy lifting of mapping native DOM events to this consistent interface. The behavior changes slightly when you use arrow functions in your JSX. If you write 'onClick={() => handleClick()}', you lose that automatic injection. In this case, you are responsible for capturing the event from the anonymous wrapper and passing it down manually, like 'onClick={(e) => handleClick(e)}'. It is a small syntactic difference, but forgetting this is a common reason why 'event.target' suddenly comes back as undefined. Understanding this flow is crucial for writing clean code. Since React 17 removed event pooling, you no longer have to worry about the event object being nullified after the handler runs. You can now use the event inside asynchronous code without calling 'e.persist()'. It is a simpler and cleaner model that allows you to focus on logic rather than browser quirks. #ReactJS #SoftwareEngineering #WebDevelopment #Javascript #CodingTips #Frontend

Your JavaScript framework is lying to you. Every senior developer knows the feeling. You land on a site, start scrolling, and you already know. No need to open DevTools. No need to check the source. You just feel it. That slight wrongness. The stack reveals itself. Every time a page hydrates, there's a moment of deception. The browser shows you something that looks ready but isn't. Buttons that don't respond. Links that do nothing. A page pretending to be alive. We called this progress and named it hydration. Morphing is different. The server speaks, the DOM listens, only what changed actually changes. No flash. No jump. The page breathes. Content shifts like light changing in a room, you couldn't say exactly when it happened, only that it did. Your coffee is still warm. You never looked up. That low-level unease you feel scrolling through certain sites, that subtle wrongness you can't name, that's your subconscious detecting the lie. Morphing never triggers it. There is nothing to detect. We are so captured by the new JavaScript world that we forgot to look at our roots. To seriously consider what hypermedia always offered. And no, I am not talking about building Excel in the browser. I am talking about normal websites. The kind that just need to show content, respond to a user, and get out of the way. Maybe the most radical thing you can do in 2026 is trust the browser. This is what Datastar does with SSE and DOM morphing. No hydration phase. No uncanny valley. No lie. #WebDevelopment #Hypermedia #Datastar #ProgressiveEnhancement #Frontend #SSE #JavaScript

The JavaScript module pattern — properly explained. Not just "use export and import." But: → Why global scope is a battlefield → How closures create privacy → What the browser does before running a single line of your module → Why modules never block your page → And where even ES Modules fall short Deep-dive guide is live. Link below. #JavaScript #WebDevelopment #Frontend

 Why Your Preloaded Images Still Lag (And How to Fix It) Just spent way too long debugging image preloading in JavaScript, and I learned it's way more nuanced than I thought. The Problem: You upload an image, preload it with new Image(), submit the form... and it still renders with a lag. What gives? The Culprit: The browser's HTTP cache. If the server sends Cache-Control: no-store, your preload gets ignored. You're not actually caching anything—you're just at the mercy of the server's caching strategy. The Fix: Use <link rel="preload" /> instead. It bypasses the HTTP cache entirely and stores the asset in a separate "preload cache." Even with no-store headers, it works like a charm. Quick Rundown of Your Options: - new Image() — Simple, but assumes HTTP caching works (it often doesn't) - <link rel="preload" /> — Reliable, uses its own cache layer ✅ - Cache API — Powerful but you manage cleanup manually - fetch() — Good control, but still respects server cache headers - Hidden div + CSS background — Works but feels hacky For most cases, <link rel="preload" /> is your sweet spot. It's been around for nearly a decade and just works. The cherry on top? If the image takes too long to load, the browser is smart enough to wait for the pending request instead of firing a new one. No duplicate requests. Anyone else run into this? What's your go-to preloading strategy? https://lnkd.in/g5bBg5mz #performance #frontend #javascript #preloading

🧠 Why map() in React Needs a key (Beyond Just a Warning) Most developers know this warning: “Each child in a list should have a unique key” So they do this 👇 {items.map((item, index) => ( <li key={index}>{item}</li> ))} Warning gone ✅ Problem solved ❌ 🔍 What actually happens? React uses key to track elements between renders. If you use index: 👉 React assumes position = identity ⚠️ The hidden bug const items = ["A", "B", "C"]; Now remove "A". New list: ["B", "C"] With index as key: "B" becomes index 0 React thinks it’s still "A" 👉 UI can behave incorrectly 👉 State can get mixed up ✅ Correct approach {items.map(item => ( <li key={item.id}>{item.name}</li> ))} 👉 Use a stable, unique key 🎯 Real Insight key is not for React warnings. It’s for correct UI behavior. 💥 Senior-level understanding Bad keys don’t always break immediately. They break when: Items reorder Items are removed State is attached to elements That’s why bugs feel random. #ReactJS #FrontendDevelopment #JavaScript #CleanCode #WebDevelopment #CodingTips #LearningInPublic

After getting comfortable with JavaScript fundamentals, I moved to working with the browser. Part that makes websites actually feel alive , the DOM and browser APIs. This is where things became more practical. I explored: ▸ DOM Manipulation — traversing the page as a tree and dynamically updating elements, attributes, and styles with JS ▸ Events & Event Handling — capturing clicks, keyboard inputs, and user interactions to build truly responsive UIs ▸ Forms & Validation — handling input fields, text areas, and select boxes, with validation logic to keep data clean ▸ Timers & Intervals — managing delayed executions and repetitive actions using setTimeout and setInterval ▸ Data Storage — persisting user data across sessions with localStorage, sessionStorage, and cookies Along the way, I built a few mini projects to apply these concepts. There's a massive difference between understanding a concept and building with it. The projects made everything click. This phase felt different from just learning syntax. It was more about connecting logic to actual user interaction. #JavaScript #WebDevelopment #DOM #LearningInPublic #Frontend

Most developers think they understand the event loop. Until performance starts breaking in production. I wrote a short breakdown on: • Why the event loop becomes a bottleneck • What actually blocks it (it’s not always obvious) • Simple patterns to avoid performance issues No fluff. Just practical insights you can apply immediately. If you’re working with JS (browser or Node), this matters more than you think. Read here: https://lnkd.in/g_8n8gvn

Day 16 — Memoization in JavaScript (Boost Performance) Want to make your functions faster without changing logic? 👉 Use Memoization 🚀 --- 🔍 What is Memoization? 👉 Memoization is an optimization technique where we cache results of expensive function calls and reuse them. --- 📌 Without Memoization function slowSquare(n) { console.log("Calculating..."); return n * n; } slowSquare(5); // Calculating... slowSquare(5); // Calculating again ❌ --- ⚡ With Memoization function memoize(fn) { let cache = {}; return function (n) { if (cache[n]) { return cache[n]; } let result = fn(n); cache[n] = result; return result; }; } const fastSquare = memoize((n) => { console.log("Calculating..."); return n * n; }); fastSquare(5); // Calculating... fastSquare(5); // Uses cache ✅ --- 🧠 What’s happening? 👉 First call → calculates result 👉 Next call → returns from cache 👉 No re-computation --- 🚀 Why it matters ✔ Improves performance ✔ Avoids repeated calculations ✔ Useful in heavy computations ✔ Used in React (useMemo) --- 💡 One-line takeaway: 👉 “Don’t recompute — reuse cached results.” --- If your function is slow, memoization can make it fast instantly. #JavaScript #Performance #Memoization #WebDevelopment #Frontend #100DaysOfCode

A friend reached out to me yesterday, frustrated with his theme toggle in Next.js. He was stuck in that classic "Hydration vs. Flicker" loop. First, he tried to detect the theme on the server, which threw a hydration error because the server can't "see" the user's browser settings. Then, he moved the logic to useEffect to make it client-only, but that caused the dreaded theme flicker—the page loads bright white for a split second before snapping to dark mode. He asked me how libraries like next-themes manage to avoid both. I honestly thought it was some complex middleware or cookie-syncing magic. But I took a look at the source code, and the solution is actually much simpler (and more clever) than I expected. The "Injected Script" Trick It turns out next-themes injects a tiny, minified script tag directly into the <head> of the document. Because scripts in the head are render-blocking, the browser stops everything to run that script before it even starts painting the UI. In those few microseconds, the script: Checks localStorage. Checks the system's prefers-color-scheme. Immediately slaps the .dark class onto the <html> element. By the time your React components actually render and the CSS is applied, the HTML tag is already set up. The browser paints it correctly on the very first frame. Why I love this We spend so much time trying to solve everything "the React way," but this is a perfect example of where a tiny bit of "old-school" vanilla JS is actually the superior tool for the job. It avoids the server-client mismatch entirely by handling the styling before the UI even exists. If you’re building a custom theme provider, definitely look into how they handle the next-themes injection. It’s a great reminder that sometimes the best engineering is just knowing exactly where to put a single line of code.