Мобильный разработчик Droids On Roids сравнил два кроссплатформенных фреймворка, Kotlin и Flutter, и рассказал, для каких проектов каждый из них подходит. 

Я, Flutter Tech Lead в Friflex Юра Петров, перевел эту статью и предлагаю сообществу обсудить особенности фреймворков.

Сравниваем

Совсем недавно Flutter называли лучшим фреймворком для разработки кроссплатформенных приложений. Позже появился Kotlin Multiplatform (KMP). Он привлек к себе много внимания и стал серьезным конкурентом Flutter.

Стоит ли теперь отказываться от проектов на Flutter? Вовсе нет! Flutter по-прежнему занимает сильные позиции. У обеих технологий есть свои плюсы и минусы. И выбирать фреймворк нужно под конкретный проект. 

Однако в этом выборе легко запутаться. Мы здесь, чтобы помочь вам понять, какая технология лучше подходит для проекта с учетом ваших ресурсов и задач.

Kotlin Multiplatform и Flutter — относительно новые инструменты кроссплатформенной разработки. К своей задаче они подходят по-разному.

Flutter использует собственный инструмент рендеринга пользовательского интерфейса, чтобы создать все, что пользователь видит на экране. Этот инструмент называется «движок Flutter». Фреймворк сам рисует все элементы и гарантирует, что приложение будет выглядеть и работать одинаково на любом устройстве и платформе.

Kotlin Multiplatform использует встроенные инструменты каждой платформы, iOS или Android, чтобы создавать визуальные элементы. Такой подход позволяет приложению выглядеть и работать нативно на каждой платформе в соответствии с ее требованиями. 

KMP расширяет нативные приложения, а Flutter — их заменяет. Многие не знают, но обе технологии, с точки зрения кода, нативные. 

Предлагаем сравнить основные функции фреймворков.

Функция

Flutter

Kotlin Multiplatform

Язык программирования

Dart

Kotlin

Инструментарий UI

Богатая библиотека виджетов, которые можно настраивать.

Для Android — нативный UI в Jetpack Compose. Для iOS — Views в SwiftUI или UIKit.

Совместное использование кода

Единая кодовая база для iOS и Android.

Совместное использование реализации логики, платформенный код для UI.

Движок рендеринга

Собственный 

Нативный 

Горячая перезагрузка

Есть

Нет

Производительность

Высокая производительность с нативным ощущением, быстрое время запуска приложений, плавная анимация.

Производительность близка к нативной, благодаря нативным возможностям и API.

Скорость разработки

Быстрая разработка с единой реализацией UI и функцией горячей перезагрузки.

Медленная разработка из-за необходимости реализации UI отдельно для каждой платформы. 

Платформенные особенности

Доступ через Platform Channels.

Прямой доступ без промежуточных слоев.

Поддержка сообщества

Быстрорастущее сообщество с поддержкой на платформах GitHub и Stack Overflow.

Постепенно растущее сообщество, официальная поддержка Google.

Сценарии использования

Благодаря единой кодовой базе подходит для приложений, которые нужно быстро разработать и запустить. Подходит для разработки MVP.

Подходит для проектов, в которых нужна нативная производительность и платформенные особенности. Отлично подходит для миграции развитых проектов.

Известные приложения 

Google Ads, Alibaba, Hamilton, myBMW, Philips Hue.

Netflix, McDonald’s, Forbes, 9GAG, Bolt, Google Docs.

В таблице представлены ключевые различия, которые важно учитывать, когда вы выбираете между Flutter и Kotlin Multiplatform. Окончательный выбор зависит от целей проекта и возможностей команды.

Смотрим на детали

Давайте поговорим про каждую технологию отдельно.

Что такое Flutter? 

Это открытый фреймворк для разработки пользовательских интерфейсов, который компания Google представила на конференции Google I/O в декабре 2018 года.

С помощью Flutter разработчики могут создавать нативно компилируемые приложения из единой кодой базы для разных платформ: iOS, Android, Windows, macOS, Linux, Google Fuchsia. А также на Flutter можно разрабатывать веб-приложения и интерфейсы для встроенных устройств.

Flutter использует язык программирования Dart, который известен своей эффективностью и производительностью.

Преимущества Flutter

  • Единая кодовая база. С Flutter вы пишете код один раз и запускаете его на нескольких платформах. Фреймворк сокращает время и требует меньше ресурсов для разработки.

  • Горячая перезагрузка. Изменения в коде отображаются мгновенно. Разработчику не нужно перезапускать приложение. Разработка становится быстрее и эффективнее.

  • Богатый набор виджетов. Flutter предлагает большую библиотеку виджетов, которые можно настраивать, чтобы создавать визуально привлекательные и отзывчивые интерфейсы.

  • Производительность. Компиляция Dart и нативный код обеспечивают производительность не хуже, чем у нативных приложений. 

  • Открытый исходный код и поддержка сообщества. Существует большое и активное сообщество разработчиков Flutter, члены которого постоянно публикуют новые плагины и пакеты. А также помогают с поддержкой и релизами. 

  • Доступ к нативным функциям. Интегрировать функции, специфичные под конкретное устройство, легко. Плагины Flutter дают доступ к нативным функциям и API устройств.

Недостатки Flutter

  • Размер приложения. Приложения на Flutter, как правило, большие по размеру. Им нужно больше места и времени для загрузки по сравнению с нативными. Вместе с приложением загружается движок Flutter, который добавляет к общему весу приложения 3-4 МБ.

  • Проблемы с производительностью. Производительность Flutter сильно выросла с первого релиза, но она все еще уступает нативной. Дело в промежуточном слое, который необходим для взаимодействия с нативными функциями. 

  • Ограниченный доступ к нативным функциям. Flutter сильно зависит от сторонних плагинов, которые дают доступ к нативным возможностям мобильных устройств. Сейчас у разработчиков в доступе большой выбор эффективных плагинов. Но их все равно не хватает, особенно для сложных  функций. 

  • Ограниченный доступ к последним системным функциям. Нативные приложения получают мгновенный доступ к новым функциям Android и iOS. Продукты на Flutter — с задержкой. А иногда и вовсе не получают, потому что для поддержки новых функций нужны обновления.

  • Особенности языка Dart. По сравнению с другими языками программирования Dart используется реже. Сообщество разработчиков на Dart меньше, но оно растет вместе с ростом популярности языка. 

Необходимость переписывать уже существующее нативное приложение. Чтобы перейти на Flutter, готовое нативное приложение придется полностью переписать.

Что такое Kotlin Multiplatform?

Чтобы понять, что такое Kotlin Multiplatform, нужно познакомиться с языком программирования Kotlin, который разработала компания JetBrains.

Сейчас Kotlin ассоциируется с платформой Android, но его создавали как универсальный язык, который может эффективно взаимодействовать с другими языками и использоваться для кроссплатформенной разработки.

Kotlin Multiplatform (KMP) — это набор инструментов, который упрощает и организует работу с языком Kotlin на нескольких платформах одновременно, Android, iOS, веб.  А также его можно использовать для настольных и серверных приложений.

Большую часть кода можно реализовать один раз на Kotlin и использовать повторно в нативных приложениях. Разработка полнофункциональных нативных приложений становится быстрее.

Преимущества Kotlin Multiplatform

  • Высокая производительность. У нативных приложений на KMP производительность не уступает эффективности и скорости аналогов.

  • Полный доступ к платформенным API и библиотекам. Можно использовать любые нативные технологии и комбинировать их с Kotlin Multiplatform. Это особенно удобно для разработки приложений на нативных решениях, например, AR.

  • Общая кодовая база. Можно написать общий код для разных платформ и сэкономить ресурсы.

  • Простая миграция. Готовое нативное приложение на KMP разработчики могут переносить постепенно. Им не нужно переписывать все приложение. Такой подход позволяет вносить изменения, но не трогать при этом пользовательский интерфейс.

  • Нативный UI. С KMP разработчики могут реализовывать платформенный UI. В этом им помогают фреймворки SwiftUI и Jetpack Compose.

  • Нативный дизайн. В приложении можно настроить внешний вид и поведение, которые будут соответствовать рекомендациям платформы. Приложение будет выглядеть, как нативное. 

  • Доступ ко всем функциям Kotlin. Разработчики могут использовать все возможности Kotlin, в том числе строгую типизацию, защиту от null-значений и корутины.

  • Растущая экосистема. Сообщество KMP развивается, растет поддержка библиотек. 

Недостатки Kotlin Multiplatform

  • Библиотеки находятся на ранней стадии развития. В архитектуре и тестировании у KMP пока нет такого количества программных библиотек, как у Flutter.

  • Ограниченные онлайн-ресурсы. У разработчиком на KMP меньше ресурсов (документации, учебных материалов) по сравнению с более устоявшимися инструментами. Разработчикам сложнее найти нужную информацию и поддержку. Ситуация может улучшиться с ростом экосистемы KMP. По мере того, как инструмент будет развиваться, количество доступных ресурсов увеличится. 

  • Совместное использование UI находится на ранней стадии развития. KMP дает возможность разрабатывать совместный пользовательский интерфейс с помощью Compose Multiplatform. Но функция только начинает развиваться и пока не может сравниться с возможностями Flutter.

  • Ограничения Objective-C. Перевод кода Kotlin на Objective-C для iOS-приложений может привести к ограничениям и другим сложностям. Например, к проблемам с параметрами методов по умолчанию.

Основные различия

Теперь давайте рассмотрим, что отличает Flutter и Kotlin Multiplatform, и почему одна технология может быть лучше другой в разных обстоятельствах.

Технический подход

Flutter и Kotlin Multiplatform сильно отличаются по техническому подходу. 

Flutter использует язык программирования Dart и компилирует код в нативный бинарный файл, который включает дополнительный движок Flutter. Этот движок написан на C++. Он управляет каждым пикселем на экране. Так Flutter-приложения могут работать на разных устройствах через промежуточный слой.

KMP компилирует код на языке Kotlin в нативный код каждой платформы без дополнительных слоев. Приложение на KMP работает как обычное нативное. Kotlin Multiplatform легко интегрируется с нативным кодом и предоставляет прямой доступ к платформенным API.

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

В KMP общий код может напрямую использовать нативный код, специфичный для каждой платформы. 

Во Flutter общий код получает доступ к нативному коду через механизмы Platform Channels, которые сериализуют и десериализуют данные для взаимодействия движка Flutter с системой.

Обычно Platform Channels работает эффективно, но он может снижать производительность. Большинство функций Flutter обрабатываются с помощью пакетов, которые используют Platform Channels. Если подходящего пакета нет или он не удовлетворяет требованиям, разработчикам приходится реализовывать абстрактный слой самостоятельно.

Стратегия миграции

Flutter и KMP предлагают разные стратегии миграции. 

Для миграции на Flutter приходится переписывать все приложение на языке Dart. Некоторым развитым приложениям требуется несколько месяцев для полноценной миграции. 

Flutter также позволяет писать отдельные функции на Dart и интегрировать их в нативные приложения.

У KMP другой подход. Вместо того чтобы переписывать код, его можно постепенно перемещать из Android-приложения в мультиплатформенный модуль. А затем интегрировать в iOS-приложение. 

Миграцию начинают с абстрактных элементов, например, моделей данных, затем переходят к бизнес-логике и, наконец, к слою представления. При этом сохраняется нативный пользовательский интерфейс. 

Такой подход позволяет проводить миграцию и не прерывать бизнес-операции, а также обеспечивать высокое качество пользовательского опыта.

4 ключевых критерия, которые помогут выбрать фреймворк

KMP помогает снизить затраты на разработку и сохранить нативную производительность и пользовательский опыт. Миграцию можно проводить итерациями, чтобы не прерывать бизнес-процессы. 

Flutter эффективно работает в кроссплатформенных проектах благодаря единой кодовой базе. Но миграция уже готовых больших приложений может быть сложной и трудоемкой. 

Рассмотрим несколько других случаев, для которых подойдут фреймворки.

Фокус приложения

Kotlin Multiplatform подходит для приложений, в которых:

  • функции связаны с аппаратными возможностями: виртуальными примерочными (AR), навигацией, обработкой изображений, телефонными звонками или видеоконференциями;

  • необходимо использовать функции Android и iOS сразу после их релиза;

  • пользовательский интерфейс должен соответствовать требованиям платформ, например, Google Material Design или Apple Human Interface Guidelines.

Flutter подходит для приложений, в которых:

  • основной упор сделан на UI/UX, а нативные функции, например, сканирование штрихкодов, — это второстепенная задача;

  • требуется единый пользовательский опыт на Android и iOS без строгого соблюдения гайдов;

  • в приоритете уникальный и настраиваемый UI с возможным расширением до веб-платформ в будущем.

Организационная структура

Kotlin Multiplatform подходит, если:

  • у вас уже есть мобильное приложение и команда разработчиков на Android/iOS, и вы хотите работать с техническим партнером;

  • вы планируете интегрировать новые компоненты в существующее приложение или упростить разработку при помощи единой кодовой базы.

Flutter подходит, если:

  • вы новичок в индустрии, и вам нужен технический партнер, чтобы создать первое приложение; 

  • у вас нет команды разработчиков, и вам нужен партнер, чтобы управлять разработкой.

Приоритеты и рыночная среда

Kotlin Multiplatform подходит для компаний, которые:

  • выходят на высококонкурентный рынок, где критически важно предоставить хороший нативный опыт для каждой платформы;

  • ставят в приоритет нативный пользовательский интерфейс и опыт пользователей разных платформ.

Flutter подходит для компаний, которые:

  • хотят быстро выйти на рынок, чтобы протестировать бизнес-гипотезы или запустить MVP в инновационных и малоизученных отраслях;

  • получают выгоду от быстрой разработки и таких функций, как горячая перезагрузка.

Итог

Выбор между Kotlin Multiplatform и Flutter — это выбор между двумя мощными инструментами, каждый из которых имеет свои преимущества. Мы рекомендуем выбирать фреймворк на основе своих приоритетов и условий. 

Kotlin Multiplatform лучше подходит для приложений:

  • функции и бизнес-задачи которых связаны с аппаратными возможностями: виртуальными примерочными для одежды или конфигураторами мебели в AR, навигацией, обработкой изображений, телефонными звонками или видеоконференциями;

  • которым необходим постоянный доступ к последним функциям Android и iOS;

  • где UI/UX должен максимально соответствовать рекомендациям платформ.

Приложения на Kotlin Multiplatform разрабатываются для рынков с высокой конкуренцией, когда каждая мелочь имеет значение. 

Flutter подходит для приложений, в которых:

  • нативные функции используются как дополнительные. Например, для приложений интернет-магазинов, которым важнее всего показать товары и организовать удобный процесс оформления и оплаты покупки;

  • UI/UX должен быть одинаковым на всех платформах;

  • UI/UX должен быть индивидуализированным и при этом не следовать рекомендациям Google или Apple.

Помните, что не обязательно выбирать только один путь. Оба инструмента предлагают свои способы разработки и развития приложения. Выбор зависит от бизнес-задач и условий проекта.

Комментарии (23)


  1. Anfet
    30.08.2024 16:08
    +5

    KMP выглядит перспективно, но пока коллеги очень противоречиво о нем отзываются. Даже то, что проект для КММ не создаётся с нуля в студии, а где-то в стороннем решении это уже печаль.

    Плюс, даже вы указали, что либ нет или мало. Что делать когда нужно что-то, а этого нет? Писать руками. Но у флаттера это все в минус запихивают, а у кмп почемуто молчат, хотя это самое важное. Компоуз - это прямо привет из флаттера.

    Далее, горячая перезагрузка, даже для иоси - это просто божественная штука экономящая десятки часов времени. В Кмм - облом, перекомпиль, перезапускай.

    И ещё. Сделать приложения для яблока и для дроида в Кмм одним разрабом пока или нельзя, или очень сложно. А флаттер даёт это. И это тоже колоссальная экономия для заказчика.

    Производительность, если присмотреться к тестам очень близка к нативу. А платформ каналы это не реакт, они реально могут перегонять тонны данных.

    Так что сложно все это. Нужно ещё времени, чтобы разработка на Кмм была такой же лёгкой как на флаттере.

    Ещё в нативке есть кучи всяких фреймворков, DI, подходов. И это создает ад. Я еще и нативщик. Но когда мне говорят "давайв го в легаси" у меня дрожь по телу. Потому что никогда не знаешь, что там напридумали. Во флаттере кол-во пакетов и подходов в разы меньше.

    А еще флаттер прост в обучении, и за 4-6 месяцев джун уже неплохо им овладевает и спокойно выполняет работы мидла.


    1. koperagen
      30.08.2024 16:08

      Сторонее решение не обязательно, можно создать проект тут https://kmp.jetbrains.com/


    1. Goetz
      30.08.2024 16:08

      Думаю что стоит начать с того, что KMP ещё в бета, и, вероятнее всего, потому гугл и не занесли в студию создание проекта KMP по дефолту (а может никогда не занесут), но странно что это причина для расстройства, создать KMP проект не проблема, на сайте jetbrains (см. комментарий выше) или из репо Цховребова (https://terrakok.github.io/Compose-Multiplatform-Wizard/) где можно собрать проект с нужными либами, которые уже работают в мультиплатформе. Да и работать над проектом не обязательно в студии, jetbrains предлагает использовать fleet, сам я использую обе IDE.

      По поводу либ, да, не все либы портированы на все платформы, но есть относительно удобные механизмы для того, чтобы использовать специфичные либы на отдельных платформах, Розов собрал актуальный список либ (https://github.com/androidbroadcast/AndroidToKMPState), которые можно заюзать в мультиплатформе, ну и собственно в конструкторе проектов от Цховребова перечислены только полностью мультиплатформенные (насколько помню). И если взглянуть на список полностью мультиплатформенных библиотек, то видно что их достаточно для многих проектов.

      Архитектурный подход и DI на проекте вы устанавливаете сами, и делаете единый на весь проект, наверное только из каких-то иррациональных побуждений разработчик будет применять разные паттерны, но и тут за нас уже все придумали, совсем недавно выходила очень хорошая статья на хабре о том как правильно организовывать архитектуру проекта https://habr.com/en/articles/824048/ . Помимо этого есть очень хорошие библиотеки для MVI, например MVIKotlin (Аркадия Иванова), которые избавляют нас от головной боли по архитектуры и специфичных провайдов.


      1. glider_skobb
        30.08.2024 16:08
        +1

        Печально каждый раз видеть, как люди путают Kotlin Multiplatform, который уже давно Stable, и Compose Multiplatform, который Stable для Android и Desktop, Beta для iOS и Alpha для Web. В этой статье вообще про Compose Multiplatform пара предложений (видимо, автор оригинального материала не вполне в курсе последних апдейтов и релизов), а между тем фреймворк уже сейчас вполне может соперничать с Flutter. По пути своего развития он будет собирать все те же проблемы, что и Flutter: производительность, поддержка собственного канваса на iOS, баги платформенных реализаций под капотом, и т. д.

        Но гибкость Compose Compiler и Compose в целом как инструмента реактивного декларативного UI рвет на части все. Будем дальше наблюдать за этой эпической битвой)


    1. rozoomcool
      30.08.2024 16:08

      полностью согласен. Пробовал как то писать на kmp с compose и понял, что это очень сырой инструмент, ну или же я не понял его фишки. На флаттер я могу написать среднее по объему приложение за 2 недели, благодаря большому количеству пакетов, большому коммюнити и простоте написания. А в KMP мне придется либо отказаться от компоуз и использовать нативный ui, так как ui библиотек очень мало(я лично столкнулся с тем, что не было ar sdk), а некоторые не stable. Также просто убивает настройка gradle. Я конечно не прокачаный сеньор, но не советовал бы использовать kmp(Если только ваше приложение не строится на нативных возможностях), тем более flutter в производительности практически ничем не уступает. И автор в статье приводил пример со сканом штрихкодов на флаттер. Я недавно делал проект со сканером и у меня проблем со скоростью не возникало. Была проблема если в приложении было несколько экранов, использующих разные пакеты для управления камерой, но эта проблема решилась правильной сменой контроллеров камеры. Короче, язык котлин я люблю, но kmp меня разочаровал.


    1. lil_master
      30.08.2024 16:08

      Подписываюсь под каждым обзацем, + Киркоров довольно мудро сказал, что каждый хотя бы раз в жизни входит не в ту дверь, окей Гугл, в какую дверь пойдём после КМП?


  1. ris58h
    30.08.2024 16:08
    +2

    Flutter vs. Kotlin

    Вы фреймворк и ЯП сравниваете?

    В оригинале этой глупости нет.


    1. mrDevGo Автор
      30.08.2024 16:08

      Согласен, есть коллизия. Спасибо поправил.


  1. itmind
    30.08.2024 16:08

    Вместе с приложением загружается движок Flutter, который добавляет к общему весу приложения 3-4 МБ

    Т.е. размер приложения Flutter всего на 4 Мб больше чем размер приложения KMP? Раньше кажется разница была около 30 МБ

    Сейчас весь store завален приложениями по 150-200 Мб, хотя раньше они занимали около 30 Мб. Думаю это из-за перехода на Flutter, а не из-за контента. Считаю такой размер очень большим. Приложений же не одно на телефоне и когда они обновляются, то за раз скачивается несколько Гб. Не везде еще в России хорошая связь да и трафик на многих тарифах не безлимитный. В свое время отказался от Flutter из-за размера приложения.


    1. mrDevGo Автор
      30.08.2024 16:08

      Ну сейчас уже выигрыш в размере у KMP надо Flutter не актуален). Это как на спичках экономить).


    1. lil_master
      30.08.2024 16:08
      +1

      Думаю это из-за перехода на Flutter, а не из-за контента. Считаю такой размер очень большим.

      Вы это серьёзно? На какой версии флаттера вы остановились из-за размера приложения? В каком году это было? Попробуйте установить флаттер и собрать приложение на флаттере и КМП, размер будет в худшем случае на 4 мб больше, а в большинстве случаев размер приложений такой же как у нативных. Я перешёл на флаттер с натива, мне есть с чем сравнивать. В плей сторе большой вес имеют приложения, собранные на unity и unreal. И то что в России интернет "не только лишь везде" - это не проблема флаттера.

      И вообще в плей стор грузится формат aab, который подгружает и обновляет только необходимые библиотеки.


  1. GILL71
    30.08.2024 16:08
    +1

    если вы не хотите разбираться в куче разных фреймворков, если вы не разрабатываете приложение для знакомого с ИП, если вы хотите хорошо, поддерживаемо и надолго - выбирайте натив
    а для всего остального конечно, можно изгаляться как угодно, лишь бы попасть в свои хотелки с изучением нового, ускорением=удешевлением разработки и тд


    1. mrDevGo Автор
      30.08.2024 16:08
      +1

      Представьте, вы создали успешный продукт, который взлетел на Android. Что дальше? Собирать команду для реализации на iOS? А потом ещё придётся адаптировать его под Аврору. А завтра выйдет Kaspersky OS или что-то ещё. В наше время нужно серьёзно задуматься, прежде чем начинать разрабатывать продукт на нативе.


      1. Anfet
        30.08.2024 16:08

        О да. А потом, через пару лет он станет Легаси, и вы за голову будете браться при его виде. Что во флаттере, что в нативе. Вот только во флаттере вам 1 разраб нужен. А в нативе - два.


    1. mrDevGo Автор
      30.08.2024 16:08

      если вы не хотите разбираться в куче разных фреймворков, 

      Просто выбираете Flutter и на первом этапе больше ничего не надо.


    1. itmind
      30.08.2024 16:08

      хотите хорошо, поддерживаемо и надолго - выбирайте натив

      Вы считаете, что приложения, созданные с использованием Flutter, работают плохо, не поддерживаются и имеют недолгий срок жизни? Хотелось бы услышать более конкретные замечания по этому фреймворку. И почему натив - это хорошо и поддерживаемо?


      1. ris58h
        30.08.2024 16:08

        Хотелось бы увидеть какие-то тесты по производительности flutter приложений. И по расходу батарейки тоже.


        1. lil_master
          30.08.2024 16:08

          Если действительно хочется - можно зайти в интернет и посмотреть


    1. lil_master
      30.08.2024 16:08
      +1

      Если вы не разбираетесь ни в нативе, ни в фреймворках - не пишите свою философскую ерунду.

      Жаву в нативе сменил Котлин, обж-с сменил Свифт и куча народу бегает в поисках специалистов, которые переписали бы старый натив на новый натив. Где ж надолго Карл?


  1. ris58h
    30.08.2024 16:08
    +1

    Заменили бы во flutter dart на kotlin…


    1. AlexFox63
      30.08.2024 16:08

      Чтобы избавиться от горячей перезагрузки и получить возможность быстрее делать модельки?


    1. mrDevGo Автор
      30.08.2024 16:08

      Я писал года 2 на котлин. Хороший язык я не спорю. Но дарт я на котлин не променяю.


    1. Anfet
      30.08.2024 16:08

      А чего вам не хватает? Скобочки не те? Ну есть немного. Или расширений и ютилити функций нет? Ну так их можно отдельной либой сделать.