Duc Dang’s Post

🚀 Frontend Performance — Learning in Public Over the last couple of days, I explored Lighthouse-based performance analysis on a real application. Key learnings 👇 🧠 Main Thread Matters 👉 Browser runs on a single thread 👉 Heavy JS → slower interaction 🚦 Render-Blocking Resources 👉 CSS/JS can delay UI rendering ⛓️ Critical Request Chain 👉 Too many dependencies → slower loading 📊 Lighthouse Insight 👉 It’s not about score 👉 It’s about identifying root causes 🎯 Big takeaway: Performance = reduce work + remove blockers 📌 Next: Building a real-world performance audit report #Frontend #WebPerformance #JavaScript #ReactJS #SoftwareEngineering #LearnInPublic

🚀 JavaScript Project 3: Counter System Built a stste-driven counter with increment, decrement and reset actions —but this time, I focused on how engineers think, not just making it work. 🔑 Key ideas: • State is the single source of truth • UI updates are centralized ( updateUI ) • Event delegation for scalable interaction • Data-driven actions using data-* attributes • Clear UI feedback (disabled states, interaction response) 💡Biggest insight: Don't manipulate the UI directly — update state, then let the UI reflect it. 🔗 Live: https://lnkd.in/dTNy6A2M 💻 Code: https://lnkd.in/dp638D6h This is part of my journey building JavaScript systems step-by-step. More coming. #JavaScript #Frontend #WebDevelopment #LearningInPublic

We often hear that JavaScript is single threaded. But at the same time, it handles API calls, timers, and UI updates smoothly. The reason is the Event Loop. Here is a simple way to understand it. Think in terms of 5 parts: 1. Call Stack This is where code runs right now. If something blocks here (like an infinite loop), everything else stops. 2. Web APIs The browser handles things like fetch, setTimeout, and events outside the main thread. When they are done, they send callbacks to queues. 3. Microtask Queue (high priority) This includes Promise callbacks and async/await. All microtasks run completely before anything else happens. -> If you keep adding microtasks (like recursive Promise.then), you can actually block rendering completely. 4. Macrotask Queue (low priority) This includes setTimeout, setInterval, and other tasks. Only one macrotask runs at a time. 5. Render After microtasks are done, the browser updates the UI (layout and paint). -> The browser decides when to paint — not strictly after every loop. Simple cycle: Run one macrotask → run all microtasks → update UI → repeat JavaScript isn’t non-blocking — the event loop just makes it feel that way. #javascript #frontend #reactjs #webdevelopment #softwareengineering #webperformance #systemdesign #Coding

Just built a dynamic product card using JavaScript DOM manipulation What I love about this project is how flexible it is — I can generate as many cards as I want dynamically, making it super useful for real-world applications like e-commerce or dashboards. Features: Fully dynamic card creation using DOM Clean and modern UI design Reusable component structure Easy to scale for multiple products This project helped me strengthen my understanding of how the DOM really works behind the scenes — not just static HTML, but building everything programmatically. 📂 GitHub Repository: https://lnkd.in/gwcZG2pf Would love to hear your thoughts or suggestions for improvement! #JavaScript #WebDevelopment #Frontend #DOM #Coding #Projects #Learning #100DaysOfCode

Why does your 'ref' return 'null' the moment you wrap your input in a custom component? It is one of those React quirks that trips up even experienced developers. By default, refs do not behave like props. They are treated as special instances that stop at the component boundary to protect encapsulation. This is exactly why we need 'forwardRef'. It acts as a bridge that allows a parent component to reach through a child and grab a direct handle on an internal DOM node. The most practical application is building a reusable UI library. If you create a custom 'Input' or 'Button' component, your parent component might need to call '.focus()' or '.scrollIntoView()'. Without 'forwardRef', your parent is just holding a reference to a React internal object, not the actual HTML element. Another real-world scenario involves Higher-Order Components (HOCs). If you wrap a component with a 'withAnalytics' or 'withTheme' wrapper, that wrapper will 'swallow' the ref by default. By using 'forwardRef' in your HOC implementation, you ensure the reference passes through the wrapper and lands on the component that actually needs it. It is about making your abstractions transparent and ensuring that the parent component maintains the control it expects over the physical DOM. Using this pattern sparingly is key. It is an escape hatch for those moments where declarative state isn't enough to manage physical browser behavior. It keeps your component interfaces clean while providing the necessary access for specialized UI interactions. #ReactJS #SoftwareEngineering #Frontend #WebDevelopment #Javascript #CodingTips #CodingBestPractices

React performance optimization is not about using useMemo() everywhere. It starts with understanding why your components re-render. Most production performance issues come from: ❌ Unnecessary re-renders ❌ Large Context API updates ❌ Recreating functions on every render ❌ Heavy calculations inside render ❌ Missing or unstable key props ❌ Lifting state too high ❌ Large bundle sizes slowing initial load Many developers start optimization with React.memo(). But real optimization starts much earlier—with better component architecture. What actually helps: ✔ Avoid unnecessary re-renders ✔ Use React.memo() for stable reusable components ✔ Use useCallback() only when function references matter ✔ Use useMemo() for expensive calculations, not everything ✔ Optimize Context API by splitting contexts ✔ Use stable and unique keys in lists ✔ Apply code splitting and lazy loading ✔ Virtualize long lists for better rendering performance ✔ Keep state local instead of lifting it unnecessarily The biggest lesson from production systems: Premature optimization creates complexity. Smart optimization creates scalability. Don’t optimize because React provides hooks. Optimize because your application actually needs it. Measure first. Optimize second. That’s how high-performance frontend systems are built. #ReactJS #PerformanceOptimization #FrontendDevelopment #JavaScript #ReactDeveloper #WebDevelopment #SoftwareEngineering #CleanCode #TechLeadership

I’ve used CSS-in-JS heavily in production systems. At small scale, it feels like a clear win scoped styles, dynamic props, no naming headaches. It improves developer experience in all the right ways. But at scale, the conversation changes. CSS-in-JS moves work into the runtime: -Styles are generated during render -Injected into the DOM repeatedly -Paid for during hydration, not build Individually, these costs look small. Together, they show up as slower renders, heavier pages, and harder to debug performance issues. What makes this tricky is that nothing “breaks.” The system just becomes gradually less efficient. That’s why many teams are quietly shifting, towards build-time extraction, utility first CSS, or zero runtime approaches. Not because CSS-in-JS is wrong but because the cost model doesn’t scale cleanly. As engineers, we don’t just choose tools based on DX. We choose them based on where the cost lands. And in this case, the cost lands on the user. Curious — at what scale did CSS-in-JS start becoming a problem for you? #FrontendEngineering #WebPerformance #SoftwareEngineering #CleanCode #ScalableSystems #JavaScript #ReactJS #CSS

JavaScript isn’t hard unclear logic is. One thing I’ve learned while building real frontend features is this: Most bugs don’t come from JavaScript itself… They come from assumptions we make while writing it. Here’s a simple rule that has saved me countless hours: Always validate your data before using it. Because in real projects, you’re not just writing code you’re handling unpredictable inputs, API delays, null values, and user behavior. A few examples that prevent 80% of silent failures: • Check if an array actually exists before mapping • Confirm API responses before rendering UI • Avoid chaining methods on undefined • Never trust user input without validation • Use optional chaining when the structure isn’t guaranteed Small checks. Big impact. Clean code isn’t about writing more it’s about writing responsibly. When your logic is predictable, your UI becomes reliable. And reliability is what users remember. #JavaScript #FrontendDevelopment #WebDevelopment #CleanCode #TechTips #UIUX #DeveloperLife

I built a Pomodoro timer into ACE and honestly it's been one of those features I didn't know I needed until I had it. The idea was simple. I was using ACE to study and kept switching tabs to find a timer. So I just built one in. 25 minutes. Focus. Break. Repeat. If you're building something, don't sleep on the small features. Sometimes the thing that makes your product actually usable isn't the AI or the fancy architecture. It's the 25 minute timer sitting quietly in the corner. #buildinpublic #nextjs #webdevelopment #javascript #frontenddevelopment

🚀 Improving Frontend Performance with Throttling & Debouncing One key realization while optimizing UI performance 👇 👉 Not all issues are about page load 👉 Many come from how frequently our code runs 🧠 The Problem Events like scroll 📜, resize 📏, and typing ⌨️ can fire hundreds of times per second This leads to: ❌ unnecessary work ❌ busy main thread ❌ poor responsiveness ⚙️ The Solution 🔹 Throttling 👉 Limit execution frequency 👉 e.g., run once every second 🔹 Debouncing 👉 Execute only after user stops 👉 e.g., search after typing stops 🎯 Key Difference 👉 Throttle = steady control 👉 Debounce = wait then act 📊 Why it matters 👉 Less work for browser 🧠 👉 Better responsiveness ⚡ 💡 “Performance is not just faster loading — it’s smarter execution.” #Frontend #JavaScript #WebPerformance #ReactJS #FrontendEngineering