Sergey Panin’s Post

Source: https://lnkd.in/ez_73Acw 🚀 Front-end devs often overlook the "waking up" of static HTML—hydration is key! 🌐 But why hydrate the whole page? Partial hydration + islands architecture (like Astro.js) let us focus JS on critical parts. 💡 React 16’s Fiber revolutionized rendering with time slicing, making UIs responsive during updates. Yet, useMemo can backfire if overused—stale closures are a sneaky bug source! 🐛 For backend mastery, Boot.dev is a game-changer: build real projects, earn XP, and tackle challenges with AI tutoring. #FrontEnd #React #DevTools

🎬 𝐄𝐯𝐞𝐫𝐲 𝐛𝐥𝐨𝐜𝐤𝐛𝐮𝐬𝐭𝐞𝐫 𝐦𝐨𝐯𝐢𝐞 𝐡𝐚𝐬 𝐨𝐧𝐞 𝐫𝐮𝐥𝐞 𝐨𝐧 𝐬𝐞𝐭 — No one waits for anyone else to finish their scene. ━━━━━━━━━━━━━━━━━━━━━━━ 𝗧𝗵𝗮𝘁'𝘀 𝗲𝘅𝗮𝗰𝘁𝗹𝘆 𝗵𝗼𝘄 𝗡𝗼𝗱𝗲.𝗷𝘀 𝗲𝘃𝗲𝗻𝘁 𝗱𝗿𝗶𝘃𝗲𝗻 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝘄𝗼𝗿𝗸𝘀. 🧵 Node.js Event Driven Architecture ━━━━━━━━━━━━━━━━━━━━━━━ 𝗧𝗵𝗲 𝗖𝗼𝗿𝗲 𝗣𝗵𝗶𝗹𝗼𝘀𝗼𝗽𝗵𝘆 𝗘𝘃𝗲𝗿𝘆 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗗𝗲𝘃 𝗦𝗵𝗼𝘂𝗹𝗱 𝗦𝘁𝗮𝗿𝘁 𝗪𝗶𝘁𝗵 Most traditional backends think like this — → Request comes in → Server processes it → Response goes out Linear. Blocking. Predictable — but not scalable. Node.js flips this entirely. ━━━━━━━━━━━━━━━ 𝗧𝗵𝗲 𝟯 𝗣𝗶𝗹𝗹𝗮𝗿𝘀 𝗼𝗳 𝗘𝘃𝗲𝗻𝘁 𝗗𝗿𝗶𝘃𝗲𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲: ━━━━━━━━━━━━━━━ 1️⃣ 𝗘𝘃𝗲𝗻𝘁 𝗘𝗺𝗶𝘁𝘁𝗲𝗿 — fires the signal. Something happened. 2️⃣ 𝗘𝘃𝗲𝗻𝘁 𝗟𝗶𝘀𝘁𝗲𝗻𝗲𝗿 — watches and waits for that signal. 3️⃣ 𝗘𝘃𝗲𝗻𝘁 𝗖𝗮𝗹𝗹𝗯𝗮𝗰𝗸 — reacts the moment the signal arrives. This is called the 𝗢𝗯𝘀𝗲𝗿𝘃𝗲𝗿 𝗣𝗮𝘁𝘁𝗲𝗿𝗻 — and it's the backbone of how Node.js handles thousands of concurrent connections without breaking a sweat. ━━━━━━━━━━━━━━━ 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝗸𝗲𝘀 𝗡𝗼𝗱𝗲 𝘀𝗰𝗮𝗹𝗲: ━━━━━━━━━━━━━━━ → Components don't call each other directly → They emit events and let listeners react independently → That's 𝗹𝗼𝗼𝘀𝗲 𝗰𝗼𝘂𝗽𝗹𝗶𝗻𝗴 — the foundation of every scalable backend system One event. Multiple listeners reacting independently — logging, auth, analytics — all at once. No blocking. No waiting. Express, NestJS, Socket.io — all built on this exact idea. 🚀 Next post — this in real code. 👀 #NodeJS #BackendDevelopment #JavaScript #SystemDesign #EventDriven #Developer

Higher-Order Components are often called “old React.” But that’s only half the story. In React, HOCs introduced one of the most important ideas in frontend architecture: 👉 Separating behavior from UI Most developers focus on what components render But scalable systems depend on how behavior is reused That’s where HOCs changed the game: Wrap components without modifying them Inject logic like auth, logging, loading Keep UI clean and focused ⚡ Where HOCs still matter today: • Legacy codebases • Authentication & route guards • Analytics / logging layers • Enterprise abstraction layers 🧠 What I learned working on real systems: Hooks made things simpler — no doubt. But they didn’t replace the idea behind HOCs. Because at scale: 👉 You don’t just write components 👉 You design reusable behavior layers 💡 The real takeaway: HOCs are not about syntax. They’re about thinking in abstractions. And once you start thinking this way — your frontend code becomes: ✔️ Cleaner ✔️ More reusable ✔️ Easier to scale #️⃣ #reactjs #frontenddevelopment #javascript #softwarearchitecture #webdevelopment #coding #reactpatterns

I read a React codebase's sidebar component top to bottom. Twelve files, one SaaS suite, zero magic. The whole thing fits in a carousel. ↓ What you'll see, file by file: → Composition by convention — numbered folder prefixes (_1/_2/_3) that enforce visual order. → Union types + Record<K,V> — the compiler refuses to build until every variant has a label. → Design tokens as data — avatar sizes, paddings, border widths all in one typed object. No JSX ternaries. → CustomSelect — one component, three+ use cases. Base styles locked, overrides via cn(). → Triple memoization on Context — useCallback on setters, useMemo on the value, fully enumerated deps. No accidental re-renders. → Animation variants as objects — Framer Motion configs live outside the component. Testable, swappable, versioned. → Exit faster than enter — 120ms out, 180ms in. Asymmetric durations feel right because they match human attention. → Effects are contracts — polling pauses when the tab is hidden. Listeners always removed in cleanup. Every slide is real code from a production SaaS frontend. Not a tutorial, not a toy example. Rust on a chip was post #01. React in the browser is post #02. Same ethos: small files, sharp decisions, no magic. Repo link in the first comment. #ReactJS #TypeScript #Frontend #NextJS

You know how to create components in React and call APIs, so does the AI. A lot of people think (even I did back in 2023) that if you know how to make components, pass props, and call an API, you’re ready for backend. But I was wrong. React is not just about components, props, and API calls. I realized this when I got a frontend project from another developer. Everything looked fine. UI was good, backend was clean. But something felt off. Then I noticed the dependency array was not handled properly. The result? 100+ API calls on page load, and 429 errors started showing. There are no shortcuts to fundamentals. #javascript #frontenddevelopment #backenddevelopment #webdevelopment

React Rule at Factory: No direct useEffect allowed They banned calling useEffect directly in the codebase. For the rare cases needing external sync on mount, they use a single explicit hook: useMountEffect(). Why? Most useEffect usage was creating: Infinite loops Race conditions Hidden dependency hell Flaky refactors Debugging pain (“why did this run?”) This is even more critical now that AI agents are writing frontend code and often add “just-in-case” effects. The team replaced most effects with these 5 clean patterns: Derive state — don’t sync it with effects Use proper data-fetching libraries — no manual fetch + setState Event handlers — not effect flags useMountEffect — only for true external sync (DOM, third-party widgets) Reset with React keys — instead of effect choreography Result: Fewer bugs, easier reasoning, faster onboarding, and a more predictable codebase. It started as a strict rule born from production pain — now it feels like an essential guardrail. Would you adopt a “no direct useEffect” rule on your team? Thoughts? Too extreme or smart discipline? Drop your take below #React #ReactJS #Frontend #WebDevelopment #JavaScript #CleanCode #SoftwareEngineering

Writing a JavaScript Framework: Project Structuring Simplified   When building a JavaScript framework, structuring your project is everything. A well-designed architecture ensures scalability, maintainability, and performance.   This visual (inspired by RisingStack Engineering) highlights how different layers interact within a framework: 🔹 Middlewares – Handle core functionalities like routing, rendering, and data interpolation 🔹 Helpers – Tools like compiler and observer that power reactivity and optimization 🔹 Symbols & Components – The building blocks that connect logic with UI 🔹 Your App – The central piece that ties everything together seamlessly   💡 The takeaway? A strong separation of concerns and modular design is what makes frameworks robust and developer-friendly. If you’re exploring how frameworks work under the hood, this is a great starting point to understand the bigger picture.   ✨ Build smarter. Structure better.   #JavaScript #WebDevelopment #Frontend #Frameworks #SystemDesign #SoftwareArchitecture #FullStack #Developers #Coding #TechLearning

Day 57 of 100 Days of AI — 🎨 Frontend Work Begins Backend done. Time to build what users actually see. Started working on the frontend today — a clean landing page where people can subscribe to the newsletter. Hosting it on Cloudflare, built in Next.js. One thing I tried differently today — used Claude to help design the UI. Described what I wanted, iterated on the design in real time, and got something that actually looks good without spending hours on Figma or fighting with CSS from scratch. The design process felt completely different — faster, more collaborative, less painful. The page is simple by design. One clear message. One action. Subscribe. No fluff. No feature bloat. Just — here's what you get, here's where you sign up. When the backend is this solid the frontend almost writes itself. Almost. #100DaysOfAI #BuildInPublic #NextJS #CloudflareWorkers #AIEngineering #Python #Newsletter #SideProject #Frontend

React has come a long way - and we’ve officially entered the Compiler Era. From the complex, hard-to-scale codebases of 2013 to today’s intelligent systems, React’s evolution has been nothing short of transformative. With React 19.2.5, the “manual labor” of coding is steadily fading away. The framework is now smart enough to handle repetitive optimizations - so developers can focus on what truly matters: building great products. The Evolution Breakdown: 1️⃣ The Syntax Era Complex boilerplate and rigid structures made scaling difficult 2️⃣ The JSX Era UI became declarative, readable, and more intuitive 3️⃣ The Hooks Era Functional components took over, simplifying state and logic 4️⃣ The SSR Era Focus shifted to SEO and faster initial load performance 5️⃣ The Framework Era Tools like Next.js and Remix unified client and server development 6️⃣ The Intelligent Era (Now) With the React Compiler, we move beyond manual optimizations - less worrying about useMemo and useCallback, more focus on outcomes Why this matters for Developers & Businesses: ✔️ Reduced Tech Debt - Fewer manual optimizations, fewer hidden bugs ✔️ Performance by Default - Faster apps without constant fine-tuning ✔️ Focus on Logic, Not Plumbing - Build features instead of managing lifecycles ✔️ Higher Productivity - Spend time where it creates real value #ReactJS #WebDevelopment #Frontend #SoftwareEngineering #Programming #TechTrends #React19 #JavaScript

Clean code > "Clever" code. I’d rather debug a "slow" function that I can understand in 30 seconds than a "blazing fast" algorithm that looks like a bowl of alphabet soup. In React and TypeScript development, it's easy to obsess over re-renders and micro-optimizations before the UI is even finished. But I’ve learned that the hierarchy of needs usually looks like this: - Correctness comes first (Does it actually work?). - Readability keeps it alive (Can someone else fix it?). - Performance makes it scale (Is it actually lagging?). If you can’t explain your optimization to a teammate without a 20-minute whiteboard session, it might be time to refactor for clarity instead of speed. The machine might run the code, but a human has to maintain it. Agree or disagree?👇 #Javascript #ReactJS #TypeScript #WebDev #ProgrammingLife #CleanCode