Закатывает ли солнце кроссплатформенные технологии?

Вернемся к 20 июня 2018 года. Мы все на два года моложе, и пока никто не говорит о глобальной пандемии (эта часть особенно хороша, хотя, я полагаю, мы не оценили насколько хорошо это было в то время).

Airbnb объявил, что они отказываются от использования React Native в своих приложениях и вместо этого полностью используют свой собственный опыт. До этого момента они были одной из многих компаний, которые хорошо использовали платформу для разработки мобильных приложений Facebook. Через месяц Udacity прекратил эксперимент с React Native и решил не продолжать его.

В последнее время нативная разработка вообще не застаивалась. Apple выпустила SwiftUI недавно, получив широкое признание, и Android также улучшил свой собственный набор инструментов. Таким образом, аргументы в пользу нативной разработки никогда не были лучше, только одна проблема - процесс написания приложения n раз, где n - количество платформ, на которых вы хотите, чтобы ваше приложение работало.

Нетрудно понять, почему существует так много кроссплатформенных фреймворков. Написание одного и того же приложения несколько раз для нескольких платформ, похоже, нарушает один из основных принципов разработки программного обеспечения - Don’t Repeat Yourself (DRY). Но написание приложения на одном языке и его развертывание на нескольких целевых устройствах, таких как iOS или Android, всегда сопряжено с компромиссами с . Давайте взглянем на некоторые из этих технологий, прежде чем вернуться к Flutter.

Вначале была Кордова

Я знаю, что Cordova сначала была PhoneGap, и я также знаю, что концепции кросс-платформенной разработки восходят к Java и не только, но вы не хотите читать полное эссе из 20 000 слов о кроссплатформенной разработке программного обеспечения (и Я не хочу писать один), поэтому Кордова кажется хорошим местом для начала.

Когда Cordova впервые была выпущена в 2009 году, Интернет был в расцвете сил. Всего несколько лет спустя был выпущен HTML5, и идея заключалась в том, что если бы вы знали HTML и JavaScript, вы могли бы создать довольно привлекательное приложение для телефона. И это было бы верно, если бы вы были исключительно талантливым разработчиком, который понимал нюансы платформ, на которые вы нацеливались. Если ваш бизнес в первую очередь ориентирован на Интернет и вам нужно приложение для телефона, не лучше ли вы использовать существующие знания своего веб-разработчика для создания приложения, а не нанимать другого разработчика для iOS и Android?

К сожалению, было выпущено множество приложений, которые либо выглядели ужасно, либо вели себя ужасно. Создание микровайтов через Cordova, которые обладали встроенной функциональностью, было плохой заменой фактическому созданию добросовестного нативного опыта. Некоторые приложения были даже настолько плохими, что пользователь мог выделить текст в приложении (как на обычной веб-странице) или щелкнуть пальцем, чтобы увеличить части приложения, которые не были предназначены для этого, и так далее.

Со временем у нас были другие прогрессивные технологии, такие как Ionic, которые также использовали Cordova и предлагали более прочную основу для создания вашего приложения, но основные проблемы, связанные с размещением микровеб-сайта на вашем телефоне с доступом к собственным компонентам, преобладали. Самой большой проблемой, помимо удобства использования, была производительность. Использование HTML и JavaScript на устройстве в качестве приложения обычно приводило к снижению производительности.

Если ваш бизнес в первую очередь ориентирован на Интернет и вам нужно приложение для телефона, не лучше ли вы использовать существующие знания своего веб-разработчика для создания приложения, а не нанимать другого разработчика для iOS и Android?

Затем был Xamarin

В 2013 году вышел Xamarin Native, а вскоре и Xamarin Forms. Это было особенно заманчиво для людей, которые уже обладали знаниями и опытом в C # и .NET, поскольку теперь они также могли создавать приложения для телефонов. Теоретически это был данк. У вас был доступ к C # - зрелому, продвинутому языку - и вы могли разрабатывать свой пользовательский интерфейс на XAML. Некоторое время препятствием была высокая стоимость входа для фактического создания приложения Xamarin Forms, но затем Microsoft приобрела Xamarin и сделала так, чтобы любой мог разработать полноценное корпоративное приложение, не платя за лицензию.

На бумаге это невероятное предложение. Похоже, вы просто щелкнули переключателем, и вдруг каждый, кто знает C # и немного Windows Presentation Framework (WPF) или UWP (универсальная программа Windows), может создать приложение для телефона. Более того, они могут создать нативное приложение для телефона - без использования HTML или JavaScript. Производительность также была бы отличной, поскольку само приложение работало бы со скоростью, близкой к родной.

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

Эти реализации платформы, как следует из названия, предназначались для каждой платформы, поэтому, если вам нужен красивый прямоугольник с градиентом или что-то в этом роде, вам придется написать собственный рендерер для iOS, Android и даже Universal Windows. Что еще хуже, у каждой отдельной платформы был свой язык, который был сопоставлен с C # через библиотеку привязок. Это означало, что даже если вы нашли способ получить желаемый эффект, вам придется вручную переписать его на C #. Это достаточно плохо, но если вы не знаете Swift или Kotlin, вы в конечном итоге пытаетесь перевести с незнакомого вам языка на тот, который вы знаете, что, по-видимому, приведет к плохому результату.

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

А еще у нас был React Native

React Native стал, осмелюсь сказать, одной из самых популярных кроссплатформенных нативных реализаций. Это позволяет разработчику представлять собственные представления, и эти представления могут взаимодействовать с кроссплатформенным сервером JavaScript через мост. На самом деле я не слишком много использовал React Native. Мне не нравилось, как объявлялись представления, и в то время, когда я его использовал, JavaScript был единственным поддерживаемым языком, поэтому безопасность типов не была включена в это поле. Позже в React Native появилась поддержка TypeScript, но мне лично не понравились шаблоны представлений JSX или TSX для разметки моего приложения. У React Native, несомненно, огромное количество разработчиков, поэтому ясно, что многие люди предпочитают React Native для создания своих приложений.

А потом пришел флаттер

В декабре 2018 года вышел первый стабильный релиз Flutter. А теперь давайте будем честны с собой. Вероятно, я не знаю, есть сотни тысяч разработчиков, которые либо уже знают кросс-платформенный фреймворк, либо полностью довольны использованием нативных реализаций. Так что, на самом деле, с точки зрения общественного мнения, Flutter пришел в очень плохие времена. Почему я это говорю?

У людей уже есть мнения о кроссплатформенных решениях

Поскольку существует так много людей, которые использовали кроссплатформенные решения, неизбежно возникнет множество мнений о том, что уже существует. И в большинстве случаев эти мнения будут отрицательными: что они медленные, что они не работают, что вы должны пожертвовать слишком многим, чтобы получить надежный опыт. Эта критика верна и долгое время актуальна в кроссплатформенном пространстве. С Xamarin я даже убедился, что мое приложение отлично работает при отладке, а затем просто вылетает на рабочий стол, когда я пытаюсь создать релизную сборку. Я также настаивал на кроссплатформенной разработке на моем рабочем месте, чтобы мне сказали, что вместо этого мы разработаем нативное приложение.

Люди уже выбрали фреймворк

Если кто-то открыт для идеи, что кроссплатформенная разработка может работать, то, скорее всего, он уже выбрал предпочитаемый фреймворк и в настоящее время использует его для создания своих приложений. Чтобы они изменились, аргумент должен быть убедительным. Зачем вам отказываться от своего языка или фреймворка, с которым вы уже привыкли? То, что вы перемещали к, должно быть намного лучше.

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

Вы ничего не можете взять с собой

Чтобы выучить Flutter, вам необходимо выучить Dart. Вы не можете брать с собой свой JavaScript, C #, Kotlin или любой другой язык. У Dart много общего с этими языками, и сделать прыжок не слишком сложно , но для разработчика должны быть убедительные аргументы в пользу изучения Dart. Разработчики не из тех людей, которые изучают новые эзотерические языки по прихоти - они понимают, что каждый язык требует времени для изучения и еще больше времени для освоения.

Долго ли оно будет?

До того, как Флаттер приземлился, Дарт был фактически мертвым языком. Я знаю, что люди в Google использовали его в некоторых своих приложениях, но факт в том, что TypeScript был гораздо более популярным и широко используемым языком. В 2018 году он был признан худшим языком для работы. Очевидно, что в последнее время это изменилось с ростом популярности Flutter, но у Google также есть привычка убивать продукты, которые одинаково нравятся пользователям и разработчикам. Так что опасения по поводу того, будет ли Flutter существовать через два года, зная данные Google, вполне обоснованы.

Итак, мы увидели проблемы, с которыми кросс-платформенная разработка сталкивалась на протяжении многих лет, а также рассмотрели некоторые потенциальные проблемы самого Flutter. Стоит ли еще задуматься?

Как складывается флаттер?

Итак, чтобы у Флаттера даже была лошадь в этой гонке, должно выполняться следующее:

  1. Он должен быть настолько хорош, чтобы вы были счастливы выучить новый язык (дротик).
  2. Он должен предложить больше, чем нынешние игроки в этом пространстве.
  3. Поскольку вы тратите годы на ресурсы и техническую документацию для его использования (потому что он существует гораздо меньше времени, чем его аналоги), эта жертва того стоит.
  4. Вы должны быть уверены, что у него есть будущее.

Все, что я могу сделать, это размышлять о моем личном опыте, который в основном заключается в том, что я создавал приложения в Cordova, Ionic и Xamarin Forms, прежде чем перейти на Flutter. Итак, давайте рассмотрим эти моменты.

Стоит изучить Дарт для

Я знаю я знаю. Трудно выучить новый язык. Нам, разработчикам, у которых в голове уже крутится столько языков, это еще сложнее, и еще труднее для специалистов, работающих с полным стеком, которым, помимо всего прочего, приходится сталкиваться с различными языками сценариев оболочки. Но я думаю, что стоит изучить Дарт. Я использовал C #, TypeScript, JavaScript и многие другие, и мне кажется, что Dart - красивый, выразительный язык для использования.

Дротик как-то проще в использовании, чем многих других игроков в этом пространстве, но в то же время он так же могущественен, если не сильнее, чем они. Это не та статья, чтобы углубляться в операторы Dart, но даже способ, которым Dart позволяет мне управлять списками, на годы опережает все, что доступно в C # сегодня.

Он также меняет уровень многословия на условность. Например, вы можете сделать поля частными, просто поставив перед ними знак подчеркивания. Поля без префикса являются общедоступными. Есть и более мелкие изменения, которые мне действительно нравятся, например, удаление оператора new. Чтобы создать новый объект, вы просто вызываете конструктор с необходимыми параметрами, и все. Это может показаться простым изменением, но оно заставляет вас понять, что оператор new лишний и на самом деле ничего не добавляет к написанному вами коду. Я считаю, что Dart полон синтаксических сюрпризов, которые делают написание кода более приятным и быстрым.

Трудно выучить новый язык. Но я думаю, что стоит изучить Дарт.

Он может многое предложить

Возможно, это не лучшая идея - заходить в Интернет и заявлять, что один язык или фреймворк «лучше», чем другой. Это просто отличный способ начать драку. По моему личному мнению, Flutter может предложить больше, чем любое другое кроссплатформенное решение, существующее в настоящее время. Я говорю это по следующим причинам:

Отличный контроль над визуальными эффектами в приложении. Поскольку Flutter выполняет рендеринг непосредственно на экране и контролирует каждый пиксель экрана (как игровой движок), вы полностью контролируете то, что отображается на экране. В то же время у него также есть класс CustomPaint, который позволяет рисовать на экране все, что угодно. Когда вы думаете об этом в контексте того факта, что Flutter поддерживает Android и iOS, а затем, в бета-версии, Web, Windows, macOS и другие, это становится довольно феноменальным.

Тот факт, что я могу создать градиент, который выглядит «определенным образом» и воспроизводит одно и то же, независимо от того, на какой платформе он выполняется, очень впечатляет. Он предоставляет множество захватывающих и красивых впечатлений на самых разных платформах. Возможность отображать что-либо на экране без написания кода для конкретной платформы - это то, что я нашел доступным только во Flutter. Конечно, есть невероятный набор готовых виджетов, которые поставляются с фреймворком, и вы можете использовать их по своему усмотрению, но также углубитесь в мелкие детали и самостоятельно визуализируйте некоторые настраиваемые элементы управления, когда вам нужно что-то особенное. посмотрите или почувствуйте.

Собственная производительность. Flutter создает собственное приложение для устройства iOS или Android, на котором оно работает. В сочетании с усилиями Google, направленными на то, чтобы каждое приложение работало со скоростью 60 кадров в секунду, это означает, что приложения очень удобны в использовании. Даже в способах, которыми Flutter отображает ListView , означает, что элементы в списке отображаются только тогда, когда они прокручиваются в поле зрения, что обеспечивает высокий уровень производительности и меньшее использование памяти на устройстве. Вам не нужно выполнять какие-либо сложные математические вычисления, чтобы определить, отображается ли элемент списка на устройстве или нет, Flutter сделает это за вас.

Отличный выбор государственного управления. Когда вы работаете над приложением большего размера, вам всегда, вероятно, придется выбрать платформу для развития, а не просто полагаться на то, что дает вам собственная среда. В Xamarin это обычно какой-то вариант модели представления ViewModel (MVVM). На Flutter это обычно паттерн BLOC. После создания архитектуры приложения в Xamarin Forms и последующего переписывания того же приложения во Flutter я чувствую, что BLOC более расширяемый, простой в использовании и легче тестируемый, чем все, что я использовал в любой другой платформе.

Он обеспечивает правильный кроссплатформенный баланс. В Xamarin Forms абсолютно все написано на C #, даже реализации средств визуализации для конкретных платформ. Не поймите меня неправильно, я знаю, что во многом суть Xamarin заключается в написании кода вашей платформы на C #, и написание общей части вашего приложения на C # имеет смысл. Написание специфичных для платформы битов на C # не имеет смысла и, на мой взгляд, только усложняет процесс.

Причина, по которой я так считаю, заключается в том, что быстро становится непонятно, что «правильно» использовать в коде для конкретной платформы. Например, на Android вы используете List или JavaList? Они не взаимозаменяемы, и если вы воспользуетесь неправильным, в лучшем случае вы получите ошибку безопасности типа или, в худшем случае, вызовете проблемы в своем приложении.

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

Что не так с привязкой библиотек?

Xamarin предоставляет встроенную функциональность на устройстве через так называемую библиотеку привязки - библиотеку, которая сопоставляет внутреннюю поверхность API с его эквивалентом в C #. Это означает, что когда вы ищете способ выполнить свою конкретную задачу, вы обычно всегда найдете результаты только на родном языке этой платформы и очень редко найдете результаты, которые уже написаны для вас на C #.

Это означает, что вам нужно переписать любую функциональность с его родного языка (например, Kotlin, Objective-C или Swift) на C #. Как кроссплатформенный разработчик с ограниченным знанием этих языков, вы, возможно, в лучшем случае могли бы повозиться с существующими исправлениями в StackOverflow, но полное их переписывание на другом языке просто вызывает проблемы.

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

Когда я переписал свое приложение с Xamarin Forms на Flutter, я перешел от требования платформенно-зависимого кода для определенных средств визуализации и т. Д. К тому, что он вообще не нужен.

Доступно удивительное количество технической информации.

Каждую неделю (или около того) на YouTube-канале Flutter появляется новый видеоролик Виджет недели, демонстрирующий, как использовать определенный виджет во Flutter. Возможно, это звучит так же увлекательно, как наблюдать за высыханием краски, но некоторые из виджетов позволяют создавать по-настоящему красивую анимацию и взаимодействия, которые вы можете легко применить в своих приложениях.

Другие компании, такие как Codemagic (поставщик CI / CD), идут дальше, также предлагая технические руководства по другим областям Flutter. По моему опыту, существует достаточно технической информации, чтобы сегодня можно было создавать большинство приложений, и вы, вероятно, не столкнетесь с проблемами, уникальными только для вас.

Он будет держаться *

(*наверное)

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

Итак, стоит ли использовать Flutter? Стоит ли изучать совершенно новый язык, отказываться от других доступных ресурсов, которые есть у других фреймворков, потому что они существуют дольше, и торговать ими, чтобы иметь возможность использовать Flutter в качестве фреймворка для своего телефонного приложения? На мой взгляд, да. Это определенно.

Это проблема времени

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

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

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

Получайте удовольствие и получайте удовольствие по пути 😊.