New Architecture is here
React Native’s new architecture prompts mixed reactions from mobile developers weighing cross‑platform tradeoffs against native solutions like SwiftUI, Jetpack Compose, and Kotlin Multiplatform. Many praise the maturing React Native + Expo ecosystem, improved performance (especially with the bridge removal), and faster upgrades, while others report persistent Android performance issues, dependency breakage, and difficult debugging compared to fully native or Flutter-based stacks. A recurring theme is that React Native remains attractive for small teams and CRUD-style apps needing shared code across web and mobile, but may be less compelling for highly polished, performance‑critical or deeply native experiences.
Expo vs Bare React Native
- Several commenters ask whether RN is usable without Expo and complain about past native dependency pain.
- Others say bare RN has been fine for years due to autolinking; native deps “just work” with
yarn add+ CocoaPods. - Expo supporters argue config plugins, prebuilds, and Expo Application Services largely solve native integration and upgrade pain.
- Critics dislike potential SaaS lock‑in and limits around custom native modules, especially for advanced media/VoIP; others counter that custom native code is possible with modern Expo, just not via Expo Go.
New Architecture & Performance
- A contributor to the blog post explains the new architecture replaces the JS bridge with direct JS→C++ calls, removing serialization/queues.
- The UI tree is now a single immutable C++ tree shared across platforms, enabling thread‑safe layout and addressing issues like flicker, not just raw speed.
- Linked benchmarks are mentioned, but no Flutter comparison data is provided.
- One user benchmarks a simple list: new RN still slower than web React for 2,000 views on Android, despite the new arch.
Cross‑Platform vs Native (Flutter, Kotlin, Compose, etc.)
- Some argue RN and Flutter were crucial historically but modern SwiftUI/Compose and Kotlin Multiplatform make pure native (or Kotlin‑centric) a better long‑term bet.
- Others report strong results with RN or Flutter and see them as the most practical way to target many platforms with one team.
- Common theme: cross‑platform works well for CRUD/simple apps; high‑end or highly native‑integrated apps may still benefit from fully native implementations.
RN vs Web / PWAs / Other Stacks
- Debate over whether web apps should replace native entirely.
- Some see modern web APIs and PWAs as sufficient; others emphasize performance, accessibility, and distribution limitations vs native.
- Capacitor and similar webview‑based solutions are described as viable for simple apps but often clunky and less performant than RN for complex ones.
Developer Experience, Bugs, and Fragmentation
- Reports of RN being “finally pretty good,” especially with Expo, but with recurring issues on Android, device‑specific bugs, and fragile upgrades.
- React‑Native‑Web and future React‑Strict‑DOM are seen as key to better web/native code sharing, though current RN‑web parity is lacking.
- Fragmentation across RN‑web/windows/macos is noted; some wish for clearer signaling of RN support in libraries.
Meta: Quality of HN Discussion
- Multiple comments lament that much of the thread veers into generic framework wars and negativity instead of the specifics of the new architecture.
- Others push back, arguing differing opinions, even contrarian ones, are valuable and that downvotes and “karma” dynamics distort participation.