Comments 32
Никогда не понимал задумку делать с помощью Айоника приложение с долгосрочным развитием. PoC или MVP - пожалуйста, но с условием дальнейшего переписывания под конкретные платформы отдельно.
Ну, 90% мобаппов, которыми люди пользуются это простые бизнес приложения, у которых низкие требования к UI и скорости работы. Например ФБ, ТГ, Вотсапп, Тиндер, Метро, Такси, Еда, всякие одностраничные аппы компаний с инфо о них и максимум записью на услуги. Хотелось бы научиться делать такие, но без геморройной отладки и изучения новых языков и встроенных фич платформы, а с типовым фронтенд стеком, который я знаю.
А ты знаешь как написан Тиндер к примеру? У меня самого там претензии к его работе, кажется там типичный Нэйтив подход.
Айоник для этих всех приложух вряд-ли использовался. Пруфы хотелось бы конечно, но чтоб никто не брал на вооружение гибридный подход если качество важно на выходе.
Ты же сам привел Флаттер как пример) вот там лучше результат будет, это не Гибрид, там нэйтив лучший выходит среди всех кроссплатформенных инструментов
И как это тебе советовали Mobile Blazor Bindings?? Там ещё очень сыро и годится только для попробовать. И между прочим шансов в среде .NET спустится до нэйтив куда больше вашего недоАйоника.
Да, очень сырая штука и раздел на сайте выглядит заброшенным.
Он переходит под MAUI, мне кажется все будет только после полноценного релиза этого фреймворка. Но там есть такие глюки, не годится для продакшн разработки пока что.
И опять же гибридный подход и здесь не зайдет для больших проектов, даже средних. Да, здесь нет плагинов, нейтив код писать можно, но WebView портит всю малину как и в Айоник.
Вот прям досада берет, почему Ионик сделали весь свой набор контролов, штук 50 - но засунули приложение с ними внутрь вебвью/браузера. Можно наверно было как-то исхитриться и трансформировать их (и фронт бэк в виде Ангуляр впридачу) в нейтив приложение с нейтив контролами Андроид/iOS чтобы получить высокую скорость нейтив аппа, а не эти постоянные мелькания вебвью.
Даже React Native не облегчает сильно эту задачу приближения к Нэйтив и он сильно уступает Флаттеру по скорости. NativeScript не знаю.
У меня знакомый из продуктовой компании делал версию продукта года три на Айоник. Вначале было красота, удобство, спустя время - боль с плагинами, производительностью и т.д. Потом его отстранили и он стал заниматься чисто веб-приложением, никакого мобайла.
Я делал несколько приложений на Ionic - мельканий не было, может это просто неправильное использование того же Ангуляра, когда не часть страницы перерисовывается, а вся целиком?
В моем тестовом аппе на первом табе штук 50-100 контролов из которых 15-20 замаплено на захадкоженные (без получения данных с бэка по веб апи) переменные во фронтовом бэке *.ts коде контроллера страницы/компонента. Имхо ангуляр должен такое на лету без задержек отображать. Имхо это не повод тормозить по 30-40 сек при отображении таба и мелькать.
С мельканием (не в Ionic, а просто AngularJS) у меня была один раз проблема, когда использовались чекбоксы с событиями и там так получилось, что эти события генерились без перерыва, вроде бы и работает, но дерганье и вообще страница еле шевелится (в итоге пришлось ту логику сделать двумя иконками, похожими на чекбоксы)).
Т.е. я к тому что не стоит полностью полагаться на модель работы Angular, иногда может возникнуть проблема в том месте, где этого совсем не ждешь)
Ох, в своё время наелся я этими гибридами так, что даже и близко не хочу подходить, если клиенту требуется полноценное мобильное приложение.
Сам я бэкенд разработчик, но несколько раз в сложных ситуациях приходилось затаскивать мобильную разработку, имея в распоряжении команду, работающую со стеком "для сайтостроя". То есть единственным выходом в моем случае было выбрать технологию, на которой интерфейс можно тупо сверстать, а нативный функционал получить плагинами.
С чем бы я ни работал - чистый PhpneGap, DrupalGap, Ionic (2016 года выпуска) - во всех случаях полученный результат напоминал поделку на коленке, а не полноценное приложение. Несмотря на то, что к разработке со стороны фронтенда привлекалась сильная команда ни с одним крутым проектом за спиной.
И проблемы везде одни и те же:
Всё крутится в браузере. А движки везде разные. Где-то web view одной версии, где-то другой, какие-то мелкие ньюансы они рендерят по-разному. Конечно на демо-приложениях это не видно, но в продакшнне у требовательного корпоративного или гос-клиента......
Плагины. И мало того, что есть они далеко не на все случаи жизни, так ещё и на разных платформах по-разному работают, если вообще от одного автора есть под всё платформы этот плагин. В итоге получаем платформо-зависимый код, хотя нам обещали, что его не будет...
Отклик интерфейса, вообще внешний вид. Он медленный. Прямо вот видно, что это какой-то веб-сайт, даже если клики на ссылках не подсвечиваются визуально (на некоторых устройствах они всегда подсвечиваются, выделяя ссылку, и сразу становится ясно, что это тупо сайт)
В целом набор возможностей. Например, в одном проекте у нас в дизайне были карты и кнопка, чтобы восстановить ориентацию "на север". Позже клиенту предстояло узнать, что на Ionic такого мы никогда не сделаем.
JavaScript и среда выполнения. Всё-таки браузер - не лучшее место для обширной логики, кучи асинхронных операций, включая коммуникацию по REST. Особенно если это браузер на доходом мобильном устройстве с дохленьким процессором и короткой памятью.
По каждому из пунктов можно нырнуть внутрь и "набомбить" ещё с десяток подпунктов и историй об их взаимосвязи, но, наверное,ине в формате комментария.
Итого, мне вообще удивительно, что эти "гибридные" решения всё ещё развиваются в качестве отдельных продуктов, ориентированных на мобайл. Одно дело, когда твой фреймворк позволяет делать адаптивные сайты с возможностью какой-то работы оффлайн, тут требования ниже.
А Ionic и аналоги, по сути, это фреймворки, которые были бы хороши для разработки мобильных сайтов, но вводят нас в заблуждение, обещая, что отлично будут решать поставленные задачи и узконаправленно на мобилках.
В общем, моё мнение - просто не нужно использовать ЭТО для мобильной разработки. Ни вчера, ни сегодня, ни через годы. Лучше оно не станет, ведь все болячки прописаны в их "генетическом коде".
Спасибо за крутой коммент! Был бы чрезвычайно благодарен если найдете время и отпишите здесь или ссылкой на статьи (своей статьей на хабре?) со списком всех тех багов, которые связаны с Ионик на разных устройствах в т.ч. старых. Т.к. некоторые мелкие баги могут оказаться фатальным шоустоппером для конкретного кейса и позволят оперативно принять решение стоит ли связываться с Ионик.
Framework7 быстро отрисовывается на мобиле, почти как Native на iOS, на старых Android есть проблемы со скоростью работы webview, насколько помню для решения этого собирали приложение c добавление webview из Crosswalk, который билдится со свежей версии Chrome.
Полезная статья. Как раз собирался заняться Ionic, но по всему выходит, что буду постенно изучать Flutter. Спасибо, за статью.
Да, после прочтения комментарий и своего небольшого практического опыта с Ионик тоже стал склоняться к Флаттер или Реакт нейтив или, если оставаться в известном мне .net/c# стеке - Xamarin или Unity. Попробую еще одно приложение на Ионик сваять и замерю скорость. Если будут тормоза - запуск аппа >7сек, а переключение между табами (отклик на клик по кнопке) >5 сек без доп нагрузки по получению данных с бэка, то придется с Ионик заканчивать.
Было бы интересно узнать о результатах
В целом апп с Ионик тормозит больше, чем нейтив, но не сильно критично для типовых офисных аппов, где нет жестких требований по скорости. В моем аппе первый таб был сильно нагружен контролами - штук 100 и поэтому начальный старт аппа (и соотв отображение контролов первого таба) тормозило. Если выставить другой таб по умолчанию, стартует апп намного быстрее.
Было очень интересно почитать про такую экзотику, как Ionic.
Считаю, что сейчас самым актуальным кросс решением является Flutter, с единым языком в "обойме". Dart - весьма простой и наглядный ЯП. Переход на него с JS происходит очень быстро. А если есть опыт разработки React/React Native, так и вообще всё просто.
Подскажите, почему в стравнениях нету KivyMD? Тоже, вроде как, сейчас вполне живой проект со своими адептами.
KivyMD - в первый раз о таком слышу и ни в одной статье где сравнивали фреймворки для моб разработки о таком не упоминали. Может и крутая штука, но исследование его возможностей требует времени, которое можно потратить на изучение более популярных библиотек.
Насчет Flutter и React native - у меня опыт с .Net/C# и Angular/Typescript/Html - поэтому для моб разработки искал в первую очередь что-то дотнетное или вебовское из знакомого мне стека.
Спасибо автору за статью.
Я пишу на Ionic, и его реинкарнации Capacitor, уже довольно долго.
И не совсеми тезисами я могу согласиться.
В статье смешаны понятия Ionic, Ionic + Cordova и Capacitor.
Сам по себе Ionic - это набор веб-компонентов заточенных под использоватние на мобильных устройствах. Его можно спокойно использовать на любых веб-страницах.
Cordova + Ionic - Это Cordova-приложение. И тут архитектуру диктует именно Cordova. С этим связано то, что прложение получается тяжелым и медленным. А также то что вносить измменения в нативную часть очень тяжело. Я в своё время модифицировал плагин пуш уведомлений, а плагин Apllepay добавил в магазин плагинов.
(Сразу оговорюсь, не я автор плагина Apple Pay. Я только его нашел, доработал, и добавил в магазин.)
Capacitor - Это новая реинкарнация этого фреймворка. Тут уже берется любое SPA и запускается в нативном WebView. Тем самым получая лучшее из связки натива и веба.
Дальше, при желании, приложение можно модифицировать как со стороны веба, так и со стороны натива. Типичный пример - добавление функционала получения Push-уведомлений на IOS. Там не просто плагин добавляется, там нужно ручками внести изменения в нативную часть.
Основным приимуществом разработки мобильного при ложения на крос-пратформе - это дешевизна для бизнеса. Один разработчик и для фронта и для мобильной разработки, причем как для Android так и для IOS.
И, насколько я понимаю, команда Ionic движется в сторону структуры когда в в нативном приложении будут запускаться несколько мелких веб приложений. Давая нативному приложению гибкость дизайна веба.
Возможности браузера(читаем Chrome) растут очень быстро, а с ними и возможности кросплатформенных фреймворков.
Так что не стоит недооценивать фозможности такой разработки.
А для тех кто все же решил писать на Ionic/Capacitor я бы посоветовал начинать так же изучать и нативную часть мобильной разработки.
Спасибо за подробный ответ. Будет супер если поделитесь инфой какие минусы у Ионик есть с учетом вашего опыта разработки на Ионик. Насколько трудоемко оказалось решение проблем в реальных кейсах и в каких случаях баги пофиксить не удалось (= примирили клиента что это не фиксится из-за родовых травм Ионик).
По поводу того, что в статье смешаны понятия. Старался писать понятно, возможно недостаточно смог это сделать. ОК, я писал о связке Ionic+Capacitor. Т.е. я открыл спеку ионик, прочел ее всю и сделал все примеры с применением Capacitor как было сказано в учебной спеке + еще 3 плагина Capacitor.
В целом мой посыл был в том, что я хочу получить мобапп. Какие технологии будут внутри - без разницы, но желательно знакомые мне (C#, Angular, Typescript, Html). От моб фреймворка я всего-то хочу:
1) Быстрый дебаггинг/лайв релоадинг - как у веб аппов за секунду перебилдивается апп в браузере - Ионик это делает прекрасно, понятно, что нейтив фичи надо тестить в эмуляторе или смарте.
2) Быстрая работа приложения, задеплоенного на смарт на всех (почти), в том числе старых смартах (до 5 лет). А не такая порнография как переключение табов по 40 сек и старт аппа за 30 сек.
3) Отсутствие геморроя при работе с нейтив фичами через плагины и др.
По большому счету сейчас нет разницы на чем писать.
Кросплатформенно можно писать на любом стеке. На Kotlin - под iOS, на Swift - под Android и бекенд.
Как веб проникает в нативные приложения через WebView так и наоборот, нативные языки проникают в веб через Webasembly.
Вопрос обычно в том что кому нравится и кто на чем уже умеет писать, чтобы не переучивать спецов или нанимать новых.
Скорось работы зависит от количества "наворотов", количества графики, сложности переходов.
Отсутствие гемороя при работе с нативными фичами никто не может гарантировать. Думаю это относится к приложениям написанным на любых языках/фреймворках.
Операционки не стоят на месте и никто не гарантирует что в новой версии все будет работать так же как и в прошлой. Так же нужно понимать что фреймворк зависит от огромного количества мелких пакетов и иногда обновление в одном пакете может уронить весь билд.
По своему опыту могу сказать что этим любит грешить Apple. Был случай когда после обновления IOS у меня ломался дизайн. Был случай когда после выхода нового npm-пакета ломался билд. Был случай когда проявилась ошибка только на новейшем на тот момент iPhone 8+. Потому что там в настройках телефона добавили ностройку, а в эмуляторе этой настройки небыло, и при попытке выбора файла приложение просто зависало. Или в 2019 у новых планшетов Apple оказалось нестандартное разширение экрана и как результат - дизайн поехал.
Мне нравится скорость развития JS/TS и других веб технологий. Они сами по себе кроссплатформенны и это "+". Нравится строгость и гибкость Angular. Нравится то что Capacitor позволяет нормально работать не только с веб, но и с нативной частью.
Есть вещи которые не доступны этому фреймворку. Например создание виджетов, или сервисов которые будут работать в фоне. Скорее всего это потому что там нет места WebView и для таких вещей полюбому нужно учить нативный язык.
А если натив не нужен - то я за PWA.
Вынесу из личной переписки. Имхо очень важный момент про негатив сторов к аппам, построенных на webview. Буду рад если прокомментируют те, кто выкладывал в стор аппы, сделанные на Ionic/WebView, были ли проблемы с этим.
>>> Привет насчет вашей статьи. Вы не озвучили главную проблему. Сторы крайне негативно относятся к приложениям на WebView до того что у меня было 4 заказа от людей опубликовать cordova приложения. А Xamarin или react native очень хороши. Ну и да смените процессор все же гонять в эмуляторе с ускорением намного лучше причем фирменный эмулятор менее глючный. И один из моих проектов по запуску macos в виртуалке.
https://vc.ru/dev/102724-app-store-novye-trebovaniya-skoro-vstupayut-v-silu-chto-budet-s-prilozheniyami-na-html5 и вот это https://coderoad.ru/31170598/%D0%A0%D0%B0%D0%B7%D1%80%D0%B5%D1%88%D0%B0%D0%B5%D1%82-%D0%BB%D0%B8-app-store-%D0%B8%D0%BB%D0%B8-Play-Store-%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B8%D0%BC%D0%B5%D1%8E%D1%89%D0%B8%D0%B5-WebView-%D1%82%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE-%D0%B4%D0%BB%D1%8F
Сейчас пилю MVP pet проекта. Под капотом так:
UI: Svelte + Ionic (собираем yarn'ом)
Back: AIOHTTP за Caddy (такааая вкусняяяшка, простой конфиг + автоматически сам разруливает с HTTPS сертификатами) + PostgreSQL (пробую PonyORM)
CI/CD: podman (self VPS)
Бандл первого экрана c элементами интерфейса весит 650Kb (вместе с библиотеками компонентов, стилями, иконками, Ionic с CDN), передано по сети 200Kb. Нужная графика, конечно, в svg. Работает, вроде, довольно шустро. Багов с компонентами Ionic за два месяца не обнаружено, написано 10 экранов разных интерфейсов. Особо радует Svelte со своим Stores (state management) - это просто песня.
Вибро из Chrome (Navigator.vibrate()) в андроиде работает. В iOS не работает. Работу в Safari (неважнецкая поддержка новых/старых фичей JS) тестирую в VMware Workstation 16 с образом macOS Mojave через эмулятор iPhone в Xcode.
Что нравится в Ionic, платформозависимый интерфейс веб приложения из коробки. На разных устройствах вид нативных приложений. Компоненты интерфейса туда же. Очень легко и быстро собрать MVP. Бандл очень маленький.
Я к чему. Если не нужен функционал нативных приложений, рассмотрите возможность не заворачивать фронт в приложение, как PWA работает достаточно удобоваримо.
UPD 20:40 03.01.22: Обновил графики по числу вакансий. Добавил статистику по Linkedin (РФ, Ванкувер, Берлин). Также пересчитал статистику для двухбуквенных слов (React Native, Android Native, jQuery Mobile, Corona SDK). При поиске на сайте стал задавать их в кавычках: "jQuery Mobile". На первую тройку технологий (Unity, React Native, Flutter) это не повлияло, но как и требовалось, опустило "jQuery Mobile" на последние позиции, т.к. раньше по статистике у dice.com она была на первом месте.
Как я научился делать мобильные приложения на Ionic/Angular за 42 часа