Как стать автором
Обновить

Битва титанов: натив, кроссплатформа и PWA — ищем плюсы и минусы на каждом этапе разработки

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров2.4K
Всего голосов 12: ↑11 и ↓1+12
Комментарии12

Комментарии 12

Кроссплатформу/натив вместе с web view не рассматривали? В этом случае можно будет отображать UI довольно легко и использовать возможности устройства.

Да, рассматривали и делали сами. Действительно решает проблему доступа к возможностям устройства, но остается вопрос со сторами. В контексте этого сравнения он важен

Подскажите пожалуйста, что за вопрос со сторами?

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

У вас нет этой Миро доски в текстовом варианте?

В общем-то эта статья и есть текстовый вариант брейншторма, зафиксированного на доске

В то же время нативные приложения самые быстрые. 

А почему вы так уверены? У меня иной опыт (native <=> PWA).

А вообще, мне кажется, нужно отталкиваться от необходимого функционала. Если доступ к мобилке нужен, только натив. Если нет - только PWA или webview на ней. Будущее Flutter слишком туманно, а текущий функционал слишком не очень.

мне кажется, нужно отталкиваться от необходимого функционала. 

да, тут и не было идеи стать адвокатом чего-то одного. Везде свои плюсы и минусы, вес аргументов зависит от потребностей в конкретной ситуации

На этапе идеи и сбора требований может быть важно показать или попробовать прототип, а то и десяток прототипов. Тут преимущество у КП и PWA.

Зачем искать специалистов по Dart? Их можно подготовить быстрее чем за неделю. Может быть имелись в виду специалисты по Flutter? И тут вспоминается Delphi - всё хорошо пока что-то не хорошо и нужно выходить за пределы. Так что в большой группе, где есть специалисты по нативу, хотя бы двое, Flutter много лучше чем в малой где их нет. И с PWA то же самое.

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

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

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

Если вдруг вспомнить что кроме Андроид, iOS и PWA есть ещё Windows, macOS и Web, то статью стоит перечитать. Ничего принципиально не изменится, но восприятие весов факторов поплывёт. Да и КП, особенно не Flutter, может побочным продуктом давать PWA.

И тут вспоминается Delphi - всё хорошо пока что-то не хорошо и нужно выходить за пределы

Можно развернуть тезис?

И Flutter и Delphi

  • Требуют изучения языка мало применяемого ещё где-то.

  • Имеют собственную систему элементов управления.

  • Включают в себя много компонентов или библиотек или как кому угодно.

  • Позволяют написать много неплохо работающих приложений.

  • При необходимости выйти за пределы необходимо изучить натив.

Иными словами, рано или поздно выясняется - приходится знать и Delphi или Flutter, и натив, и технику связи между нативом и Delphi или Flutter. То есть натив нужно знать на уровне, на котором и Delphi и Flutter просто не нужны. Тогда зачем тратились силы?

В обоих случаях есть случаи когда либо выходить за пределы не нужно, либо проблема решается путём привлечения разных специалистов. История Delphi общеизвестна…

Так, если речь идёт о прототипе, то вряд-ли потребуется выход за пределы. В то же время, если для pwa потребуется выйти за пределы, то у вас вообще мало что получится.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий