Comments 54
К недостаткам я бы добавил риск того, что Гугл в один прекрасный день возьмет да и закроет этот проект, как многие другие до этого. Вряд ли, конечно, но имхо это тоже нужно учитывать при выборе кросс-платформ инструмента для разработки коммерческих приложений.
Такой риск правда существует, но лишь упомяну, что переход Flutter-разработчика в нативного возможен с меньшими затратами, поскольку присутствует общий опыт взаимодействия с платформами
Но какие инструменты разработки закрыл Google? Наоборот, не бросил Dart а дал ему новую жизнь.
Второй момент - инструмент Open Source, я думаю просто передадут его сообществу, как скажем с Rust получилось, во Flutter нет ничего что было бы прямо завязано на гугл.
Так то можно сказать что и Apple всех прокатила с Objective-C когда-то.
Так то можно сказать что и Apple всех прокатила с Objective-C когда-то.
эмм.... что? ))))
например gwt, который было отнолительно популярен. Теперь куча компаний думает куда мигрировать.
Кстати да, совсем забыл о нём. Google Web Toolkit, классная была штука раньше, - пишешь фронтенд на Java, компилишь все в яваскрипт бандл и вуаля. Справедливости ради, GWT вроде как еще есть, но не развивается и подзаброшен.
В данный момент в режиме поддержки, не будет новых фич, только чтобы можно было все еще запускать старые проекты. Мы старались переписать gwt модули на J2CL, но уткнулись в то, что не понятно как эффективно поддерживать i18n, а это используется почти во всех модулях. Есть closure-library, но тогда нет возможность соблюдать обратную совместимость.
J2CL классная штука, но скажу, что товарищи из компании, где делают только добро, не очень заинтересованы в популяризации (вот сейчас прям я доволен, как мне удолось мягко высказаться), или простым языков им просто плевать на пользователей вне. Наша маленькая группа навояла j2cl-maven-plugin, и им даже можно пользоваться (относительно удобно), но это все равно не так круто, как было с gwt.
В общем по доглу службы мне приходиться иметь дело с решениями гугла, но я был бы очень осторожен, если бы меня спросили стоит ли на них основывать свои бизнес решения.
Google Gears. Закрыли в 2009 году. Сейчас его аналог это React Native/Electron.
Забыли основной недостаток: надо учить отдельный язык, который больше нигде не используется и не будет. Именно поэтому от Flutter отказываются, а не потому что там кодогенерация.
Да, я не в теме, но экосистема будет, как я понял, от Ноды? То есть, JavaScript учить тоже всё равно придётся?
>Да, я не в теме, но экосистема будет, как я понял, от Ноды? То есть, JavaScript учить тоже всё равно придётся?
Экосистема уже есть (pub.dev), она независимая, там нет ноды и джаваскрипта, dart only.
Да, несомненно нужно потратить своё время чтобы разобраться в языке, но на деле начать писать на Dart не так сложно. В Flutter бывает начинаешь писать на Dart, потом переключаешься на Kotlin или Swift, чтобы реализовать конкретную нативную часть, и происходит это без страшных последствий. Наверное, с опытом уже неважно на чём писать :)
давно никакого JavaScript там нет. Object-C учили, swift учили, они кроме как ios вообще не используются же, да и чего там учить, все языки одинаковые, да и по мне Dart намного проще той же жабы, только с котлином можно сравнивать
Если вы думаете, что выучите один язык и всю жизнь будете на нем писать, то я вас разочарую. Очень мало шансов что так получится. Либо вы сами захотите попробовать что-то новенкое, либо обстоятельства заставят.
К недостаткам: отсутствие динамического обновления (code push ReactNative).
Иметь возможность внести изменения оперативно, не дожидаясь пока магазин разрешит или пока пользователь обновит проложение - критично для большого круга компаний
Спасибо за материал! Некоторые проблемы, озвученные в статье, могут быть решены в ближайшее время (статическое метапрограммирование). Насколько мне известно, команда dart активно над этим работает. А ещё, ждём вход dart 3 в стабильную ветку flutter (хотя пользоваться можно уже сейчас). А ведь это records (с поддержкой деструктуризации), pattern matching, модификаторы классов...
Есть вроде как разумное и не особо радостное наблюдение происходящего с Flutter
https://levelup.gitconnected.com/i-am-falling-out-of-love-with-flutter-f667bd450aa
К слову, сам язык «из коробки» однопоточный только если присоединиться к толпе затрудняющейся подобрать слова поточнее чем single threaded. Автор весьма прав утверждая что «ключевое отличие находится в технической составляющей». К сожалению, по тексту почерпнуть из этого что-либо кроме «выше написана ерунда» не удалось. Лучше молчать чем так, хотя я понимаю - по нынешним временам одна эта тема обеспечит статью.
Как по мне, главный вопрос к Flutter - маниакальное упорство Гугол в его «продвижении» требует объяснения. Вонь от бесплатного сыра…
А состояние Flutter - поздняя альфа. Первая версия Dart провалилась и танцы вокруг null safety пока не кончились, хотя вот-вот и должны. Первая версия Flutter провалилась, без Impeller, то есть на мобильных устройствах Эппл, она не рабочая, и обратно без Impeller и, соответственно, 3D, она никому толком не нужна, и без хоть и обещанного но грядущего усовершенствования WebAssembly и, соответственно, применения для Интернета без трансляции в JavaScript, она ещё раз никому толком не нужна. Ключевое слово - толком.
Сам Dart тоже вызывает недоумение - и просто, и быстро, и удобно, и даже где-то красиво, а им всё то Rust то Kotlin подавай, а то и Go, а от Dart фанатеть отказываются. С чего бы это, знают что-то такое чего я не знаю?
Чтобы окончательно добить карму, дам непрошеный совет. Если кто уверен что быстрее чем за год Flutter не выучит, начинайте прямо сейчас.
Очень грустно читать такие статьи.
Потому что сам SDK действительно интересный, в чем-то уникальный и позволяющий делать крутые, приложения c нестандартным красивым дизайном.
Но все эти сравнения с нативом ни к чему хорошему не приводят, потому что:
они только разжигают новые холивары нейтив VS кроссплатформа, чем еще больше отталкивают людей и привлекают троллей.
решения о переходе принимаются не только на основании технических факторов, но многих других (какая аудитория, сроки, на какие платформы запускать, можно ли быстро нанять новых людей и тд). хотя конечно отстутствие быстрых линтеров для удалений неиспользуемых классов/методов это тоже важно.
Как правило, проекты под нейтив и кроссплатформу - это разные типы проектов и они не конкурируют. Те условно, какой-то большой интернет банкинг с кучей клиентов и сотней разрабов врядли будут делать на кроссплатформе потому что и так достаточно ресурсов держать такую армию разрабов и нативщиков нанять быстрее и проще. В тоже время, какой-то стартап который хочет быстрее запуститься под обе мобильные платформы и где, условно, не хватает ресурсов сразу на все - может попробовать начать сразу на Flutter. Поэтому тут не надо никого агитировать переходить, люди сами придут к тому или иному решению, даже если оно технически не совсем правильное, но с которым у них есть опыт и они его могут развивать.
К слову, сам язык «из коробки» однопоточный
Это не так, см Isolate или вот
Для сравнения, в Kotlin есть довольно быстрый фоновый KSP и его более современная замена kapt.
все строго наоборот: сначала был kapt (как реализация стандартного аннотейшн процессора в джаве для котлина, которые работает достаточно медленно), а потом уже появился KSP.
Помимо этого, Flutter не поддерживает сборку проекта под архитектуру x86 для Android.
это конечно очень грустно, но интелы уже давно свои армы под андроид не выпускают, это было очень давно, таким устройствам уже 7+ лет (зенфоны на интеле и др) + там была фишка что заложена эмуляция arm32 либ, тк много кто те времена в приложения не добавлял x86 версии либ, так что может даже и так все заработает.
Если говорить о веб-приложениях, то разработка на Flutter Web будет требовать особый и настолько строгий подход к оптимизации, что заставит переосмыслить ее целесообразность
это все зависит от сценария использованения, для главной страницы магазина - врядли такое подойдет, но для внутренней админки бекенда - вполне, учитывая скорость разработки + функциональность.
Соглашусь, любой инструмент выбирается от задачи и жизненного цикла приложения.
Это не так, см Isolate или вот
Каждому изоляту выделяется отдельный Event Loop и своя память, а взаимодействие между изолятами возможно только посредством сообщений, что ведёт к тому, что в Dart нет параллелизма с общим состоянием. Вообще язык очень хитрый в этом плане, я бы назвал это псевдо многопоточностью? :)
все строго наоборот: сначала был kapt (как реализация стандартного аннотейшн процессора в джаве для котлина, которые работает достаточно медленно), а потом уже появился KSP.
Спасибо за наводку, действительно перепутал местами.
это все зависит от сценария использованения, для главной страницы магазина - врядли такое подойдет, но для внутренней админки бекенда - вполне, учитывая скорость разработки + функциональность.
Конечно это не останавливает разработчиков писать приложения на Flutter Web, но порой сталкиваешься с такими проблемами, которые и вовсе быть не должны. Скорость разработки может упасть, как только разработчик столкнется с проблемой движка, отсюда появляются обходные решения, костыли и креатив разработчика тут уже задействуется на полную. Иногда вот думаешь, а зачем я этими проблеми занимаюсь?
Вообще язык очень хитрый в этом плане, я бы назвал это псевдо многопоточностью?
В оф доках все это есть https://dart.dev/resources/faq#q-is-dart-single-threaded можно было их почитать и не надо придумывать своих терминов и вводить в заблуждение, цитата оттуда:
Is Dart single-threaded?
No. On native targets, Dart’s isolate API can enable multiple threads of execution at any given time. The Dart VM uses multiple processor cores to run those threads concurrently.
И про KAPT все равно не правильно изменили:
Для сравнения, в Kotlin есть довольно быстрый фоновый kapt и его более современная замена KSP. В отличие от build_runner в Dart, с ними приятно работать.
Все кто работал с KAPT знают, что основная его проблема - это скорость, он работает очень медленно, медленее даже чем стандартный java annotation processors, про это много где уже писалось и тд. Так что он никак не быстрый и с ним не очень приятно работать, собственно по этой (и не только) причине появился KSP. Зачем это было писать в статье, если вы не работали с этим? Тем более в контексте сравнения с дартом.
Иногда вот думаешь, а зачем я этими проблеми занимаюсь?
Ну да, а под WEB же когда люди пишут на react или других фреймворках у них проблем не бывает, там же все браузеры одинаково работают и CSS у всех стандартно поддерживается и не надо версиями и багами JS парится, там же всегда все работает. И в либах проблем тоже нет, там же без багов сразу пишут и тд.
Везде есть проблемы, почти все всегда можно решить, для этого и нужны разрабы.
Другое дело что конкретно под ваш проект этот инструмент не подходит, если говорить про Flutter Web, то это у них как раз описано тут https://docs.flutter.dev/development/platform-integration/web/faq
Можно почитать, попробовать, отказаться.
Скажу по нашему опыту еще раз, мы делали 2 небольшие админки (REST, авторизация JWT, формы, списки с фильтрацией у группировкой), проблем никаких не было, единственное собирать на CI пришлось заморочиться немного, остальное все работает и сейчас.
В оф доках все это есть https://dart.dev/resources/faq#q-is-dart-single-threaded
Спасибо за ссылку, очень полезно
Все кто работал с KAPT знают, что основная его проблема - это скорость, он работает очень медленно
В сравнении с build_runner, это небо и земля. Не было цели сравнивать только kapt и KSP между собой. Посыл был в том, что если это работало хотя бы на уровне kapt, то проблема не казалась бы существенной.
С чего это псевдо поточность? Вполне реальная многопоточность там. Просто без компут и изолятов сама по себе асинхронность в общем случае не даёт многопоточности. Поэтому и говорят, что дарт однопоточный с одним ивентлуп. Но есть элементы языка позволяющие организовать вполне нормальную многопоточность.
кроме того стоит заметить что по крайне мере на Android java/kotlin приложение не более нативное чем flutter-приложение, каждое из них исполняется в своей среде исполнения ART и Skia соответственно. Да конечно flutter-приложение запускается из обычного и может взаимодействовать с ним, но сравнивать производительность я бы поостерегся - и то и другое продукт Google.
Насчёт банкинга, вот прям с точностью до наоборот. Зачем держать зоопарк натива, когда все кросплатформой реализуется. Да и нативного разработчика переучить под флаттер один раз не так уж сложно(было бы желание разработчика).
Ждём развития KMM. Писать на compose приятнее, ходят легенды что он будет единым для всех платформ.
Еще забыл ОГРОМНЫЙ .apk файл при генерации из Flutter
К примеру пустой проект .apk ->
Flutter: 30мб+
Нативный: 3мб+
Разница в 10 раз!
Но всё равно топлю за Flutter, кодить на нем намного проще и быстрее чем на нативе
Вы не используете команду --split-per-abi? Откуда такой размер для flutter приложения в 30мб? Да даже толстый апк не выйдет весом более 30мб...
Для мультиплатформы сейчас флаттер самое стабильное и зрелое решение, есть KMM, но пока он сырой, но многие именно на него делают ставку в дальнейшей перспективе. Если нужна какая то одна платформа, то лучше использовать натив, тем более появилась возможность декларативной верстки, например compose в плане верстки проще и менее громоздкий чем flutter.
К примеру пустой проект .apk ->
Flutter: 30мб+
Если запустить это в терминале:
flutter create size
cd size
flutter build apk --release --split-per-abiТо в результате сбилдятся 3 apk:
✓ Built build/app/outputs/flutter-apk/app-armeabi-v7a-release.apk (5.6MB).
✓ Built build/app/outputs/flutter-apk/app-arm64-v8a-release.apk (6.1MB).
✓ Built build/app/outputs/flutter-apk/app-x86_64-release.apk (6.2MB).Конечно, это не 3Мб, но в 6Мб уже весь движок и кусочек приложения
И толку тебе от 3 разных apk файлов? Скинешь кому-то не с тем ядром и у него не установится. Выложить куда-то - тоже самое, будет ошибка установке у половины пользователей которые установят не тот апк.
Выход- собирать один включающий эти 3 сразу.
Не вопрос:
✓ Built build/app/outputs/flutter-apk/app-release.apk (16.8MB).Да, это больше чем пустой проект (я создал в студии пустой проект и сделал релизный билд - 4.5Мб), но если это действительно критично, то стоит использовать только нативную разработку
Моё мнение: большинство нативных приложений уже давно имеют размер выше 15Мб - поэтому размер Flutter приложения не так критичен в большинстве случаев
А вы как в каком режиме сгенерели? Девелоп? Или релиз? Думается, мне что девелоп.
Указано, что
"Для сравнения, в Kotlin есть довольно быстрый фоновый KSP и его более современная замена kapt. В отличие от build_runner в Dart, с ними приятно работать"
Но это KSP как раз более быстрый и свежии. Даже по указанным вами ссылкам можно прочитать, что kapt перешел в maintenance mode
Я считаю что самый ценный ресурс - это время. Тогда становится актуальным вопрос, а нужно ли тратить время на изучение Dart? Кроме Flutter толку от него мало. Сказки про то, что язык можно быстро освоить, можно оставить для джунов. Что бы быть действительно профессионалом своего дела, язык нужно хорошо изучить, знать его фишки, фичи, особенности и нюансы. А на это нужно время. С тем же Kotlin больше профита.
Можно подумать что swift имеет обширную область применения
Фишки, фичи - все нормальные языки программирования плюс минус синхронизировали сахаров
Особенности и нюансы - это вы про косяки js? в норм языках middle, senior поймёт их проблемы из статьи на 5 минут чтения
И главное - мобильный разработчик выше джуна знает паттерны, виьюшки и их поведение, либы, и другие нюансы которые никогда не зависят от языка.
Я когда переходил с xamarin на flutter, сам язык походу осваивал, и умения построить архитектуру и найти наивыгоднейшее решение отличали меня от джуна....
Я замечу, что до бизнеса есть несколько недостатков.
Отдельный язык Dart, который больше нигде так или иначе не применяется. Да, он может быть похож на другие языки. Проблемы не со вкатываним в язык, а в том, что на рынке труда проще найти C#-разработчика или того же JS-ника. Другой вопрос в том, что Flutter и Dart являются инструментарием направленным узко в сторону мобильных клиентов. Скажем, в отличии от C# (и его Xamarin a.k.a. MAUI + ASP.NET Core) или JavaScript (Node + React Native). Представленные языки и их окружение могут предоставить разработчикам, например, единство имплементации модели данных. Второй плюс связан с тем, что у вас появляются т.н. full-stack разработчики, когда у тебя нет двух команд (с разной степенью раздельности), а есть единая команда в рамках которой могут быть люди с разной степенью специализации, но всё же говорящих на одном языке.
Странные вы, а вы расширения, поддержку iPadOS, macOS со всеми внутренностями и и например прикручиваем Mint, Windows. Опять же с работой всей перефирии? Не надо все в кучу сибирать, везде есть ограничения, а Flutter максимум для MVP версий.
Как то пробовал года два назад эту тему. По итогу не понравилась. Отдельный язык который непонятно зачем есть и непонятно зачем существует используется в узконаправленном фреймворке.
Пробовал на нем писать. Но после непонятных багов чуть ли не на hello World, где после хотрелоада отпадала клавиатура и ввод и около года открытого issue почти без единого комментария разработчиков - забил. Может быть сейчас уже лучше но серьёзно на нём что то делать кроме мелких проектов - смысла не вижу.
Переходим на Flutter: за и против