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

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

Как бы я не любил нативную разработку, надо признать что к 2021ому рынок и развитие технологий пришли к тому, что для новых проектов оправдано делать сразу только web-фронтенд с бекендом на сервере. Можно сказать что бекенд это и есть настоящее продолжение нативных/дестопных приложений.
Web фронтенд дает кроссплатформенность из коробки и очень легко упаковывается в нативное приложение если нужно размещение в сторах. Делать классическое нативное android/iOS/Desktop приложение оправдано только для игр и какого-то ну очень тяжелого ПО вроде фотошопа.

Если сервис использует какие-то платформенные особенности, все же нужно приложение. И все же есть класс приложений, где бы я, например, не рискнул обходиться веб версией или использовать кроссплатофрму. Но тенденция есть, согласен

Тем временем фотошоп пришел в веб. WASM в помощь. Про PWA еще не забывайте, в каких-то случаях даже заворачивать ничего не надо - поддерживается нативно на ряде платформ.

А потом ты пытаешься сделать нестандартное что то с железом(прочитать NFC или узнать окружение BT и тому подобное) и очень очень груснеешь, а ещё бывает так, что связка WEB-Native сломана и ты сидишь и ждёшь годами, когда её починят.

BT и NFC кстати есть в Chromium. Нужно просто требования заранее составить, какие АПИ действительно нужны, какие платформы, и от этого отталкиваться. Много чего можно закрыть нативным вебом, что-то через гибриды, а где-то без натива никак.

А в сафари есть? Ведь на айфоне любой браузер — сафари

В сафари нет и пока не предвидится. Опять же надо смотреть на требования. Можно сделать веб версию для всех, а для айфонов - нативную/гибридную. Это уже дешевле чем делать 3+ разных версий, особенно когда веб версия тоже нужна.

Вот у нас сейчас задача: ездит человек по селам. Что-то там фотографирует. И должен передать фотоотчет на сервер. Именно фото. Веб не позволит загрузить фото фоном, как я понимаю. А нативное приложение уже позволит. Как только появился интернет - что-то загрузить.

Хотя, возможно, я ошибаюсь. Мы в выбираем сейчас решение. Сами больше понимаем в классической веб разработке.

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 можно через небольшой костыль. Вес - килобайты, кода никакого не хранится в магазинах. И все, поддерживаете один веб-сайт, собираете трафик со всех платформ + веб.

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

Я разочарован в массовом пользователе. И в том, что такой способ использования заставляет тратить в сумме огромные ресурсы на повышение цифровой энтропии.

Приложения позволяют следить за пользователями😎

Странно, что не упомянут КММ...

Он где-то посередине, нет? Логику (то, что не зависит от платформы) пишем на нем. А на чем делать UI?

нативно, естественно

А в каком состоянии сейчас Qt? Если абстрагироваться от стоимости лицензий и делать, к примеру, open source.

Все такой же - сложный, редкий и кривой

Честно говоря, не погружался в Qt совсем, не могу ответить. Но с учетом распространенности React Native и Flutter мне тяжело придумать кейс, в котором именно Qt себя лучше всего покажет

Кейс: любые тяжеловесные выборки данных со сложными 2д анимациями. Пока ничего шустрее qml либо native я не встречал.

Adobe AIR уже был (аналог Flutter), при этом на весьма популярном в былые времена AS3. И что, и где он? Это про "Flutter лучше RN". Adobe AIR постоянно ставили в укор не использование нативных компонентов и у RN и было преимущество именно нативные компоненты. В случае с Flutter порицаемый подход AIR почему-то преимуществом оказался.

Почему-то примеры приложений на RN какие-то скупые вышли, а как-же Facebook, Instagram, Skype и множество других?

Согласен, обделил вниманием примеры по React Native. Добавил несколько. Facebook/Instagram и прочие по большей части нативные, мне кажется не совсем правильно будет их сюда вносить.

>>>>> В случае с Flutter порицаемый подход AIR почему-то преимуществом оказался.

Лично для себя не считаю это плюсом с точки зрения UX на iOS) С точки зрения производительности, пожалуй, можно назвать плюсом

Не соглашусь с автором.

По скрину с замером фпс не видно превосходства у натива.

На флаттере можно разрабатывать и более того, успешно разрабатываются сложные и большие приложения, а не только витрины.

И если нет какой-либо функциональности, можно написать плагин для взаимодейсвия с ОС.

Если плагинов нужно много, то легче оказывается нативно писать.

С использованием чужих готовых есть риск получить несовместимости на новых версиях ОС и автор оригинальных плагинов может не торопиться их исправлять.

Ну а так как фича для плагина обычно требуется на всех платформах, получается, что экспертизу надо иметь на всех платформах + Flutter.

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

Я бы сказал навскидку, что для 90% потребностей разработки плагины уже есть.

И, кстати, нередко можно не писать плагин, а обмениваться данными через MethodChannel.

мне на iOS не до конца нравилось, как работает, но вижу улучшения:) Насчет витрин - смотря что считать витриной. Может, приведете пару примеров, если NDA позволяет?)

Когда уже во Flutter завезут 3d? А то ситуация странная, на RN хоть игры пиши, на Flutter максимум 3d модель только можно встроить.

Ну, ещё есть Xamarin...

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