Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности.
Основное в чем человечество сошлось — это браузер. Практически вся кроссплатформа основана на использовании браузерного рендеринга. Варианта ровно 2 — либо HTML-based либо Canvas-based.
Основные: React Native (HTML), Flutter (Canvas), Xamarin (как я понял, вызывают API ОС?)
Есть половинчатые — типа ElectronJS — не поддерживают моб.
Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Здравствуйте, Shmj, Вы писали:
S>Основное в чем человечество сошлось — это браузер. Практически вся кроссплатформа основана на использовании браузерного рендеринга.
У традиционных веб-приложений есть существенный недостаток, они не позволяют свободно манипулировать данными на клиенте. Можно, конечно, попытаться извратиться скриптами, но это будет малоэффективно. Очевидно придётся грузить эти скрипты многократно, а работать они будут просто ужасно.
По сути всё сводится:
1) К скорости доступа к памяти.
2) То, что клиент вообще сможет получить доступ к памяти.
По первому пункту, скорость идёт по убывающему от регистров процессора, озу, ssd, hdd, интернету. От наносекунд к микросекундам, от микросекунд к миллисекундам, от миллисекунд к секундам.
По второму, ну давай представим, что доступ к интернету у тебя всё же есть, но сервер из-за чего-то недоступен. А доступа может и не быть. Или возьмём убогий локальный HDD, мало того, что отклик с него будет быстрее, чем с интернета, так он ещё и всегда доступен.
Есть ещё минус веб-приложений, причём дело не в самих веб-приложениях, а в способе их реализации. Да, запускать скрипты может быть и удобно при разработке, но лично мне вся это возня с веб-серверами вроде nginx и прочих не особо нравится.
Итого, веб-приложения удобны как дополнительный интерфейс доступа к сервису, но не более. Так то разработчики очень многое теряют выпуская не десктопную или мобильную версию. А ещё браузеры устроены очень уродско, трут SSD почём зря. Они в этом плане и рядом не лежали с транзакционным доступом к базе данных.
И я бы вообще старался не употреблять слово кроссплатформа рядом со словом веб, особенно до уровня смешения. Кроссплатформа это запуск приложений на множестве платформ, под которыми понимается железо, операционные системы, способы запуска, такие как кроссплатформенная компиляция или виртуальные машины.
А веб-приложения основываются на разделении обязанностей на сервер и клиент, то есть запуск идёт не у тебя на платформе, а где-то удалённо на сервере. Это нельзя назвать кроссплатформенностью, разве что понимать под этим то, что тот же веб-сервер nginx или другой кроссплатформенны, и заставлять обычных пользователей запускать эти сервера и плагины для скриптов к ним у себя на компьютерах.
S>Основные: React Native (HTML), Flutter (Canvas), Xamarin (как я понял, вызывают API ОС?) S>Есть половинчатые — типа ElectronJS — не поддерживают моб. S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Попробую выразиться как-то помягче, это лютое говнище. Нормальные приложения на том же C/C++ будут рвать их в хламину. По мне всё очень просто, как говорил один великий мыслитель, не только лишь все могут, мало кто может это делать.
Весь этот мусор на скриптах годится для дешёвых команд говноразработчиков. Но нужно понимать, что как только придут профи с нормальными языками программирования, они натянут все эти говносервисы на скриптах на огромный болт.
Говносервисы спасает лишь то, что реально крутых программистов в мире не так уж и много. Да и в целом, почему люди не хотят замечать очевидного. Достаточно взглянуть как и на чём сделаны популярнейшие в мире программные продукты.
Нет, не нужно смотреть, что интересует всяких нубов в интернете, или что там должно стать популярным по мнению анал-итиков. И даже не то сколько вакансий на сайтах работы. Давайте просто взглянем на чём сделаны самые крутые программные продукты и вопросы отпадут сами собой.
Здравствуйте, Nuzhny, Вы писали:
N>Системное и серверное ПО — отдельно, вот всякие мессенджеры — да, вполне
Телеграм на C++/Qt написан.
Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают.
Здравствуйте, Skorodum, Вы писали:
N>>Системное и серверное ПО — отдельно, вот всякие мессенджеры — да, вполне S>Телеграм на C++/Qt написан. S>Electron плохой выбор для текстового мессенджеров, т.к. даже небольшие лаги в набирании текста раздражают.
<Label Text="Hello, XAML!"
VerticalOptions="Center"
FontAttributes="Bold"
FontSize="18">
<Label.TextColor>
Aqua
</Label.TextColor>
</Label>
У нас есть реальный проект на этой фигне, который пытается воспроизвети интерфейс сделанный на Qt/QML. И код и интерфейс на MAUI выглядят так себе. С деплоем у них тоже какой-то геморрой.
Здравствуйте, Shmj, Вы писали:
S>Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности.
Если реально нужна кроссплатформенность то уже лет дцать как можно использовать С++/Qt. Есть минусы:
* требует умения читать документацию и более-менее прямых рук
* коммерческая лицензия довольно дорогая
Плюсы:
* работает везде и быстро.
Я отвечаю за приложение, которое официально работает на винде, маке, линухе (x86-64 и арм). При необходимости и на андроиде и яблофоне взлетит. В исходниках платформоспецифичного кода примерно 0.1% (поддержка named pipe/fifo). Серьезные отличия только в инсталяторе, но скорее всего перейдем на IFW и там тоже отличий будет мало.
Здравствуйте, Shmj, Вы писали:
S>Великая мечта — пишешь один раз, отлаживаешь используешь везде — все-таки приближается к реальности.
Первая, главная и принципиальная ошибка! Провозглашённая "мечта" — тупой хайп красноглазых пингвизятников, которым надоело клепать редакторы и канпелять ведро и им захотелось "серьёзного софта". Кроме пингвизятников ПРАКТИЧЕСКИ НИКТО не думает о том, что надо бы поддерживать ещё что-то.
Виндузовый мир давно укрепился на десктопе и им вообще по-барабану другие платформы. Ну а Эппл — там "своя атмосфера" — хомячки любят скруглённые углы, диктатуру и "жри чо дают", поэтому и там никто даже не пытается портировать свои плюшки вне iOS.
Возникает вопрос — кто и зачем разводит этот говнохайп "а давайте кроссплатформу"? Зачем вообще говорить об этом, если и так очевидно, что все операционки РАЗНЫЕ? Практика "амфибий" прекрасно доказала, что она и в воде — неахти, и на дороге — простигосподи. Теперь какой-то идиот пытается это запилить через софт — чего ради? Получить уродца типа Qt? Уже получили, дальше что? Победы этого тулкита до сих пор не видно, что опять доказывает — многоплатформа никому не упёрлась.
S>Основное в чем человечество сошлось — это браузер
Нет, опять фэйл, Шмж! Браузер — это не многоплатформа, как правильно заметил velkin, а тупо костыль, некая "своя отдельная и сильно ограниченная платформа".
S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Будете носиться со своей кроссплатформой — будете в тупике. Разувайте уже мозги, студота! Сколько можно теребить общественность своими глупыми мечтами? Работайте уже! Вон, есть VS — пишите нормальные FW-приложения, там работы — непочатый край.
Здравствуйте, Shmj, Вы писали:
... S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Странно читать всю эту тему... В одном топливном дивизионе одной популярной госкорпорации 1С наше всё.
"Коллеги, на 1С можно написать всё".
"Импортозамещение" называется...
Сообщение заговорено потомственным колдуном, целителем и магом в девятом поколении!
Модерирование или минусование сообщения ведет к половому бессилию, венерическим заболеваниям, венцу безбрачия и диарее!
К>"Коллеги, на 1С можно написать всё". https://1c.ru/news/info.jsp?id=29748 Поддержка процессоров архитектуры ARM с версии 8.3.22 платформы "1С:Предприятие"
Скоро уже пролоббируют обязательную её предустановку на все смартфоны?
V>Весь этот мусор на скриптах годится для дешёвых команд говноразработчиков. Но нужно понимать, что как только придут профи с нормальными языками программирования, они натянут все эти говносервисы на скриптах на огромный болт.
уже не скрипты же, вебасм уже. да, остались интеропы между апи браузера и вебасм, но в кол-во скриптинга
упало примерно до 1% от общей кодовой базы.
если клиенту не нужен прямой доступ к функциям ОС, то нормальное решение для клиента — простота обслуживания.
Здравствуйте, Shmj, Вы писали:
S>Кто что может сказать по этому добру? Тупиковая ветвь или это наше ебудущее?
Есть такое предположение, что в итоге всё cойдется к HTML, включая нативные приложения ОС. Я имею в виду, HTML как движок UI. А логику к нему можно будет писать на любом языке, не только как сейчас на JavaScript.
Вот представьте такую штуку: возьмем известную многим концепцию WPF приложения и выкинем из него .xaml файлы, вместо них добавим .html файлы. Это, конечно же, уже не будет WPF приложением, но практически все остальные концепции и атрибуты приложения сохраняются. Из C# code behind файла дергаем HTML DOM. CSS ресурсы используем как шаблоны стилей. Тема приложения — это корневой CSS, в идеале идет из коробки и в точности повторяет общую тему ОС, в которой приложение работает.
Ништяк? Абсолютный. Не нужно никаких клиентов и серверов, все происходит как в самом обычном приложении.
HTML движок есть готовый на всех более-менее распространненых ОС. Но самое интересное это то, что реализация такой можели приложений получилась бы относительно компактной, так как львинная доля работы ложится на плечи уже готового HTML движка, который по-умолчанию брался бы из ОС и не требовал распространения в составе самого приложения.
Почему HTML? Потому что это де-факто стандарт UI. Многие конечно возразят, что нативные контролы лучше и т. д., но вы видели в каком состоянии эти контролы в последних релизах ОС? Возьмём High-DPI монитор и сможем быстро увидим, что те же Win32 сontrols — это просто динозавры, которые рендерятся в высоком разрешении с хаками и некрасивостями. Да, они были отточены для 96 DPI, но на high-DPI на них трудно смотреть без слёз.
WinRT — недостаток в том, что это только Windows, плюс эта подсистема относительно закрыта и плохо документирована, поэтому используется мало и в основном только самими Microsoft.
WPF — достойно, но не кроссплатформенно.
MAUI — ИМХО тупиковая свистоперделка основанная на каличном Xamarin'е у которой нет шансов.
Avalonia — очередной .NET-only велосипед. Хоть и кроссплатформенная, но тюрьма.
И вот он, HTML. Скоромно сияет в сторонке, как диаманд на фоне всего этого уныния вокруг и ждет своего часа.
A>Вот представьте такую штуку: возьмем известную многим концепцию WPF приложения и выкинем из него .xaml файлы, вместо них добавим .html файлы. Это, конечно же, уже не будет WPF приложением, но практически все остальные концепции и атрибуты приложения сохраняются. Из C# code behind файла дергаем HTML DOM. CSS ресурсы используем как шаблоны стилей. Тема приложения — это корневой CSS, в идеале идет из коробки и в точности повторяет общую тему ОС, в которой приложение работает.
Зачем что-то представлять, воображение напрягать? Blazor именно так и работает, вполне себе уже в продакшине используется.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Зачем что-то представлять, воображение напрягать? Blazor именно так и работает, вполне себе уже в продакшине используется.
Не совсем. Blazor — эта такая себе .NET тюрьма. А я говорю за всё множество языков, в том числе и нативных. Чтобы было так:
"UI на OCaml — легко!"
и не нужно было переучиваться под конкретную связку programming language — UI framework.
Здравствуйте, Aquilaware, Вы писали:
A>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Зачем что-то представлять, воображение напрягать? Blazor именно так и работает, вполне себе уже в продакшине используется.
A>Не совсем. Blazor — эта такая себе .NET тюрьма. А я говорю за всё множество языков, в том числе и нативных. Чтобы было так:
Ну я на предложение про WPF отвечал. WPF точно также гвоздями прибит к .net.
У Микрософт была попытка "сделать точно такой же WPF, но отвязанный от языка и платформы" — то что называлось uwp\winrt. Но на практике 95% приложений для него на шарпе писалось.
Что касается html\css то он слишком низкоуровневый — в любом случае нужен фреймворк поверх.
Мне кажется, что тупиковая. Эдакий локальный максимум. Любой инженер морщится, когда ему надо использовать семантический HTML для несемантического UI. Но для преодоления этого тупика требуется недюжинные усилия крупнейших корпораций, в первую очередь гугла и эппла.
На мой взгляд правильная кроссплатформа выглядит так: выпускается условно микро-браузер. Он умеет wasm и ряд важнейших API, в первую очередь WebGPU. Этот микро-браузер имеет малый размер и малое потребление ресурсов. Конечно у него нет никакого своего интерфейса, по сути просто рантайм, на котором запускается веб-приложение. И к этому микро-браузеру делается набор библиотек, тот же флаттер, чтобы обычные программисты могли этим пользоваться. Этот микро-браузер может и должен идти в составе гугль хрома, чтобы обновляться с ним синхронно. А установленные веб-приложения должны интегрироваться в систему на уровне обычных (иконки в пуске и тд).
Гугль может это сделать для десктопа и андроида. Но для полноценного распространения нужна заинтересованность эппла, чтобы на айфоне и макбуке оно работало так же. И желательно микрософта.
А там можно этот рантайм отпилить от бразуера и использовать независимо, если очень хочется. Хотя я считаю, что рантайм должен быть общий, это правильней. И обновлять его удобней в одном месте и ресурсов жрать меньше будет. Отпиливать его может быть уместно во встраиваемых приложениях, чтобы на каких-нибудь микроконтролерах рисовать интерфейс.
Но это всё лирика. Понятно, что сегодня кроссплатформа это обычный браузер и тут пока ничего не поделаешь.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>У Микрософт была попытка "сделать точно такой же WPF, но отвязанный от языка и платформы" — то что называлось uwp\winrt. Но на практике 95% приложений для него на шарпе писалось.
Классная идея. Но её нужно было делать вокруг открытого стандарта, потому что никто на проприетарщину подсаживаться сейчас в здравом уме уже не будет. Точнее, конкретная реализация может быть и проприетарной, но стандарт должен быть открытым. HTML как раз и претендует на роль такого стандарта.
ЕА>Что касается html\css то он слишком низкоуровневый — в любом случае нужен фреймворк поверх.
Абсолютно верно. Из коробки могло бы поставлятся только то, что умеет делать хост система, всё остальное — сторонние примочки, в том числе и коммерческие.
В WPF задумка именно такая, но реальность значительно хуже, потому что то, что там идет из коробки не достаточно приближено к UI системы и это видно невооруженным глазом. Поэтому разработчикам пол WPF ничего не остаётся как где-то брать темы, стили. Что на самом нелегко и далеко не всегда оправдано.
vsb>Но это всё лирика. Понятно, что сегодня кроссплатформа это обычный браузер и тут пока ничего не поделаешь.
На "обычном браузере" все "современные" г-сайты, надизайненные 20-летними сеньорами по паттернам, выдают только требование скачать новейший браузер не старше прошлой недели.
