>> Flutter Desktop и Flutter Web были просто ужасны, это был просто тот же самый мобильный UI, просто растянутый на десктопный экран
Если вёрстка была изначально задизайнена для мобилок, не стоит ожидать, что при запуске на десктоп она сама собой превратится в вёрстку, идеально адаптированную для десктопа. Это отдельная большая работа по адаптации, и она лежит в плоскости работы в первую очередь дизайнера, а не разработчика.
Фреймворк позволяет написать хорошо адаптированное приложение. Большего от него требовать я бы не стал.
2) Лучше, чем описано в этой статье, я не отвечу: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf. TL;DR смысл есть, не просто потому что гуглерам взбрело в голову. На момент проектирования фреймворка не существовало другого языка и рантайма, который бы обеспечил его потребности.
3) Реально писать кроссплатформенные приложения, но нужно понимать, где граница между прикладной надстройкой и платформой. Волшебства не бывает, с платформой надо "разговаривать" на платформенном языке. Но все стандартные кейсы закрыты готовыми плагинами, избавляющими от необходимости часто лезть в нативную часть.
4) Когда нужно писать платформенную интеграцию, нужно доставать "нативный" для платформы язык. Для iOS - Swift или Obective C, для Android - Kotlin или Java и так далее. Добавлять их не сложно, но некоторое количества бойлерплейта написать придётся.
В дополнение к вышесказанному, Dart компилируется в нативный код, что хотя бы с точки зрения реверса даёт какую-никакую безопасность. js никогда не будет достаточно безопасен для проекта, где это имеет большое значение.
Спасибо за развёрнутый комментарий, я согласен с вашими наблюдениями.
Да, вероятно, что серьёзный проект облсужить при помощи Github Actions будет непросто. Но для небольшого опенсорса или пет-проекта — это отличный вариант. Простота интеграции с репозиторием, который и так в 99% случаев будет у вас на Github заставляет простить многое.
Об этом буду писать в следующей части. Сейчас как раз разбираюсь с этим.
Скорее всего пойдем решать эту задачу через Fastlane, благо, готовые экшны для него есть.
Всё дерево виджетов создаётся в коде, и единственный способ визуализировать его — в виде древовидной структуры в одной из вкладок плагина. Но есть утилиты, позволяющие эмулятор использовать в качестве интерактивного макета. Открываешь «Flutter Inspector», кликаешь на «Toggle Select Widget Mode», далее жмёшь на любой UI-элемент в запущенном приложении и инспектор тебя перебрасывает к нужному элементу в дереве виджетов.
Основной момент, в котором Flutter со старта имеет большое преимущество — производительность. Не нужно использовать JS Bridge при прямом обращении к платформе, а за счёт этого значительно проще выйти на 60 FPS при отрисовке UI.
Был бы рад, если бы вы были правы, но вы сильно преувеличиваете рентабельность едтех-проектов.
>> Flutter Desktop и Flutter Web были просто ужасны, это был просто тот же
самый мобильный UI, просто растянутый на десктопный экран
Если вёрстка была изначально задизайнена для мобилок, не стоит ожидать, что при запуске на десктоп она сама собой превратится в вёрстку, идеально адаптированную для десктопа. Это отдельная большая работа по адаптации, и она лежит в плоскости работы в первую очередь дизайнера, а не разработчика.
Фреймворк позволяет написать хорошо адаптированное приложение. Большего от него требовать я бы не стал.
1) Android - 6 Мб, iOS - 29 Мб
2) Лучше, чем описано в этой статье, я не отвечу: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf. TL;DR смысл есть, не просто потому что гуглерам взбрело в голову. На момент проектирования фреймворка не существовало другого языка и рантайма, который бы обеспечил его потребности.
3) Реально писать кроссплатформенные приложения, но нужно понимать, где граница между прикладной надстройкой и платформой. Волшебства не бывает, с платформой надо "разговаривать" на платформенном языке. Но все стандартные кейсы закрыты готовыми плагинами, избавляющими от необходимости часто лезть в нативную часть.
4) Когда нужно писать платформенную интеграцию, нужно доставать "нативный" для платформы язык. Для iOS - Swift или Obective C, для Android - Kotlin или Java и так далее. Добавлять их не сложно, но некоторое количества бойлерплейта написать придётся.
Вопрос не очень понятен. Что именно они собирать могут?
«hello world на flutter по прежнем занимает 5Mb?»
Давно не смотрел, но точно не меньше.
«Появилась ли возможность собрать desktop приложение?»
Да, пока далеко не в стабильном канале, но есть.
«Есть ли проблемы с тормозами при срабатывании garbage collector?»
Нет.
Да, вероятно, что серьёзный проект облсужить при помощи Github Actions будет непросто. Но для небольшого опенсорса или пет-проекта — это отличный вариант. Простота интеграции с репозиторием, который и так в 99% случаев будет у вас на Github заставляет простить многое.
Скорее всего пойдем решать эту задачу через Fastlane, благо, готовые экшны для него есть.
Если хочется ещё строже, можно «затянуть гайки» на уровне статического анализатора:
dart.dev/guides/language/analysis-options#enabling-additional-type-checks
Всё дерево виджетов создаётся в коде, и единственный способ визуализировать его — в виде древовидной структуры в одной из вкладок плагина. Но есть утилиты, позволяющие эмулятор использовать в качестве интерактивного макета. Открываешь «Flutter Inspector», кликаешь на «Toggle Select Widget Mode», далее жмёшь на любой UI-элемент в запущенном приложении и инспектор тебя перебрасывает к нужному элементу в дереве виджетов.