The Dark Side of React

Front-end frameworks help developers build the structure, design, and behavior of websites and apps. React is technically a library for building user interfaces, usually combined with other tools to handle routing, data fetching, and deployment. Together, these tools form the application stack.

React remains an established choice, with a large ecosystem of developers, components, and integrations. Its reusable components can help organizations build consistent digital experiences. But choosing React does not automatically deliver a fast, accessible, secure, or easy-to-maintain website.

So, what challenges should you consider, and how can you address them?

No Automatic Success in a Shifting Landscape

Building with React increasingly means choosing a framework around it. The React team recommends starting new applications with a framework, such as Next.js or React Router. These provide integrated approaches to routing, data loading, and rendering. Create React App has been deprecated; a build tool such as Vite remains an option when you need a custom setup.

React itself continues to evolve. React 19.3 brings stable View Transitions for interface animations, while React Compiler can automate parts of rendering optimization. These developments offer useful capabilities, but your team still needs to decide which features serve the project and how they fit the existing stack.

Performance Takes More Than Choosing React

React does not guarantee good UX, quick loading, or responsive interactions. Large JavaScript bundles, slow data requests, unnecessary rendering, and third-party scripts can still overwhelm a user's device. Rendering on the server can improve the first load, but interactive components may still require JavaScript to download and run in the browser.

Start by delivering essential content early. Split code so users download features when they need them, optimize images and fonts, and avoid chains of data requests that wait unnecessarily for one another. Measure real-user performance alongside controlled tests, using Core Web Vitals: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability.

The stable React Compiler can reduce unnecessary component rendering through automatic memoization. For an existing application, adopt it incrementally and verify the results. It can help with rendering efficiency, while network requests, bundle size, and overall application design still need attention.

Moving Work to the Server Brings New Trade-offs

Server-side rendering produces HTML before it reaches the browser. Hydration then connects that HTML to the JavaScript needed for interactivity. React Server Components provide another way to divide the work: their component code runs at build time or on a server and is not shipped to the browser. Interactive Client Components handle browser-side features such as expanding menus and updating local state.

This can reduce browser workload, but introduces decisions about server capacity, caching, data access, and the boundary between server and client code. Choose a rendering strategy for each part of the experience: static generation for suitable public content, request-time rendering when needed, and client-side rendering for browser-driven interactions. Server Components require a framework or toolchain that supports them.

For a CMS-driven website, define how publishing refreshes cached pages and how editors preview drafts. Keep draft content and personalized responses out of shared public caches. Otherwise, a fast website can serve outdated content or expose information to the wrong audience.

Just a Tool, Not a Unicorn

React can help implement an interface, but users still need clear navigation, understandable content, accessible controls, and useful feedback when something loads or fails. Semantic HTML, keyboard access, focus management, and screen-reader testing remain essential. New animation features should support these goals and respect users' reduced-motion preferences.

Your developers also need a shared understanding of state, Hooks, Effects, and server/client boundaries. Invest in conventions, documentation, and tests for critical user journeys. React's stable releases follow semantic versioning, but major upgrades and changes in surrounding frameworks or dependencies still require planning. Follow the release guidance for the complete stack you use.

Avoid Unnecessary Dependence on One Ecosystem

Standardizing on React can make collaboration and component reuse easier. However, adopting framework-specific routing, caching, data access, and hosting services can make future changes more expensive. Assess those dependencies alongside the benefits they provide.

Keep content and business rules accessible through clear APIs, isolate integrations that depend on a particular provider, and favor maintained components built on web standards. React can work with ordinary JavaScript libraries and browser APIs; you do not need a React-specific package for every problem. A smaller, well-understood stack is often easier to maintain.

Security Extends Across the Stack

Third-party packages bring maintenance responsibilities. As with extensions for platforms such as WordPress, assess who maintains the dependencies you introduce and how updates reach production. React's architecture is different, but the need to manage third-party code remains.

Security also involves React's server-side features. The React team disclosed a critical Server Components vulnerability in December 2025, followed by further advisories updated in January 2026. These concerned affected RSC packages and their framework integrations. Check the official guidance against your deployed stack and apply the relevant patched releases.

Maintain a dependency inventory and lockfile, monitor advisories, and make security updates part of routine maintenance. Treat Server Functions as public-facing endpoints: validate inputs and check authentication and authorization on the server. Sanitize untrusted HTML from content sources, and keep credentials and privileged CMS access tokens in server-side code. React 19.3's Trusted Types support can complement a Content Security Policy and sanitization policies to help prevent DOM-based cross-site scripting.

See also: Why go headless with a hybrid CMS?

How to Solve SEO Problems

React is not inherently bad for SEO. Google can render JavaScript, but rendering failures and inaccessible resources can prevent it from seeing content. Other crawlers may have more limited capabilities. For important public pages, delivering meaningful HTML through static generation or server-side rendering reduces reliance on crawler-side JavaScript execution.

Rendering is only part of the solution. Provide crawlable links, descriptive titles, appropriate metadata, canonical URLs, and correct HTTP status codes. Add relevant structured data and sitemaps, and verify that important content appears in the rendered page. Use Search Console to investigate indexing problems, following Google's JavaScript SEO guidance.

For organizations using Enonic, React4XP supports rendering React components on the server and hydrating them in the browser. A separate Next.js front end can use Next.XP to connect with Enonic, including editor preview and cache revalidation. Choose the approach that fits your architecture and editorial workflow.

Think About How You're Building Your App

Start with the experience you need to deliver, then choose the tools and rendering strategy that support it. Before committing to a React stack, agree on:

• Rendering and content: Which pages need static HTML, request-time rendering, or browser-side interactivity—and how publishing refreshes them.
• Performance and accessibility: Which user journeys, devices, and measurable targets you will use to evaluate the experience.
• Security and maintenance: Who owns dependency updates, access controls, monitoring, and framework upgrades.
• Editorial workflow: How content teams will preview, localize, and publish without unnecessary developer involvement.

Make ownership explicit before launch, and review performance, accessibility, security updates, and content freshness throughout the website's life.

First published 21 April 2021, updated 30 September 2026.