Потому что этот здесь, чтобы остаться.

Некоторое время я искал гибридные мобильные решения, но не изучал Android (Java) или iOS (Objective-C). Как backend-разработчик, мне нужно было практическое решение с приятной документацией и относительно низкой кривой обучения.

Поскольку я не большой поклонник создания компонентов с нуля, я также искал набор готовых компонентов, которые были бы легко настраиваемыми и, наконец, также были бы перформативными. Было не так уж много вопросов, правда? Я искал то, что нужно каждому программисту, когда они собираются узнать что-то новое.

Большая проблема в том, что все решения, которые я нашел в процессе, лишь частично удовлетворяли требованиям. В общем, решения всегда имели некоторые недостатки с точки зрения производительности и встроенного опыта (как и в случае с такими опциями, как WebView или Bridges).

Задача была решена, и я был взволнован открытиями, которые я сделал в процессе. И да, конечно, я подумал о React Native! Я еще вернусь к этому моменту, но я хочу лучше рассказать вам обо всем моем пути с Flutter в этом посте:

Встреча с Флаттером

Когда я встретил Флаттера, он был уже 1 год в бета-версии, но без версии 1.0.

Я был удивлен, обнаружив, что даже в бета-версии некоторые приложения уже были в разработке. Конечно, их было немного, но у них уже было несколько анимаций и функций, необходимых для создания отличного приложения.

Если вы еще не знаете, Flutter поддерживается Google. Этот звонок заставил меня почувствовать твердость («этот никуда не денется»), особенно после того, как Google вложил значительные средства в маркетинг, учебные пособия и собственную команду разработчиков Flutter.

Еще одна любопытная особенность Flutter - это язык Dart, созданный Google в 2011 году. В то время большинство программистов никогда не слышали о Dart - и я включаю себя в этот список.

Этот язык Dart был моим первым препятствием при работе с Flutter. В любом случае, я решил пойти глубже и проследить. Стоит поделиться с вами тем, что я узнал.

Язык дротиков

Должен признаться, что поначалу я сопротивлялся Дарт и его печатанию. Я всегда пытался печатать все, что мог, и даже тогда это было препятствием для Dart.

Однако я не сдавался и сразу принял эту идею. Вместе с IDE я начал продюсировать. Примечательно, что даже в самом начале мне удавалось что-то продюсировать. Это только подтвердило, что у Flutter будет низкая кривая обучения, которую я искал. Конечно, я говорю это, потому что я уже программировал на другом языке.

То, что было препятствием вначале, стало положительным. В конце концов, я заметил, что, поскольку Dart был напечатан, я делал меньше ошибок времени выполнения или синтаксических ошибок, поскольку среда IDE всегда показывала мне правильный метод и поскольку индексация выполнялась поверх объектов Dart. По сравнению, например, с Javascript или Ruby, это намного проще.

Кроме того, то, что делает Dart идеальным языком для Flutter, - это поддержка JIT (Just-in-time), упрощающая разработку (Hot reload) и AOT (Ahead-of-time), которая очень эффективна в производстве.

Почему Флаттер привлек мое внимание?

Поняв язык Dart, я смог сосредоточить свое внимание на Flutter.

Больше всего меня привлекло то, что эта идея решает проблему: дублирование кода в мобильном мире. Одна только эта единственная цель заставила меня укрепить уверенность в том, что это будет мощный инструмент.

Еще одна особенность Flutter заключается в том, что это фреймворк пользовательского интерфейса, то есть созданный для того, чтобы вы могли управлять пользовательским интерфейсом вашего приложения. Другими словами, можно сказать, что процессы созданы для такой оптимизации и производительности.

Поскольку он создан для пользовательского интерфейса, будет справедливо иметь много (но много!) Готовых к использованию компонентов. И это именно то, что фреймворк предоставляет изначально, что дает вам уверенность в том, что этот компонент или виджет будет отрисован с максимальной производительностью.

Говоря о производительности, возможно, что Flutter вообще не имеет моста и отображает виджеты непосредственно в системе, используя для этого Skia Engine, что создает меньше проблем и узких мест, чем использование мостов.

Как работает архитектура Flutter

Flutter не имеет стандартной или рекомендованной архитектуры. Некоторым это может показаться плохим моментом, но, на мой взгляд, это положительный момент. В конце концов, таким образом можно создать что угодно и, таким образом, отлить решение проблемы.

Я видел что-то подобное на Vue раньше. И работая с Vue, я чувствовал себя свободно, создавая архитектуру, которая подходила бы именно для моего проекта.

Еще один важный момент, о котором стоит упомянуть, - это «управление состоянием во флаттере». Даже после использования Flutter я все еще не мог решить, какой тип управления состоянием я предпочитаю. Сегодня существует несколько вариантов, таких как SetState (native), Mobx, Bloc, Provider, Redux и другие, каждый со своей особенностью и популярностью.

Для тех, кто только начинает, Provider - отличный вариант, так как SetState болезненен для приложения. Несмотря на то, что Bloc является одним из наиболее часто используемых, он более сложный, плотный и требует некоторого изучения перед практикой.

Поскольку Provider очень похож на других менеджеров состояний, которым я научился во внешнем интерфейсе, это мой выбор сегодня для архитектур, которые я создаю.

Google Fuschia: операционная система, использующая Flutter

Fuschia - это новая операционная система Google, которая будет напрямую конкурировать с Android (также принадлежащим Google). Да это правильно.

В этой операционной системе интересно то, что она также написана на Dart и использует Flutter в качестве GUI SDK.

Примечательно, что изначально приложения, разработанные для Fuschia, будут работать поверх Flutter, сразу после запуска Google Fuschia. Так что тот, кто знает Flutter, наверняка будет впереди на рынке.

У Flutter не только цветы.

Как и в случае с любой другой структурой, совершенства не существует. И Flutter не был бы исключением. Сегодня есть еще определенные проблемы. Я поделюсь некоторыми:

  • Язык Dart. Как я уже упоминал в этой статье, использование языка Dart является большим препятствием для многих разработчиков и компаний при выборе фреймворка;
  • Сообщество - например, для тех, кто использует Javascript, вы почувствуете разницу в участии сообщества. Как и в случае с любым новым инструментом, этот процесс построения сообщества требует времени для развития. Мы смогли ясно увидеть это с помощью Google Trends и StackOverflow.

В любом случае, почему я выбрал Flutter вместо React Native?

Когда вы думаете о фреймворке для мобильной разработки, это нормально, что первое имя, которое приходит вам в голову, - это React Native. В конце концов, он написан на JavaScript и использует мосты для рендеринга компонентов.

Фактически, React Native уже хорошо зарекомендовал себя на рынке, и для нового программиста, ищущего работу, Stack JS всегда является отличным вариантом. Однако, несмотря на то, что у нас работает много приложений с React Native, по-прежнему существует большая разница в производительности между React Native и Flutter.

Помимо производительности, следует отметить, что в React Native большую часть времени необходимо использовать сторонние пакеты, что, на мой взгляд, создает зависимость от пакетов, выпуск которых можно прекратить в любой момент.

Вскоре я обнаружил, что Flutter - отличный инструмент для рисования пользовательского интерфейса с отличной производительностью, почти сопоставимой с нативным. Таким образом, можно создавать приложения с собственным интерфейсом для Android и iOS с помощью всего одного кода.

Также: используя Dart в качестве базового языка, Flutter поддерживает JIT (Just-in-time), что значительно упрощает его во время разработки, и AOT (Ahead-of-time), что значительно повышает производительность при работе в продакшене.

Сообщество растет и уже во многом удовлетворяет потребности проектов. И поскольку он поддерживается Google, есть хорошие гарантии, что Flutter действительно останется.

Думаю, важно подчеркнуть, что я не осуждаю React Native и любые другие фреймворки или языки! Я сам использую другие варианты, потому что одно можно сказать наверняка: одна технология не исключает другую. Просто используйте лучший вариант для поиска конкретной проблемы, которую необходимо решить.