Комментарии 31
Как бы я не любил нативную разработку, надо признать что к 2021ому рынок и развитие технологий пришли к тому, что для новых проектов оправдано делать сразу только web-фронтенд с бекендом на сервере. Можно сказать что бекенд это и есть настоящее продолжение нативных/дестопных приложений.
Web фронтенд дает кроссплатформенность из коробки и очень легко упаковывается в нативное приложение если нужно размещение в сторах. Делать классическое нативное android/iOS/Desktop приложение оправдано только для игр и какого-то ну очень тяжелого ПО вроде фотошопа.
Если сервис использует какие-то платформенные особенности, все же нужно приложение. И все же есть класс приложений, где бы я, например, не рискнул обходиться веб версией или использовать кроссплатофрму. Но тенденция есть, согласен
Тем временем фотошоп пришел в веб. WASM в помощь. Про PWA еще не забывайте, в каких-то случаях даже заворачивать ничего не надо - поддерживается нативно на ряде платформ.
А потом ты пытаешься сделать нестандартное что то с железом(прочитать NFC или узнать окружение BT и тому подобное) и очень очень груснеешь, а ещё бывает так, что связка WEB-Native сломана и ты сидишь и ждёшь годами, когда её починят.
Вот у нас сейчас задача: ездит человек по селам. Что-то там фотографирует. И должен передать фотоотчет на сервер. Именно фото. Веб не позволит загрузить фото фоном, как я понимаю. А нативное приложение уже позволит. Как только появился интернет - что-то загрузить.
Хотя, возможно, я ошибаюсь. Мы в выбираем сейчас решение. Сами больше понимаем в классической веб разработке.
Chromium умеет в фон. На Safari никак, придется брать натив или гибрид. Можно попробовать гибрид для Safari через ionic а для хрома как PWA.
>Web фронтенд дает кроссплатформенность из коробки и очень легко упаковывается в нативное приложение
Зачем тогда вообще приложение? Почему все словно помешались на приложениях? У практически каждого крупного магазина и прочей организации есть приложение. С чем я сталкивался за последнее время: спортмастер, до-до пицца, delivery club, mybox.
При этом все эти приложения не имеют (я не нашел) какой-либо функциональности, отличной от взаимодействия с сервисом. Приложения полностью повторяют функциональность веб-сайта, теряя такие возможности, как копирование, вкладки, адресную строку и так далее!
У компании уже есть веб-сайт (адаптивный, кстати). Зачем тратить свои средства на разработку приложений, а ресурсы пользователя (место в памяти, траффик итп) на установку приложения, которое делает всё то же самое? (Mybox - 74 мб, спортмастер - 42 мб, не слишком много для простой "отображалки"?)
Может, стоит вложить средства в отпимизацию веб-сайта, чтобы он был удобнее и производительнее? Тем более, когда существуют все эти [тысячи спецификаций](https://habr.com/ru/company/dcmiran/blog/493018/), чтобы внести в веб всё новые и новые фичи. Всякие хранилища и сервис воркеры существуют давно.
Зачем?
З.Ы. Мысль не нова: https://ithappens.me/story/13155
З.З.Ы. В комментах хабра сломали Markdown?
Потому что трафик из магазинов приложений не получается игнорировать, тут помешательства нет, просто для массового пользователя это самый привычный сценарий что-то "установить" в свой телефон. Вы совершенно правы, тут на помощь как раз и приходит PWA. Делаете супер оптимизированный адаптивный веб-апп, публикуете его нативно в магазины google, ms, даже apple можно через небольшой костыль. Вес - килобайты, кода никакого не хранится в магазинах. И все, поддерживаете один веб-сайт, собираете трафик со всех платформ + веб.
Посмотрите как обычный человек находит нужный сайт: пишет его название в поисковую строку. Практически никто не пользуется закладками. Компаниям хочется контролировать трафик напрямую, без зависимости от поисковой выдачи. И приложение с иконкой это наверное единственый понятный массовому пользователю способ сохранить сервис у себя в телефоне на будущее. Считайте иконку эдакой закладкой.
Приложения позволяют следить за пользователями😎
Странно, что не упомянут КММ...
А в каком состоянии сейчас Qt? Если абстрагироваться от стоимости лицензий и делать, к примеру, open source.
Adobe AIR уже был (аналог Flutter), при этом на весьма популярном в былые времена AS3. И что, и где он? Это про "Flutter лучше RN". Adobe AIR постоянно ставили в укор не использование нативных компонентов и у RN и было преимущество именно нативные компоненты. В случае с Flutter порицаемый подход AIR почему-то преимуществом оказался.
Почему-то примеры приложений на RN какие-то скупые вышли, а как-же Facebook, Instagram, Skype и множество других?
Не соглашусь с автором.
По скрину с замером фпс не видно превосходства у натива.
На флаттере можно разрабатывать и более того, успешно разрабатываются сложные и большие приложения, а не только витрины.
И если нет какой-либо функциональности, можно написать плагин для взаимодейсвия с ОС.
Если плагинов нужно много, то легче оказывается нативно писать.
С использованием чужих готовых есть риск получить несовместимости на новых версиях ОС и автор оригинальных плагинов может не торопиться их исправлять.
Ну а так как фича для плагина обычно требуется на всех платформах, получается, что экспертизу надо иметь на всех платформах + Flutter.
Не приходит в голову, зачем может понадобиться много самописных плагинов, если уже есть очень много реализованных. Конечно, случаи, когда нет готового, будут, но они со временем уменьшаются.
Я бы сказал навскидку, что для 90% потребностей разработки плагины уже есть.
И, кстати, нередко можно не писать плагин, а обмениваться данными через MethodChannel.
мне на iOS не до конца нравилось, как работает, но вижу улучшения:) Насчет витрин - смотря что считать витриной. Может, приведете пару примеров, если NDA позволяет?)
Когда уже во Flutter завезут 3d? А то ситуация странная, на RN хоть игры пиши, на Flutter максимум 3d модель только можно встроить.
Если я не ошибаюсь, Jetbrains развивает котлин в сторону кроссплатформенных приложений.
Ну, ещё есть Xamarin...
Мобильная разработка: Cross-platform или Native