Comments 27
А flutter почему не рассмотрели?
flutter на хайпе но еще сырой и плохо развит инструментарий и тем более вряд ли можно считать его популярным по сравнению с ReactNative или Xamarin (достаточно легко в этом убедиться если сделать поиск на любом сайте с работами). Но относительно статьи можете считать что аналогом flutter является React Native.
это вовсе не аналог react native, flutter рисует интерфейс и все анимации сам, поэтому в данной статье он скорее похож на подход Qt/QML.
Честно говоря, не ковырял устройство flutter, но по первому впечатлению — это верхеуровневый фреймворк (Qt низкоуровневый), работающий поверх верхеуровневых системных API для Objective C и Java. Но целом да, проблемы будут примерно те же, что с Qt/QML, но только без танцев с wrappers при доступе к нативке. Скорее всего flutter получит свою нишу для несложных информационных проектов.
высокоуровневость / низкоуровневость видимо отностительна. Когда я последний раз работал с Qt (много лет назад, еще без QML) он был более чем высокоуровневый, вполне себе аналог C# с WindowsForms с кучей своих высокоуровневых либ для работы с сетью, данными и тд. Они даже свой препроцесор запилили, чтобы упростить многие вещи в С++.
Я посмотрел немного Flutter, штука забавная, в принципе там можно и с нейтив взаимодействовать достаточно плотно, удобнее чем в ReactNative и потенциально нет проблем с многопоточностью. Минусы: экзотический язык, он сам все рисует, даже системные эффекты, поэтому не будет идеального look and feel, минус также и компания разработчик, сейчас для Google это второстепенный проект, который может внезапно закрыться, хоть и ходят слухи о некой новой ОС где возможно Dart и Flutter могут играть значительную роль
Я посмотрел немного Flutter, штука забавная, в принципе там можно и с нейтив взаимодействовать достаточно плотно, удобнее чем в ReactNative и потенциально нет проблем с многопоточностью. Минусы: экзотический язык, он сам все рисует, даже системные эффекты, поэтому не будет идеального look and feel, минус также и компания разработчик, сейчас для Google это второстепенный проект, который может внезапно закрыться, хоть и ходят слухи о некой новой ОС где возможно Dart и Flutter могут играть значительную роль
А почему его необходимо рассматривать? Он пока сырой и не пригоден к реальным проектам, в отличие от рассмотренных в статье фреймворков. Оно даже ReactNative тоже сыроват еще.
А может уже пора «самым гигантским гигантам» Microsoft, Apple и Google (кстати, про Linux что-то в статье ни слова, его-то почему забыли? или мы про мобильную разработку сейчас?) наконец договориться на самом «низком» уровне и прийти к одному API высокого уровня? </розовые очки>
Ну это подход «технарей», а миром ИТ (как и многими другими) правят деньги. Да и платформы все разные со своими особенностями. Да и «зачем»?
В *nix-мирке и так есть какой-никакой POSIX, остальные умышленно делают vendor-lock и кроссплатформенные инструменты для них — заноза, а не панацея. Да и сама стандартизация — это тот еще тормоз прогресса.
А причем здесь кроссплатформенные инструменты? У них свои бизнес-задачи и своя доля рынка. Это не 100% замена стандартных инструментов от самих владельцев экосистем
А причем здесь кроссплатформенные инструменты? У них свои бизнес-задачиЗадача одна — дешево и перспективно писать прикладное ПО.
Это не 100% замена стандартных инструментов от самих владельцев экосистем… Другое дело, что разные подходы (кроссплатформенность на уровне исходного кода, промежуточного представления или системного API) имеют свои недостатки, поэтому приходится балансировать между различными решениями.
Ведь вопрос же не в инструменте, а в команде, которая этим инструментом умеет пользоваться. Так что «занозой» что-то может быть только в том случае, если оно используется не по назначения или неопытной командой.
Кстати, POSIX и в Windows есть (сам не проверял, но тема старая): en.wikipedia.org/wiki/Windows_Services_for_UNIX
Кстати, POSIX и в Windows есть (сам не проверял, но тема старая): en.wikipedia.org/wiki/Windows_Services_for_UNIX
Про «занозы» говорилось в комментарии про вендоров, а не про прикладных программистов)
Кстати, POSIX и в Windows естьПодобных решений существует немало, как от MS, так и сторонних разработчиков, но все равно же это больше боль и страдания в попытке перенести непереносимое с *nix на Windows (те же Git, Docker), чем полноценные целевые платформы.
Медленно? Да, возможны падения производительности при неумелом взаимодействии с операционной системой через мост. Однако сами по себе кросс-платформенные миры такие же быстрые, как и нативные.
Я вам больше скажу, возможны падения производительности даже при неумелом использовании нативных компонентов без всяких мостов.
Вот только у меня такой вопрос к статье: а что это у вас за мобильное приложение, которое мало использует этот мост? ИМХО, но 95% того что есть на мобилках (за вычетом игр) — это всякого рода тонкие клиенты, которые так или иначе отображают контент. Т.е. основная работа это отрисовка интерфейса с красивыми анимациями и прочими свистоперделками + активное взаимодействие с сетью. Т.е. именно то, с чем у кроссплатформы проблема, ибо надо пробрасывать вызовы через мост с преобразованием данных. Дальше веселее: предположим у вас приложение, которое должно выполнять приличный кусок бизнес логики на клиенте, вот тут, казалось бы, самое оно для кроссплатформы, но тут мы можем внезапно упереться в повышенное энергопотребление и ограниченные ресурсы мобильной платформы, где каждый процент прироста производительности или экономии памяти может быть существенным, а потому самые «тяжёлые» куски всё равно будут писаться на «нативном» языке, что практически убивает идею кросплатформерной разработки.
В итоге у нас остаются игры, с которыми всё и так понятно, и приложения для которых производительность не очень важна и в целом «и так сойдёт». Другой вопрос, что «и так сойдёт» многих вполне устроит.
Странное ИМХО, если честно.
> Вот только у меня такой вопрос к статье: а что это у вас за мобильное приложение, которое мало использует этот мост?
Обычные приложения ;) Вы хоть раз писали реальные кроссплатформенные программы?
Открою вам маленький секрет. В реальных сценариях приложение ЖДЕТ и НИЧЕГО НЕ ДЕЛАЕТ основную часть времени, эпизодически реагируя на действия пользователя. И вот в этих эпизодах иногда возникает потребность обратиться к платформе — только здесь задействуется мост. И только здесь может чуть-чуть больше задействоваться процессор и как следствие батарейка. А игры тут вообще при чем? ;)
> Вот только у меня такой вопрос к статье: а что это у вас за мобильное приложение, которое мало использует этот мост?
Обычные приложения ;) Вы хоть раз писали реальные кроссплатформенные программы?
Открою вам маленький секрет. В реальных сценариях приложение ЖДЕТ и НИЧЕГО НЕ ДЕЛАЕТ основную часть времени, эпизодически реагируя на действия пользователя. И вот в этих эпизодах иногда возникает потребность обратиться к платформе — только здесь задействуется мост. И только здесь может чуть-чуть больше задействоваться процессор и как следствие батарейка. А игры тут вообще при чем? ;)
Открою вам маленький секрет. В реальных сценариях приложение ЖДЕТ и НИЧЕГО НЕ ДЕЛАЕТ основную часть времени, эпизодически реагируя на действия пользователя.
Открою вам маленький секрет: атом на 99% (грубо) состоит из пустоты. Значит и вы на 99% состоите из пустоты, и по большому счёту вас нет. Извините, не удержался.
По сути вопроса: в реальном мире, когда приложение находится на экране мобильного, пользователь, обычно, с ним активно взаимодействует, ну там скроллит, свайпит, вот это вот всё. При этом очень много разных элементов интерфейса нужно перерисовать, предварительно рассчитав новые позиции и размеры, а так же подтянув необходимые для отображения данные. И крайне желательно, чтобы это всё не тормозило, любят пользователи чтобы всё было плавно и не приходилось ждать следующего экрана по 15 минут. И вот тут даже с нативным кодом бывает приходится помучиться, ибо когда у вас на экране много всего разного, и картинки, и текст, и тенюшки повсюду, и кнопочки с блюром, то мобильное железо может и не справиться и приходится делать разные интересные вещи. Вот сможете ли вы сделать какие-то хитрые оптимизации на своём кроссплатформерном фреймворке не залезая в нативный код? А если вам туда регулярно приходится залезать, то стоило ли вообще тогда его использовать?
И вот в этих эпизодах иногда возникает потребность обратиться к платформе — только здесь задействуется мост. И только здесь может чуть-чуть больше задействоваться процессор и как следствие батарейка.
Ага, я прям вспоминаю старое приложение фейсбука и рекомендации по использованию браузера вместо него. Вот где было торжество кроссплатформерности и «чуть-чуть больше» задействованных процессора и батарейки.
А игры тут вообще при чем? ;)
Ну, наверно при том, что это, всего лишь, самый успешный и распространённый класс кроссплатформерных мобильных приложений.
Что-то где-то с матчастью пробелы:
> При этом очень много разных элементов интерфейса нужно перерисовать, предварительно рассчитав новые позиции и размеры, а так же подтянув необходимые для отображения данные.
Это все обычно за вас делает ОС, а не ваш код, не важно на каком языке. Если конечно вы свои методы отрисовки и обработки скролла сделали… То это ваши проблемы.
> Ага, я прям вспоминаю старое приложение фейсбука и рекомендации по использованию браузера вместо него.
Если вы следили за развитием событий, то приложение фейсбук было сделано на HTML5 и потом сам Цукерберг признал это ошибкой.
Так в чем ваш вопрос? Я только понял, что реальной разработкой мобильных приложений, тем более кроссплатформенной, вы не занимались.
> При этом очень много разных элементов интерфейса нужно перерисовать, предварительно рассчитав новые позиции и размеры, а так же подтянув необходимые для отображения данные.
Это все обычно за вас делает ОС, а не ваш код, не важно на каком языке. Если конечно вы свои методы отрисовки и обработки скролла сделали… То это ваши проблемы.
> Ага, я прям вспоминаю старое приложение фейсбука и рекомендации по использованию браузера вместо него.
Если вы следили за развитием событий, то приложение фейсбук было сделано на HTML5 и потом сам Цукерберг признал это ошибкой.
Так в чем ваш вопрос? Я только понял, что реальной разработкой мобильных приложений, тем более кроссплатформенной, вы не занимались.
Это все обычно за вас делает ОС, а не ваш код, не важно на каком языке.
Система за вас не делает ничего. Вы вправе доверить сие действие той или иной библиотеке, в том числе системной, однако это вовсе не означает, что она делает это оптимальным, для вашего конкретного случая, образом. Одно только количество альтернатив для NSAutoLayout говорит о многом.
Если конечно вы свои методы отрисовки и обработки скролла сделали… То это ваши проблемы.
В том-то и фишка, что это будут именно что МОИ проблемы, как разработчика. А не того эффективного менеджера, который протолкнул использование кроссплатформерного фреймворка.
Если вы следили за развитием событий, то приложение фейсбук было сделано на HTML5 и потом сам Цукерберг признал это ошибкой.
Т.е. фейсбук сделал кроссплатформерное приложение, а потом признал это ошибкой и переписал на натив, я вроде нигде не ошибся?
Так в чем ваш вопрос?
Вопрос был в оригинальном комментарии. Что у вас за мобильные приложения, которые «не взаимодействуют активно с ОС»? Они простые числа в фоне вычисляют?
Я только понял, что реальной разработкой мобильных приложений, тем более кроссплатформенной, вы не занимались.
Аргумент. Но нет, занимался и занимаюсь.
Я правильно понимаю, что вас в статье напряг момент о том, что можно с меньше или большей интенсивностью взаимодействовать с платформой через мост? То есть о том, что есть большой класс задач, которые могут быть выполенены без взаимодействия с нативкой? Парсинг, хранение и обработка данных, бизнес-логика поведения приложения (viewmodels/controllers, плюс сервисы). Это именно то, что не требует постоянной (по каждому чиху) интеграции с нативкой и живет себе комфортно в виртуальной среде, лишь изредка дергая нужные методы из операционной системы.
Или это ваши общие доводы в пользу того, что кроссплатформа должна умереть, ибо это «тормоза и костыли»? Плюс вы почему-то сваливаете в кучу все кроссплатформенные инструменты и приравниваете провал Facebook с HTML5 с проектами на Xamarin или ReactNative.
Или это ваши общие доводы в пользу того, что кроссплатформа должна умереть, ибо это «тормоза и костыли»? Плюс вы почему-то сваливаете в кучу все кроссплатформенные инструменты и приравниваете провал Facebook с HTML5 с проектами на Xamarin или ReactNative.
приложение, которое должно выполнять приличный кусок бизнес логики на клиенте… а потому самые «тяжёлые» куски всё равно будут писаться на «нативном» языке, что практически убивает идею кросплатформерной разработки.
Если этим нативным языком будет C, который поддерживают все платформы, то почему же убивает? Бизнес-логика — это штука в себе, платформенных зависимостей не требует.
Можно Делфай еще вспомнить.
Спасибо автору. Давно ждал. Немного «подредактировать» Заключение, немного сократить основное «тело», — и рекомендую своему начинающему руководителю для принятия решения выбора.
Совершенно не понимаю этой современной тенденции на вебовость и кроссплатформенность. Уже пришлось отказаться что от нового скайпа на десктопе, что под андроид. Из текстовых редакторов видимо придется серьезней вим осваивать, apple music под андроид тоже видимо кто то вебанутый пилил, терплю только из за широты ассортимента, иначе бы на любимой яндекс музыке оставался. Вообще замечаю что единицами приложений можно пользоваться из тех что сделаны на веб-технологиях. Даже и вспомнить то таких с ходу не могу. Да даже 1с свою платформу выпустила кроме десктопов еще и под мобилки. Естественно с кучей ожидаемых проблем. Правда они хотя бы судя по всему что то нативное использовали для разработки этой самой платформы.
Sign up to leave a comment.
Нативно или нет? 4 мифа о кросс-платформенной разработке