Давайте сразу выделим платформы в порядке популярности:
1. WebBrowser (да, да — браузер — нынче своего рода ОС).
2. Windows.
3. Android.
4. iOS.
5. MacOS.
6. Linux.
7. Не знаю стоит ли выделить, но можно сказать что серверная часть (бэкэнд), который обычно на Linux.
Основные игроки, которые могут везде или почти везде:
Вроде самые универсальные — Qt, Flutter и KMM — могут в т.ч. на Linux. А это бывает важно, есть конторы которые исключительно на Linux сидят и если вам нужно какую тулузу сделать — то на других платформах просто отсутствует физическая (практическая для Нomunculus) возможность.
Минс Qt — язык С++ да и Python. С++ имеет слишком сложный компил-тайм вариант, Python не строгий. Хотя, стоит отметить, что тот же C++ при разумном использовании в современном варианте не плох, не особо чем хуже Kotlin или Dart. Но ведь вы же знаете — если можно изрвратиться — люди будут извращаться — а C++ дает слишком широкие возможности для изврата.
Xamarin не имеет поддержки Linux.
React Native — JavaScript/TypeScript зло.
Flutter не плох, но единственный момент — это Google, который иногда кидает. Может прекратить поддержку и все.
А вот KMM и глубоко уважаемая с безупречной репутацией JetBrains — на мой взгляд, имхо, выглядит наиболее интересно.
Здравствуйте, kov_serg, Вы писали:
_>Уточните кто такие игроки. И какая цель игры.
Под "игроками" в данном контексте подразумеваются инструменты, фреймворки или технологии, которые предоставляют возможности разработки кросс-платформенных приложений. Цель "игры" заключается в том, чтобы создать одно приложение, которое будет работать на множестве платформ, таких как Windows, Android, iOS, Linux, macOS, и даже в веб-браузерах.
Основные аспекты "игры":
1. Минимизация усилий:
Разработчики хотят писать код один раз и использовать его на всех целевых платформах.
Это снижает трудозатраты и стоимость разработки.
2. Поддержка платформ:
Чем больше платформ поддерживает инструмент, тем большее количество пользователей можно охватить.
Например, Qt поддерживает Windows, Android, iOS, Linux и macOS, что делает его универсальным.
3. Производительность и удобство:
Важно, чтобы фреймворк обеспечивал высокую производительность и не создавал дополнительных сложностей для разработчиков.
Например, React Native позволяет использовать JavaScript, который популярен среди разработчиков, но вызывает вопросы из-за своей гибкости и потенциальной сложности отладки.
4. Долгосрочная надежность:
Некоторые инструменты (например, Flutter) могут вызывать опасения из-за риска прекращения поддержки.
В то же время, инструменты от компаний с безупречной репутацией (например, Kotlin Multiplatform Mobile от JetBrains) выглядят более надежными.
Таким образом, "игра" в данном случае — это выбор оптимального инструмента для кросс-платформенной разработки, который позволит достичь баланса между универсальностью, производительностью, удобством и долгосрочной перспективой.
S>Цель "игры" заключается в том, чтобы создать одно приложение, которое будет работать на множестве платформ, таких как Windows, Android, iOS, Linux, macOS, и даже в веб-браузерах.
Приложение в широком смысле – это может быть бэк+база+фронт+мобилки. Это первое.
Второе: если речь идет именно об одной сущности "приложение", код которой написал в одном месте и оно везде работает, то у меня вопрос: зачем?
Ну и третье: в различных системах очень много нюансов (размеры, возможности, периферия, ограничения, подходы и best practices, да элементарно – варианты использования у платформ разные) и запихнуть все в один код, ИМХО, ненужная, неэффективная, да к тому же и неэффектная идея.
Здравствуйте, DiPaolo, Вы писали:
DP>Приложение в широком смысле – это может быть бэк+база+фронт+мобилки. Это первое.
Фронт (браузер) + мобилки — это все решается данными подходами. Т.е. нет нужды платить n раз отдельным разработчикам под браузер и под все версии мобилок — пишите один раз и работает везде.
DP>Второе: если речь идет именно об одной сущности "приложение", код которой написал в одном месте и оно везде работает, то у меня вопрос: зачем?
Чтобы не платить n раз за одно и тоже.
DP>Ну и третье: в различных системах очень много нюансов (размеры, возможности, периферия, ограничения, подходы и best practices, да элементарно – варианты использования у платформ разные) и запихнуть все в один код, ИМХО, ненужная, неэффективная, да к тому же и неэффектная идея.
S>Фронт (браузер) + мобилки — это все решается данными подходами. Т.е. нет нужды платить n раз отдельным разработчикам под браузер и под все версии мобилок — пишите один раз и работает везде.
Утопия... вынести кору в общий компонент – да. Сделать кроссплатформу под винду+мак+линукс – с натяжкой да. Заставить веб-страницу прикидываться десктопом – можно.
НО все это играет в минус как UI, так и UX, а порой и ресурсов.
S>Чтобы не платить n раз за одно и тоже.
Скупой платит дважды.
S>Все это уже смогли эффективно решить.
Примеры?
Ну и да, не забудь про еще одну платформу – TvOS. Ах да, а киоски – еще плюс платформа. CLI – еще тебе вот одна платформа... Что с этим всем делать?
Поясню на простом примере проблему: допустим, есть система управления проектами (Jira, к примеру). Как ты в телефон засунешь редактирование диаграмм Ганта? или просмотр 10ти колонок и 100+ задач? или написание задачи с 10-тью полями? И главное – зачем тебе это в телефоне? Вот именно — не нужно! В телефоне тебе максимум надо будет прочитать описание задачи и попереписываться в коментах, пока едешь в такси/метро. Ну еще добавить задачу с одним лишь тайтлом, пока не забыл. Ну ладно, вывести три цифры о состоянии спринта/релиза/проекта.
Это то, о чем я говорил – юз кейсы разные.
Или возьми для примера программы для редактирования видео. Ты элементарно не засунешь в мобилку или планшет то, что засунешь в десктоп, который можно открыть на 40"+ экране. Зато упрощенное редактирование — вполне!
Здравствуйте, Shmj, Вы писали:
_>>Уточните кто такие игроки. И какая цель игры.
S>
S>Под "игроками" в данном контексте подразумеваются инструменты, фреймворки или технологии, которые предоставляют возможности разработки кросс-платформенных приложений. Цель "игры" заключается в том, чтобы создать одно приложение, которое будет работать на множестве платформ, таких как Windows, Android, iOS, Linux, macOS, и даже в веб-браузерах.
S>Основные аспекты "игры":
S>1. Минимизация усилий:
S>Разработчики хотят писать код один раз и использовать его на всех целевых платформах.
S>Это снижает трудозатраты и стоимость разработки.
S>2. Поддержка платформ:
S>Чем больше платформ поддерживает инструмент, тем большее количество пользователей можно охватить.
S>Например, Qt поддерживает Windows, Android, iOS, Linux и macOS, что делает его универсальным.
S>3. Производительность и удобство:
S>Важно, чтобы фреймворк обеспечивал высокую производительность и не создавал дополнительных сложностей для разработчиков.
S>Например, React Native позволяет использовать JavaScript, который популярен среди разработчиков, но вызывает вопросы из-за своей гибкости и потенциальной сложности отладки.
S>4. Долгосрочная надежность:
S>Некоторые инструменты (например, Flutter) могут вызывать опасения из-за риска прекращения поддержки.
S>В то же время, инструменты от компаний с безупречной репутацией (например, Kotlin Multiplatform Mobile от JetBrains) выглядят более надежными.
S>Таким образом, "игра" в данном случае — это выбор оптимального инструмента для кросс-платформенной разработки, который позволит достичь баланса между универсальностью, производительностью, удобством и долгосрочной перспективой.
Не аспекты, а какая цель?
По поводу минимизации усилий: Посмотрие на веб, то что раньше можно было сделать просто и дёшево. Теперь можно сделать тоже самое сильно дороже и оно будет более требовательно к ресурсам и работать только в свежих браузерах
Здравствуйте, DiPaolo, Вы писали:
S>>Все это уже смогли эффективно решить. DP>Примеры?
Вроде My BMW App, Alibaba-клиент. Это из крупных.
А так, конечно, в основном для мелких контор, никому не известных, но которые тоже как-то живут и хотят чтобы можно было ПРОСТО пользоваться.
DP>Поясню на простом примере проблему: допустим, есть система управления проектами (Jira, к примеру). Как ты в телефон засунешь редактирование диаграмм Ганта? или просмотр 10ти колонок и 100+ задач? или написание задачи с 10-тью полями? И главное – зачем тебе это в телефоне? Вот именно — не нужно! В телефоне тебе максимум надо будет прочитать описание задачи и попереписываться в коментах, пока едешь в такси/метро. Ну еще добавить задачу с одним лишь тайтлом, пока не забыл. Ну ладно, вывести три цифры о состоянии спринта/релиза/проекта.
Элементы для адаптации функционала так же уже продуманы.
DP>Или возьми для примера программы для редактирования видео. Ты элементарно не засунешь в мобилку или планшет то, что засунешь в десктоп, который можно открыть на 40"+ экране. Зато упрощенное редактирование — вполне!
Это все продумано и есть рекомендации как делать.
Но вы правы вот в чем — универсальная платформа применима в двух случаях:
1. Нужно экономить деньги. Если денег куры не клюют — то зачем?
2. Приложение достаточно простое по функционалу и нет особой разницы между десктопной и моб. версией.
Здравствуйте, kov_serg, Вы писали:
_>Не аспекты, а какая цель?
Цель игры — победить, т.е. сделать так, чтобы платформа использовалась и нужны были разработчики, которые на ней пишут.
_>По поводу минимизации усилий: Посмотрие на веб, то что раньше можно было сделать просто и дёшево. Теперь можно сделать тоже самое сильно дороже и оно будет более требовательно к ресурсам и работать только в свежих браузерах
Позволю не согласиться. Требовательно к ресурсам — да, т.к. перестали об этом заботиться. Дороже — не думаю.
Сложнее в написании — тоже нет. Но раньше тебе нужно было знать вещи более фундаментальные — как-то протоколы. А теперь — тебя оградили от протоколов и нужно знать фреймворки.
Здравствуйте, Shmj, Вы писали:
S>Цель игры — победить, т.е. сделать так, чтобы платформа использовалась и нужны были разработчики, которые на ней пишут.
Цель порабощения мира? Работа ради работы. Зачем одной платформе поддерживать кункурирующую платформу? Что-бы потом кинуть?
S>Позволю не согласиться. Требовательно к ресурсам — да, т.к. перестали об этом заботиться. Дороже — не думаю.
То есть вы считаете при увеличении сложности подготовки специалистов, просить денег будут меньше?
S>Сложнее в написании — тоже нет. Но раньше тебе нужно было знать вещи более фундаментальные — как-то протоколы. А теперь — тебя оградили от протоколов и нужно знать фреймворки.
Раньшне не нужно было знасть столько мусора и фреймворков однодневок
Здравствуйте, kov_serg, Вы писали:
S>>Сложнее в написании — тоже нет. Но раньше тебе нужно было знать вещи более фундаментальные — как-то протоколы. А теперь — тебя оградили от протоколов и нужно знать фреймворки. _>Раньшне не нужно было знасть столько мусора и фреймворков однодневок
Раньше нужно было понимать. А сейчас — просто знать, понимание не нужно, т.к. все эти фреймворки смысловой нагрузки не несут. Просто находишь в справочнике и повторяешь. А сейчас еще и искать легче стало — GPT все тебе по запросу сам найдет и подстроит под твой контекст.
Здравствуйте, DiPaolo, Вы писали:
DP>что первые, что вторые — нашел только лишь для андроида и айфона. А где же другие платформы?
Ну даже для iOS и Android единая кодовая база — это уже
А другие платформы — крупные компании делать не будут — у них денег куры не клюют. Это для локальных компаний, для корп. софта — какие-то админки, чтобы работники могли и на планшетах и на компьютере с линуксом юзать. Но именно таких мелких компаний и большинство.
Очевидно, что для UI чтобы работало везде, подходит только веб.
Иетересная тема это WASM, взять какой-то легковесный тклкит на C++ или что там сейчас модно-молодёжно- на Rust, и собирать нативные дистры + деплоить веб-сайт c WASM.
Странный список. А где, собственно, веб-платформа? Это самый очевидный и самый популярный вариант. Я не знаю ни одного приложения на Qt или Flutter-е. Может и есть где-то, но это маргинальщина. А веб — везде. vscode, discrord, 1Password, Obsidian, да везде короче...
Здравствуйте, Артём, Вы писали:
Аё>Очевидно, что для UI чтобы работало везде, подходит только веб.
Нет, см. вышеприведенные фреймворки.
Аё>Иетересная тема это WASM, взять какой-то легковесный тклкит на C++ или что там сейчас модно-молодёжно- на Rust, и собирать нативные дистры + деплоить веб-сайт c WASM.
Здравствуйте, vsb, Вы писали:
vsb>Странный список. А где, собственно, веб-платформа? Это самый очевидный и самый популярный вариант. Я не знаю ни одного приложения на Qt или Flutter-е. Может и есть где-то, но это маргинальщина. А веб — везде. vscode, discrord, 1Password, Obsidian, да везде короче...
Сама платформа — на 1 месте. А вот фреймворки под Web- работают все из вышеперечисленных. Отказ от JS в пользу правильных языков — с компиляцией в WASM.
