Комментарии 17
А гугл же вроде уже забросил flutter. Какие у него перспективы теперь?
А есть кому это потом продать?
Нет ни одной нормальной причины выбрать Flutter вместо React Native. Dart намного хуже TS, фреймворк хуже React, линтеры хуже, популярность сильно меньше чем React + TS, доступность (accessibility) хуже чем у React Native Web, система лейаутов у RN flex, как и в вебе. С новой архитектурой RN производительность больше не проблема, хотя и раньше не особо была проблемой. Проекты крутые на RN на слуху, в том числе от самих Facebook - и это крайне важно с точки зрения будущей поддержки, у Flutter все грустно, гугл его забросил и не использует. Мусор.
Толсто )
"Конструктивные" нападки на Flutter со стороны React Native разработчиков выглядят так - "мыши кололись, но продолжали кушать кактус". Достаньте голову из песка и сравните две технологии объективно.
Я перешел на Flutter после долгого периода работы с React Native и по достоинству оценил качество Flutter. Change my mind :)
Еще один пустой комментарий без единого аргумента, так держать 👍
Еще один пустой комментарий без единого аргумента, так держать 👍
А Вы привели хотя бы один обоснованный аргумент? Случалось всерьёз поработать с Flutter, чтобы была возможность объективно сравнивать? Мой опыт, например, говорит о его серьёзном преимуществе над RN. У Вас же просто набор истерических выкриков типа
Dart намного хуже TS
Вот интересно, чем, да ещё и намного? Хотя бы это попробуйте обосновать.
Почитал ваше статью - серьезное преимущество это видимо потратить кучу денег компании на внедрение BDUI из за неудачного выбора технологии. Добавил там более подробный комментарий.
Dart хуже тк провоцирует писать в неудачном, устаревшем ООП стиле (это отдельный разговор), куда более многословный для одного и того же кода, особенно для функционального стиля, система типов TS это вообще шедевр по сравнению в Dart - Union type, generics и мн.др., наличие лучших фреймворков и библиотек, линтеров и тп.
Почитал ваше статью
Простите? У меня нет статей на Хабре.
Dart хуже тк провоцирует писать в неудачном, устаревшем ООП стиле
Понятно, религия. Чего сразу не хаскель тогда?
куда более многословный для одного и того же кода
Очередное голословие. Пример можно?
система типов TS это вообще шедевр по сравнению в Dart - Union type, generics и мн.др.
Вы бы хоть удосужились познакомиться с языком, который критикуете. Дженерики в Дарт есть. "И мн.др.". Юнионы же – ИМХО костыль, при наличии дженериков практического применения не имеющий. Более того, их использование, как правило, свидетельствует о низком качестве кода – программист не знает, что ему в какой момент прилетит.
наличие лучших фреймворков и библиотек, линтеров и тп.
Опять же, есть смысл познакомиться с тем, что критикуешь. Флаттер сам по себе фреймворк, зачем ещё какие-то? А чрезмерные зависимости от внешних библиотек – штука весьма опасная. В обсуждаемом комментарии я упоминал о сложностях с сборкой RN – в значительной степени вызванных применением внешних, нерегулярно поддерживаемых библиотек. Мы стараемся свести такие зависимости к минимуму. Не могу не признать, флаттер тоже не свободен от этой проблемы – но такое встречается куда реже.
Понятно, религия. Чего сразу не хаскель тогда?
Тем кто способен только верить - религия. Компетентные выбирают умом.
Очередное голословие. Пример можно?
Дженерики в Дарт есть
Никто не спорит что их нет, но в TS намного больше возможностей типизации, а более строгая типизация - меньше ошибок в коде на этапе выполнения, быстрее разработка из за autocomplete и автоматическая "документация". Взять к примеру RRC, во флаттере абсолютно невозможно полностью типизировать код типа:
// result здесь в зависимости от параметра query, здесь - User (для ненормализованной версии)
// значение query проверяется компилятором, это union type
const [{result, loading, error}, fetchUser] = useQuery({
query: 'getUser',
params: userId
})
// user здесь в зависимости от typename - в данном случае User
// значение typename проверяется компилятором - это union type
const user = useSelectEntityById(userId, 'users')Юнионы же – ИМХО костыль
Они используются во всех опенсорс проектах от крутых технологических компаний типа Microsoft и др, как и в моем коде, и используются не зря. И код выше тому доказательство - они куда компактнее и читаемее чем те же enum. С такими заявлениями стало понятно что в TS вы совсем не разбираетесь.
Не могу не признать, флаттер тоже не свободен от этой проблемы
Вот именно, и чем больше будет библиотек на флаттере, тем больше будет таких проблем, так как новички любят бездумно добавлять библиотеки чтобы "сложить два плюс два". Решение везде одинаковое - строго следить что добавляешь в проект, минимизировать нативные библиотеки.
Тем кто способен только верить - религия. Компетентные выбирают умом.
Разумеется. Там, где уместно применение ООП – используют его. Где функциональщина – там её. Я не зря упомянул хаскель – TS ровно в той же степени, что и Дарт, "провоцирует" ООП. Ибо возможно. Если стоит задача полностью отказаться, то и язык нужно брать чисто функциональный. А так в Дарте есть всё, что необходимо для функционального программирования – используйте, буде есть такое желание. Функции первого класса, кортежи, patterns matching,... – да флаг в руки, вперёд. Если же "провоцирование" выражается в том, что средства ООП в Дарт существенно мощнее, чем в TS – то это вряд ли свидетельствует о его ущербности.
во флаттере абсолютно невозможно полностью типизировать код типа:
Во флаттере абсолютно невозможно написать нетипизированный код – Дарт строго типизированный язык. И это замечательно. А за код, как в Вашем примере, я программистов бью по рукам. Ибо что он делает и с какими типами данных работает, должно быть очевидно при беглом взгляде – не должно быть необходимости писать к нему комментарии длиннее самого кода. Он как раз таки нечитаем. Кстати, стесняюсь спросить: понятие "интерфейс" Вам знакомо? Почему его не использовать вместо невнятных юнионов?
Они используются во всех опенсорс проектах от крутых технологических компаний типа Microsoft и др, как и в моем коде, и используются не зря.
Хороший аргумент. Заменим юнионы на ООП и Вы признаете его полезность?
Вот именно, и чем больше будет библиотек на флаттере, тем больше будет таких проблем
В RN эта проблема уже есть, в полный рост, и в обозримом будущем никуда не денется. Но дело в том, что она отнюдь не единственная. Перечислять все долго и ненужно – но неужели Вы думаете, что команда, которая за год довела до релиза весьма непростое приложение (точнее даже, платформу, на которой на данный момент уже 20 приложений) на абсолютно новом для себя флаттере, не в состоянии была разобраться с премудростями RN? Имея в составе пару человек, которые несколько лет уже на нём работали? А то, что RN в принципе позволил написать тот говнокод, с которым нам пришлось бороться, ни о чём не говорит?
Хочу заметить, я никого не убеждаю отказываться от RN. Комфортно вам с ним – да пожалуйста. Но флаттер – весьма добротный и качественный инструмент, который как минимум, не хуже, а по моему мнению, так и лучше. Классифицировать его, как "мусор", практически не будучи с ним знакомым – ну так себе идея. По стилю сильно напоминает разборки супругов при разводе.
Во флаттере абсолютно невозможно написать нетипизированный код
А за код, как в Вашем примере, я программистов бью по рукам
Я привел пример где нельзя типизировать, в ответ это. Слив зачитан.
Ибо что он делает и с какими типами данных работает, должно быть очевидно при беглом взгляде
не должно быть необходимости писать к нему комментарии длиннее самого кода
Комментарии здесь исключительно для вас, тех кто с пеной у рта доказывал бы что "строки это ужас, не проверяются в рантайме" и тп ерунду.
Типы все видны в среде разработки, учите матчасть потом спорьте. Больше настолько очевидные вещи объяснять не буду.
Почему его [интерфейс] не использовать вместо невнятных юнионов
Потому что юнион строже типизирует и не создает дополнительные прослойки типов чем сильно упрощает код, без оверинжиниринга, который в большинстве случаев делает только хуже. И многим не понять пока не попользуются, к сожалению.
неужели Вы думаете, что команда, которая за год довела до релиза весьма непростое приложение ... не в состоянии была разобраться с премудростями RN
Судя по тому что я пишу на RN уже много лет и проблем не имею, видится что не смогла. Хотя скорей дело в лиде, который принял некомпетентное решение, которое уже принесло проблемы и еще аукнется в будущем.
А то, что RN в принципе позволил написать тот говнокод, с которым нам пришлось бороться
Ну Flutter то конечно не позволяет писать говнокод))) С тем же успехом можно написать бесполезную статью как переписывали падающий говнокод с <любая технология> на <любая технология>.
Но флаттер – весьма добротный и качественный инструмент, который как минимум, не хуже, а по моему мнению, так и лучше
Я привел множество примеров почему он хуже, и я бы никогда не выбрал его в 2024 году как инструмент разработки. Но если вы сделали такой выбор, удачи вам.
Вы как разработчик который прошли такой большой путь, не могли бы посоветовать юным еще зеленым разработчикам, а как же все таки найти людей которые занимаются тем же чем и я? Чаты по типу Dart & Flutter не подходят так как там напрямую решаются проблемы которые возникают во время разработки, но и чаты по типу "Программисты чат" такой себе вариант ибо 90% его составляют маленькие питоноюзеры которые посмотрела полтора урока. Хочется в подробностях узнать где искать подобные обсуждения которые построены просто на общении, ибо учится одному хорошо но вместе лучше). Так же где взять поток информации который можно постоянно изучать, я ежедневно просматриваю хабр на наличие новых статей по flutter но постоянно мучает мысль что я что то упускаю.
флаттер эпически рулит
Три пути к Flutter: истории разработчиков, которые справились