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

Нативная разработка vs кросс-платформенная — нужно ли выбирать?

Время на прочтение 5 мин
Количество просмотров 14K
Всего голосов 15: ↑10 и ↓5 +5
Комментарии 22

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

Когда речь идет об одиночном разработчике, он не сможет сделать приложение для iOS и Android ни на чем кроме React Native, если он знаком только с Java Script.

PhoneGap (ранее Cordova), например. Сам использовал, и остался доволен — идеально для «хуяк-хуяк и в продакшен», или для создания прототипов. И более понятный, чем RN.

Можно даже взять приложение, написанное на обычной React.js и обернув в PhoneGap получить, нормальное приложение на смартфон.
Тоже вариант. Просто мы его не используем :)
Это как сказать, что люди бывают только мужчинами, потому что вы не женщина.
А чем PhoneGap лучше PWA?
Ну, в том, что PWA — это, по сути, просто сайт, развёрнутый в full-screen, а PhoneGap — это приложение, внутри которого ваш сайт. Примерно, как Electron.
Ок, чем фонгап лучше чем вебвьюха с PWA внутри?
Ок, я не говорил, что он прямо лучше. Но разница однозначно есть.

У меня не столько опыта с обеими технологиями, чтобы их сравнивать, и говорить, что лучше. Но об этом есть статьи/сравнения.
Phonegap и Cordova разные проекты, с отдельным развитием. Cordova продолжает, Phonegap остановился.

Веб-разработчики (фронтендеры), профессионалы в PWA, работающие со сложными веб-приложениями, с большой кодовой базой (конечно на TS или JS + Flow), FLUX-архитектурой, кэшированием в локальном хранилище, знакомыми с процессами рендеринга HTML, CSS в браузерах, которые понимают, что мобильные веб-сайты это не просто схлопнутый Bootstrap.

Да, они могут что-то сделать на платформах типа Cordova/Phonegap.

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

Простите, коллеги, помогите, пожалуйста, найти в этом предложении несколько слов… Сейчас, дайте вспомнить… «Производительность», кажется… «Удобство» ещё вроде, заморское «UX» тут всплыло… Ещё вроде что-то говорили о том, что не все смартфоны оборудованы топовым железом, но это ведь бред какой-то, правда? Кому они нужны, давайте всё лепить абы как, точно, это же дешевле и проще!
дешевле хочет бизнес, заодно он хочет это быстрее.
Бывает необходимо проверить гипотезу, и не хочется тратить на это много денег.
Бывает просто бюджет ограничен, но сильно хочется.

Если есть спрос, должно быть предложение. Иначе зачем вообще тогда Facebook/Google разрабатывают кросс-платформенные решения? Думаете у них не хватает ресурсов?
Но, естественно, обращение к низкоуровневым компонентам поддерживаться не будет — это касается гироскопа, компаса и другого железа.

Даже с этим?

Обычно на нативных языках доступ к функционалу низкоуровневых компонентов гораздо шире.

Всё-таки между "поддерживаться не будет" и "функуционал гораздо шире" довольно приличное такое не одно и тоже. И я просто взял первый попавшийся пакет по запросу "gyro". Ну и как я понимаю вызов нативного кода из Дарта это не прям уж рокетсаенс. https://flutter.dev/docs/development/platform-integration/platform-channels

Я вот гордый программист-одиночка. Фуллстек. Знаю C# и JavaScript. Поэтому пишу под мобильные платформы… На Xamarin. И потому некоторые ваши преимущества нативной по сравнению с кроссплатформенной звучат для меня странно. Обратиться к гироскопу? Да пожалуйста. Отпечаток пальца? Нате!

А Вы пользуетесь Xamarin.Forms? Или же просто на шарпе пишете нативный (насколько это можно так назвать) код платформы?
Просто я пробовал Xamarin.Forms достаточно давно, когда каждый второй кросс-платформенный компонент на андроиде жутко сбоил. Мне было бы интересно узнать, как сейчас с этим дела.

На Xamarin.Forms. Сейчас всё сильно стабильнее стало по сравнению с тем, что было ещё года два назад. Плюс, многие сторонние плагины для кроссплатформенной работы с аппаратной частью заменены реализацией в Essentials. И оно как-то стабильнее стало.
Пока единственные проблемы со стабильностью, с которыми сталкиваюсь, касаются фич в preview (experimental) статусе. Остальное очень даже работает.
Когда разработчик знает только javascript и собирается писать приложение для смартфона, напрашивается вывод, что он всё-таки web-разработчик. А это как бы не одно и то же. Согласно голосованию в конце статьи, самым адекватным вариантом было бы писать на нативном для этой платформы языке. Иначе ленивым web-программистам не придётся выходить за рамки любимой связки JS+фреймворки, а людям придётся обновить в очередной раз свои телефоны. Надо соблюдать баланс между удобством разработки и последующим использованием софта.

Следующий браузер будет написан на JS-фреймворке.

В идеальном мире этот баланс определяет бизнес, получив оценки типа: "нативно мы затратим N денег на разработку и покроем P1 процентов целевой аудитории, выбрав X мы затратим на разработку M денег и покроем P2".

А Qt Framework не рассматриваете? Здесь вам и JavaScript, и наивный C++, iOS/android/win/mac/Linux и ещё куча платформ.

Взять например, виртуальную реальность VR — ее поддержка в RN и Flutter реализована только на базовом уровне, а всех эффектов вы сможете добиться только в нативных средах.
Пример выбран не очень. VR-приложения пишут обычно на игровых движках. AR ещё куда ни шло, его по хайпу везде пихают… Хотя в простом виде можно вообще использовать WebXR.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории