LiveView vs React — Which Delivers Better Performance for Dynamic Lists?
LiveView vs React — Which Delivers Better Performance for Dynamic Lists?
By Louise Blanc, Emilia Hårdén & Matilda Källström Final Thesis for Chas Academy – Fullstack Open Source 2025
The Question We Wanted to Answer
Modern web applications are becoming increasingly data-driven. Whether building an analytics dashboard, a booking platform, or a social feed, developers face a recurring challenge: how to render large dynamic lists efficiently, without compromising speed or user experience.
To explore this, we compared two popular but fundamentally different technologies: Phoenix LiveView and React.
React is a client-driven JavaScript library that manages updates through a virtual DOM. Phoenix LiveView, powered by Elixir, takes a server-driven approach, rendering updates via WebSockets.
Both are capable of high performance, but they achieve it in different ways. We wanted to find out which one performs better in practice and how the developer experience differs when building real-world, data-intensive applications.
Why LiveView vs React?
Comparing React and LiveView may seem like comparing apples and oranges: one is a frontend library, the other a full-stack framework. But many development teams face this exact decision when choosing an architecture.
React is a much more used framework, it offers fine-grained control over the client, a massive ecosystem, and unparalleled flexibility. Developers can leverage the virtual DOM's diff algorithm to minimize re-renders, creating highly interactive experiences directly in the browser.
LiveView challenges that model by simplifying the stack. Instead of shipping large bundles of JavaScript, it handles interactivity from the server, transmitting minimal diffs over persistent WebSocket connections. This approach eliminates the need for separate API layers, reduces context switching between frontend and backend, and keeps the client lightweight.
Under the hood, LiveView benefits from the BEAM virtual machine, the same technology that powers Erlang's legendary concurrency and fault-tolerance. The BEAM's lightweight process model enables handling thousands, even millions, of concurrent connections on minimal hardware. This makes it particularly effective for real-time, multi-user systems where traditional architectures would require substantial infrastructure.
Our objective was not to find a single winner but to analyze the trade-offs in rendering speed, scalability, developer workflow, and long-term sustainability.
The Setup — Building the Same Feature Twice
We implemented the same feature twice: a hotel room list within a booking platform. Both applications fetched identical data from a PostgreSQL database, first with 10 items, then with 1000, and rendered them on screen.
The database schema consisted of two tables: hotels and hotel_rooms, connected through a one-to-many relationship. To ensure consistent testing conditions, we used seed files to populate the database with mock data in JSON format, matching the schema structure exactly.
We then used Chrome DevTools and Google Lighthouse to measure rendering time, visual stability, and user-centric performance metrics. All tests were conducted locally without caching to ensure fair comparison.
Tech Stack Overview
React
LiveView
Both implementations displayed the same user interface: a simple scrollable list of rooms with identical visual presentation.
Understanding the Technical Differences
React's Client-Driven Approach
React performs all rendering in the browser using its virtual DOM. When state changes occur, React's reconciliation algorithm calculates the minimal set of changes needed and efficiently updates only the affected DOM nodes. This approach excels at micro-interactions and provides immediate client-side responsiveness.
However, this comes with trade-offs:
LiveView's Server-Driven Model
LiveView generates HTML on the server and sends only the differences to the client through a WebSocket connection. The mount/3 function runs twice during the lifecycle: first during the initial HTTP request for static rendering, then again when the WebSocket connection establishes for interactivity.
This dual-phase mounting introduces a small initial delay but provides significant advantages:
The trade-off is that all interactivity depends on the server connection, making it less suitable for offline-first applications.
How We Measured Performance
We measured both technical performance and perceived responsiveness using multiple metrics:
Core Web Vitals
All tests were repeated three times, and median values were used to eliminate anomalies. Using the median rather than the mean reduces the impact of outliers caused by network fluctuations or system processes.
The Results
Small List (10 Items)
Rendering Performance:
Lighthouse Scores:
Both handled small datasets efficiently, but LiveView achieved a significantly higher Lighthouse score thanks to superior layout stability and minimal layout shifts.
Detailed Metrics (10 items):
React showed faster initial content display, but LiveView's near-perfect layout stability (CLS of 0.002) demonstrated its rendering consistency.
Large List (1000 Items)
Rendering Performance:
Lighthouse Scores:
React maintained faster raw rendering time for larger datasets, but the user experience told a different story. While React's page felt choppy during the 1000-item load, LiveView provided smooth scrolling despite the longer initial render time.
Detailed Metrics (1000 items):
The most striking finding was LiveView's perfect visual stability (CLS 0.000) with large datasets, while React showed noticeable layout shifts. LiveView also achieved a better LCP, meaning users saw the main content faster despite the longer total render time.
Developer Experience: Code, Context, and Cohesion
Performance results are only part of the story. How it feels to develop with each framework can be just as important—and significantly impacts long-term project success.
Recommended by LinkedIn
The React Development Journey
With React, we constantly switched between backend and frontend contexts:
This multi-layered architecture allows flexibility but adds substantial cognitive overhead. Each feature requires coordination across multiple systems and languages. The project requires managing Node.js, npm, TypeScript, build tools like Vite, and potentially additional libraries for state management and data fetching.
The LiveView Development Experience
LiveView offered a dramatically different experience. Everything, state management, rendering, data access, and routing, exists in one unified Elixir codebase.
We could:
We could focus on core logic without worrying about API endpoints, authentication tokens, or frontend frameworks. The development process felt more cohesive and less fragmented.
A practical example: When we needed to implement multi-tenancy with schema prefixes, we created simple migration functions that worked seamlessly with both database operations and LiveView rendering. In React, this would have required coordinating changes across API endpoints, authentication middleware, and frontend state management.
The Learning Curve
However, LiveView is not without challenges. The initial learning curve is steeper, particularly for those new to:
The mount/3 function's dual execution (HTTP then WebSocket) can be confusing initially and introduces a measurable delay. Understanding when and how to optimize this requires deeper knowledge of the framework.
Yet, once the fundamentals clicked, writing real-time features without JavaScript felt efficient and liberating. The constraint of working within a single paradigm actually simplified decision-making, there were fewer ways to structure code, which paradoxically made development faster.
Key Insights
1. Server-Driven Rendering Can Be Fast
We initially assumed that LiveView's server dependency would make it slower. Instead, Elixir's concurrency model and lightweight processes kept it remarkably responsive, even under heavy data loads. The BEAM VM's ability to handle millions of concurrent processes meant that serving WebSocket connections added minimal overhead.
2. Raw Speed vs. Perceived Performance
React rendered 1000 items faster (88ms vs 528ms), but the experience felt choppier with noticeable layout shifts (CLS 0.123). LiveView's slower initial render still provided a smoother experience with perfect layout stability (CLS 0.000). This highlights an important lesson: raw metrics don't always align with user experience.
3. React Excels at Micro-Interactions
For highly interactive applications, drag-and-drop interfaces, in-browser editing, complex animations, offline functionality, React remains the most effective solution due to its direct access to the browser and DOM. The client-side control enables instantaneous feedback without server round-trips.
4. Developer Experience Shapes Productivity
React projects often require managing multiple dependencies, frameworks, and toolchains across the full stack. LiveView projects feel simpler, you build both frontend and backend in the same environment, which saves time and reduces errors.
The context switching cost is real. Working in React meant constantly translating between JavaScript/TypeScript on the frontend and Elixir on the backend, each with different patterns, idioms, and error handling approaches. LiveView minimized this switching, allowing us to stay focused and productive.
5. Infrastructure Efficiency and Sustainability
Elixir's BEAM VM is not only fast but energy-efficient. It can manage thousands of concurrent connections using minimal hardware. Real-world examples demonstrate this dramatically:
This efficiency has real sustainability implications. Fewer servers mean lower energy consumption, reduced cooling requirements, and smaller data center footprints, making technology choices like Elixir increasingly relevant as organizations prioritize environmental responsibility.
Architectural Considerations
When React Makes Sense
Choose React when your application needs:
When LiveView Makes Sense
Choose LiveView when your project involves:
The unified codebase advantage becomes more pronounced as team size increases, fewer opportunities for miscommunication between frontend and backend developers.
Broader Reflections
This project changed how we think about modern web architecture.
React's client-driven approach offers power and flexibility, particularly for complex SPAs that demand frequent updates and offline capabilities. It enables specialists to optimize every aspect of the user experience. The ecosystem maturity means solutions exist for virtually any problem.
LiveView takes a more integrated path, merging backend and frontend logic into a single real-time system. It's ideal for data dashboards, admin panels, and systems where live updates and simplicity outweigh offline needs. It empowers generalists to build full-featured applications without mastering multiple paradigms.
For small teams or fast-moving startups, this simplicity can be transformative. LiveView reduces dependencies, improves maintainability, and makes the development process more predictable. The learning curve pays dividends in long-term velocity.
Both approaches have proven themselves at scale, React powers Facebook, Instagram, and countless major platforms, while LiveView enables companies like Adobe, Financial Times, and Bleacher Report to handle millions of users efficiently.
Limitations and Future Work
Our study focused specifically on list rendering performance in controlled conditions. Several areas deserve further investigation:
Scope Limitations
Optimization Opportunities
We didn't implement advanced optimizations that could significantly improve results:
Future research should explore these optimizations to understand each framework's true potential when fully tuned.
Tooling Considerations
While Chrome DevTools and Lighthouse provided valuable insights, framework-specific tools like React Developer Tools and Phoenix Telemetry offer deeper analysis. Time constraints prevented their inclusion, but future comparative studies would benefit from leveraging these specialized instruments.
Conclusion
React remains an excellent choice for interactive, client-heavy applications where fine-grained control and offline functionality matter. Its ecosystem maturity and community support make it a safe, well-understood option.
LiveView, however, proves that server-driven rendering can be not only viable but competitive. It simplifies architecture, improves developer productivity, and delivers smooth real-time experiences with minimal JavaScript. The perfect layout stability (CLS 0.000) we measured with 1000 items demonstrates its capability to handle complex UI updates gracefully.
The infrastructure efficiency gains, demonstrated by Pinterest's 95% server reduction and BBC's successful migration, show that this isn't just about developer preference. There are real economic and environmental benefits to choosing technologies that use resources efficiently.
If your project involves real-time dashboards, collaborative interfaces, or administrative tools, LiveView deserves serious consideration. If your application needs complex client-side interactivity or offline functionality, React is still the stronger choice.
Ultimately, the decision is not about which is faster, but about which fits your team's workflow, expertise, and long-term goals.
Technology choices shape how teams think and work. React empowers specialists who want maximum control over every aspect of the client experience. LiveView empowers generalists who value simplicity and unified codebases. Both push the web forward, just from opposite directions.
The future of web development likely isn't about choosing one paradigm over another, but understanding when each approach serves your users best.
For the complete technical implementation details, code examples, and full methodology, see our thesis: "LiveView vs React: En prestandajämförelse vid listladdning" Ask and we can send the pdf.
Cool but yea not suprised Phoenix Liveview Performs badly if not using streams. Would have been interesting to see optimized React code vs optimixed Phoenix code.
Thank you for sharing
Great work! Interesting read. 😊