Comments 30
Прежде чем начнем, не забудьте уволить вашего CTO/Тимлида, если вы до сих пор не используете Flutter.
Без сомнения flutter/dart - замечательные инструменты. Но основная причина использования/неиспользования того или иного инструмента в организации, является экономическая целесообразность. Следом пойдут, распространенность инструмента, количество сторонних пакетов и количество специалистов в данном сегменте, т.е. кадровый вопрос. Конечно замечательно, что можно переучить, к примеру, nodejs специалиста на flutter/dart за полгода/год, но зачем компания будет за это платить?
а как насчет переиспользования Dart? разработчики RN/Typescript легко переходят на react web и обратно практически без переучивания.
Если очень хочется, можете писать на Dart и бэкенд, и чистые веб приложения ;)
Ну на счёт веб приложений это очень компромиссное решение
В флаттере для вела нужно быть очень аккуратным из за производительности, сео нет, а преимущества.... Ну только если переиспользуемость, но это сомнительно. Да и поддержка плагинов для веба в среднем меньше. Админки пилить пойдет, глубже вряд ли
«А как насчёт вопроса-допроса не от фаната-обсоса, а от разозлённого хейтера?» («Рик и Морти»)
Сейчас объясню смысл этой цитаты. Я не являюсь хейтером 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, поэтому раздувать дистрибутив не придётся. Что касается скорости, помимо Хромиума существуют быстрые и нетребовательные к ресурсам реализации, сопоставимые с нативными приложениями.
по-хорошему, надо сравнивать с HTML
Что-то лучше в описании интерфейса чем HTML/CSS/JS вряд ли можно придумать. Тут вопрос в том а точно оно Вам надо в десктопным/мобильных приложениях? Например в мобильных приложениях есть нативные контролы которые имеют нативное поведение к которому привыкли пользователи но Вам в Вашем WebBrowserBasedApplication необходимо самому это реализовывать и когда в новом sdk что-то меняется да надо снова догонять.
Мобильные и десктопные HTML-приложения можно писать на C++, C#, Java, JS, Rust… Веб-приложения (у которых бизнес-логика на стороне сервера) можно писать на C#, Java, PHP, ROR и т.п.
Это зависит от приложения, если Вам только отобразить "также как на сайте" и все то да, но если надо использовать нативные фичи на полную, есть какая-то логика которую можно выполнять на стороне приложения но которая изначально написана на стороне сервера, то тут уже не все так однозначно.
Например в мобильных приложениях есть нативные контролы которые имеют нативное поведение к которому привыкли пользователи но Вам в Вашем WebBrowserBasedApplication необходимо самому это реализовывать
<input> заточен именно под это, особенно при правильной настройке.
А вообще, как это ни странно, для кого я работал, все, наоборот, хотели кросс-платформенную унификацию дизайна. Соответственно, с кастомизацией под корпоративный стиль и т.п. вещами. Среди них были сурьёзные товарищи (типа мирового лидера по разработке промышленных навигаторов и одной конторы помельче по разработке бытовых навигаторов). Меня самого это удивляло, я вырос на Microsoft/Apple Design Guidelines, но что есть, то есть. Да и если посмотреть правде в глаза, тот же Microsoft разве следовал когда-то своим Guidelines? Со стороны кажется, они считают, что это для лохов, а сами они выше этого.
Это зависит от приложения, если Вам только отобразить "также как на сайте" и все то да, но если надо использовать нативные фичи на полную, есть какая-то логика которую можно выполнять на стороне приложения но которая изначально написана на стороне сервера, то тут уже не все так однозначно.
Я могу, опять же, только сослаться на свой опыт. Из rich-вещей я написал на HTML аналог Classic Shell (подойдёт под критерий «нативные фичи на полную»?). Понятно, что там было нужно сделать отдельно немного хендловой магии, парсер .lnk, поиск по файловой системе и тому подобные вещи, но всё основное, что съедает время в таких проектах, сделано было именно на HTML. И в ретроспективе это было правильное решение.
<input>заточен именно под это, особенно при правильной настройке.
Заточено под что? Различие в работе даже между html движками на голом input-e будут заметны. И если надо настраивать (особенно для каждого движка по своему) то простите грошь цена такому "классному" инструменту, проще использовать нативный контрол который просто из коробки будет таким как надо.
А вообще, как это ни странно, для кого я работал, все, наоборот, хотели кросс-платформенную унификацию дизайна.
Я говорил не про дизайн а про поведение нативных контролов. Дизайн понятно можно накидать быстро а вот повторить поведение/анимации/навигацию/системные вызовы/интеграции и чтобы пользователь ничего не заметил тут уже сложнее. Например ну допустим повторили Вы экран iOS приложение до пикселя но при взаимодействии с чем-то в нативном контроле вызвается системная менюшка или функцию например а в Вашем аналоге такое реализовать просто невозможно.
Из rich-вещей я написал на HTML аналог
И немного занудства, корректно говорить написал на "Web технологиях" потому что явно вы использовали и CSS и JS а то выглядит как будто Вы пользовались только HTML.
И если надо настраивать (особенно для каждого движка по своему)
Вообще, я пользуюсь одним движком, сборки которого есть подо все нужные мне платформы (Windows, MacOS, Linux и Android). И он из коробки умеет в look-n-feel нативных контролов данной платформы. Правда, как я уже написал, для реальных проектов надобность в этом возникает нечасто.
Я говорил не про дизайн а про поведение нативных контролов
Я выше поправился, заменив слово «дизайн» на “look-n-feel”.
И немного занудства, корректно говорить написал на "Web технологиях" потому что явно вы использовали и CSS и JS а то выглядит как будто Вы пользовались только HTML.
Я думаю, когда я написал, что преимущество HTML в том, что он разбит на четыре DSL'я, всё должно было стать понятно :)
Добрый день, ваши аргументы совершенно справедливые, поэтому предлагаю вернуться в 90-ые и верстать html+css.
Если же мы рассматриваем вопросы бизнеса, где нужно сделать и чтоб работало везде, то Flutter, как и многие кроссплатформы, но статья написана по той причине, что в сети большое количество KMM-убийц, которые рьяно пытаются всем доказать, что их технология топ, а все остальные ничто. И как это принято в продвижении себя, нужно замахнуться на самого сильного, чтобы попытаться привлечь аудиторию. По этой причине в сообществе гуляет много необоснованных принижений данной технологии
Добрый день, ваши аргументы совершенно справедливые, поэтому предлагаю вернуться в 90-ые и верстать html+css.
Всё наоборот: это в 90-е было авангардом, а сейчас это самый очевидный путь.
Я, кстати, в 99-м впервые это попробовал, и тогда это казалось безумно смелым экспериментом. Мне в MFC-приложение потребовалось вставить интерактивную интегрированную помощь. Ну вот, кто в те времена писал, тот помнит, как там вставлялась анимированная картинка или avi. Подумав, я добавил куда надо WebControl (Trident .ocx), после чего вместо программирования эту часть приложения стало можно просто верстать.
Если же мы рассматриваем вопросы бизнеса, где нужно сделать и чтоб работало везде
Все нулевые и десятые я именно этим и занимался: писал бизнес-приложения на связке C++/HTML. И уверяю, бизнес очень ценит такие вещи как:
Возможность сделать темы оформления или сменные головы для смартфона/десктопа, чтобы модуль бизнес-логики приложения про это ничего не знал.
Возможность что-то поправить в изолированном слое UI без перетестирования заново всего приложения, зная, что коммит гарантированно не внёс ошибок никуда глубже.
Возможность писать в разы быстрее (поскольку декларативно), и делать интерфейс гораздо круче (поскольку современный CSS из коробки умеет дофига красивого).
Возможность принципиально вынести в UI такие вещи, как подсказки при наборе (не проверку орфографии и не T9, а именно осмысленные варианты), и не иметь их в основном коде приложения (где они только мешались бы).
Возможность быстро нанять специалиста, который разберётся в UI-коде.
пытаются всем доказать, что их технология топ,
Это про HTML? ;) На нём, как бы, в данный момент пишется бОльшая часть UI.
Скажу своё мнение профана.
Да, сравнивать ui фреймворк с HTML очень правильный подход .
Будучи нубом и обучаясь разметке и вёрстке, а потом потыкав flutter, я почувствовал насколько flutter удобнее для формирования UI, особенно типичных интерфейсов.
HTML+CSS+JS , это три слоя, где один проникает в другой и может выполнять часть функций. Разобраться как сделать одну и ту же задачу лучше, когда реализаций идентичных 10 штук, немного неприятный процесс.
Так вот виджеты flutter и декларативный UI это так удобно для нуба, просто манна небесная. Есть виджеты, они друг в друга вложены, можно каждый посмотреть и разобраться как они работают.
Я считаю подход flutter более простым. А всё простое победит. Или будет популярно, как минимум.
Я не против сравнить на какой-нибудь конкретной задаче.
Можно взять ту, которую я уже упоминал: помощь с заполнением. Допустим, у нас есть поле, куда юзер вводит URL. Если он написал “fa”, надо предложить ему “https://facebook.com”. Эта задача обобщается на любой типизированный ввод (название фильма, название города, модель автомобиля данного производителя и т.п.). Устроит такая задача? Если да, предлагаю сравнить решения. Для HTML оно не только короткое и выразительное, но и полностью изолировано от кода приложения, а это значит, что оно:
Не содержит багов нигде за пределами автокомплита.
Не содержит уязвимостей на уровне приложения.
Не мозолит глаза при программировании слоя бизнес-логики, т.к. написано буквально там же, где описана конкретная форма (или библиотека для создания типовых форм).
Господин, HTML - это язык разметки, а не язык программирования. Flutter - это не только разметка. Flutter - это фреймворк языка Dart. Dart - это полноценный и очень мощный язык программирования.
Хотите - разделяйте код на бизнес логику и представление, не хотите - не разделяйте. Flutter позволяет оба варианта. Тоже самое и с веб вью.
Если конкретно вы не разбираетесь в Dart/Flutter, не надо выдавать ограничения своего восприятия за ограничения Dart/Flutter.
У Dart/Flutter есть минусы и недоработки, чтобы их понять надо наверное поработать с этим стеком.
И полностью согласен с "о Flutter должен знать каждый тимлид".
Вы просто не понимаете, как на эти вещи смотрит бизнес (и поэтому обвинения в узком кругозоре выглядят особенно комично). Последний тендер (который не напрягаясь выиграли я и HTML), включал в себя, помимо HTML, такие таких несопоставимых ни с ним, ни между собой, участников, как:
SDL
OpenGL
GDI+
Qt
JavaFX
На кону стояла разработка информационно-развлекательной системы для юзеров.
Я прекрасно понимаю бизнес. Именно поэтому я выбрал Flutter, как самую выгодную кроссплатформу. Большинство тех технологий, которые вы перечислили в списке реализуются на Dart/Flutter и FFI.
Я делал много проектов на Flutter+WebView, почему? Потому что лёгкость использовать плагины WebView + скорость разработки для 6 платформ выше чем, к примеру, на Java или Qt.
Вывод о кругозоре я делаю не из своих мыслей, а из ваших заявленний о Flutter, которые возможно имели актуальность два года назад, но сейчас экосистема Flutter позволяет очень удобно кодить, в том числе и бывшим веб разработчикам.
Если вы понимаете бизнес, то зачем тогда обвинять меня в том, что я сравниваю несравнимое? Для бизнеса Flutter это инструмент создания крутых интерфейсов, и HTML это инструмент создания крутых интерфейсов.
А если хорошо понимать бизнес, то будут ещё много интересных вопросов, например, кого проще нанять: HTML-ниндзя или Flutter-ниндзя.
Я сожалею, что изначально перегнул палку с «молодёжной прямотой» ©, можно было бы сформулировать иначе, и, возможно, получилась бы интересная дискуссия со сравнением и полезными выводами.
Извините.
Можно спокойно заменить все слова Flutter на RN, Avalonia Ui, Uno Platform, Compose(нужное подчеркнуть) и получить новую статью о плюсах искомой платформы. Хоть ГПТ не использовали и на том спасибо.
Написать данную статью меня подтолкнули размышления разработчиков, которые в 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 нужно смотреть в оба.
Ставлю жирный лойс статье за то, что много ссылок. Теперь есть повод почитать и освежить память :)
Здесь был комментарий от читателя про вакансии, но я неправильно понял функционал и отклонил его.
Отвечаю, чтобы не было ощущения игнора.
С вакансиями во Flutter все неплохо, HR регулярно заходят в личку и приглашают на разные проекты. Из минусов могу заметить, что в большом количестве случаев ищут именно middle+, поскольку в проект нужны уже опытные руки. Джунов, наверное как и везде, набирают в основном в состоявшиеся коллективы с возможностью вкладывать ресурсы в рост сотрудника, либо компании-галеры, у которых строится бизнес на продаже слабых ребят под видом специалистов.
Подробной статистики по месяцам/годам у меня, к сожалению нет, но на hh и в профильном тг канале вакансии появляются регулярно.
По ЗП могу сказать, что уровень миддл может расчитывать на 200-320тр в зависимости от компании, синьоры в среднем получают 300-400тр в зависимости от компании.
Однако следующая версия Kivy, будет использовать в качестве движка - Skia :D
Флаттер хорош в мобильной разработке, но так как это мультиплатформа, то неплохо бы его рассмотреть в контексте десктопа и веба и тут уже не все так радужно, поэтому флаттер хороший фреймворк условно.
Ну смотрите, про десктоп на 100% рано говорить, тк его допиливают, но оно уже работает, равно как и в вебе бОльшая часть функционала. С вебом в целом никаких проблем не наблюдалось, за исключением наличия поддержки от некоторых критичных пакетов. Те баги, которые появляются они спустя время решаются (поменяем пока СЕО), но раз флаттер интегрируется в виде ПВА, то становится очевидно, что это не киллер-фича.
У нас в банке (увы, уже мертвом) были планы по замене веб-версии интернет банка на флаттер приложение, поскольку после санкций ios версия и так переехала на пва и была доступна с обычной ссылки всем желающим и на декстопе.
Поэтому никто не будет спорить, что флаттер не стоит использовать в КАЖДОМ проекте, но в определенных условиях это может стать очень хорошим решением, тк возможности у фреймворка большие, из коробки можно сделать большую часть функционала даже не залезая в платформенную логику.
Однопоточность действительно проблема. Пробовал я в пет проекте выносить тяжелые расчеты в пул изолятов. И как бы все ок, но взаимодействие с ними построено нифига не удобно (особенно прерывание запущенных задач и планирование новых), плюс если надо гонять большие объемы данных (а мне надо было) - тратится время на копирование данных, что к задержке UI изолята приводит с пропусками кадров + требует дополнительных трат ОЗУ.
По некоторым другим пунктам тоже поспорить могу. Например по части размера приложения - да, 5 мегабайт вполне заметно. Приложение конечно не крупное, где то 100kloc + зависимости внешние + ресурсы, разрабатывается полутора людьми, так что понятно что там где для банков команды из десятков разработчиков миллионы строк кода фигачат и итоговые сборки 100+мб там 5мб может быть 5% всего будет, но в нашем случае это больше 30% веса добавит.
Hidden text
Не понял, как можно парсить JSON в отдельном потоке - результат парсинга же потом нужно передать в главный поток, а это, насколько я понял, можно сделать только через сериализацию-десериализацию (т.е. опять-таки парсинг).
Why Flutter? Почему Flutter?