Comments 12
Какой экономический профит?
У вас было два android-разработчика и два ios. Они могли писать нативные приложения под каждую платформу. Вы выбрали WebView и дополнительно стали нанимать еще и JS разработчиков. Следовательно затраты на ФОТ выросли. Для js нужно больше тестов, больше работы по верстке под нативный вид (притом на android своя верстка, на ios своя, тут выигрыша нет). Это доп затраты.
А профит тут в том что людям дают работу - молодец архитектор!
Два iOS разработчика и два Android разработчика не справились бы с тем количеством сервисов, которые мы разрабатываем, поэтому, чтобы выполнить все хотелки бизнеса, пришлось бы нанимать большое количество таких разработчиков.
А так мы пилим сервисы на JS сразу для Web и Mobile на одном стеке.
Затраты на ФОТ выросли из-за большого количества задач. Если бы это делали отдельно на Kotlin, отдельно на Swift, а потом отдельно на JS, то ценник на разработку был бы в 2-3 раза больше)
Сейчас у всех банков помимо клиентов под смартфоны есть ещё и веб приложение. Почему нельзя просто его сделать устанавливаемым Progressive Web Application? Почему принято отдельно ещё и для мобилок что-то дополнительное делать пусть даже с WebView? И это не только банков касается, но и многих других приложений вроде поиска работы, объявлений и т. д. Просто исторически сложилось или там на самом деле какие-то проблемы с этим?
В AppStore такие приложения разве пускают? Или вы как то хитро оборачиваете свои PWA и обходите ограничения от Apple? Или установка приложения происходит не через AppStore?
Тут какое-то странное повествование. Чувак говорит что сперва был капитаном хоккейной команды, а потом стал тимлидом. Это звучит не то, что странно. Это звучит смешно. Типа женщина недавно работала вон там уборщицей, но недавно её назначили директором другой компании. Специально создан такой маразм?
Вообще-то это не обязанности тимлида - выбирать архитектуру. Это задачи техлида/ПМа. Ну или бизнес/системных (как бы тупо не звучало, но хотя бы так) аналитиков на крайняк, так как у них есть обязанности строить планы на перёд. Но никак не тимлида продуктовой команды.
В статье flutter стоит как пример? Это тоже маразм. Зачем? Он всем хуже чем Kotlin MP, ещё и требует новых специалистов.
Да, такой маразм создан специально, очень рад, что удалось вас рассмешить.
Про обязанности тимлида - а в статье нигде не сказано, что выбирал ее я лично :) У нас есть архитектор и команда техлидов.
Почему flutter - маразм? Довольно субъективное мнение. А Kotlin MP совсем недавно выпустил стабильную версию, до этого была бета.
как вы считаете, есть ли светлое будущее у PWA-приложений
НЛО только что приземлился и разместил это здесь
React Native - 90 процентов js логика 10 процентов нативной составляющей
По сути реакт нейтив обучается обычный js разработчик и может успешно на нем писать.
Нужно только от 1 РНщика с коммерческим опытом который будет лидить jsеров.
Разделение на платформы дает дополнительно клиент который не сломается если условно сайт ляжет из за инцидента(а во время активной разработки это достаточно частое явление может быть), он более статичен(цикл обновление в среднем раз в 2 недели с основательным регресс флоу) и условно если это еком достаточно хорошо снижает риски, сломали сайт, перейдут делать покупки в приложение.
Про обновление в обход сторов
Expo Application Services (EAS) are deeply integrated cloud services for Expo and React Native apps, from the team behind Expo.
Или же можно написать свою реализацию если угодно. В кратце у нас есть нативное приложение с JS бандлом на РН и мы можем перед инициализацией запрашивать его с сервера и заменять если он изменился на клиенте. В обход сторов. В целом сторы это прощают если
Разрешает ли это Apple?Да! Раздел 3.3.2 Программы разработчика iOS разрешает это, "при условии, что такие скрипты и код не изменяют основное назначение приложения путем предоставления функций, которые несовместимы с предполагаемым и рекламируемым назначением Приложения".Разрешает ли это Google?Конечно!
Нюанс если обновились нативные зависимости и мы их дергаем с JS потока, нужно обновлять приложение ведь этих нативных модулей у пользователей нет, однако когда приложение в состоянии саппорта и по большей части все нативные модули уже добавлены, это редкое явление.
И к чему мы подходим, зачем кросс платформенная разработка? Да все просто - нативный экспиренс. Вы лукавите на записях экрана что это ну тоже самое. Не то же самое. Совсем не такой опыт взаимодействия, да даже тот же свайп назад на вебвью ощущается коряво. Скроллинг больших списков аналогично, удобное АПИ для взаимодействия с нативными модулями. С вебвью получается винегрет из технологий. И достаточно сложно в этом разбираться. У нас на проекте было вебвью и мы его переписывали на РН.
Рейтинг в сторах с 1.8 поднялся до 4,9 за полгода. (Тут есть элемент спекуляции потому что мы начали запрашивать оценку после совершение покупки, но опять же с вебвью это просто геморойно и не лежит на поверхности, надо писать шину взаимодействия между вебвью и нативной частью(у нас это по евентсобытиям было), писать реализацию на нативе ну и это все дело будет как то общаться между сайтом и нативкой по шине, тут много мест где можно зафакапить в будущем, сложнее поддерживать, сложнее анбордить новых разрабов и все это скажем так больше стоить будет в бабках по итогу. В РНе эта задача заняла 2 дня работы с тестами и созвонами часа по 2-3 в день (так не каждый день). Все красивенько, добавил пакет, вызвал окно отзыва, обработал в js потоке, закрыл окошко, покрыл тестами. Легко читается легко поддерживается. Тайм ту маркет только что займет до 3 дней(и это с автотестами) так как будет ревью сторов и регресс приложения, но и релиз не будет ради этой фичи, обычно релиз раз в 2 недели.
С кадрами опять же дела обстоят так что нужен 1 рн на команду и добирать веберов на реакте, они достаточно быстро начинают приносить велью. Ценник рнщика такой же как на нативщика, у вебера будет поменьше косты (процентов на 25-30).
В один момент разделения на веб/реакт нейтив сводится на нет и один разраб пишет сначала веб, потом пишет на рн(там совпадение логики 100 процентов, синтаксис на 80-90 процентов, тесты хорошо ложаться используя одну и ту же либу например react-testing-library) и в итоге мы получаем ресурс в виде разработчика который эффективно может использоваться (веб/приложение) и получаем нативное приложение которое радует пользователей.
П С Не все так радужно, с РНом есть вопросы с теми же длинными списками или большими таблицами, так же если происходит много изменений на экране это все узкие места которые будут нетривиальны. У нас были проблемы со списками и большой таблицей сравнения, но за неделю две на основе пакетов именитых компаний допилили напильником под наши нужды и теперь вопросов нет. Вообщем не серебрянная пуля, надо смотреть под свои нужды. (Игру или клиент для биржи сомнительная затея писать)
Для вас имхо нативный экспиренс не очень нужен, так как это внутренний проект, он не приносит денег поэтому вебвью вполне себе вариант. Сотрудники потерпят если не устраивает. Если бы проект приносил деньги есть прямая коррелляция конверсия/положительный пользовательский опыт.
Спасибо за внимание.
WebView: быстрый релиз, никаких ревью в сторах, а минусы есть?