Comments 20
Все справедливо
Интереснейшая статья, спасибо. Подробный анализ от человека непосредственно "с полей", внимательно прочитал, во многом мои ощущения подтвердились. Похожее мнение у Attila Vágó в его статье "I Am Falling Out Of Love With Flutter" на медиуме.
Ситуация с Dart напоминает ActionScript. И хотелось бы под Rust иметь Flutter
В чём смысл статьи?
Flutter и Dart - несовершены? Да
Если что-то лучшее и качественнее решающее проблемы (Android, iOS и crm на web) чем Flutter и Dart? Сомневаюсь
Часто люди ноют применяют те инструменты которые применять не стоит каких-то ситуациях, и получают проблемы)
Особенно угорнул с "нативных ui" на flutter, друг ты явно не понимаешь чего хочешь и как это решить
Смысл статьи в том, что проблемы как перечислены, так и объяснены. Что приводит к практически верной мысли что других проблем нет. И да, хотелось бы идей про почему так, но это не про смысл, а про качество.
Что-то лучшее точно есть, особенно если вместо типа приложений перечислять платформы и не конкретизировать «лучшее». Кстати, в таком перечислении Мак, Окна и Линукс обязаны присутствовать. С ходу - Godot.
«Нативные UI» тоже напрягли, но это вполне себе болевая точка - балаган Flutter годы колесит по миру, а вот ведь как его воспринимают.
Если что-то лучшее и качественнее решающее проблемы (Android, iOS и crm на web) чем Flutter и Dart?
Delphi - FMX (все платформы, не нативные контролы или частично)/FGX (Android/iOS, нативные контролы). При этом код всегда нативный. Под веб, конечно, пока не может. Но ждем сборку под WebAsm уже
Сравнения не корректные, судя по сайту FGX платный, да и много людей со знаниями Delphi или желающих в него инвестировать свое время? Dart в этом плане ничем не лучше, но сам язык простой + синтакс похож на Java, переход не такой сложный.
FMX насколько понимаю тоже не совсем бесплатный, по крайней мере на сайте бесплатно предлагают только попробовать.
Ну и к обоим этим проектам вопросы про зрелость, поддержку, количество успешных проектов. Думаю, если поковырять их то там будет куда больше проблем, чем перечислено в статье.
FGX не бесплатный, да, а вот FMX входит в поставку среды как второй фреймворк. "Платность" такая же как и в VS. Т.е. есть некоммерческое использование (Community версия) и коммерческое.
Зрелость. Ну FMX уже лет так 17-18. Развиваться усиленно начал где-то лет 10 назад. Сейчас на нём серьезные проекты пишутся без проблем.
FGX более молодой фреймворк, но работает по иному принципу, т.к. является по сути оберткой над нативными контролами мобильных платформ. Серьезные проекты уже пишутся и не мало.
У FMX есть свои болячки, не без этого. Правда у кого их нет. В частности, есть проблемы с рендером текста (он там не очень оптимальный). Ну и сам фреймворк пока ограничен на андроид в 60fps, на иос 120fps под свежий SDK.
В остальном, FMX достаточно уникален. Со своей системой стилизации. Если в кратце, то любому контролу можно придать любой вид (в любой момент). Например, можно обычной кнопке придать вид таблицы или наоборот. Пример крайне странный, но показательный.
С его помощью можно почти в полной мере повторить HTML/CSS стилизацию. При чем не прибегая к коду. Пара примеров под спойлером
FGX не бесплатный, да, а вот FMX входит в поставку среды как второй фреймворк. "Платность" такая же как и в VS. Т.е. есть некоммерческое использование (Community версия) и коммерческое.
Ну т.е. если хочу выпустить свой продукт, на котором буду зарабатывать деньги, то нужно в любом случае покупать их лицензию?
Это не совсем корректно, т.к. flutter бесплатный и там никаких ограничей нет.
Думаю позволить себе купить лицензию "профессионал" за 50-70к (я за столько покупал) можно. За достаточно удобный инструмент я не пожалел денег.
Но тем не менее, да, вы правы. Напрямую сравнивать не очень корректно. Однако, мы здесь обсуждали альтернативу и в контексте проблем, а не только стоимости и доступности
Ну чтобы тут сравнивать в контексте проблем, хорошо бы иметь опыт использованися обеих технологий. У меня такого нет, поэтому вам виднее) Но судя по тому что вы написали, выглядит довольно интересно.
Если говорить про те проблемы которые описаны в статье, то в нативной разработке например (Android) их не меньше, но они другие. Везде есть проблемы, идеального ничего нет, многое зависит от самих разработчиков, их опыта и желания изучать что-то новое.
Удивительно, что про точку с запятой не упомянуто в статье.
Как я понял, в большинстве случаев, Intellij Idea не виновата, так как они просто подключаются к Dart Analysis Server. Порой кажется, что в команде Dart не хотят что-либо улучшать. Не хочу никого оправдывать, но выходит, что IDE виновата только от части и это не отменяет проблем описанных в статье. Я бы, например, очень хотел бы, что бы локальные переменные или функции имели приоритет в выдаче, но мечтать не вредно. тыц
Логично встает вопрос: если стандартные компоненты приходится переписывать для кастомизации под конкретные проекты, то зачем Material и Cupertino виджеты гвоздями прибиты к Flutter SDK? Не логичнее ли было вынести их как отдельные пакеты и подключать по необходимости?
Наверное, это может быть решено
Как итог, пока что стараюсь не использовать эту функцию, хотя большинство коллег пользуются ею на ура. А вы используете эту возможность? Были ли с ней проблемы?
Виджеты пересобирать - норм работает же
Самым ярким примером я бы назвал go_router ... Нестабильный API, большое количество багов, проблемный генератор роутов, сложности в вебе. И все это подается под соусом лучшего решения для Flutter — проекта
Кстати, у Flutter есть такой интересный репозиторий, где они обсуждают как реализовать те или иные вещи. И в нём можно найти как они пришли к go_router.
Как я понял, в большинстве случаев, Intellij Idea не виновата, так как они просто подключаются к Dart Analysis Server. Порой кажется, что в команде Dart не хотят что-либо улучшать. Не хочу никого оправдывать, но выходит, что IDE виновата только от части и это не отменяет проблем описанных в статье. Я бы, например, очень хотел бы, что бы локальные переменные или функции имели приоритет в выдаче, но мечтать не вредно. тыц
В статье речь шла о языковом плагине, который в свою очередь и использует Dart Analysis Server. К IDE претензий нет.
Наверное, это может быть решено
Да вот это было бы здорово. Возможно когда-нибудь в будущем это случится. Ведь все предпосылки для этого есть.
Виджеты пересобирать - норм работает же
Вот у меня не всегда, и мне проще просто не использовать, чем выяснять проблема в коде, или просто хот релоад не сработал.
Кстати, у Flutter есть такой интересный репозиторий, где они обсуждают как реализовать те или иные вещи. И в нём можно найти как они пришли к go_router.
Интересно, спасибо! Почитаю.
Я вас отвечу комментарием из процитированной вами же статьи статьи
1) Ты можешь, либо сгенерировать код, либо написать код. Код генерируется по правилам, которые заложил разработчик генератора. Не нравится - используй другой генератор. Не нравятся все кодогены - пиши ручками.
3) Почему голый sdk обязан сериализовывать json (и кучу прочих форматов) в модельки ? Используй генераторы или самописные мапперы. Это обязанность разработчика.
5) Срзн ? Flutter несет с собой один из самых больших тулингов из коробки. Что-то я не видел в поставке kotlin ios и macos компоненты. Бред чистой воды.
7) А может платформа сама должна написать весь интерфейс по тз ? Нужны специфические возможности видео плеера? Заноси на проект нативный код и реализуй.
9) Не хватило фантазии на 10 пунктов и просто повторяете 2 ? Плагины и пакеты - отдельные продукты, с отдельными тестами, которые нужно отдельно запускать, это самоочевидно. Когда вы тестируете свою приложение - должно тестироваться само приложение, и ни в коем случае не должны тестироваться все пакеты, которые задействованы в проекте.
Вы называете себя Solution Architect и вы позорите эти слова. Не потому-что вы некомпетентны(у вас огромный опыт и вы понимаете о чем говорит), а потому-что вы пытаетесь поймать волну популярности самим грязным и обесценивающим труд создателей flutter способом - критикой надуманных и высосанных из пальца проблем.
Я сожалею, что это статья существует.
Где та самая киллер‑фича языка?
Возможность компилироваться в jit и aot. hot-reload/hot-restart. Isolate. Future и Stream api.
Вообще то что вы хотите под "инновационность" это больше похоже на сахар, который уже можно потрогать в dart 3.
Работа над ошибками
Автор, а вам не кажется что вы хотите "здесь, все и сразу"? Как раз Google умеет в планирование и они это делают в нужной момент времени, с пониманием куда язык растёт и какие он потребности закрывает.
По поводу ваших примеров кода, вас не смущает что вы сравниваете getter?
Кодогенерация
Вы сравнили кодоген из C# и dart, но похоже явно не понимаете в чем между ними разница и как они работают, для вас важен лишь результат (скорость). Я видел проекты когда MSBuild собирался по 15 мин, вот это я понимаю скорость...
По поводу макросов, их уже делают, можно потрогать в dart 3.
Грабли
Из этой части я все больше стал приходить к тому, что Автор не любит Google и в этом основная проблема.
Сравнение с современниками
А вот это вообще глупо, каждый язык разрабатывается под конкретную задачу. Сравнивать их в лоб по количеству сахара, как-то тупо...
Java в Intellij Idea, C# в Rider или JS/TS в WebStorm
Вот тут ситуация интересная, все что вы перечислили конкретные реализации ide под нужды конкретного языка, когда в свою очередь поддержка Dart в Intellij Idea создаётся через плагин и командой гугла. Странно что вы не указали GoLand ;)
Кастомизация
По моим наблюдениям стандартные компоненты и не нужны. В плане написания своих виджетов есть полная свобода, и нечего вам в этом не мешает. Также я бы сказал что это рай для дизайнера, спросите как дизайнер делает ui/ux для нативных приложений :)
Заключение: я бы мог опровергнуть каждое ваше предложение, но мне банально лень. Так же, можно сделать подобные статьи на любой ЯП, и по содержанию они будут примерно такими же, но это не значит что тот или иной ЯП плохой или имеют недостатки.
Динамическая типизация разрешалась в первом Dart по причине того, что так проще перейти на Dart с JS, а это виделась как большая аудитория.
Во второй версии строгая типизация пришла потому, что так хотели пользователи языка.
Так язык и развивается дальше, учитывая пожелания тех, кто его использует. И мне так очень даже нравится.
Почему не придумать бы все сразу? Потому что слишком сложно учесть, какую судьбу в будущем постигнет язык. Это уже спор про выпуск продукта сразу готового и без изменений против итеративной разработки.
Автор, я имею опыт работы на Dart/Flutter ещё с первой версии языка, с тех пор внимательно чекаю новые версии и то что мне нужно использую, так вот что я скажу:
Во-первых: часть проблем из статьи о производительности у меня лично не наблюдается. Может быть это вопрос к Вашему железу?
Во-вторых: приходилось писать разные приложения, но, акцентируя внимание на поиске решения, вместо того чтобы зацикливаться на проблеме - удалось решить практически все возникшие проблемы + с каждым новым обновлением этих проблем всё меньше, это очень радует.
В-третьих: насчёт киллер-фичи, а чем текущая кроссплатформа - это не киллер-фича? Я перепробовал Cordova, Xamarin, React Native. Не то они, не то. А Flutter - то.
В-четвёртых: Dart - отличный язык программирования. Я не выбирал Dart из-за Flutter, мне изначально понравился именно Dart. И он, кстати, больше похож на C#, чем на Java.
В общем: спасибо за некоторые моменты в статье - очень объективная критика, но не надо так сильно пинать, технология активно развивается и уже вполне себе классная и юзабельная.
Спасибо за статью. Справедливости ради отмечу, что в Dart есть рефлексия. Ее убрали во Flutter, да, но сам Dart вполне успешно справляется с анализом AST при выполнении (в частности, это используется в ORM на Aqueduct/Conduit).
Болевые точки Dart и Flutter