How React Works and Why Developers Love It

Lena: You know, Miles, I was looking at my phone this morning and realized that almost every app I touched—Instagram, Netflix, even Airbnb—is actually powered by the same DNA. It’s all React.

Miles: It’s wild, right? We’re living in a world where over 11 million websites rely on this one library. And get this—even though it’s been around for over a decade, about 42% of developers still choose it over every other option. It’s basically the industry standard at this point.

Lena: Which is funny because when it first launched back in 2013, developers actually hated it! They thought mixing HTML and JavaScript was a total "violation" of coding principles.

Miles: Exactly. But now, it’s the philosophy that everyone wants to learn because it turns web building into a game of Legos. Instead of rewriting code, you’re just snapping reusable components together.

Lena: I love that analogy. So today, we’re moving past the scary jargon like "client-side rendering" and getting into the must-know basics—props, JSX, state, and even how this translates to mobile with React Native.

Miles: It’s a lot to take in, but once you get the mental model down, everything clicks. Let’s explore how React actually "thinks" by breaking down its component philosophy.

Lena: So, Miles, we’ve established that React is like building with Legos—but I want to really dig into that "component" philosophy. For someone just starting out, is a component just a fancy word for a button or a search bar?

Miles: That’s a great starting point, but it’s actually much deeper than that. Think of a component as an independent, reusable piece of the user interface—or UI. In the modern React world of 2026, we think of these as functional components. It’s literally just a JavaScript function that returns what the UI should look like. So, yeah, a button is a component, but a whole sidebar or even an entire page can be a component too. The magic is in the isolation. If you build a "UserProfile" component, you can drop it onto the home page, the settings page, or a search results page, and it works exactly the same way every time.

Lena: That sounds like a dream for maintenance. I mean—if I want to change the font of every user’s name across the whole site—I just change it in that one "UserProfile" component?

Miles: Exactly! You’ve hit the nail on the head. Instead of hunting through ten different HTML files to find every instance of a user’s name, you update it once. This is what we call the Single Responsibility Principle—or SRP. Each component should do one thing and do it well. If your component starts getting too big—like over 200 lines of code—that’s usually a signal to break it down into smaller sub-components. It’s like taking a big, messy Lego castle and realizing it’s actually made of a drawbridge, four towers, and a courtyard. If the drawbridge breaks, you only fix the drawbridge.

Lena: I love that. It makes the code feel less like a giant, scary wall of text and more like a collection of specialized tools. But how do these components actually "talk" to each other? If I have a "List" component and a "ListItem" component, how does the list tell the item what text to display?

Miles: That’s where "props" come in. Think of props—which is short for properties—as the arguments you pass to a function. It’s how data flows down the component tree. If you have a "WelcomeMessage" component, you might pass it a prop called "name." So one time you use it, it says "Hello, Lena," and the next time it says "Hello, Miles." The component itself stays the same—the "Lego brick" is identical—but the data inside it changes based on the props it receives.

Lena: Okay, so components are the structure, and props are the instructions or the data we feed into that structure. But there’s this other term that always comes up alongside components: JSX. It looks like HTML, but people keep telling me it’s not. What’s the deal there?

Miles: JSX is essentially a bridge. It stands for JavaScript XML. It’s a syntax extension that lets us write HTML-like structures right inside our JavaScript code. Before JSX, you had to write these really clunky JavaScript functions to create every single div or span. It was a nightmare to read. JSX makes it visual. It’s expressive, it’s clear—and honestly—it’s safer. React automatically escapes any values you embed in JSX, which helps prevent cross-site scripting attacks.

Lena: So it’s like writing a blueprint that the browser can actually understand after it gets "transpiled" or converted. It sounds like the goal is to keep the structure of the UI close to the logic that controls it.

Miles: Precisely. In 2026, we don’t want our logic scattered in one file and our UI in another. We want them co-located. When you look at a component file, you see the data it uses, the logic for how it behaves, and the JSX for how it looks—all in one place. It makes onboarding new developers so much faster because they don’t have to play detective to figure out how a button actually functions.

Lena: We’ve got our components and our props—but those feel kind of... static? Like, if I click a "Like" button, the number has to go up. Props can’t do that because they’re passed down from a parent, right?

Miles: Spot on. Props are read-only. They’re like a gift from a parent component—you can’t change them yourself. For things that change over time—like a counter, a form input, or whether a menu is open—we need "state." State is a component’s internal memory. It’s data that the component manages itself.

Lena: So if props are the "instructions" coming from the outside, state is the "mood" or the "current status" on the inside?

Miles: I like that! And in 2026, the primary way we handle this is with something called the `useState` hook. It’s a special function that returns two things: the current value of the state and a function to update it. When you call that update function, React says, "Oh, something changed!" and it automatically re-renders that component to show the new data. You don’t have to manually tell the browser to update the text on the screen. You just update the state, and React handles the rest.

Lena: That sounds incredibly powerful, but I can imagine it getting messy if every single component has its own state. I’ve heard people talk about "prop drilling" and "global state." Is that where things get complicated?

Miles: It can. Prop drilling is when you have to pass data through ten layers of components just to get it to the one at the bottom that actually needs it. It’s like passing a physical note through a whole classroom just to reach the kid in the back corner. To solve that, we use things like the "Provider Pattern" or "Context API." It’s like putting the note on a bulletin board that everyone in the room can see at once.

Lena: Ah, okay. So you’ve got local state for the small stuff—like if a dropdown is open—and then global state for the big stuff—like "is the user logged in?"

Miles: Exactly. And as of 2026, the community has really settled on using the right tool for the job. For global UI state, like themes or modals, a lot of teams use a lightweight library called Zustand. For server state—which is data coming from an API—we almost always use something like TanStack Query. The big mistake people used to make was trying to put everything into one giant "global state" bucket. That leads to massive performance issues because every time one tiny thing changes, the whole app tries to re-render.

Lena: That makes sense. It’s about keeping the data as close to where it’s used as possible. I was reading a guide from earlier this year—March 2026—that mentioned a "Four-State Model." It broke state down into Server state, Global UI state, Form state, and even URL state.

Miles: Yes! That’s such a smart way to think about it. URL state is actually one of the most underused tools. Think about filters on an e-commerce site. If you put those filters in the URL—like `?color=blue`—then a user can refresh the page or send the link to a friend, and they’ll see exactly the same thing. If you just keep that in local component state, it vanishes as soon as they leave the page.

Lena: It’s interesting how "state" isn’t just one thing. It’s about being intentional. If I’m building a checkout form, I use a form state library. If I’m fetching a list of products, I use a server state tool. It’s all about using the right tool for the specific type of data you’re handling.

Miles: And that intentionality is what separates a beginner from a senior engineer. A beginner puts everything in `useState`. A senior engineer asks, "Does this data belong to this component? Does it need to persist in the URL? Is it coming from a database?" Once you start asking those questions, the architecture of your app starts to feel a lot more stable.

Lena: We’ve been talking about the internal logic, but I want to zoom out to the big picture—"rendering." I hear these acronyms everywhere: CSR, SSR, RSC. It feels like an alphabet soup!

Miles: It really does. But the mental model is actually quite simple if you ask one question: "Where and when does the HTML get generated?" If it happens in the user’s browser, that’s Client-Side Rendering—or CSR. If it happens on your server every time a request comes in, that’s Server-Side Rendering—or SSR. And if it’s generated once when you build the app, that’s Static Site Generation—or SSG.

Lena: Okay, so CSR is like sending someone the ingredients and a recipe, and they cook the meal in their own kitchen. SSR is like a restaurant where they cook it and serve it to you hot.

Miles: Perfect analogy! And just like a restaurant, SSR is great because you get the "food" almost immediately. This is huge for SEO. Search engine crawlers love SSR because when they visit your site, they see a fully formed HTML page with all your content right there. With CSR, they often just see an empty `<div>` and have to wait for the JavaScript to load and run before they can "see" your site.

Lena: So if I’m building a blog or a store where I need Google to find me, SSR is a no-brainer. But what about the "scary" part? I’ve heard people say SSR is more expensive or complicated.

Miles: It is. With CSR, you can just put your files on a cheap CDN—like a global file cabinet—and you’re done. With SSR, you need an actual server running Node.js or an Edge runtime. Every time a user visits, that server has to do work. It has to fetch data, render the components, and send the HTML. That costs money and adds "latency"—which is just a fancy word for the time it takes for the server to respond.

Lena: And then there’s this new player on the block: React Server Components, or RSC. I was reading a guide from April 2026 that called RSC the "biggest architectural shift since hooks." How does that fit into the CSR/SSR split?

Miles: RSC is the hybrid model we’ve all been waiting for. It’s not just SSR. In traditional SSR, the server sends the HTML, and then the browser has to "hydrate" it—which means it downloads the same JavaScript code and runs it again to make the page interactive. With Server Components, some components render *only* on the server and stay there. They never send any JavaScript to the client.

Lena: Wait—so the browser gets the result, but it doesn't have to download the "recipe" or the "logic" for those specific components?

Miles: Exactly! Imagine a heavy library for formatting dates or a complex markdown parser. In the old days, you’d have to ship that entire library to the user’s phone. With RSC, the server uses that library, generates the HTML, and sends just the HTML. The user’s phone stays fast because it’s not doing all that heavy lifting. You’re pushing the "client boundary" as far down the tree as possible.

Lena: That sounds like a massive win for mobile users especially. If you’re on a slow 4G connection, not having to download hundreds of kilobytes of JavaScript is a game changer.

Miles: It really is. And the modern approach in 2026—especially with frameworks like Next.js 15—is to use Server Components by default. You only switch a component to a "Client Component" if it needs interactivity—like an `onClick` handler—or if it needs to use browser APIs like local storage. It’s about being "server-first" to keep things lean.

Lena: So if I’m building something more than just a simple todo list—let’s say a full-scale dashboard for a company—how do I organize all these components and rendering strategies so I don’t lose my mind?

Miles: This is where "System Design" comes into play. You can’t just throw everything into a "components" folder and hope for the best. In 2026, we’ve moved away from the old "Atomic Design" where everything was an atom, molecule, or organism. It just didn't scale well with React. Instead, most senior engineers are using "Feature-Sliced Design" or "Domain-Driven Components."

Lena: Domain-Driven? So instead of grouping by "type"—like all buttons together—you group by "purpose"—like everything related to "Authentication" or "ProductCatalog"?

Miles: You’ve got it. Each feature becomes a "vertical slice." Inside an "Authentication" folder, you’ll have the UI components, the state logic, the API calls, and even the tests—all together. This is called "co-location." It reduces the "cognitive overhead." When you’re working on the login screen, you don’t have to jump between five different top-level folders. Everything you need is right there in that slice.

Lena: I can see how that would make a huge difference in a big team. If I’m the "Auth" developer, I’m not stepping on the toes of the "Checkout" developer. But what about the stuff that *is* shared? Like a standard brand button?

Miles: Those go into a "Shared" or "Design System" layer. These are your primitives. In 2026, we use "Compound Components" for these. Think of how `<select>` and `<option>` work in HTML. They’re separate tags, but they work together. We build React components the same way. Libraries like Radix UI have popularized this. It gives the developer using the component a lot of flexibility without making the component code itself a mess of a hundred different props.

Lena: It’s like providing a set of specialized tools instead of one "Swiss Army Knife" component that tries to do everything but is impossible to maintain.

Miles: Exactly. And there’s one more layer that’s non-negotiable now: the "Infrastructure Layer." This is where you decide your bundling strategy and deployment topology. Are you deploying to the Edge? Are you using Node.js? In 2026, you can actually deploy individual routes to the Edge for lower latency. If a route is stateless and sensitive to speed, send it to the Edge. If it needs a heavy database connection, keep it in Node.

Lena: It sounds like building a React app today is almost like being a city planner. You have to think about the zones, the traffic flow of data, and where the "power plants" or servers are located.

Miles: It really is! And the best teams start by writing a "one-page architecture decision record." Before they write a single component, they decide: "What’s our rendering strategy? How are we handling state? How are we organizing folders?" Taking 30 minutes to decide that upfront saves you 30 days of refactoring later when the app inevitably grows.

Lena: That’s a great piece of advice. It’s so tempting to just start coding, but having that blueprint—that intentional architecture—is what keeps the project from collapsing under its own weight as you add more features.

Lena: We’ve touched on performance a bit, but I want to dive deeper. I think a lot of people think of performance as something you "fix" at the end—like adding a coat of paint. But you’re saying it’s actually part of the foundation?

Miles: Oh, absolutely. In modern React, you can’t "bolt on" performance at the end. It has to be baked into how you structure the app. One of the biggest shifts we’ve seen in 2026 is the "React Compiler." It’s finally stable, and it’s a total game changer. It automatically handles "memoization"—which is just a way of telling React, "Hey, don’t re-calculate this unless the data actually changed."

Lena: So we don’t have to manually wrap everything in `useMemo` or `useCallback` anymore? I remember those being a huge source of confusion for beginners.

Miles: Mostly, no! The compiler is smart enough to do it for us. Manual memoization is actually starting to be seen as a bit of a "code smell" unless you’re doing something really niche. Instead, our optimization energy is shifting toward "render boundaries" and "Suspense coordination."

Lena: "Suspense coordination"—that sounds like conducting an orchestra. What does that actually look like in practice?

Miles: It’s about managing how your page "pops in." Imagine a page with a header, a sidebar, and a main content area. If the header loads in 100ms, the sidebar in 500ms, and the content in 2 seconds, the page can feel very "janky" as things jump around. With Suspense, you can wrap those different sections and define "loading states"—like skeletons—so the transition feels smooth. React 19.2 actually patched some visual inconsistencies here, making sure that multiple boundaries resolving at the same time "reveal" together rather than one-by-one.

Lena: So it’s less about making the code "faster" and more about making the *experience* feel better for the human using it.

Miles: Exactly. It’s "perceived performance." Another huge tool is "HTML Streaming." Instead of the server waiting for every single piece of data to be ready before sending *any* HTML, it sends the "shell" immediately. The browser can start rendering the header and the layout while the server is still fetching the "slow" data for the main content. Once that data is ready, the server "streams" the rest of the HTML into the same connection.

Lena: That’s wild. So the user sees the page layout almost instantly, and then the content just... fills in?

Miles: Yes! And when you combine that with "Selective Hydration," it’s even cooler. If the user clicks a button in the sidebar while the main content is still loading, React will prioritize "hydrating" or making that sidebar interactive first. It basically says, "Oh, the user is over here! Let’s make this part work right now." It’s an intelligent way of managing the browser’s limited resources.

Lena: I can see why the architecture matters so much then. If you’ve split your app into small, focused components, React can be much smarter about how it loads them. If you’ve built one giant "god component," it’s all or nothing.

Miles: You’ve hit on the most important rule: "Code splitting is your friend." Every route in your app should be a split point. If a user is visiting the "Settings" page, they shouldn't have to download the code for the "Dashboard" or the "Profile" editor. In 2026, most frameworks do this automatically, but as a developer, you still have to be careful about not importing huge libraries into your global "layout" file, or else they’ll be part of the bundle for every single page.

Lena: We’ve talked a lot about the web, but one of the biggest selling points of React has always been "learn once, write anywhere." Does all this component and state logic really carry over to mobile apps?

Miles: It does, and it’s honestly one of the coolest parts of the ecosystem. React Native takes the same philosophy—components, props, state, hooks—and applies it to iOS and Android. But here’s the key difference: instead of rendering to a browser’s DOM with `<div>` and `<span>`, it renders to *native* UI elements.

Lena: So a "View" in React Native becomes a "UIView" on iOS and an "android.view" on Android?

Miles: Exactly. It’s not a web view—it’s not just a website inside an app shell. It’s truly native. This means you get the performance and "feel" of a native app, but you get to use the React skills you already have. You’re still using `useState` for your counter and `useEffect` for your data fetching. The mental model is identical.

Lena: That sounds like a huge business advantage. You can have one team—or at least a team using the same language—building for the web, iPhone, and Android.

Miles: It’s a massive efficiency gain. Many companies use a "monorepo" architecture now, where they have a shared "packages" folder for all their business logic and types, and then separate "apps" for Web and Mobile. They might share 80% of their code—the stuff that handles data and state—and only write the UI layer specifically for the platform.

Lena: Are there any pitfalls though? I mean, a phone screen is very different from a 27-inch monitor.

Miles: For sure. Navigation is the biggest one. On the web, you have URLs and the "back" button in the browser. In a mobile app, you have stacks, tabs, and drawers. You have to use a library like "React Navigation" to handle that. And you have to think about "touch" differently than "clicks." Phones have gestures, swipes, and long-presses. But even there, React’s declarative nature makes it much easier to manage. You just describe the state of the app, and React Native handles the transition between screens.

Lena: It’s also interesting to see how the "Server Components" world is starting to touch mobile too. I’ve seen some early experiments where you can stream UI updates to a mobile app without having to go through an App Store update.

Miles: That’s the "holy grail" right there! Being able to fix a layout bug or update a promotional banner instantly across all devices. We’re not quite there for everything, but the gap between web and mobile development is shrinking every year. If you can build a solid React web app, you are already 75% of the way to being a mobile developer.

Lena: That’s so encouraging. It really justifies the time spent learning these core concepts. You’re not just learning a "web tool"—you’re learning a system for building any kind of interface, on any device.

Miles: And that’s why React has stayed at the top for so long. It’s flexible enough to adapt to these new platforms and rendering strategies without forcing you to throw away everything you’ve learned. The "component" is the universal language of modern software design.

Lena: We’ve covered a ton of ground, Miles. If someone is listening to this and wants to start building a modern, production-grade React app *today*, what’s the stepwise plan? What are the non-negotiables?

Miles: Okay, let’s break it down into a playbook. Step one: Choose a framework that supports the modern rendering spectrum. In 2026, that almost always means Next.js 15 or Remix v3. Don’t start with a plain "Vite" setup unless you’re building a very simple, internal-only dashboard. You want the power of Server Components and Streaming from day one.

Lena: Step two: Set up your folder structure for the long term. Don’t do a "type-based" structure where all your hooks are in one giant folder and all your components in another.

Miles: Right. Use a "Feature-Based" or "Domain-Driven" approach. Create a "features" folder, and inside it, give each business concept—like "billing" or "inventory"—its own home. This keeps your code modular. If you ever need to delete a feature, you just delete one folder. You don’t have to hunt for its ghost across ten different directories.

Lena: And step three: Be intentional about your state.

Miles: This is huge. Use the "Four-State Model." For server data, use TanStack Query. For global UI state, use Zustand. For forms, use a library like React Hook Form. And most importantly, keep as much state as possible in the URL using your router. If it’s not in one of those buckets, only then put it in a local `useState`.

Lena: What about the UI? We mentioned "Compound Components" and "Design Systems."

Miles: Step four: Don’t reinvent the wheel. Use a headless UI library like Radix UI or shadcn/ui. These give you accessible, battle-tested "primitives"—like dropdowns and dialogs—that you can style yourself. It saves you weeks of work handling things like keyboard navigation and screen readers, which are incredibly hard to get right from scratch.

Lena: And step five: Performance as an architectural choice. Use the React Compiler—which should be on by default in 2026—but also be diligent about "Suspense" boundaries. Wrap your slow data-fetching components in `<Suspense>` with a clear fallback skeleton. This ensures your app feels fast even when the network is slow.

Miles: And the final, "bonus" step: Write an Architecture Decision Record. It sounds formal, but it’s just a simple document that says, "We chose Zustand for state because X" or "We’re using Edge rendering for the landing page because Y." It keeps the team aligned and prevents those "why did we do it this way?" arguments six months down the line.

Lena: It’s really about moving from "coding" to "engineering." It’s about being deliberate. I think a lot of people are afraid of the complexity, but these tools—if used correctly—actually make your life easier by giving you a clear path forward.

Miles: Exactly. The complexity is there to solve real problems that appear when apps get big. For a beginner, the "Playbook" is: start small, use the defaults of a modern framework, and slowly adopt these patterns as you feel the "pain" they are designed to solve. Don’t try to do everything at once, but know that these tools are in your toolkit when you need them.

Lena: Before we wrap up, I want to talk about the "scary" stuff—the mistakes people make that end up costing them weeks of refactoring. What’s the number one thing you see developers get wrong in 2026?

Miles: Without a doubt, it’s the "Server-Client Boundary." With the new Server Components model, it’s so easy to accidentally "leak" client logic into a server component or vice versa. For example, if you try to use `window.localStorage` in a Server Component, your app will crash because the server has no idea what a "window" is. You have to be very strict about where you put that `'use client'` directive.

Lena: It’s like a border crossing. You have to have your "passport" ready. Is there a tool that helps with that?

Miles: Yes! Use TypeScript. In 2026, TypeScript is no longer optional for professional React development. It catches these boundary issues at "compile time"—meaning as you’re typing—rather than letting them crash your app in production. It’s your safety net.

Lena: Another pitfall I’ve heard about is "over-fetching" or "waterfalls."

Miles: Oh, the "waterfall" is a classic. That’s when Component A fetches data, and only *after* it’s done, Component B starts fetching its data. It leads to this slow "staircase" of loading states. To fix this, you want to "parallelize" your fetches. In the modern App Router, you can just fire off all your server promises at once and then `await` them all together. It can literally cut your page load time in half.

Lena: That makes sense. And what about "hydration mismatches"? I’ve seen those weird errors in the console where the browser says the HTML doesn't match what the server sent.

Miles: Those can be a nightmare to debug. They usually happen when you use something that changes between the server and the browser—like `new Date()` or a random number. If the server says "It’s 10:00 AM" and by the time it reaches the browser it’s "10:01 AM," React will freak out and re-render the whole page from scratch. In 2026, React 19.1 actually improved the error messages for this, giving you a detailed "diff" so you can see exactly what mismatched. The fix is usually to move that dynamic logic into a `useEffect` so it only runs on the client.

Lena: It’s interesting how many of these "pitfalls" are just about understanding the lifecycle of a request. Once you realize there’s a "Server phase" and a "Client phase," the errors start making a lot more sense.

Miles: Totally. And the final pitfall: "Premature Optimization." Don’t spend days trying to shave 5 milliseconds off a component render if your main problem is a slow database query. Use the React DevTools "Profiler" to see where the *actual* bottlenecks are. Most of the time, the real wins are in how you fetch data and how you manage your "Suspense" boundaries, not in micro-optimizing a single loop.

Lena: So, focus on the big architectural wins first. Get the structure right, get the data flow right, and then—if you still have a performance issue—start looking at the small stuff.

Miles: Precisely. Build a "boring" foundation so you can be creative where it actually matters—on the features that your users love.

Lena: As we bring this to a close, I’m struck by how much React has evolved. It started as this controversial way to build UIs, and now it’s this incredibly sophisticated, full-stack ecosystem.

Miles: It really is a testament to the community. We’ve gone from just "rendering some HTML" to managing complex streaming pipelines and native mobile apps. But at its heart, it’s still about that one simple idea: the component. If you can understand how to break a problem down into small, manageable pieces, you can build anything.

Lena: I love that. It’s an empowering way to think about software. It’s not about being a genius who can hold a million lines of code in their head. It’s about being an architect who can organize simple bricks into something beautiful and functional.

Miles: Exactly. So for everyone listening, I’d encourage you to take one thing from today—maybe it’s the "Four-State Model" or the idea of "Feature-Slices"—and try to apply it to your next project. Don’t worry about mastering every hook or every rendering strategy on day one. Just focus on building clean, independent components.

Lena: And remember, the 2026 ecosystem is there to support you. Between the compiler, the new hydration debugging tools, and the power of Server Components, it’s never been a better time to be a React developer. The tools are getting smarter so we can focus on the "why" instead of just the "how."

Miles: That’s a perfect place to end. Whether you’re building the next big social platform or just a simple tool for yourself, the principles stay the same. Stay curious, keep building, and don't be afraid to break things down into smaller pieces.

Lena: Thanks for joining us for this deep dive into the world of React. It’s been a blast exploring these concepts with you.

Miles: Absolutely. It’s a fascinating world, and we’ve only scratched the surface. To our listeners—take a moment to reflect on your own projects. Are there "god components" you can break down? Is there state you can move to the URL? The best way to learn is to do. Thank you for listening!