Kishor Dhokade’s Post

🚀 Day 8 Not Just Motivation — Real Concepts to Build Strong Technical Understanding (Part 8) Why does JavaScript remember variables even after a function finishes? The answer is Closure. Let’s understand this using a real-world example from React: useState. A simplified mental model of useState (conceptual) function useState(initialValue) { let state = initialValue; function setState(newValue) { state = newValue; render(); // re-render component } return [state, setState]; } Here, setState is a closure. It remembers state even after useState finishes execution. Example: Counter Component function Counter() { const [count, setCount] = React.useState(0); return ( <button onClick={() => setCount(count + 1)}> Count: {count} </button> ); } Every render is a new function call. So how does React remember count? Let’s go step by step. Render 1 – Initial Mount 1. React calls the component: Counter(). 2. useState(0) runs and creates a state slot outside the function (heap/fiber). 3. count is set to 0 and setCount is returned as a closure. 4. JSX is rendered and UI shows Count: 0. User Clicks the Button 1. Browser triggers a click event. 2. React handles the event via its synthetic event system. 3. setCount(count + 1) is called. 4. React updates internal state and schedules a re-render. Render 2 – After State Update 1. Counter() runs again. 2. Local variables are recreated, but state is preserved. 3. useState does not reinitialize; it reads existing state from memory. 4. count is now 1 and UI updates accordingly. Final Takeaway The component function re-runs on every render, but state survives because React stores it outside the function. setState works because it is a closure pointing to that preserved state. Closures are the reason useState works. #javascript #closure #reactjs #reacthooks #frontend #webdevelopment

I just finished Frontend Masters “A Tour of JavaScript & React Patterns” and the biggest mindset shift for me was this: Most React “performance problems” are actually rendering problems. Not “React is slow”, but “I accidentally made more of the tree render than needed”. A few things I’m taking away and actively applying: ✅ Context is not a state manager It is a delivery mechanism. If the value changes often, it becomes a re-render broadcaster. That is perfect for “rarely changes” state (theme, locale, auth), risky for high frequency state. ✅ The fastest component is the one that does not re-render Before reaching for memo everywhere, I ask: Can I move state down? Can I split the provider? Can I pass a stable callback? Can I avoid creating new objects in props? ✅ Render cost is usually in the children Even small parent changes can re-render expensive lists, charts, tables. Splitting components and isolating heavy parts pays off more than micro-optimizing one hook. ✅ Patterns are about shaping render boundaries Custom hooks, compound components, provider splitting, controlled vs uncontrolled components. These are not just “clean code” choices. They decide how much UI updates when data changes. And a big one outside the component tree: ✅ Performance starts before React even runs Choosing the right rendering strategy changes the whole user experience: CSR when you need app-like interactivity and data is truly user-specific SSR when you need fast first paint plus fresh data per request SSG when content is stable and you want maximum speed ISR when you want SSG speed but still keep content reasonably fresh without rebuilding everything Simple rule I like now: Architecture is often performance in disguise, both in your component tree and in your rendering strategy. #react #nextjs #javascript #performance #frontend #webdevelopment #softwareengineering

🚀 Just Discovered: Oat — A Breath of Fresh Air for Frontend Development Really impressed by the simplicity and clarity of Oat. Great work by Kailash Nadh and team 👏👏👏 If you’ve ever felt weighed down by complex build systems, heavy frameworks, or endless dependencies — this might excite you. I came across Oat, an ultra-lightweight HTML/CSS UI component library that actually lives up to its name. At ~8KB (minified + gzipped), it gives you: 🔹 Semantic, zero-dependency UI components 🔹 No frameworks, no build tooling, no class pollution 🔹 Minimal JS (WebComponents) where needed 🔹 Styles native HTML elements contextually out of the box 💡 Perfect for: ✔ Developers who value semantic HTML ✔ Projects where performance really matters ✔ Anyone tired of bloated UI frameworks Check it out here 👉 https://oat.ink/� #FrontendDevelopment #WebDevelopment #UIEngineering #WebComponents #SemanticHTML #CSS #JavaScript #PerformanceMatters #MinimalismInTech

Frontend has evolved. But has it become unnecessarily heavy? We started with simple HTML, CSS and JavaScript. - Then came frameworks; - Then abstractions; - Then hooks;  - Then dependency arrays; - Then memoization; - Then performance optimization strategies for our optimization strategies. Somewhere along the way, building a button started requiring architectural decisions. Don’t get me wrong. React changed frontend development forever.  - It made components mainstream.  - It made UI declarative.  - It built an ecosystem that powers a large part of the web. But every abstraction comes with a cost. Most modern frameworks rely on a runtime engine that ships to the browser. That runtime tracks changes, compares virtual trees, reconciles differences, and manages re-renders. It works; It scales. But it also adds weight. More JavaScript shipped; More mental models to learn; More concepts before productivity. Now here’s the question: - What if your framework didn’t need to run in the browser to manage your UI? - What if it could do most of its work at build time? That’s where Svelte changes the conversation. Instead of shipping a large runtime to the browser, Svelte compiles your components into minimal, optimized JavaScript. No virtual DOM. No diffing engine. No heavy reconciliation cycle. Just surgically targeted DOM updates. The result? Less JavaScript; Less overhead; Less performance tax. This is not about React vs Svelte - This is about runtime vs compile-time thinking. During this deep-dive series, I’ll break down: - Why modern frontend feels heavier - What “performance tax” really means - How Svelte simplifies reactivity - Where React shines - And where Svelte quietly outperforms Frontend doesn’t need more abstraction - It needs clarity. Let’s start the conversation #Svelte #FrontendDevelopment #WebPerformance #JavaScript #ReactJS #WebEngineering #UIEngineering #CompiledSpeed #TechLeadership #SvelteWithSriman

React Hooks didn’t just change syntax — they changed how we design UI systems. ⚙️🧠 Before hooks, stateful logic lived in class components, and “reuse” often meant HOCs, render props, and tangled lifecycles. Hooks made component logic composable again: small pieces of behavior you can share, test, and reason about. Why they matter in real projects 👇 ✅ Clearer mental model: state + effects are explicit. No hidden lifecycle edge cases. ✅ Reuse without wrappers: custom hooks turn messy cross-cutting concerns (auth, caching, analytics, feature flags) into clean APIs. ✅ Better performance control: useMemo/useCallback aren’t “speed buttons” — they’re tools to stabilize references for expensive computations and child renders. ✅ Fits modern frameworks: Next.js + React Server Components push more work to the server, but hooks still define predictable client boundaries (“use client”) and interactive behavior. Practical takeaway: treat useEffect as integration glue, not a default. If derived state can be computed during render, don’t store it. If an effect exists, ask: “what external system am I syncing with?” 🔌 What’s the hook pattern you rely on most in production? 👀 #react #javascript #nextjs #frontend #webdev #softwareengineering

🚀 Building Reactive UI with Zero Effort: A pawaJs Sneak Peek I’ve been experimenting with pawaJs, and the developer experience is incredibly smooth! Check out how easily we can manage state and create reactive components. In this example, I’m building a simple counter that demonstrates the core strengths of the framework: Reactive State: Using state-count="0" directly in the HTML to initialize data. Computed Values: Notice how the doubleCount automatically tracks and multiplies the base state—reactivity handled for you! Custom Components: I registered a <compo></component> component with RegisterComponent in just a few lines of code. Directives: Clean, attribute-based event handling like on-click="count.value++". What I love most is how pawaJs keeps the logic readable and the boilerplate to an absolute minimum.it feels like a framework built for modern performance. The web is evolving, and tools like this make building interactive interfaces feel like a breeze again. 🍦 #pawaJs #WebDevelopment #JavaScript #Frontend #OpenSource #WebDev #Programming #TechInnovation

🚀 The hidden JavaScript function that's cleaner than your setTimeout(0) hacks If you’ve been around JavaScript long enough, you've probably used: setTimeout(() => { … }, 0) just to make something run after the current execution finishes. It works - but let's be honest - it's a hack. setTimeout schedules a macrotask, which means your callback waits for the entire event loop cycle… including rendering and other browser work. That’s often later than you actually need. 👉 Enter queueMicrotask() I like to think of it as the VIP lane for your code. It says: "As soon as the current call stack is done, run this - before the browser even thinks about repainting." Why should you care? 🤔 ✅ Predictability: Avoid those Zalgo bugs where APIs are sometimes sync and sometimes async. queueMicrotask guarantees async - but still immediate. 📈 Performance: Microtasks run sooner than setTimeout, so your logic executes faster and more consistently. 🧹 Cleaner intent: queueMicrotask(() => { … }) clearly communicates purpose. No more mysterious "0ms delays" 🚫 The "wait… don't do that" part: This is NOT a magic speed button. If you put heavy CPU work inside queueMicrotask, you'll block rendering entirely. Microtasks run before paint — so long-running work here = frozen UI. Not fun 😅 🤙 Rule of thumb 👉 Use queueMicrotask for small, quick logic that must run before the next frame 👉 Use setTimeout or requestIdleCallback for work that can wait a heartbeat Have you started replacing your setTimeout(0) calls with queueMicrotask yet - or are you sticking with the classics? Drop your thoughts in the comments 👇 #JavaScript #Frontend #WebDevelopment

🚀 The Frontend Evolution: From HTML to TypeScript This image perfectly captures how frontend development — especially JavaScript — has evolved over time 🛠 HTML The foundation. Static pages, basic structure. No logic, no interaction — just content. 🎨 CSS Design entered the game. Layouts, colors, responsiveness — making the web look good. ⚙️ JavaScript Everything changed here. From simple DOM manipulation to powering real-time interactions, logic, and dynamic behavior. ⚛️ React Component-based thinking. Reusable UI, state management, faster development, and scalable frontend architecture. 🧠 TypeScript JavaScript, but safer. Type safety, better tooling, fewer runtime bugs — built for large and complex applications. 📈 Key takeaway for frontend developers: JavaScript didn’t just grow — it matured. And as developers, we grow by adapting, learning, and choosing the right tools at the right time. The journey isn’t about chasing trends — It’s about understanding fundamentals and evolving with the ecosystem. #FrontendDevelopment #JavaScript #React #TypeScript #WebDevelopment #FrontendJourney #LearnAndGrow

“Why async JavaScript still blocks your UI” 👇 Because async ≠ non-blocking. JavaScript is still single-threaded on the main thread. What async/await actually does 👇 ✅ Makes code look asynchronous ❌ Does not move work off the main thread So this still blocks your UI: `` await heavyCalculation(); `` Why? Because: - async pauses your function - But CPU-heavy work still runs on the main thread - Rendering, input, animations → all wait Common UI killers 👇 ❌ Large JSON parsing ❌ Complex loops & calculations ❌ Image/data processing ❌ Synchronous third-party libraries The browser can’t render while JS is busy. The real fix 🧠 - async/await → helps with I/O - Web Workers → required for CPU-heavy work. 🧵 Smooth UI isn’t about async code. It’s about protecting the main thread. 💬 Honest question: What’s the heaviest thing running on your main thread right now? #JavaScript #FrontendPerformance #WebDevelopment #SoftwareEngineering