Native и PWA: выбор, а не претенденты!

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

Меня не интересует этот бой. Конечно, я «веб-парень», но это не значит, что я не вижу привлекательности нативной разработки; Я также разработчик программного обеспечения. Но прежде всего я прагматик. Я понимаю, что каждый проект уникален, и что наш подход к каждому должен быть адаптирован к потребностям и целям проекта.

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

Быстрое сравнение

Практически с самого начала веб-приложения сравнивали со всем, от программного обеспечения для настольных компьютеров (оригинальные «нативные приложения») до интерактивных компакт-дисков, Flash и, совсем недавно, с мобильными приложениями. Несмотря на то, что сеть неоднократно объявлялась мертвой, она сохранилась. Во многих случаях он даже пережил своих предполагаемых убийц (RIP Flash).

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

Однако одна область, в которой Интернет исторически терпел неудачу, была в области производительности. Установленное программное обеспечение может быть связано с базовой операционной системой способами, недоступными для Интернета. Они написаны на лингва-франка своего хоста, с прямым доступом к оборудованию или «ближе к металлу», как мы часто говорим. Интернету, который почти всегда оперирует одним или несколькими уровнями абстракции над этим, было трудно конкурировать, когда дело доходит до производительности. Хотя разрыв в производительности со временем сократился, нативный код, скорее всего, продолжит работать быстрее, чем веб-код, по крайней мере, до тех пор, пока сеть не сможет интерпретировать сигналы непосредственно с аппаратных контактов.

Наряду с преимуществом в производительности, нативная разработка имеет гораздо более широкий (и более ранний) доступ к таким функциям устройства, как NFC, Bluetooth, датчики приближения и внешней освещенности и многое другое. Интернет также неуклонно получает доступ к этим функциям, но он всегда будет отставать от нативных, потому что нативные API-интерфейсы должны быть разработаны до того, как Интернет сможет их использовать, а стандартизация в среде браузера требует времени.

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

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

Сервисные работники являются одним из трех технических стержней PWA. Еще один — манифест веб-приложения. Хотя это может показаться немного скучным, манифест веб-приложения на самом деле является невероятно мощным инструментом, поскольку он позволяет веб-сайту рекламировать себя как приложение. Этот относительно простой формат файла JSON предоставляет обширную информацию о веб-сайте, который он описывает, и позволяет браузерам и операционным системам, поддерживающим PWA, устанавливать сайт, как если бы это было собственное программное обеспечение.

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

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

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

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

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

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

Когда дело доходит до подбора персонала для разработки продукта, определенно проще нанять людей, которые знают, как создавать продукты для Интернета. Пока я печатаю, индекс языков программирования в настоящее время оценивает JavaScript как самый популярный язык, сразу за ним следует Java. C# находится на 5-м месте, HTML — на 7-м, CSS — на 9-м, а Swift — на 15-м. Этот индекс ссылается на теги переполнения стека со строками, измененными в общедоступных репозиториях на GitHub, поэтому его следует воспринимать с долей скептицизма, но он дает довольно четкое указание на то, что многие люди знают (и используют) веб-технологии. С другой стороны, часто бывает сложно найти и нанять талантливых нативных разработчиков, потому что их меньше и они пользуются большим спросом.

Редкий талант означает, что вы, вероятно, в конечном итоге будете платить больше за нативную разработку. Очевидно, что каждый проект уникален и имеет разные функции и требования, но для наглядности можно посмотреть на средние затраты на разработку в качестве сравнения. Comentum предполагает, что создание веб-приложения среднего размера стоит от менее 10 000 до 150 000 долларов США. По оценкам Appster, стоимость проектов мобильных приложений среднего размера составляет от 110 000 до 305 000 долларов США. Вероятно, можно с уверенностью предположить, что нативные проекты, вероятно, будут стоить примерно в два раза дороже, чем веб-проекты. И это на платформу. Нативные приложения также обычно требуют больше времени для разработки.

Стоит отметить, что существуют варианты создания собственного программного обеспечения с использованием веб-технологий без создания PWA. Такие платформы, как React Native, PhoneGap, Ionic и Appcelerator Titanium, позволяют создавать собственный код из HTML, CSS и JavaScript. Использование одного из этих инструментов может снизить ваши расходы на персонал и разработку по сравнению с наймом команды нативных разработчиков, но с точки зрения доступа к функциям устройства ваш проект будет ограничен теми, которые реализованы фреймворком. Планируйте соответственно.

После разработки приложения вы также должны учитывать текущие расходы на обслуживание указанного приложения или приложений. В ответ на опрос, проведенный Clutch, Dom & Tom рекомендует закладывать в бюджет 50% от начальной цены продукта в первый год, 25% во второй год и 15-25% на каждый последующий год.

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

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

Проект №1: Существующее нативное приложение

Допустим, вы уже прошли процесс создания нативного приложения. Если все идет хорошо, нет причин менять курс. Не выбрасывайте всю свою существующую работу, чтобы переключиться на PWA, если у вас нет действительно веской причины для этого. Я могу представить только один сценарий, который может оправдать переход на PWA: добавление поддержки новой ОС. И даже тогда это действительно имеет смысл только в том случае, если потребности вашего приложения могут быть удовлетворены только в Интернете.

Если вы добавляете в продукт поддержку новой платформы, это создает прекрасную возможность оценить потребности и цели проекта с точки зрения стоимости удовлетворения этих потребностей. Если веб не подходит для этой задачи, придерживайтесь нативного. Однако, если это так, сделайте паузу и подумайте об этом: добавление поддержки новой платформы с помощью PWA позволит вам поддерживать дополнительные платформы (включая Интернет) в будущем и может даже позволить вам заменить существующее родное приложение после того, как PWA был тщательно протестирован.

Если замена существующего нативного приложения на PWA кажется вам немыслимой, подумайте об этом: Starbucks и Twitter уже изучают эту идею.

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

Проект №2: Существующее кроссплатформенное приложение

Если у вас есть существующее приложение, которое работает на разных платформах, вы, вероятно, тратите много денег на постоянную разработку и поддержку этого приложения. Вы также, вероятно, увидите некоторые различия в функциях приложений, поскольку каждая нативная платформа, как правило, имеет свой собственный график разработки. Приложение для ритейлера Target, например, в настоящее время позволяет пользователям управлять списком покупок на iOS, но в версии для Android такой функции нет. Во многом это похоже на расхождение, которое мы иногда наблюдаем между «настольной» и «мобильной» версиями веб-сайта.

Если Интернет уже является частью вашего кроссплатформенного сочетания, это дает хорошую возможность удвоить ваши инвестиции в него и рассмотреть возможность замены ваших нативных приложений на PWA. Такие инструменты, как сонар и Lighthouse, могут дать вам представление о том, насколько хорошо ваш существующий сайт подготовлен для PWA-фикации, а также подсказать, над чем вам нужно поработать. Оттуда превратить ваш сайт в PWA относительно просто. Существуют даже бесплатные инструменты, которые помогут вам обновить сайт до PWA за несколько минут. Однако, если это не так, на самом деле нет большого стимула для этого шага, если только расхождение функций между платформами не станет действительно вопиющим или вы не планируете добавить в смесь еще одну нативную платформу (или сеть).

Проект №3: Новый кроссплатформенный продукт

Если вы запускаете новый проект, нацеленный на более чем одну платформу, создание и поддержка его в одном месте в качестве PWA определенно должны быть на столе. В зависимости от вашего бюджета и персонала, это, вероятно, увеличит ваш бюджет больше всего. Тем не менее, если вашему продукту требуется прямое подключение к оборудованию или базовой ОС, вам все равно может потребоваться перейти на нативную версию. Но прежде чем пойти по этому пути, составьте список всех ваших требований, а затем проверьте, что Интернет может делать (и что он не может). Обязательно проверьте поддержку более чем в одном браузере.

Проект № 4: Новый сверхцеленаправленный продукт

Если вы создаете новый продукт, и частью общей цели этого продукта является его глубокая связь с определенной платформой, во что бы то ни стало, создайте для этой платформы. Например, если ваш продукт использует платформу Apple Messages или интеграцию с HomeKit, обязательно создайте его для iOS и/или macOS в Swift. Если ваш продукт будет лучше всего удовлетворять потребности пользователей с помощью виджета или вы создаете собственный модуль запуска, вам лучше всего создать Android, и вам нужно будет использовать Java.

Однако не все местные особенности представляют собой обнесенные стеной сады. В то время как Alexa от Amazon, Siri от Apple и Google Assistant требуют нативного кода (или JSON API) для интеграции с вашим приложением, что интересно, Cortana от Microsoft будет озвучивать ваше PWA, используя только файл XML, связанный с head вашего HTML. Возможно, их примеру последуют и другие.

PWA или родной? Выбор за вами

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

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

Ресурсы, связанные с PWA

• Конструктор PWA
  Трехэтапный инструмент для создания веб-сайта в PWA с полезными рекомендациями и рецептами. Это также позволяет вам превратить PWA в устанавливаемые нативные приложения для Windows, Android и iOS.
• Прогрессивная дорожная карта для вашего прогрессивного веб-приложения
  Джейсон Григсби рассказывает о том, как его команда в течение нескольких месяцев начала внедрять аспекты PWA на свой веб-сайт, наглядно продемонстрировав, как различные функции можно добавлять постепенно.
• Да, этот веб-проект должен быть PWA
  Обзор UX-возможностей (и рисков) PWA, написанный вашим покорным слугой.
• Прогрессивные веб-приложения на MDN
  Центр всех технических деталей, которые вам нужно знать о том, что характеризует качественное PWA.
• Что Интернет может сделать сегодня
  Ознакомьтесь с API, поддерживаемыми вашим устройством, ОС и браузером. То, что вы найдете, может вас удивить.
• Могу ли я использовать
  Окончательная база данных о том, какие API и функции доступны в каждом основном браузере, и как эта поддержка измеряется по сравнению с браузерами, которые люди фактически используют. Это также может дать вам отличный обзор назад во времени, чтобы увидеть, насколько обратно совместимы определенные функции.