×Закрыть

Flutter, React Native, Kotlin Native, PWA: есть ли будущее у кросс-платформенных приложений?

У Гугла есть команды, которые конкурируют между собой, развивая разные направления по созданию мобильных приложений. Активно продолжают развивать андроид, параллельно работают над кросс-платформенным фреймворком Flutter и еще продвигают Progressive Web Apps (PWA) — гибрид сайта и приложения. Помимо этого, еще развиваются Kotlin Native и React Native.

Какие у кого мысли по поводу политики гугла по одновременному развитию конкурирующих между собой технологий и какие перспективы кросс-платформенных приложений на конец 2018 года?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
у кросс-платформенных приложений

Есть.

Flutter, React Native, Kotlin Native, PWA

Модная проходная хрень.

Модная проходная хрень.

як ти різко, одним махом, списав їх всіх! ух!
аргументи?

Ну извини, в сортах... не разбираюсь.

Делаю сейчас 2 проекта на react-native. Если ты занимаешь этим под Windows — жди беды. На Mac все более менее. Технология очень сырая, много багов. Дебаг адекватно настроить тоже проблема особенно любителям async\await(привет babel). Части приходиться удалять node_modules и созданные при билде файлы чтобы это дело просто запустить на мобилке. Сейчас мы вынуждены работать на более старой версии.
До этого работал с xamarin, там в плане дебага все шикарно. Но проблема с кастомизацией UI + одинаковым рендерингом на всех платформах.
В общем направление перспективное, особенно для небольших бизнес приложений.

Но проблема с кастомизацией UI + одинаковым рендерингом на всех платформах.

Вероятно, вы о Xamarin Forms, поскольку «голый» Xamarin — это просто C# обёртка над нативными API мобильных платформ.

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

На DOU пока мало вакансий со словом Flutter:
jobs.dou.ua/...​s/?search=flutter&descr=1

На апворку знаходить біля 50 проектів. На ксамарині для прикладу 260. Реакт нейтив біля 1к і більше.

нам и кьюта хватает

Pricing starts at $459/mo.

невиправдано дорого
а (L)GPL версія схожа на cripple-ware

ну во первых там есть по 99
во вторых с какого

cripple-ware

?

З того, що не всі фічі доступні (там є перелік у колонці «open source» — www.qt.io/download — я тут не буду його цитувати, щоби не засмічувати ефір) або виходять під GPL, що вимагає, щоби мій код також був під GPL.
Зрозуміло, що мені ніхто нічого не винен і глупо вимагати від розробників роздавати безплатно те, у що вони відгрохали свій час та зусилля — це їх невід’ємне право встановлювати ціни та умови.
Але з іншого боку, щоби щось вивчити «для себе» або настругати безплатних або donation-ware поделок, я не виберу qt ні разу.

там практически все под лгпл3

Ничего из перечисленных дополнений не нужно в большинстве случаев.

А где вообще можно посмотреть цены? Я еще месяц назад написал письмо им с запросом цен, но ответа так и не получил.

вот цена для стартапов с доходом до 100000юсд в год
www1.qt.io/start-up-plan
проблема с кьют компани в том, что эта опция вообще не видна на сайте, если не знать, что искать
ну или использовать лгпл версию со всеми лгпл-ными заморочками (хотя их там на самом деле не много)

Вайтишникам я бы предложил изучать Flutter или React Native. Направление свежее, мало конкурентов, а вакансий становится постепенно больше. Пока опытные нативные разработчики, которые пишут для андроида и айоса, крутят носом в отношении кросс-платформенных инструментов, можно успеть неплохо прокачаться и легче потом будет найти первую работу.

PWA это старый добрый app cache + «добавить на рабочий стол»? еще в 2012 работал на проекте, который на такое полагался.

Идея с PWA выглядит очень заманчивой. PWA не требуют установки из магазина приложений, т.е, тем самым, создаются риски для недополучения доходов Гуглом в своем Google Play, так как издателям не нужно будет платить комиссию Гуглу за продажи, не понадобится также одобрение со стороны «корпорации добра» на публикацию приложения. Получается, что развивая PWA, Гугл сам себе создаст в будущем проблемы в своем магазине, а значит, и с андроидом.

тут разные use case. когда я захожу на сайт с мобильного каждый день и мне предлагают удобный ридер — это одно. когда я ищу видеоредактор, я пойду в play market, посмотрю описания и почитаю отзывы, а не буду гуглить первый попавшийся сайт, который предоставит мне PWA

ну, и если PWA работает с номером кредитки я предпочту скорее понадеяться на Google с его аудитом приложений в маркете, чем давать доступ рандомным сайтам к такой информации

Но если это будет не рандомный сайт, а уже создавшая себе репутацию компания со своими приложениями под андроид и айос, и которая платит 30% со своих доходов Гуглу и Эпплу. Они могут попробовать рискнуть уйти из маркетов, если пользователи доверяют им, и прикрутить PayPal, или другой биллинговый сервис с меньшими процентами.

а я, как существующий пользователь, перестану получать апдейты. ооок, норм стратегия :)

а хіба PWA не перегрузиться і перекешується, коли вийде нова версія?

я про старую версию из play market

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

Думаю следующий год для кросплатформы будет интересный.
Точно релизнется flutter и у них очень хороший прогресс, это заметно при переходе с rp1 -> rp2. Но тут вопрос насколько быстро подтянется комьюнити, потому что сейчас библиотек мало и все сырое.
React native вполне может остаться в аутсайдерах при их отношении к комьюнити и скорости разработки, пилить бету 5 лет это не очень хорошо.
Kotlin native имеет интересный, хоть и отличающийся концепт. UI и перформанс остаётся нативный, что может зайти для крупных и требовательных приложений.
В целом качество кроссплатформенный инструментов улучшается и количество приложений написанных на них явно будет увеличиваться.

судячи по опису, kotlin native попадає у нішу, де зараз сидить go, тому чекаємо цікавих історій :)

Запилил несложный проект на Flutter — получилось очень круто, намного круче чем React Native. Все выглядит одинаково, что на Android, что на iOS (но кастомизировать можно). Рендерится все сразу от Flutter на канвасе. Небольшая проблема — еще мало либ

А чим саме набагато крутіше, можете розписати?

1) Количество UI элементов. Уже полностью реализованы Material и Cupertino библиотеки, т.е. можно сразу писать код. В отличии от React-Native, с небольшим количеством базовых элементов (даже кнопку недавно добавили), и разными библиотеками (совместимыми с разными версиями RN) для реализации остального. Туда же навигация — под RN есть только не до конца написанные либы с косяками, в Flutter — все из коробки.
2) Реализация UI элементов. На Flutter все рендерится сразу на канвас, таким образом для iOS и Android общая кодовая база, и все выглядит и ведет себя одинаково. В RN рендеринг идет в «родной» среде, используя «родные» элементы системы. В итоге какие-то properties отвечают за то как ведет себя элемент в iOS, какие-то за то как ведет себя в Android. Причем некоторые особенности изменить нельзя. Банальный пример: CardView с тенью и border-radius, верхняя половина одного цвета, нижняя половина другого. В RN я так и не смог сделать чтобы один код отвечал и за старые Android, и за новые Android, и за iOS, были бросающиеся в глаза глюки и отличия, в итоге сделал несколько версий (помню пришлось убить пару часов на исследования почему так чтобы выбрать оптимальное решение). Во Flutter все заработало из коробки сразу.
3) Субъективно Dart более приятный язык чем JS.
4) APK на выходе весит намного меньше.
5) Первый запуск приложения на RN занимает 10+ секунд, пока идет распаковка файлов и запуск node сервера. На Flutter запускается сразу.

Что еще классно, так это то, что разрабатывать под Flutter можно в Android Studio.

Классно что можно в блокноте. ТК студия это уже просто дно какие-то как и айдеа

Все выглядит одинаково, что на Android, что на iOS (но кастомизировать можно)

А насколько сложно кастомизировать, чтобы на каждой из платформ результат выглядел как нативное приложение?

Почему спрашиваю — с точки зрения пользовательского опыта, вот это «выглядит одинаково», как раз, может быть минусом, а не плюсом, поскольку пересічний користувач привык, что все приложения на его мобильном девайсе выглядят и ведут себя более-менее однообразно. И, скажем, паттерны навигации из Android в iOS приложении могут выглядеть чужеродно и отталкивающе.

Придется писать 2 разметки — одну на Android (например с Material элементами), вторую для iOS (с Cupertino). Намного легче чем писать 2 нативных приложения.

Ага, то есть, тот же подход, что и в React Native. Спасибо!

Ща уже многие ваяют материал дизайн на все и на веб и на иос

Да, поэтому Flutter рулит)

как там из флаттера позвать с++ код? уже приделали?

Не все сразу. Пока что на такой стадии — github.com/...​utter/flutter/issues/7053

ясно. пока на уровне хотелки

Мне лично нравится идея PWA. Люди менеджеры пилят. Если интересно найду видос.

Реактор нет в шлак. Не стоит. Он для простеньких ап

Возможно, опыт Airbnb поможет сориентироваться по срокам — medium.com/...​ve-at-airbnb-f95aa460be1c. Они два года использовали React Native, но с 2019 собираются перейти полностью обратно на нативную разработку. Как мне показалось, больше по организационным причинам (в третьей статье те проблемы подробно описывают).

Зависит от того, как спроектировано и написано. Визуальные компоненты 100% придётся переделывать полностью, т.к. в RN разметка хоть и похожа на HTML, но только похожа.

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

Тех, кто безапелляционно утверждает, что «RN — шлак», не слушайте. Да, у платформы есть ограничения, особенно когда дело касается работы с датчиками, bluetooth, медиакодеками и прочими низкоуровневыми задачами. Но учитывая, что у вас порт с реакта, вряд ли такие задачи имели место быть.

Да, у платформы есть ограничения, особенно когда дело касается работы с датчиками, bluetooth, медиакодеками и прочими низкоуровневыми задачами.

а накойхер (фамилия такая) оно вообще тогда надо?

а накойхер (фамилия такая) оно вообще тогда надо?

Потому что довольно большой процент приложений это не использует?

Про медиакодеки спешу отдельно уточнить, что проигрывать и записывать аудио/видео из RN можно, а вот перекодировать в другой формат или, скажем, вырезать фрагмент видеофайла — уже не факт, что получится без написания нативных расширений.

Будущее мобильных прихожух — без GC и виртуальных машин. Я верю в Харви Дента Kotlin Native.

Естественно, оно ж компилируется в нэйтив.

А где связь? Если нэйтив — это не значит, что без ГЦ. Либо я не распарсил сарказм)

Разные понимания слова Native. Java это не Native в том смысле в котором говорят ваши собеседники, т.к. она компилируется не напрямую в машинный код, а в код для виртуальной машины. Kotlin Native компилируется сразу в машинный.

Котлин нейтив использует lvvm — low level virtual machine, и через него может в машинный код, но это не значит, что там нет гц. И судя по сорцам, там таки есть гц, с сомнительной возможностью гц отключить.
Иначе как соблюдать консистентность кода с ручным управлением памятью и JVM?

The Kotlin/Native compiler produces standalone executables that can run without any virtual machine.

blog.jetbrains.com/...​view-kotlin-without-a-vm

і там же про GC:

Kotlin/Native is designed to potentially enable different memory management solutions for different target platforms. For example, in the future it may make sense to have a tracing GC for server/desktop platforms, while ARC makes a lot more sense on iOS. Some platforms may only need manual memory management, and get an even smaller Kotlin/Native runtime in return.

стисняюсь спросить — а поинтеры наконец будут или как?

«а я не справжній зварник, я тільки маску знайшов»
Якщо їх нема, то може і не буде, бо іначе синтаксис міняти треба.
Або будуть як у rust-і — красіві строго типізовані дженерік класи-поінтери, тіпа (це не код на Котліні!):
Pointer<MyClass> object = new MyClass();

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

Подписаться на комментарии