Прежде чем начнем, не забудьте уволить вашего CTO/Тимлида, если вы до сих пор не используете Flutter.
Кто я такой и зачем пишу эту статью?
Меня зовут Адрианов Алексей и я пишу на Flutter с первого релиза (декабрь 2018). За эти 5 лет я реализовал 4 коммерческих продукта различной направленности, участвовал в двух стартапах на старте карьеры, а также реализовал примерно десяток приложений “для себя”. Кроме того, имею большой опыт в собеседовании кандидатов на позиции в разные компании и оценке знаний сотрудников на основе собственной грейдовой сетки.
Написать данную статью меня подтолкнули размышления разработчиков, которые в 2024 году не понимают, почему Flutter существует и зачем нужен. Материал статьи может быть полезен менеджерам или стартаперам, запускающим новый проект, чтобы определиться почему стоит использовать Flutter, а также разработчикам, которые уже давно пытаются протолкнуть идею фреймворка в компании, где ее не воспринимают всерьез.
Статья не преследует цели сравнивать Flutter с другими технологиями, поскольку автор в них не разбирается на глубоком уровне (как и вы, возможно, во Flutter). Я хочу подсветить сильные стороны фреймворка и развеять мифы, которые так прочно сидят в сознании людей, даже спустя столько времени после релиза.
Так что же такое Flutter? В 2024 году многие уже слышали о нем, поэтому сильно вдаваться в определение не буду, но для тех, кто сталкивается с ним в первый раз, вот краткая справка. Flutter - мультиплатформенный фреймворк компании Google, который позволяет разрабатывать приложения любой сложности (говорю из личного опыта), делая большой акцент на визуальной составляющей.
Статья содержит много ссылок, поэтому подготовьте заранее спасательный круг, чтобы не утонуть в море информации. А теперь к сути.
Dart
О языке
Итак, начнем с основ. Если вы знаете хоть один С-подобный язык, то Dart не станет чем-то сложным. Язык учится быстро и спустя неделю, а то и несколько дней изучения Language Tour вы сможете без проблем заниматься разработкой.
Кроме того, команда разработки Dart работает совместно с командой Flutter, что позволяет языку соответствовать требованиям фреймворка (например, spread operator), регулярно обновляться и обзаводиться новыми фишками и синтаксическим сахаром.
Часто встречаемая фраза “Это же детище Google, когда-то они его точно забросят” не была бы такой забавной, если бы Google не был основным мейнтейнером андроида (just think about it). Теоретически, возможно все, что угодно: даже мордокнига (запрещенная в России организация) может забросить RN и уйти во Flutter. Dart активно развивается, что говорит о серьезном настрое разработчиков в отношении платформ, поэтому в ближайшие годы точно не стоит ожидать закрытия проекта. Кроме того, большое количество приложений с использованием Flutter публикуются в сторы.
Злостные ненавистники Dart в качестве аргумента против использования этой технологии, упоминают однопоточность. Давайте разберемся, что на самом деле это означает и почему агрессоры неправы.
Если вкратце - да, Dart однопоточный, но не совсем. Для логики, выполняемой в рамках Event Loop разработчику по прежнему стоит помнить об этом, однако, например, запросы в диск происходят через ThreadPool у DartVM, а не в EventLoop, в котором лишь ожидается получение данных.
Асинхронные операции с сокетами выполняются на главном потоке с использованием OS специфичного механизма неблокирующего I/O (epoll on Linux, kqueue on Mac, overlapped io on Windows). Сокеты OS уведомляют, когда во входящем буфере есть данные, которые можно прочитать без блокировки, или когда есть место в исходящем буфере, чтобы записать данные. Само чтение из буфера / запись в буфер осуществляется синхронным read/write syscallом на главном потоке. Это, правда, обычно быстрая операция. (Спасибо @mraleph за пояснения)
Flutter также имеет ряд потоков, которые отвечают за растеризацию и UI. Из выше сказанного можно сделать вывод, что бОльшая часть внешнеориентированного кода, который разработчик пишет на Dart почти никогда не блокирует UI так сильно, как об этом рассказываю злостные хейтеры. А если разработчик делает расчеты Фибоначчи в главном изоляте, то тут умрет что угодно. Но даже если нужно выполнить сложные операции, можно использовать изоляты (отдельные потоки), о которых ненавистники почему-то не говорят.
Для читателей, владеющих английским, предлагаю также ознакомиться со статьей об устройстве DartVM от уже знакомого разработчика нашего любимого языка.
А еще не забывайте, на сколько у Dart’а прекрасная документация, в которой вы никогда не потеряетесь и найдете ответы на множество вопросов.
А если Вы разработчик на kotlin/swift/js (подставь свой язык) и не понимаете, как можно писать на Dart (ведь там есть точка с запятой и нет data-классов), то просто смиритесь с тем, что язык - это инструмент, к нему можно привыкнуть и адаптироваться.
Pub
Люди, знакомые с JS знают, как тяжело работать, когда нет единого общепризнанного источника зависимостей.
К счастью, в Dart эта проблема решена. Команда разработки языка сделала пакетный менеджер, названный Pub (уже видите связь о том, что в пабах играют в дартс?)
Чтобы добавить зависимости в проект, нужно всего лишь создать pubspec.yaml файл и указать в нем все, что вам нужно. А чтобы найти нужные пакеты или плагины (да, есть различие) достаточно зайти на официальный сайт менеджера и в поиске вбить ключевые слова. Если с экосистемой вы не знакомы, то подойдет поиск в гугле, наверняка на StackOverflow уже были подобные вопросы.
“Да там же огромное количество пакетов, чем это лучше JS?” - спросят непогруженные читатели. “Системой оценки” - отвечу я. В мире, где все быстро меняется и одни пакеты заменяют другие, не только новичку, но и опытному разработчику бывает сложно найти подходящий пакет. Но разработчики Dart учли и эту проблему. Кому-то она может показаться неидеальной, но спустя время, можно с уверенностью сказать, что эта система работает и позволяет значительно сократить время поиска пакета, если вам вдруг понадобилось что-то нестандартное, а времени копаться в исходниках, чтобы найти идеальный вариант, у вас нет.
Разумеется, не все пакеты идеальны, какие-то из них заброшены и для решения задачи придется форкать и дорабатывать, но бОльшая часть критически важных пакетов находится на достойном уровне.
Бывают случаи, когда разработчику задали нетипичную задачу, которую до него никто в комьюнити не решал, пакетов соответствующих не найдено и остается только реализовать самостоятельно. Но даже в таких условиях Dart&Flutter не бросят вас на амбразуру, ведь взаимодействие с платформой в разы проще, чем кажется (а если задача вовсе не требует связи с платформой, то намотай сопли на кулак и сделай сам ???? )
Flutter
О фреймворке
В качестве очевидных плюсов Flutter, можно отметить следующее:
простота реализации любого дизайна
интеграция и написание любой функциональности, даже “тяжелой” (смотри раздел “Работа с платформой”
легкость изучения, для вкатывания во фреймворк понадобится 1-2 месяца работы, а за 4-5 месяцев регулярной работы получится дойти до уровня премидл-мидл
пока другие технологии обещают стать убийцей кроссплатформы, Flutter стал убийцей мультиплатформы.
А теперь давайте рассмотрим некоторые, не совсем корректные комментарии разработчиков.
“Интерфейс создается с помощью кода, из-за чего грань между логикой и дизайном гораздо меньше”. Удивительное замечание, в особенности, когда передовые платформы переходят на этот формат верстки (раз и два). Но эта проблема решается грамотным проектированием и явным разделением слоев в проекте (хороший вариант). А здесь, разумеется, нужен опыт, умение мыслить абстрактно и понимать планы на развитие продукта.
“Получившееся приложение на Flutter слишком большое” - говорят они. Ну, если в 2024 году разработчику жалко добавить 5 МБ в исходный пакет, то перестаньте использовать JS и упаковывать в один файл. Были случаи, когда разработчики не удостоились прочитать документацию и заявляли, что apk файл с минимальной сборкой весит 100+МБ. Читайте документацию, не стоит бросаться непроверенными высказываниями.
“А где же нативное поведение анимаций и компонентов?” Тут вопрос заключается в том, что разработчики хотят видеть полноценную библиотеку виджетов cupertino во Flutter. Но зачем? Нет, если надо, вы можете использовать ее и бОльшую часть задач она закроет, но Flutter предлагает разрабатывать собственную дизайн систему, чтобы соответствовать корпоративному стилю, что дает больше свободы выбора. Но если вы стартап и ну очень нужно делать платформенное поведение, то используйте, например, такой пакет.
“Не, ну вы видели, сколько в официальном репозитории гитхаба issue висит?” Видели, а какой процент их этих issue является критичным? Сколько из них мешают фреймворку работать и развиваться? Эти вопросы почему-то задавать не принято. Еще в давние времена, после релиза фреймворка, разработчики насыпали много однотипных вопросов, связанных с их личной глупостью, поскольку они не умеют читать документацию. Разве от этого фреймворк становится плохим? Также хейтеры не обращают внимание на то количество issue, которые закрываются с каждым релизом (эта информация есть в каждой статье, посвященной выходу новой версии).
“Flutter непроизводителен, потому что использует Skia”. Да, Flutter использует (в скором времени будет в прошедшем времени) Skia для рендера, но это не мешает рисовать картинку с частотой, соответствующей частоте экрана (даже 120 FPS). Проблема с шейдерами была, но как временное решение использовали прогрев, а импеллер и вовсе решает эту проблему (смотри раздел Производительность). Dart и Event Loop в контексте производительности уже обсудили выше. Для нормальной скорости рендера разработчику достаточно придерживаться простых правил для верстки, которые приведены в разделе Производительность.
Ладно, с комментариями закончили, а теперь давайте вспомним, на сколько у Flutter потрясающая документация. Удивительно, но комьюнити переняло опыт качественного документирования кода и большинство пакетов, даже маленьких, будут объяснять, как их использовать (А если и не будут, то это видно в системе баллов и, скорее всего, вы не добавите его к себе в проект).
Работа с платформой
Сложно поверить, но до сих пор находятся люди, которые заявляют, что Flutter это фреймворк для рисования, с его помощью глупо писать логику. “На Flutter нельзя написать банковское приложение или какой-нибудь видео-плеер, потому что там нужно … “. Но когда приводят пример, что на Flutter написаны как минимум СМП+МОБ банки (уже мертвые после поглощения), РСХБ банк (внутренний и сейчас запускается ДБО для физиков), видео-стриминг The Hole, крипто-кошелек EverWallet (или новая версия), Яндекс Go (и другие проекты компании) и многое другое, они не знают как парировать и меняют тему, либо продолжают отпускать тупые шутки по типу “Ну KMM все равно рвет ваш Flutter”.
Основная часть функционала описанных выше приложений пишется на языке Dart, а код платформенных взаимодействий реализуется либо на платформенных языках(Kotlin/Swift/JS, итд.) и с помощью MethodChannel интегрируется во Flutter, либо на низкоуровневых (компилируемых в С - C, C++, Rust, Go, итд.) языках и интегрируется с помощью ffi.
А если и этого мало, то вы можете интегрировать платформенные View прямиком во Flutter (раз, два, и аналогично для остальных платформ), как это сделано, например, с картами или WebView.
Разумеется, если приложение на 50+% состоит из платформенной функциональности, а плагин не удовлетворяет вашим запросам, то Flutter не лучший выбор для разработки приложения. Но если это единичные случаи, на которых нет большой завязки, то наверняка вас это устроит.
Прокручиваемые списки
Те, у кого есть опыт реализации прокручиваемых списков в Android или iOS (до модификаций верстки в декларативную), знают, как сложно это было, а уж если речь заходила о добавлении анимаций, то можно было вообще повеситься. Во Flutter создание списков не составляет никакого труда. Здесь присутствуют ListView, GridView и самый простой SingleChildScrollView (отличается от ListView, важно помнить). Если же необходимо добавить более сложную физику скролла, можно использовать механизм Sliver. И как это принято во Flutter, в SDK уже есть множество стандартных решений, которые позволяют добавить Sliver в приложение (также в пабе присутствует много пакетов, которые расширяют стандартное поведение). Но даже если не нашлось того, что нужно, сделать Sliver самому не составит труда. Достаточно создать Delegate (например, SliverPersistentHeaderDelegate или SingleChildLayoutDelegate) и вуаля!
Оптимизация у списков во Flutter прекрасная, поскольку в их основе лежит ViewPort. Разработчики могут на него немного влиять, например, увеличивая зону пре-кэша. Разумеется, можно встретить случаи, когда списки буду нещадно тормозить, но для этого есть следующий раздел.
Производительность
Раз уж Flutter в первую очередь является фреймворком для рисования, то он должен идеально рендерить. Так и есть. Если код UI написан хотя бы с базовым пониманием работы дерева элементов, фреймворк способен выдавать частоту кадров, сопоставимую с герцовкой монитора, на котором рисуется контент (это не касается PlatformView).
“На Flutter’e очень лагают шейдеры под iOS, а мы делаем бизнес, клиенты уходят, поэтому ваша кроссплатформа для нас не годится, мы лучше будем использовать RN.”
Все, кто скажут такое будут правы, но только частично, поскольку такое было на старых версиях, потому что обертка в виде Skia поверх Metal работала не очень хорошо. Но даже в те старые времена было решение в виде прогрева шейдеров. В 2024 году об этих проблемах говорить не принято, потому что разработчики написали собственный рендер движок, названный Impeller. Кстати, с его помощью во Flutter можно добавлять 3D сцены напрямую.
Если же вы столкнулись с проблемами производительности, стоит помнить несколько простых правил, которые часто помогают решить проблему:
запустить режим profile или release (в Debug она снижается)
проверить, что вы не обновляете большую часть дерева элементов на анимациях (самая частая проблема)
проверить, что у вас не загружаются картинки в гигантских размерах
если вы используете svg, то смотрите, чтобы там не было неадекватных полигонов и файл не весил мегабайты
помнить пару моментов по работе слоев
не выполнять объективно нагруженных процессов в главном изоляте (парсинг 10-20мб json можно сильно не заметить, но все же)
Поздравляю! Несколько несложных правил и с большой долей вероятности проблем будет гораздо меньше. Но если даже эти правила не помогли, то воспользуйтесь гуглом: скорее всего я что-то упустил, а в сообществе эту проблему уже решали. А если и это не помогло, воспользуйтесь DevTools, проанализируйте время билда и сделайте соответствующие выводы.
А теперь приведу субъективные плюсы и минусы, основанные на личном опыте.
Плюсы
Flutter позволяет реализовать любой задуманный интерфейс и анимации, поскольку он предоставляет прямой доступ к Canvas, а также огромное количество стандартных инструментов, упрощающих работу.
Flutter это не только рендер интерфейсов, но и полноценный инструмент для разработки приложений любой сложности.
В приложение на Flutter можно интегрировать платформенную логику, платформенные компоненты (View), а также низкоуровневое взаимодействие с C-компилируемыми языками (C, C++, Rust, Go, итд).
Минусы
Трудно найти квалифицированных разработчиков, которые отлично понимают предметную область.
Чтобы грамотно разрабатывать приложение под разные экраны, необходимо с умом спроектировать архитектуру. Она должна быть модульной и легко заменяемой. А это упирается в навыки разработчика.
Необходимо понимание не только Flutter, но и целевых платформ и умение писать для них код (но для небольших или даже средних проектов, скорее всего, не придется это делать, поскольку есть большое количество готовых пакетов).
В каждой технологии можно найти нюансы, которые будут критическими для того или иного проекта. Но утверждать, что Flutter вообще нельзя выбирать для разработки исключительно из соображений, что вы его не понимаете или слишком зациклены на своей технологии и лень изучать что-то новое, не стоит. Нужно с уважением относиться к любой технологии, которая решает задачи бизнеса и позволяет экономить огромное количество ресурсов компании.
Заключение
Flutter это далеко не только движок для рисования. С его помощью можно разрабатывать приложения любой сложности и направленности, но важно знать об особенностях работы, узких местах и способах оптимизации.
Flutter это лишь одна из многих технологий, которая позволяет разрабатывать приложения, но единственная, которая позволяет столь много, столь эффективно и столь просто.
Если найдутся эксперты, которые укажут на объективное расхождение текста статьи с реальностью, то буду признателен и с большим удовольствием внесу правки, указав автора.
Если вы сможете хорошо прокачать знания и будете понимать, как фреймворк работает, то вы сможете легко реализовывать любые приложения и крупные компании будут охотиться за вами (с копьем, разумеется).
Если вы только еще начинаете погружаться во Flutter, желаете повысить квалификацию или подготовиться к собеседованиям, то присоединяйтесь к моему каналу.
Комментарии (20)
lymes
18.01.2024 06:58+1а как насчет переиспользования Dart? разработчики RN/Typescript легко переходят на react web и обратно практически без переучивания.
AlexAdrianov Автор
18.01.2024 06:58+1Если очень хочется, можете писать на Dart и бэкенд, и чистые веб приложения ;)
ImagineTables
18.01.2024 06:58«А как насчёт вопроса-допроса не от фаната-обсоса, а от разозлённого хейтера?» («Рик и Морти»)
Сейчас объясню смысл этой цитаты. Я не являюсь хейтером Flutter'а, но эта якобы критика, честно говоря, больше похожа на прямую линию.
Злостные ненавистники Dart в качестве аргумента против использования этой технологии, упоминают однопоточность.
Серьёзно? Ненавистники жалуются на однопоточность? Или на сам Дарт? Или на всё остальное, упомянутое в статье? А вот я бы задал другой вопрос, который, кстати говоря, можно задать хоть флуттерам, хоть кьютерам, и звучит он так: «А почему не HTML?».
HTML много лет является мейнстримом, и за это время он вобрал в себя лучшие идеи из мира UI.
Во-первых, это разметка (markup). Вообще-то, конечно, разметка это настолько естественная идея, что она в том или ином виде присутствует везде. Разметка была даже в примитивных Windows-приложениях (.rc → .res). Псевдоразметка присутствует в WinForms (в виде системы [де]сериализации из кода). Но когда разметка не только явно выделена, но и правильно спроектирована, это большой плюс.
Что приводит нас к «во-вторых». Что такое «правильное проектирование» в данном случае? Это разбивка на 4 DSL'я плюс отдельный ЯП для бизнес-логики. Это очень важно, т.к. описание структуры (ML), описание внешнего вида (CSS), задание поведения (ES) и способ адресации элементов (пока что безымянный язык селекторов) — это четыре разных домена, которые имеют мало общего, и для каждого из них нужен самостоятельный синтаксис.
(В этой связке ES — самое слабое место. Из-за нестрогости динамической типизации это рассадник багов, и Дарт, пожалуй, лучше, но он совершенствуется, и прямо сейчас на нём управлять разметкой не так уж и плохо).
Вдобавок, бизнес-логику можно писать вообще на чём угодно. Мобильные и десктопные HTML-приложения можно писать на C++, C#, Java, JS, Rust… Веб-приложения (у которых бизнес-логика на стороне сервера) можно писать на C#, Java, PHP, ROR и т.п.
Так вот, поэтому любой «мультиплатформенный фреймворк» с «акцент[ом] на визуальной составляющей», по-хорошему, надо сравнивать с HTML. И получится три варианта.
В нём нет ничего из описанного. Или разметки нет, или она не разбита на разные языки, или, ещё хуже, бизнес-логика должна быть написана на том же языке, что управление контролами (в худшем случае — на ЯП без автоматического управления памятью). Ну, тогда и суда нет. Как по мне, это пережитки прошлого, с которыми надо «расставаться, смеясь».
В нём есть часть или всё вышеописанное. Если часть — тогда возникает вопрос, зачем использовать огрызок, например в виде ML, но без стилей. Если всё — тогда возникает вопрос, зачем использовать нестандартную и, скорее всего, тупиковую (по сравнению с оригиналом) вариацию HTML.
В нём заложены идеи лучше, чем в HTML. Вот это и было бы интересно почитать.
P.S. Про требовательность к ресурсам писать не надо. Подо все ОС есть дефолтные движки с поддержкой, в Андроиде это WebView, в Windows — WebView2, поэтому раздувать дистрибутив не придётся. Что касается скорости, помимо Хромиума существуют быстрые и нетребовательные к ресурсам реализации, сопоставимые с нативными приложениями.
TrueRomanus
18.01.2024 06:58по-хорошему, надо сравнивать с HTML
Что-то лучше в описании интерфейса чем HTML/CSS/JS вряд ли можно придумать. Тут вопрос в том а точно оно Вам надо в десктопным/мобильных приложениях? Например в мобильных приложениях есть нативные контролы которые имеют нативное поведение к которому привыкли пользователи но Вам в Вашем WebBrowserBasedApplication необходимо самому это реализовывать и когда в новом sdk что-то меняется да надо снова догонять.
Мобильные и десктопные HTML-приложения можно писать на C++, C#, Java, JS, Rust… Веб-приложения (у которых бизнес-логика на стороне сервера) можно писать на C#, Java, PHP, ROR и т.п.
Это зависит от приложения, если Вам только отобразить "также как на сайте" и все то да, но если надо использовать нативные фичи на полную, есть какая-то логика которую можно выполнять на стороне приложения но которая изначально написана на стороне сервера, то тут уже не все так однозначно.
ImagineTables
18.01.2024 06:58Например в мобильных приложениях есть нативные контролы которые имеют нативное поведение к которому привыкли пользователи но Вам в Вашем WebBrowserBasedApplication необходимо самому это реализовывать
<input>заточен именно под это, особенно при правильной настройке.А вообще, как это ни странно, для кого я работал, все, наоборот, хотели кросс-платформенную унификацию дизайна. Соответственно, с кастомизацией под корпоративный стиль и т.п. вещами. Среди них были сурьёзные товарищи (типа мирового лидера по разработке промышленных навигаторов и одной конторы помельче по разработке бытовых навигаторов). Меня самого это удивляло, я вырос на Microsoft/Apple Design Guidelines, но что есть, то есть. Да и если посмотреть правде в глаза, тот же Microsoft разве следовал когда-то своим Guidelines? Со стороны кажется, они считают, что это для лохов, а сами они выше этого.
Это зависит от приложения, если Вам только отобразить "также как на сайте" и все то да, но если надо использовать нативные фичи на полную, есть какая-то логика которую можно выполнять на стороне приложения но которая изначально написана на стороне сервера, то тут уже не все так однозначно.
Я могу, опять же, только сослаться на свой опыт. Из rich-вещей я написал на HTML аналог Classic Shell (подойдёт под критерий «нативные фичи на полную»?). Понятно, что там было нужно сделать отдельно немного хендловой магии, парсер .lnk, поиск по файловой системе и тому подобные вещи, но всё основное, что съедает время в таких проектах, сделано было именно на HTML. И в ретроспективе это было правильное решение.
TrueRomanus
18.01.2024 06:58<input>заточен именно под это, особенно при правильной настройке.Заточено под что? Различие в работе даже между html движками на голом input-e будут заметны. И если надо настраивать (особенно для каждого движка по своему) то простите грошь цена такому "классному" инструменту, проще использовать нативный контрол который просто из коробки будет таким как надо.
А вообще, как это ни странно, для кого я работал, все, наоборот, хотели кросс-платформенную унификацию дизайна.
Я говорил не про дизайн а про поведение нативных контролов. Дизайн понятно можно накидать быстро а вот повторить поведение/анимации/навигацию/системные вызовы/интеграции и чтобы пользователь ничего не заметил тут уже сложнее. Например ну допустим повторили Вы экран iOS приложение до пикселя но при взаимодействии с чем-то в нативном контроле вызвается системная менюшка или функцию например а в Вашем аналоге такое реализовать просто невозможно.
Из rich-вещей я написал на HTML аналог
И немного занудства, корректно говорить написал на "Web технологиях" потому что явно вы использовали и CSS и JS а то выглядит как будто Вы пользовались только HTML.
ImagineTables
18.01.2024 06:58И если надо настраивать (особенно для каждого движка по своему)
Вообще, я пользуюсь одним движком, сборки которого есть подо все нужные мне платформы (Windows, MacOS, Linux и Android). И он из коробки умеет в look-n-feel нативных контролов данной платформы. Правда, как я уже написал, для реальных проектов надобность в этом возникает нечасто.
Я говорил не про дизайн а про поведение нативных контролов
Я выше поправился, заменив слово «дизайн» на “look-n-feel”.
И немного занудства, корректно говорить написал на "Web технологиях" потому что явно вы использовали и CSS и JS а то выглядит как будто Вы пользовались только HTML.
Я думаю, когда я написал, что преимущество HTML в том, что он разбит на четыре DSL'я, всё должно было стать понятно :)
AlexAdrianov Автор
18.01.2024 06:58+1Добрый день, ваши аргументы совершенно справедливые, поэтому предлагаю вернуться в 90-ые и верстать html+css.
Если же мы рассматриваем вопросы бизнеса, где нужно сделать и чтоб работало везде, то Flutter, как и многие кроссплатформы, но статья написана по той причине, что в сети большое количество KMM-убийц, которые рьяно пытаются всем доказать, что их технология топ, а все остальные ничто. И как это принято в продвижении себя, нужно замахнуться на самого сильного, чтобы попытаться привлечь аудиторию. По этой причине в сообществе гуляет много необоснованных принижений данной технологии
ImagineTables
18.01.2024 06:58Добрый день, ваши аргументы совершенно справедливые, поэтому предлагаю вернуться в 90-ые и верстать html+css.
Всё наоборот: это в 90-е было авангардом, а сейчас это самый очевидный путь.
Я, кстати, в 99-м впервые это попробовал, и тогда это казалось безумно смелым экспериментом. Мне в MFC-приложение потребовалось вставить интерактивную интегрированную помощь. Ну вот, кто в те времена писал, тот помнит, как там вставлялась анимированная картинка или avi. Подумав, я добавил куда надо WebControl (Trident .ocx), после чего вместо программирования эту часть приложения стало можно просто верстать.
Если же мы рассматриваем вопросы бизнеса, где нужно сделать и чтоб работало везде
Все нулевые и десятые я именно этим и занимался: писал бизнес-приложения на связке C++/HTML. И уверяю, бизнес очень ценит такие вещи как:
Возможность сделать темы оформления или сменные головы для смартфона/десктопа, чтобы модуль бизнес-логики приложения про это ничего не знал.
Возможность что-то поправить в изолированном слое UI без перетестирования заново всего приложения, зная, что коммит гарантированно не внёс ошибок никуда глубже.
Возможность писать в разы быстрее (поскольку декларативно), и делать интерфейс гораздо круче (поскольку современный CSS из коробки умеет дофига красивого).
Возможность принципиально вынести в UI такие вещи, как подсказки при наборе (не проверку орфографии и не T9, а именно осмысленные варианты), и не иметь их в основном коде приложения (где они только мешались бы).
Возможность быстро нанять специалиста, который разберётся в UI-коде.
пытаются всем доказать, что их технология топ,
Это про HTML? ;) На нём, как бы, в данный момент пишется бОльшая часть UI.
wannaluv
18.01.2024 06:58+2Скажу своё мнение профана.
Да, сравнивать ui фреймворк с HTML очень правильный подход .
Будучи нубом и обучаясь разметке и вёрстке, а потом потыкав flutter, я почувствовал насколько flutter удобнее для формирования UI, особенно типичных интерфейсов.
HTML+CSS+JS , это три слоя, где один проникает в другой и может выполнять часть функций. Разобраться как сделать одну и ту же задачу лучше, когда реализаций идентичных 10 штук, немного неприятный процесс.
Так вот виджеты flutter и декларативный UI это так удобно для нуба, просто манна небесная. Есть виджеты, они друг в друга вложены, можно каждый посмотреть и разобраться как они работают.
Я считаю подход flutter более простым. А всё простое победит. Или будет популярно, как минимум.
ImagineTables
18.01.2024 06:58-1Я не против сравнить на какой-нибудь конкретной задаче.
Можно взять ту, которую я уже упоминал: помощь с заполнением. Допустим, у нас есть поле, куда юзер вводит URL. Если он написал “fa”, надо предложить ему “https://facebook.com”. Эта задача обобщается на любой типизированный ввод (название фильма, название города, модель автомобиля данного производителя и т.п.). Устроит такая задача? Если да, предлагаю сравнить решения. Для HTML оно не только короткое и выразительное, но и полностью изолировано от кода приложения, а это значит, что оно:
Не содержит багов нигде за пределами автокомплита.
Не содержит уязвимостей на уровне приложения.
Не мозолит глаза при программировании слоя бизнес-логики, т.к. написано буквально там же, где описана конкретная форма (или библиотека для создания типовых форм).
Dancho67
18.01.2024 06:58Можно спокойно заменить все слова Flutter на RN, Avalonia Ui, Uno Platform, Compose(нужное подчеркнуть) и получить новую статью о плюсах искомой платформы. Хоть ГПТ не использовали и на том спасибо.
ParaMara
18.01.2024 06:58Написать данную статью меня подтолкнули размышления разработчиков, которые в 2024 году не понимают, почему Flutter существует и зачем нужен.
Точно? А не размышления ли тех разработчиков, которые примерно понимают, а как можно быть разработчиком и вообще ничего не понимать в Flutter - это уже я не понимаю, но использовать и тем паче переходить - не хотят?
Язык учится быстро и спустя неделю, а то и несколько дней изучения Language Tour вы сможете без проблем заниматься разработкой.
Да, сможете. Да, Dart не deal breaker. Более того, Dart - просто приятный язык с неплохо работающей горячей перезагрузкой, что даже лучше быстрой компиляции. Но для любой как-то ограниченной деятельности всегда найдётся что-то более подходящее. Выбирать Dart для слабо ограниченной, она же плохо определённая, деятельности, чисто для себя, например? Можно, но выбрав многое другое Вы сможете идти в глубину, которой у Dart нету by design.
И да, Dart вполне быстр на уровне других языков со сборщиком мусора, но не быстрее. Да и Rust тут как тут...
Кроме того, команда разработки Dart работает совместно с командой Flutter, что позволяет языку соответствовать требованиям фреймворка
Да, что автоматически делает Dart языком из прошлого. Сначала были языки для вычислений, потом для GUI, потом для генерации HTML. Параллельно были типа Lisp, но EMACS- это другое. Dart - язык для GUI, отлично, а Rust или Julia - извлекщие уроки из всего этого пути...
Часто встречаемая фраза “Это же детище Google, когда-то они его точно забросят” не была бы такой забавной, если бы Google не был основным мейнтейнером андроида (just think about it).
Зачем просить think? Результат может не понравиться...
Гугл не забросил Андоид не потому, что не хотел, а потому, что не смог, см. Фуксия. Андроид очень плохо монетизируется, попытка качать деньги через сертификацию привела к анекдотичным срокам поддержки устройств вендорами. А теперь и вовсе Хуавей и сокращение срока поддержки LTS ядер, о продлении которого Гугл умолял на коленях...
С Flutter уже начались видимые проблемы как раз со стороны Гугла, типа громкого ухода ведущего разработчика, Tim Sneath если не ошибаюсь, который а) обещал Flutter не бросать и первым делом обновить roadmap и б) много чего рассказал про атмосферу в Гугле воцарившуюся. С атмосферой - сложно но печально, а roadmap вроде как https://github.com/flutter/flutter/wiki/Roadmap и ни разу не обновлён.
Долгое время главной (экзистенциальной, ведь из единственной ниши ниже Эппл может найтись кому вышибить?) проблемой Гугл было вырваться со смартфонов где Гугл запер iPad. Не был ли Flutter частью решения? Если нет, зачем для его популяризации по миру странствовал полноценный балаган? А на последнем I/O Гугол не знал других слов кроме AI. Побратим Гугла Самсунг вложился в это по полной, вчера выяснилось, фактически на AI держится судьба высших руководителей Самсунг... а у Эппл внезапно тоже обнаруживается AI.
Я не буду думать сейчас как это отразится на Flutter, я подумаю об этом завтра. Но мы точно приближаемся к очередной точке принятия решения.
Если вкратце - да, Dart однопоточный, но не совсем
Так и надо было вкратце. Был - не совсем однопоточный, стал - совсем не однопоточный, принято.
“Flutter непроизводителен, потому что использует Skia”. Да, Flutter использует (в скором времени будет в прошедшем времени) Skia для рендера, но это не мешает рисовать картинку с частотой, соответствующей частоте экрана (даже 120 FPS).
Как-бы и со стороны видно - на iOS Flutter лагает, а на iOS к этому не привыкли. И не может в 3D. И не особо может в WebAssembly и HTML. Да, impeller и усилия Гугол по WebAssembly (если и с ними всё будет хорошо) имеют, как по мне очень хорошие, шансы всё это исправить. Совсем скоро исправить. Но про проект в таком состоянии, т.е. без кусков базовой функциональности, принято говорить Альфа...
Flutter это лишь одна из многих технологий, которая позволяет разрабатывать приложения, но единственная, которая позволяет столь много, столь эффективно и столь просто.
Да, это так. Но это как пожизненная гарантия - задачу можно решать с двух сторон.
От себя, ну почти
Про Flutter была понравившаяся мне аналитика объяснявшая успех тем, что не было стремления потерпеть неудачу так, как это сделала вся иная кросс-платформа - пытаясь получить приложения идентичные натуральным. Так не работает, наблюдаемый факт. А занимаясь отрисовкой pixel perfect собственного интерфейса - работает, пусть и не для всех задач. И этого хватило чтобы Flutter вышел на первое место по популярности.
Были даже примеры выхода за пределы собственного интерфейса, типа солидные люди пишут для своего персонала на Flutter, а для клиентов - дивной красоты нативные приложения.
В одной из версий roadmap прочитал - мы расширяемся и хотим стать лучшим средством разработки вообще. То есть пойти к упадку дорогой всех остальных. Это ничего не значит, к счастью, кроме того, что за развитием Flutter нужно смотреть в оба.
AlexAdrianov Автор
18.01.2024 06:58+1Добрый день, спасибо за развернутый комментарий!
Если коротко - скоро все разработчики пойдут работать на завод, когда AI совместно с ChatGpt начнет внедрять информацию напрямую в мозг юзерам.А пока этого не произошло, Dart&Flutter лучше всех справляются со своей задачей ;)
LesleySin
18.01.2024 06:58+1Ставлю жирный лойс статье за то, что много ссылок. Теперь есть повод почитать и освежить память :)
AlexAdrianov Автор
18.01.2024 06:58Здесь был комментарий от читателя про вакансии, но я неправильно понял функционал и отклонил его.
Отвечаю, чтобы не было ощущения игнора.
С вакансиями во Flutter все неплохо, HR регулярно заходят в личку и приглашают на разные проекты. Из минусов могу заметить, что в большом количестве случаев ищут именно middle+, поскольку в проект нужны уже опытные руки. Джунов, наверное как и везде, набирают в основном в состоявшиеся коллективы с возможностью вкладывать ресурсы в рост сотрудника, либо компании-галеры, у которых строится бизнес на продаже слабых ребят под видом специалистов.Подробной статистики по месяцам/годам у меня, к сожалению нет, но на hh и в профильном тг канале вакансии появляются регулярно.
По ЗП могу сказать, что уровень миддл может расчитывать на 200-320тр в зависимости от компании, синьоры в среднем получают 300-400тр в зависимости от компании.
ALapinskas
Без сомнения flutter/dart - замечательные инструменты. Но основная причина использования/неиспользования того или иного инструмента в организации, является экономическая целесообразность. Следом пойдут, распространенность инструмента, количество сторонних пакетов и количество специалистов в данном сегменте, т.е. кадровый вопрос. Конечно замечательно, что можно переучить, к примеру, nodejs специалиста на flutter/dart за полгода/год, но зачем компания будет за это платить?
AlexAdrianov Автор
Добрый день, вы абсолютно правы
bondeg
К примеру, чтобы уйти от ненадежных ребят, например Unity эффективных менеджеров набрала и увеличила риски тех, кто с ней работает (хотели взвинтить оплату за платформу в небеса).
Да, они в итоге сдали назад, но понервничать заставили и многие задумались.