React at Scale today: The Architecture, Performance, Security, and Team Habits Behind Serious Frontend Apps

[0:00]Hamadou: Welcome back to the React stack podcast. This is episode two, and today we are staying with React, but we are changing the angle. In episode one, we opened the React stack and talked about modern React as a whole: components, React 19, Server Components, Actions, performance, accessibility, and the way React now sits inside full application architecture.

[0:42]Hamadou: Today, we are going deeper into a question that almost every frontend team eventually faces: what happens when React stops being a nice set of components and becomes a real product system? What changes when there are multiple developers, multiple routes, multiple data sources, multiple releases, security patches, accessibility expectations, performance complaints, design reviews, product experiments, and real users who do not care how elegant the component tree looks?

[1:35]Hamadou: React is easy to start. That is part of its success. You can create a component, pass props, use state, render a list, submit a form, and build something that feels alive very quickly. But the same thing that makes React friendly at the beginning can hide the harder questions. Where should data live? Which code belongs on the server? Which code belongs in the browser? Which state should be in the URL? Which interactions need optimistic feedback? Which components deserve to become part of the design system? Which dependencies are worth trusting?

[2:32]Hamadou: Those questions do not show up clearly on day one. They show up when the app grows. They show up when two teams build the same dropdown differently. They show up when a form breaks for screen reader users. They show up when a route ships too much JavaScript. They show up when a security advisory lands and nobody knows which package version is in production. They show up when a release causes hydration warnings, slow route transitions, or a crash that only happens for one type of customer account.

[3:30]Hamadou: So today, we are looking at React at scale. Not scale only in the sense of millions of users, although that matters. Scale also means codebase scale, team scale, design scale, dependency scale, and operational scale. To help us break that down, I am joined by Daniel Reyes, principal frontend engineer at LayerNorth Digital. Daniel has worked on large React applications, design systems, migration projects, framework decisions, and production frontend reliability. Daniel, welcome.

[4:05]Daniel Reyes: Thanks for having me. I like this topic because React has two personalities. The first personality is very approachable. You write a component and see something on the screen. The second personality appears later, when the product grows and React becomes the place where design, data, performance, accessibility, security, and business logic all meet. That second personality is where teams need more discipline.

[4:55]Hamadou: That is a strong way to put it. React is where everything meets.

[5:00]Daniel Reyes: Exactly. A React app is rarely just visual. It reflects product decisions. It reflects backend API design. It reflects design system maturity. It reflects whether the company cares about accessibility. It reflects release discipline. It reflects performance culture. If the organization is messy, the React app often becomes the visible layer of that mess.

[5:52]Hamadou: So when people say, “Our React app is hard to maintain,” the problem may not only be React.

[5:58]Daniel Reyes: Usually it is not only React. React can be misused, of course. But a painful React app often means the team never agreed on boundaries. They did not agree on state ownership. They did not agree on data-fetching patterns. They did not agree on component APIs. They did not agree on testing expectations. They did not agree on what belongs in the design system. So every feature becomes a local decision, and after a year the app feels like several small apps glued together.

[6:45]Hamadou: That is probably one of the most common frontend problems: local decisions becoming global debt.

[6:52]Daniel Reyes: Yes. And React makes local decisions easy. That is good when you need speed. But if nobody turns repeated local decisions into shared patterns, you get drift. One team uses one form pattern. Another team uses another. One route stores filters in memory. Another stores them in the URL. One modal handles focus correctly. Another traps users. One table is accessible. Another table is just divs pretending to be a table. Users feel the inconsistency before engineers admit it.

[7:00]Hamadou: Let us begin with components. Everyone knows React is component-based. But at scale, what does component thinking really mean?

[7:15]Daniel Reyes: At scale, component thinking means designing boundaries. A component is not just a file that returns JSX. A component is a contract. It says: give me these inputs, I will render this behavior, I will handle these responsibilities, and I will not secretly depend on things I should not know about. Good components make the rest of the application simpler. Bad components make the rest of the application negotiate with them.

[8:05]Hamadou: What does it look like when components are negotiating with the app?

[8:10]Daniel Reyes: You see props that only exist because of one screen. You see boolean flags like isSpecialMode, isCheckoutMode, isAdminButNotReallyAdminMode. You see components importing global state directly even though they are supposed to be reusable. You see visual components making API calls without the caller knowing. You see components that claim to be generic but contain product-specific language. That is a sign the component boundary is unclear.

[9:05]Hamadou: So a reusable component should not become a hiding place for unrelated product rules.

[9:12]Daniel Reyes: Right. A reusable component should reduce repeated effort. It should not become a dumping ground. For example, a Button component should know about variants, sizes, disabled states, loading states, focus styles, and accessibility basics. It should not know that the enterprise billing screen has a strange exception for one customer plan. That logic belongs outside, closer to the product flow.

[10:05]Hamadou: Where do container and presentational ideas fit today? That language is older, but the problem still exists.

[10:15]Daniel Reyes: The exact terminology is less important than the separation. Some components are mostly about data and orchestration. Some are mostly about display and interaction. Some sit in the middle. The mistake is mixing everything everywhere. If every component fetches data, formats data, handles permissions, manages layout, owns state, and renders styling, then every component is hard to reuse and hard to test.

[11:08]Hamadou: So scaling React means being honest about responsibility.

[11:12]Daniel Reyes: Yes. Responsibility is the word. The more responsibility a component has, the more careful you need to be about where it lives and who depends on it.

[11:30]Hamadou: Let us move into React 19. When you look at React 19 from a large-application point of view, what matters most?

[11:42]Daniel Reyes: The biggest shift is that React is giving teams better tools for async user interfaces. Actions, useActionState, useOptimistic, better form patterns, metadata, resource loading, and Server Components all point in the same direction. React is not only saying, “Here is how you render state.” It is saying, “Here is how you manage transitions between states when the network, server, browser, and user are all involved.”

[12:45]Hamadou: That is where real interfaces are hard. Not the perfect state, but the transition.

[12:52]Daniel Reyes: Exactly. A static mockup shows the happy state. A real React app has pending state, empty state, loading state, error state, retry state, optimistic state, stale state, unauthorized state, and sometimes partially successful state. The user may submit a form twice, lose connection, navigate away, come back, or have permissions changed while the page is open. Modern React is trying to give us cleaner primitives for those messy human situations.

[13:50]Hamadou: How should teams adopt those features without turning every new feature into a rewrite?

[13:58]Daniel Reyes: Start with pressure points. Do not rewrite the whole app because React has new APIs. Find the places where the current model is painful. Forms with scattered loading and error logic are good candidates. Mutations that need optimistic feedback are good candidates. Routes that ship too much client JavaScript may be candidates for server-aware architecture. Pages with messy metadata or resource loading may benefit from newer patterns. Adoption should solve real pain.

[14:55]Hamadou: That is practical. New APIs should pay rent.

[15:00]Daniel Reyes: Yes. Every abstraction should pay rent. If a new pattern makes the code harder to explain, harder to test, and only slightly more modern, that is not progress. But if it removes custom loading code, makes forms more reliable, reduces client JavaScript, or clarifies server boundaries, then it is worth considering.

[15:55]Hamadou: There is also a training issue. A team may have React 19 in package.json but still write React like it is 2019.

[16:00]Daniel Reyes: That happens all the time. Version upgrades do not automatically upgrade mental models. If developers do not understand the difference between server state and local state, React 19 will not save them. If they do not understand why an optimistic update can mislead users, useOptimistic will not save them. If they do not understand server-client boundaries, Server Components will confuse them. The runtime can improve, but the team still needs shared understanding.

[16:00]Hamadou: Let us talk about Server Components. At a high level, what should teams understand before using them seriously?

[16:15]Daniel Reyes: They should understand that Server Components change where some React code runs. A Server Component can render before bundling, in a server environment, and it does not need to ship its JavaScript to the browser. That can be very powerful. You can keep heavy logic and server-only dependencies off the client. You can fetch data closer to the backend. You can reduce browser work. But you are also introducing a server-client boundary that the team has to respect.

[17:25]Hamadou: What does respecting the boundary mean in day-to-day code?

[17:32]Daniel Reyes: It means knowing which components can use browser APIs and which cannot. It means knowing where event handlers live. It means not passing sensitive data to Client Components by accident. It means understanding that server-only code should stay server-only. It means treating serialization as a real boundary. It also means designing your component tree so that interactive islands are intentional rather than accidental.

[18:35]Hamadou: Interactive islands is a useful phrase.

[18:40]Daniel Reyes: Think of a product page. The title, long description, specifications, seller information, related items, and review summary may be mostly server-rendered. The image carousel, quantity selector, add-to-cart button, wishlist button, and chat widget are interactive. You do not need the whole page to be a giant client-side application. You need the interactive parts to be interactive and the informational parts to be efficient.

[19:40]Hamadou: So Server Components are not about hating the client.

[19:45]Daniel Reyes: Not at all. The browser is still where the user lives. The point is not to remove client JavaScript completely. The point is to stop shipping JavaScript for things that do not need JavaScript. That is a very different mindset. Good React architecture is not server versus client. It is asking which runtime is responsible for which job.

[20:40]Hamadou: Where do teams misuse Server Components?

[20:45]Daniel Reyes: Some teams try to use them everywhere and make simple interactions feel awkward. Other teams avoid them completely and keep shipping huge client bundles because that is familiar. The better approach is to identify server-friendly UI: data-heavy, non-interactive, sensitive, or expensive pieces. Then keep client components focused on actual interaction. You also need framework support, because Server Components are not something most teams should wire together manually.

[21:00]Hamadou: Now Actions and forms. Forms are probably the place where React 19 feels most directly useful to product teams. Why?

[21:15]Daniel Reyes: Because forms are where async UI becomes impossible to ignore. A form is not just input fields and a submit button. It is validation, pending state, server response, field errors, global errors, disabled states, retry behavior, success feedback, focus management, and sometimes optimistic updates. Actions give React a cleaner way to connect a user action to an async transition.

[22:12]Hamadou: What does useActionState change in practice?

[22:18]Daniel Reyes: It helps you model the result of an action as state. Instead of scattering submit logic across several pieces of local state, the action can receive previous state and form data, then return the next state. That makes the form flow easier to reason about. You can express: here is the form before submission, here is what happens while it is pending, here is the server response, here are the field errors, and here is the success state.

[23:15]Hamadou: And useOptimistic?

[23:20]Daniel Reyes: useOptimistic lets the UI show a likely future before the server confirms it. That is great for interactions where immediate feedback matters and the risk is low. Adding a comment, liking an item, reordering a list, marking a task complete. The UI feels faster because the user does not stare at a spinner for every small action.

[24:10]Hamadou: But optimistic UI can also become dishonest.

[24:15]Daniel Reyes: Yes. This is where engineering and product ethics meet. An optimistic update should not make a promise the system has not kept. If a user sends money, changes permissions, deletes records, submits legal information, or performs something irreversible, you need careful language and confirmation. The difference between “Saving…” and “Saved” matters. The UI should feel fast, but it should not lie.

[25:10]Hamadou: That is a recurring theme in modern React: technical state becomes human communication.

[25:18]Daniel Reyes: Exactly. Loading, pending, disabled, retrying, saved, failed, partial, stale. Those are not just variables. They are messages to the user. A mature React app treats those states as part of the product design, not as afterthoughts.

[25:50]Hamadou: What is the biggest form mistake you still see?

[25:55]Daniel Reyes: Throwing away user input after failure. It is brutal. Someone fills out a long form, one server-side validation fails, and the app wipes everything. That is not only a technical bug. That is a trust failure. Good React forms preserve input, identify the problem, focus or announce errors when appropriate, and help the user recover.

[26:00]Hamadou: Let us move into frameworks. React itself is a library, but in serious applications, teams usually choose a framework or build a framework-shaped architecture. How do you approach that decision?

[26:18]Daniel Reyes: I start with product requirements. Does this app need search visibility? Does it need server rendering? Does it need Server Components? Does it need mostly authenticated dashboard experiences? Does it need edge deployment? Does it need offline behavior? Does it need file-system routing? Does it need tight backend integration? The wrong way to choose is by vibes. The right way is by constraints.

[27:15]Hamadou: So a full-stack React framework is not automatically better.

[27:20]Daniel Reyes: Correct. A full-stack framework can be excellent if you need its integrated answers: routing, rendering, data loading, Server Components, server functions, caching, deployment conventions. But it also adds concepts the team must understand. Caching behavior, server-client boundaries, framework upgrades, route conventions, bundling behavior, and deployment platform details. Power always comes with learning cost.

[28:20]Hamadou: When is a simpler client-heavy React app enough?

[28:25]Daniel Reyes: Internal dashboards, authenticated tools, admin panels, prototypes, embedded widgets, highly interactive workspaces, and apps where SEO is not important may not need a heavy server-rendered architecture. A Vite-based React app with a strong routing and data strategy can be completely reasonable. The mistake is not choosing simple. The mistake is choosing simple while pretending you will never need routing discipline, data caching, error handling, or deployment structure.

[29:25]Hamadou: So even a simple stack needs architecture.

[29:30]Daniel Reyes: Yes. Avoiding a framework does not avoid architecture. It just means you own more of the decisions yourself. That can be good for experienced teams. It can also be dangerous for teams that do not realize they are building their own framework one helper function at a time.

[30:20]Hamadou: What are signs that a React app has outgrown its original architecture?

[30:28]Daniel Reyes: Repeated custom data-fetching logic, inconsistent error states, duplicated layouts, route transitions that feel slow, no standard mutation pattern, components that only work in one part of the app, too much global state, fragile tests, and onboarding that depends on tribal knowledge. Another sign is fear. If developers are afraid to touch shared components or upgrade dependencies, the architecture is no longer serving the team.

[31:00]Hamadou: State management. This is still one of the loudest topics in React. How should teams think about it today?

[31:12]Daniel Reyes: They should stop asking one giant question called “What state library should we use?” and start asking smaller questions. What kind of state is this? Is it local UI state? Server state? URL state? Form state? Global application state? Derived state? Cached state? Temporary state? The type of state should guide the tool.

[32:10]Hamadou: Give us examples.

[32:15]Daniel Reyes: A modal open flag is local UI state. A list of products from an API is server state. A search query, selected tab, or page number may belong in the URL. A checkout form has form state. Theme or authenticated user display information may be global application state. If you put all of those into one global store, the app may work, but it becomes harder to reason about ownership.

[33:12]Hamadou: Why is global state so tempting?

[33:18]Daniel Reyes: Because it solves immediate friction. You avoid passing props. Any component can reach the data. Early on, that feels productive. But later, everything can affect everything. A small change triggers unexpected rerenders. Tests need large providers. Developers cannot tell where data came from or who is allowed to update it. Global state should exist, but it should be intentional.

[34:15]Hamadou: What is your default rule?

[34:20]Daniel Reyes: Keep state close to where it is used until there is a real reason to move it. Put navigation state in the URL when users expect refresh, back button, bookmarks, or sharing to preserve it. Use a server-state tool or framework data layer for remote data. Use form tools for complex forms. Reach for global state only when the state is truly cross-cutting.

[35:18]Hamadou: What about derived state?

[35:22]Daniel Reyes: Derived state is a classic bug source. If something can be calculated from props or existing state, do not store it separately unless there is a strong reason. Every duplicate source of truth creates synchronization problems. React apps become much easier to reason about when there is one owner for each piece of truth.

[36:00]Hamadou: Design systems. At scale, React and design systems almost become inseparable. Why?

[36:12]Daniel Reyes: Because React makes it easy to reuse UI, and design systems give that reuse meaning. Without a design system, teams copy buttons, inputs, dialogs, tables, and cards across the app. They make tiny changes. They forget accessibility details. They create visual drift. A design system turns repeated UI into shared infrastructure.

[37:05]Hamadou: Shared infrastructure is a stronger phrase than component library.

[37:12]Daniel Reyes: It is more accurate. A design system is not just a folder of components. It includes design tokens, spacing rules, typography, color, motion, accessibility behavior, usage guidelines, content patterns, error states, loading states, and sometimes analytics expectations. It is the operating system for the product interface.

[38:10]Hamadou: Where do design systems go wrong?

[38:15]Daniel Reyes: They go wrong when they become either a museum or a dictatorship. A museum design system has beautiful documentation but nobody uses it because it does not solve current product needs. A dictatorship design system blocks every exception and slows teams down. A healthy design system has strong defaults, good accessibility, clear APIs, and escape hatches that are reviewed instead of forbidden.

[39:10]Hamadou: Accessibility is part of this, but it deserves its own focus. What do React teams still underestimate?

[39:20]Daniel Reyes: They underestimate how easy it is to break native behavior. A real button gives you keyboard behavior, focus behavior, semantics, disabled behavior, and screen reader expectations. A div with an onClick handler gives you almost none of that unless you rebuild it. React lets you create anything, which means it also lets you create inaccessible things very quickly.

[40:15]Hamadou: What should be non-negotiable?

[40:20]Daniel Reyes: Semantic HTML first. Keyboard navigation. Visible focus. Labeled form controls. Error messages that are clear and connected to fields. Dialogs that manage focus properly. Color contrast. Reduced motion support. No critical information conveyed only by color. Automated accessibility tests as a baseline, plus human testing because automation does not catch everything.

[41:00]Hamadou: Performance. React performance discussions often become very technical very quickly. Memoization, rerenders, hydration, bundles, streaming, caching. Where should teams start?

[41:15]Daniel Reyes: Start with the user journey. What does the user need to see first? What do they need to do first? What blocks them? What feels slow? Then measure. Do not start by sprinkling useMemo everywhere. A component rerender may not matter at all if the real problem is a large JavaScript bundle, slow server response, blocking font, unoptimized image, or network waterfall.

[42:10]Hamadou: So render performance is only one part of frontend performance.

[42:15]Daniel Reyes: Exactly. React render cost matters, but users experience the whole page. They experience download time, parse time, hydration, layout shifts, images, fonts, API calls, route transitions, and interaction delay. A team can over-optimize a small component and still ship a slow app.

[43:05]Hamadou: What does a performance budget look like for React?

[43:12]Daniel Reyes: It can include JavaScript size per route, maximum image weight, route transition targets, interaction responsiveness, hydration time, number of critical requests, and real user metrics. The important part is that the budget is visible before production pain arrives. If performance is only discussed after users complain, the team is already late.

[44:05]Hamadou: How do Server Components affect performance?

[44:10]Daniel Reyes: They can reduce client JavaScript by keeping non-interactive components off the browser bundle. They can also fetch data closer to the source and simplify some client loading patterns. But they are not magic. You can still create slow server responses, bad caching, unnecessary waterfalls, or confusing boundaries. Server Components are a tool for performance, not a guarantee of performance.

[45:05]Hamadou: What about resource loading?

[45:10]Daniel Reyes: Resource loading is about helping the browser prepare. Preconnect, preload, preinit, and related patterns can reduce waiting when used well. But like all performance tools, they can be overused. Preloading everything is not strategy. The point is to prioritize the resources that matter for the next meaningful user experience.

[45:48]Hamadou: And hydration?

[45:52]Daniel Reyes: Hydration is where server-rendered markup becomes interactive. If you ship a huge interactive tree, hydration can be expensive. Teams should ask whether every part of the page needs to hydrate. Server Components, islands of interactivity, code splitting, and careful component boundaries can help. But again, measurement matters. Guessing is not performance engineering.

[46:00]Hamadou: Testing and observability. What should React teams test?

[46:12]Daniel Reyes: They should test behavior that matters to users and the business. Can the user sign in? Can they submit the form? Can they recover from an error? Can they navigate with the keyboard? Does the cart update correctly? Does the permissions UI hide or disable the right actions? Does the app handle slow network responses? Good tests care less about internal implementation and more about observable behavior.

[47:10]Hamadou: Where do component tests fit?

[47:15]Daniel Reyes: Component tests are great for reusable UI and focused behavior. They can confirm that a dialog opens and closes correctly, an input shows errors, a menu supports keyboard navigation, or a table renders empty and loading states. But critical product journeys need integration or end-to-end coverage too. A checkout flow cannot be trusted only because the Button component has tests.

[48:08]Hamadou: What about production observability for React?

[48:15]Daniel Reyes: It is essential now. You need client-side error reporting, source maps managed safely, release version tags, route context, user action breadcrumbs where appropriate, performance metrics, failed network request tracking, hydration warnings, and feature flag context. When a frontend incident happens, you need to know which release caused it, which users saw it, and whether it is still happening.

[49:12]Hamadou: That sounds a lot like backend operations.

[49:18]Daniel Reyes: It is. Frontend reliability is product reliability. If the backend is healthy but the React app crashes on the billing page, the user still cannot pay. If a route transition fails only for users with a certain permission set, the system is down for those users. React apps need operational visibility.

[50:00]Hamadou: Security. React developers sometimes assume security is mostly a backend problem. Why is that dangerous now?

[50:12]Daniel Reyes: Because modern React often crosses server and client concerns. Server Components, server functions, framework loaders, actions, serialized props, authentication state, third-party scripts, markdown rendering, analytics, and dependency chains all create security questions. React helps with safe text rendering by default, but that does not make the whole application safe.

[51:05]Hamadou: The React Server Components security advisory in late 2025 made that very real.

[51:12]Daniel Reyes: Yes. The big lesson is that frontend frameworks with server capability are part of the security perimeter. If a critical advisory drops, teams need to know whether they are affected, which packages are deployed, which framework versions include vulnerable integrations, and how quickly they can patch and redeploy. Security response is not only a backend team job anymore.

[52:05]Hamadou: What are practical security habits for React teams?

[52:12]Daniel Reyes: Keep React, framework, and server-component packages patched. Review dependencies. Avoid unsafe HTML unless content is trusted and sanitized. Do not send secrets or unnecessary sensitive data to Client Components. Treat server action responses as public unless you are sure otherwise. Use authorization on the server, not only in the UI. Monitor advisories. Make emergency patching boring instead of heroic.

[53:00]Hamadou: AI-assisted development. React is one of the areas where AI can generate a lot of code quickly. Helpful or dangerous?

[53:10]Daniel Reyes: Both. AI is helpful for drafts: components, tests, Storybook stories, migration notes, accessibility checklists, refactoring suggestions, and explanations of unfamiliar code. But it is dangerous when teams accept generated React without understanding architecture. AI may put state in the wrong place, ignore accessibility, add unnecessary dependencies, leak server data to the client, or generate code that works in a demo but fails in the product.

[53:58]Hamadou: So the rule is: AI can accelerate React work, but it cannot own React work.

[54:05]Daniel Reyes: Exactly. Engineers still own correctness, accessibility, performance, security, maintainability, and the user experience. AI can suggest. The team decides.

[54:30]Hamadou: Let us close with a checklist. A React team is building or modernizing a serious app today. What should they do?

[54:38]Daniel Reyes: First, choose architecture from product needs, not hype. Second, define component boundaries and shared patterns early. Third, classify state before choosing state tools. Fourth, use React 19 features where they solve real async UI problems. Fifth, understand Server Components as a server-client boundary, not magic.

[54:50]Daniel Reyes: Sixth, build forms that preserve user trust. Seventh, invest in a design system with accessibility built in. Eighth, measure performance from the user journey, not only from render counts. Ninth, test behavior and critical flows. Tenth, add frontend observability so production issues are visible.

[54:58]Daniel Reyes: And finally, treat security and dependency updates as normal React work. Modern React is not just components. It is architecture, operations, and user trust.

[55:00]Hamadou: Daniel Reyes, thanks for joining us. End.