Flutter чи React Native: чому ми обрали Flutter

Порівняння, яке ніхто не пише чесно

Більшість статей «Flutter проти React Native» пише той, хто випускав щось на одному з них. Ми випустили вісім продуктів на Flutter — пʼять ігор, два застосунки, одну платформу — тож сприймайте це як упереджене джерело, яке принаймні намагається показати свої аргументи, включно з тими, що працюють проти нас.

Рішення звелося до чотирьох речей, і для більшості проєктів ми ухвалили б його знову. Але не для всіх.

Рендеринг: причина, через яку вибір не є близьким

Flutter малює кожен піксель сам, власним рушієм — Impeller на сучасних iOS та Android. React Native відображає ваші компоненти в нативні віджети платформи й координує їх через межу.

Ця архітектурна різниця вирішує, що буде легко. У Flutter екран із паралаксом, перетягуванням, ефектами часток і синхронізованим звуком працює однаково на обох платформах, бо нічого не транслюється. У React Native це теж можна зробити і роблять — але крива зусиль тим крутіша, чим далі ви від стандартних компонентів, і платформи розходяться в процесі.

Для наших головоломок це було вирішальним. Для бізнес-застосунку з формами й списками це значно менш важливо, і хто каже інакше — щось продає.

Dart: нудна мова в найкращому сенсі

Dart не є захопливою мовою, і в цьому, як виявилось, суть. Вона строго типізована з надійним null safety і компілюється наперед у нативний ARM. На практиці:

• Помилки спливають на компіляції, а не у вигляді звіту про збій від користувача.
• Продуктивність передбачувана — жодних пауз рушія JavaScript, жодної серіалізації через міст, про яку треба думати.
• Одна мова покриває iOS, Android, веб і десктоп, тож виправлення пишеться один раз.

Ціна в тому, що Dart майже ніде більше не використовується. JavaScript-команда буде продуктивна в React Native наступного тижня; тій самій команді потрібен реальний розгін під Dart.

Екосистема: менша, але краще доглянута

npm більший. Це не те саме, що краще обслуговуваний. Ключові бібліотеки Flutter зрілі й активно підтримуються, а стандартний набір достатньо малий, щоб більшість команд сходились на ньому — і відповідь, яку ви знайдете на форумі, зазвичай стосується саме вашої конфігурації.

Для наших застосунків ми використовуємо:

• Bloc разом із get_it і freezed — передбачуваний стан і згенеровані незмінні моделі. Riverpod там, де граф менший і церемонії не варті того: на ньому працює Qivvo.
• Drift і Hive — типізовані локальні бази, що працюють офлайн і шифруються на диску.
• go_router — декларативна навігація, яка переживає діплінки й холодний старт.

Розрив проявляється на краях: у нішевого нативного SDK радше буде офіційна обгортка під React Native, ніж під Flutter, і platform channel доведеться писати самому.

Найм, який ніхто не рахує як слід

Розробників React Native більше, ніж Flutter, і це справжній аргумент. Він також менш вирішальний, ніж звучить, бо альтернатива, з якою компанії насправді порівнюють, — це дві нативні команди. Одна Flutter-команда дешевша і цілісніша за них із великим відривом.

Де ми не обрали б Flutter

• Продукт, глибоко привʼязаний до платформи. Доступ до заліза, складна фонова робота, віджети й застосунки для годинника. Більшість коду лишиться нативною; Flutter додає міст, а не прибирає його.
• Наявна React Native команда й кодова база. Якість фреймворку рідко перемагає інституційні знання. Міграцію має виправдовувати біль, а не вподобання — і зазвичай не виправдовує.
• Одна домінуюча платформа. Якщо 95% доходу з iOS, кросплатформність забирає нативну ергономіку й дає мало.
• Крихітний короткоживучий застосунок. Для того, що існуватиме одну кампанію, виграє те, що команда вже вміє.

Висновок, у який ми справді віримо

Flutter виграє, коли потрібні одна команда, обидві платформи й контроль над кожним пікселем. React Native виграє, коли у вас JavaScript-організація і звичайний інтерфейс. Натив виграє, коли платформа і є продуктом.

Ми обрали Flutter, бо наші власні продукти візуальні, кросплатформні й робляться однією невеликою командою. Це опис нашої ситуації, а не універсальний рейтинг — і будь-яка студія, що дає вам ту саму відповідь, не вислухавши вашу ситуацію, описує свій штат, а не ваш проєкт.