Почему Flutter использует Dart, а не Kotlin или JavaScript

Flutter — открытый UI-фреймворк Google для мобильных, веб- и десктопных приложений из одной кодовой базы. Но чаще всего разработчиков и заказчиков удивляет не сам фреймворк, а выбор языка: почему для него не взяли готовый Kotlin — родной язык Android, — или JavaScript — самый массовый язык веб-разработки, — а создали собственный Dart? Ответ не в маркетинге и не в случайности: в 2015 году, когда стартовала разработка Flutter, ни Kotlin, ни JavaScript физически не могли одновременно дать AOT-компиляцию в нативный код на нескольких платформах и мгновенный Hot Reload при разработке.

Сравнить Flutter, React Native, KMP и натив под свой проект с учётом RuStore и российских SDK можно бесплатно: выбор мобильного стека.

В этой статье разбираем техническую сторону решения: как устроена компиляция Dart, почему у Kotlin и JavaScript нет прямого аналога, какие у Dart реальные недостатки и стоит ли закладываться на него в 2026 году. Если вы выбираете стек для мобильного проекта под ключ — это пригодится и как бриф для разработки приложения на Flutter.

Как Google выбирал язык для Flutter

Dart появился ещё в 2011 году — изначально как попытка Google предложить альтернативу JavaScript в браузере. Тогда идея не взлетела: браузеры так и не добавили нативную поддержку Dart-рантайма, а язык остался нишевым. Но у Google уже был готовый инструмент — зрелая VM с одновременной поддержкой JIT- и AOT-компиляции, компилятор в JavaScript (dart2js) и опытная команда языковых инженеров.

Когда в 2015 году внутри Google стартовала разработка Flutter (тогда — под кодовым именем Sky), команде нужен был язык, который одновременно компилируется в нативный машинный код на iOS и Android без интерпретатора в продакшне, поддерживает быстрый цикл разработки с сохранением состояния приложения и не тянет за собой отдельный рантайм — как V8 для JavaScript — внутрь каждого приложения. Kotlin на тот момент был ещё молодым языком: Kotlin/Native, единственный путь к нативной компиляции без JVM, появился только в 2017 году, на два года позже старта Flutter, и до сих пор уступает по зрелости тулчейну JVM. Dart, наоборот, уже умел всё нужное — оставалось адаптировать компилятор под мобильные платформы.

AOT и JIT: как Dart компилируется в два разных бинарника

Компилятор Dart поддерживает два режима из одного тулчейна — и в этом ключевое отличие от конкурентов.

JIT (Just-In-Time) работает во время разработки. Dart VM компилирует код «на лету», прямо в запущенном процессе, и Flutter использует это для Hot Reload — обновления кода без перезапуска приложения и без потери состояния экрана.

AOT (Ahead-Of-Time) применяется для релизной сборки. Весь Dart-код заранее компилируется в нативный машинный код ARM или x64 — без интерпретатора и без JIT-прогрева в рантайме, то есть без просадки первых секунд после запуска, характерной для JIT-языков.

У Kotlin и JavaScript такой связки нет — у каждого свой компромисс:

Hot Reload и модель изолятов: почему это не просто «перезапуск»

У Dart нет потоков с общей памятью — вместо них язык использует изоляты: независимые единицы выполнения с собственной кучей памяти, которые обмениваются данными только через сообщения, без блокировок и гонок за ресурсы. Именно эта модель делает Hot Reload безопасным: новый код внедряется прямо в работающий изолят, а не пересобирает процесс с нуля.

У Kotlin такой механики нет — JVM-класслоадер должен провалидировать байт-код заново, поэтому Apply Changes в Android Studio работает только для точечных правок метода и часто требует полного перезапуска Activity при изменении структуры кода (новое поле, новый класс). Так что Kotlin не подходит Flutter не потому, что он «хуже», а потому, что его модель выполнения — JVM/ART с общей памятью — для этого не проектировалась.

Dart vs JavaScript: почему не React Native или Ionic

JavaScript — самый массовый язык веб-разработки, и на нём построены целые кроссплатформенные экосистемы вроде React Native и Ionic. Но у этого подхода есть структурное ограничение: JS выполняется в собственном движке (V8 или JavaScriptCore), а не напрямую в нативном UI-потоке. Чтобы отрисовать интерфейс, вызовы проходят через «мост» (bridge) — слой сериализации между JS-потоком и нативным рендерингом.

На практике это лишние миллисекунды на каждый вызов моста и риск просадки ниже 60 fps при сложных анимациях или длинных списках — именно то, с чем регулярно борются команды на React Native. Dart, скомпилированный в нативный код и рисующий интерфейс собственным движком рендеринга (Skia/Impeller) без моста к системному UI, физически не упирается в эту проблему: 60 или 120 кадров в секунду держатся стабильно даже при активных анимациях.

Интеграция с экосистемой Google

Ещё один фактор — интеграция с экосистемой Google. Приложения на Flutter из коробки лучше стыкуются с Firebase, Google Cloud Platform и другими сервисами компании: меньше конфигурации, больше готовых пакетов и официальной поддержки.

Google активно развивает и Dart, и Flutter: обширная документация, регулярные релизы, большая команда языковых инженеров и открытая экосистема пакетов на pub.dev. Для команд, которые уже работают в инфраструктуре Google, это снижает трение при разработке и поддержке.

Null safety и синтаксис Dart: удобство без потери контроля

Dart спроектирован так, чтобы быть знакомым разработчикам с опытом в Java, Kotlin или C#: классы, дженерики, async/await, современный объектно-ориентированный синтаксис без лишнего шаблонного кода.

Ключевая особенность — sound null safety. Компилятор Dart статически гарантирует, что переменная не-nullable типа никогда не будет null, и это проверяется на этапе компиляции, а не падает исключением в рантайме:

String? nickname;               // nullable — может быть null
String greet(String name) =>    // non-nullable — компилятор гарантирует значение
    'Привет, $name!';

У JavaScript такой гарантии в принципе нет — динамическая типизация допускает undefined и null где угодно, а TypeScript добавляет проверку только поверх, на уровне сборки, а не рантайма. У Kotlin null safety тоже есть, но она не единственная причина выбора: Kotlin не даёт остальных преимуществ Dart — единого AOT-тулчейна и модели изолятов.

Какие недостатки у Dart?

У Dart есть и реальные минусы, которые стоит учитывать при выборе стека:

• Меньше специалистов на рынке. Dart-разработчиков объективно меньше, чем Kotlin- или JavaScript-программистов — это стоит закладывать в сроки найма. При этом переход с Java/Kotlin на Dart занимает у опытного разработчика 1–2 недели, а не месяцы.
• Экосистема пакетов меньше, чем npm. На pub.dev в 2026 году больше 35 000 пакетов — заметно меньше, чем в npm, хотя для мобильной разработки покрытие уже достаточное.
• Native-интеграции всё равно требуют Kotlin/Swift. Специфичные SDK, Bluetooth или биометрия на Android подключаются через Platform Channel на Kotlin — Dart не отменяет необходимость нативного кода для редких кейсов.
• Размер бинарника обычно больше. В APK или IPA зашит не только код приложения, но и движок рендеринга Flutter (Skia/Impeller), поэтому релизная сборка обычно тяжелее чистого нативного приложения.

Не устареет ли Dart? Будущее языка в 2026 году

Нет — язык активно развивается. Dart 3.x (2023–2026) добавил records, паттерн-матчинг и sealed classes — современные конструкции языка, которых не хватало в ранних версиях. Отдельное направление — компиляция в WebAssembly: dart2wasm постепенно заменяет dart2js для Flutter Web и даёт заметный прирост производительности на вебе.

Экосистема тоже растёт: pub.dev в 2026 году насчитывает более 35 000 пакетов, а Google продолжает вкладываться в язык и движок рендеринга — переход с Skia на Impeller уже завершён на большинстве платформ. Для новых проектов на горизонте 3–5 лет Dart остаётся таким же безопасным выбором, как Kotlin или Swift для своих платформ.

Выбор языка программирования для платформы вроде Flutter — это не вкусовщина, а инженерный компромисс между производительностью, скоростью разработки и стратегией компании. Dart даёт Google то, что не могли дать готовые Kotlin или JavaScript: один тулчейн с AOT- и JIT-компиляцией, модель изолятов под безопасный Hot Reload и полный контроль над языком, движком рендеринга и SDK одновременно. У Kotlin и JavaScript есть свои сильные стороны — прежде всего размер комьюнити и нативная интеграция с платформой, — но для кроссплатформенной разработки именно связка Dart и Flutter в 2026 году остаётся наиболее сбалансированным решением.

Частые вопросы (FAQ)