Вот на Dart/Flutter можно писать под моб., причем для Android оно имеет статус рекомендуемого.
Бонусом все это дело работает на iOS, Windows, Linux, MacOS и даже WebAssembly.
Язык и платформа напоминают урезанный .Net — т.е. многих фишек .Net там нет, а так все похоже.
И хотелось бы поговорить о перспективах технологий.
.Net применим для бекэнда. Однако в клиентской части практически уже все, полномочия закончились. Пытаются повторить Flutter в формате MAUI, но более убого получилось и, главное, у MS вообще не получилось в моб. платформу — по этому они не в теме (дело даже не в этом — производители моб. осей могут им ставить палки в колеса).
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Разраб, Вы писали:
Р>>PWA + FUGU буквально на днях доклад на тубе смотрел. чел двумя руками, значит можно на блазоре херачить. Р>>C#.
S>Какой получается размер hello world?
18МБ но там 3 набора dll,gz,br.
т.е. 18 / 3 ~ 6-7 МБ
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Разраб, Вы писали:
S>>>Какой получается размер hello world?
Р>>18МБ но там 3 набора dll,gz,br. Р>>т.е. 18 / 3 ~ 6-7 МБ
S>Это вы как делаете? В VS создаете Blazor — приложение и нажимаете публикацию? А клиент сколько скачать должен?
все так. 6-7мб
UPDATE ЗАМЕРЯЛ НА 7КЕ 10мб по сети 25Мб после распаковки.
Повторно даже после принудительной очистки грузит мелочь. Хотя конечно было бы неплохо придумать общий кэш для сборок дотнета как было в винде.
Здравствуйте, Разраб, Вы писали:
Р>PWA + FUGU буквально на днях доклад на тубе смотрел. чел двумя руками, значит можно на блазоре херачить. Р>C#.
Ага. Мало нам .NET с его MSIL, нужно это ещё в WASM завернуть, чтобы современные процессоры не простаивали
Человеки сошли с ума.
Вместо того, чтобы пользоваться преимуществами десктопа, тащат на него скриптовые языки типа JS или замедляют до их уровня нативные языки через WASM.
Сначала в вебе придумали Single Page Application, теперь и в десктопе модно навигацию как в браузере делать и эмулировать диалоги через всякие popup.
Нравится HTML для разметки — ну, можно Sciter взять или аналогичный подход использовать, но нет же, человеки хотят тащить целый браузер, возиться с RPC и т.д. и т.п.
По-моему люди уже не понимают какие костыли городят и просто не могут уже остановиться, а когда-нибудь этот карточный домик рухнет.
Здравствуйте, karbofos42, Вы писали:
K>Вместо того, чтобы пользоваться преимуществами десктопа, тащат на него скриптовые языки типа JS
Я в замешательстве. А КУДА надо тащить JS, если не на десктоп? На мобилки?
K>Нравится HTML для разметки — ну, можно Sciter взять или аналогичный подход использовать, но нет же, человеки хотят тащить целый браузер, возиться с RPC и т.д. и т.п.
Так там тоже есть свой JS. Ты думаешь, там DOM'ом исключительно на плюсах управляют?
Ну и не согласен с ТК, так как MAUI это не только ГУЙ, но и прежде всего кроссплатформенный код, а ГУЙ рисовать можно и платформозависимый,
если не нравится кроссплатформенный гуй.
Здравствуйте, karbofos42, Вы писали:
A>>Я в замешательстве. А КУДА надо тащить JS, если не на десктоп? На мобилки?
K>На свалку истории.
И наплевать, что у него есть своя ниша, где он вписывается лучше всего.
A>>Так там тоже есть свой JS. Ты думаешь, там DOM'ом исключительно на плюсах управляют?
K>А я говорил, что там нет JS?
Ты противопоставил его и "тащить целый браузер". А это и есть браузер, только хорошо написанный, в отличие от гуглошлака. Разницы нет. Ведь, в принципе, если тебя не устраивает read-only C++ DOM access в Хромиуме, можно спуститься на более низкий уровень, и рулить там из C++ напрямую. И всегда было так можно, со времён IHtmlElement. Видишь? Нет разницы. И там, и там можно на низкоуровневом языке управлять высокоуровневыми объектами. И там, и там вменяемые люди предпочитают вместо этого использовать ЯП, специально заточенный под задачу.
Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
Здравствуйте, Alekzander, Вы писали:
A>И наплевать, что у него есть своя ниша, где он вписывается лучше всего.
Просто так исторически сложилось, сам язык ужасен и его заслуги тут нет.
A>Ты противопоставил его и "тащить целый браузер". А это и есть браузер, только хорошо написанный, в отличие от гуглошлака. Разницы нет. Ведь, в принципе, если тебя не устраивает read-only C++ DOM access в Хромиуме, можно спуститься на более низкий уровень, и рулить там из C++ напрямую. И всегда было так можно, со времён IHtmlElement. Видишь? Нет разницы. И там, и там можно на низкоуровневом языке управлять высокоуровневыми объектами. И там, и там вменяемые люди предпочитают вместо этого использовать ЯП, специально заточенный под задачу.
Разница в том, что сейчас часто ради веб-UI в десктопном приложении по сути поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе и всё это обменивается json-чиками, т.к. нужно реализовывать IPC.
Если уж XAML всякие не нравятся и хочется именно HTML, то можно рендеринг так же в процесс библиотекой подключить и не ходить через огороды типа того же WASM.
WPF, Qt и другие библиотеки ведь как-то работают без всех этих усложнений.
A>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
А кто-то людям мешает для плюсов нормальную библиотеку сделать?
В моей жизни были и голый WinAPI и MFC и wxWidgets, как-то управлял памятью, не умер.
В том же .NET на WPF как-то народ сложные интерфейсы делает и некоторым даже нравится.
При том, что в момент появления библиотека WPF казалась очень медленной и прожорливой.
На современном железе уже и это поделие летает, поэтому решили придумывать ещё более упоротые библиотеки, которые будут потреблять ещё больше накладных ресурсов.
Зачем нам GUI компилировать, мы будем в рантайме парсить HTML, дабы сформировать его DOM, чтобы и память сожрать и процессор не бездельничал.
Современное железо конечно всё это перемелет, но я не понимаю зачем вот так через огороды заходить, героически выдумывать как оптимальнее тот же DOM формировать?
Здравствуйте, Serginio1, Вы писали:
S>Ну вот в Webassembly обещают и GC и управление DOM завести. S>Кстати в .Net Webassembly используют вместо AppDomain
Один кроссплатформенный ассемблер прогоняем через другой кроссплатформенный ассемблер.
Один я считаю это чем-то странным?
S> Ну и AOT
Здравствуйте, karbofos42, Вы писали:
K>Разница в том, что сейчас часто ради веб-UI в десктопном приложении по сути поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе и всё это обменивается json-чиками, т.к. нужно реализовывать IPC. K>Если уж XAML всякие не нравятся и хочется именно HTML, то можно рендеринг так же в процесс библиотекой подключить и не ходить через огороды типа того же WASM. K>WPF, Qt и другие библиотеки ведь как-то работают без всех этих усложнений.
Давай не будем перескакивать с одного на другое. Полно приложений, которые не "поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе", а просто используют webview в основном процессе, и открывают в нём локальный HTML-ресурс. А дальше уже он изнутри на JS работает с DOM. К их авторам какие претензии? Почему они должны выкидывать JS на свалку истории? JS, конечно, реально отстойный по сравнению с лучшими скриптовыми языками, но всяко больше для этого подходит, чем манипулирование DOM'ом на нативном языке снаружи. Хотя бы тем, что бизнес-логика автоматически отделяется от чисто интерфейсных вещей.
A>>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
K>А кто-то людям мешает для плюсов нормальную библиотеку сделать? K>В моей жизни были и голый WinAPI и MFC и wxWidgets, как-то управлял памятью, не умер.
Когда-то вообще перфокарты юзали и... БЛИН! Они все умерли!!
Хреновый это аргумент — что наши предки без современных удобств обходились, и ничего.
Кстати про предков. Как же с облегчением вздохнули юзеры одного продукта в 2003 году, когда загрузчик-хранилище файлов вынесли из внутрипроцессного COM-сервера в локальный (отдельный процесс). Он перестал, наконец, при крешах, связанных с импортом кривых файлов плохо специфицированных форматов, утягивать за собой само приложение с расчётными модулями. Хотя приложение и замедлилось за счёт передачи данных... аж на 5%, наверно.
K>Зачем нам GUI компилировать, мы будем в рантайме парсить HTML, дабы сформировать его DOM, чтобы и память сожрать и процессор не бездельничал.
Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Сейчас, допустим, есть у тебя dll, в которой собраны все ресурсы и HTML. Ты придумал какой-то компилированный бинарный формат. И опачки — уже без выгрузки в файл и декомпиляции не посмотришь на него. А ради чего? Ты это ускорение в микроскоп не увидишь.
Я думаю, так рассуждать могут только те, кто далёк от реального GUI-строения. И вообще, сильно похоже на бабкино нытьё на лавочках: нынче молодёжь распоясалась, GUI не компилируют, то ли дело мы...
K>Современное железо конечно всё это перемелет, но я не понимаю зачем вот так через огороды заходить, героически выдумывать как оптимальнее тот же DOM формировать?
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, Разраб, Вы писали:
Р>>PWA + FUGU буквально на днях доклад на тубе смотрел. чел двумя руками, значит можно на блазоре херачить. Р>>C#.
K>Ага. Мало нам .NET с его MSIL, нужно это ещё в WASM завернуть, чтобы современные процессоры не простаивали K>Человеки сошли с ума.
Я ответил на вопрос. С другой стороны у дотнета тоже есть плюшки — скорость компиляции например. богатая базовая библиотека.
Хотя в случае с pwa и fugu конечно не нужны ни дарт и шарп.
Здравствуйте, Alekzander, Вы писали:
A>Давай не будем перескакивать с одного на другое. Полно приложений, которые не "поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе", а просто используют webview в основном процессе, и открывают в нём локальный HTML-ресурс. А дальше уже он изнутри на JS работает с DOM. К их авторам какие претензии? Почему они должны выкидывать JS на свалку истории? JS, конечно, реально отстойный по сравнению с лучшими скриптовыми языками, но всяко больше для этого подходит, чем манипулирование DOM'ом на нативном языке снаружи. Хотя бы тем, что бизнес-логика автоматически отделяется от чисто интерфейсных вещей.
Что значит "манипулирование DOM снаружи"? Может не нужно было DOM наружу выносить и тогда нативный язык был бы не снаружи?
А то сами себе проблемы создали, героически придумали как их обойти, а потом ещё радуются что интерфейсные вещи отдельно от бизнес-логики.
Ну, да, приходится объекты из бизнес-логики сериализовать в json, чтобы потом их из JS парсить и распихивать по DOM — очень оптимально.
A>Кстати про предков. Как же с облегчением вздохнули юзеры одного продукта в 2003 году, когда загрузчик-хранилище файлов вынесли из внутрипроцессного COM-сервера в локальный (отдельный процесс). Он перестал, наконец, при крешах, связанных с импортом кривых файлов плохо специфицированных форматов, утягивать за собой само приложение с расчётными модулями. Хотя приложение и замедлилось за счёт передачи данных... аж на 5%, наверно.
Ну, тогда нужно каждую кнопку в отдельной процесс вынести, а то вдруг чего где не обработано, а любая ошибка может уронить всё приложение.
A>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
А ты прямо так в профайлере проваливаешься и изучаешь?
Или просто: ну, у меня пустое окно без разметки открывается 10 секунд, а заполненное — 11 секунд — ну, значит всё норм, секунда погоды не делает?
Прямо отдельно в недра движка браузера лезешь, выискиваешь отдельно парсер, отдельно рендер?
Или чисто от балды взял?
Ну, тогда нужно начинать с того, что нативной библиотеке не нужно тянуть сотню мегабайт библиотек от движка браузера.
Даже если сам парсинг будет быстрый, всё в сумме даст потерю и по памяти и по скорости.
A>Сейчас, допустим, есть у тебя dll, в которой собраны все ресурсы и HTML. Ты придумал какой-то компилированный бинарный формат. И опачки — уже без выгрузки в файл и декомпиляции не посмотришь на него. А ради чего? Ты это ускорение в микроскоп не увидишь.
т.е. *.cpp файлы не нужны? Они компилируются в какой-то придуманный бинарный формат и даже с декомпиляцией dll исходники не достать.
Ну, всё, переходим на JS, а то все эти ускорения нативных языков в микроскоп не увидишь.
Почему тот же XAML можно скомпилировать, а HTML — нельзя и обязательно вместо него нужно что-то бинарное придумывать?
A>Я думаю, так рассуждать могут только те, кто далёк от реального GUI-строения. И вообще, сильно похоже на бабкино нытьё на лавочках: нынче молодёжь распоясалась, GUI не компилируют, то ли дело мы...
Если раньше много однотипного дурацкого кода писали на "нативных" языках, это сильно раздражало, но достаточно легко отлаживалось за счёт имеющихся отладчиков.
То сейчас по-моему отлаживать GUI — то ещё приключение. Что HTML отлично отлаживается, что CSS туда же, а уж раскиданный везде JS — ещё веселее, особенно когда половину делают фреймворки.
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, Serginio1, Вы писали:
S>>Ну вот в Webassembly обещают и GC и управление DOM завести. S>>Кстати в .Net Webassembly используют вместо AppDomain
K>Один кроссплатформенный ассемблер прогоняем через другой кроссплатформенный ассемблер. K>Один я считаю это чем-то странным?
Песочница! S>> Ну и AOT
K>Ну, WASM — это не так, чтобы Native.
Кто то про ассемблер говорил?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, Alekzander, Вы писали:
A>>Давай не будем перескакивать с одного на другое. Полно приложений, которые не "поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе", а просто используют webview в основном процессе, и открывают в нём локальный HTML-ресурс. А дальше уже он изнутри на JS работает с DOM. К их авторам какие претензии? Почему они должны выкидывать JS на свалку истории? JS, конечно, реально отстойный по сравнению с лучшими скриптовыми языками, но всяко больше для этого подходит, чем манипулирование DOM'ом на нативном языке снаружи. Хотя бы тем, что бизнес-логика автоматически отделяется от чисто интерфейсных вещей.
K>Что значит "манипулирование DOM снаружи"?
Выше ты написал: "Вместо того, чтобы пользоваться преимуществами десктопа, тащат на него скриптовые языки типа JS ... Нравится HTML для разметки — ну, можно Sciter взять или аналогичный подход использовать".
Когда ты это писал, то помнил, что при использовании HTML для разметки альтернатива JS — взять Скайтер и манипулировать DOM снаружи (на C++). А теперь вдруг забыл.
A>>Кстати про предков. Как же с облегчением вздохнули юзеры одного продукта в 2003 году, когда загрузчик-хранилище файлов вынесли из внутрипроцессного COM-сервера в локальный (отдельный процесс). Он перестал, наконец, при крешах, связанных с импортом кривых файлов плохо специфицированных форматов, утягивать за собой само приложение с расчётными модулями. Хотя приложение и замедлилось за счёт передачи данных... аж на 5%, наверно.
K>Ну, тогда нужно каждую кнопку в отдельной процесс вынести, а то вдруг чего где не обработано, а любая ошибка может уронить всё приложение.
Если каждая кнопка занимается импортом кривых файлов плохо специфицированных форматов (зона высокого риска) — то да, нужно. Если не занимается — нет, не нужно. Третий раз пишу: можно не валить всё в одну кучу?
A>>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
K>А ты прямо так в профайлере проваливаешься и изучаешь? K>Или просто: ну, у меня пустое окно без разметки открывается 10 секунд, а заполненное — 11 секунд — ну, значит всё норм, секунда погоды не делает?
Я действительно нечасто пользуюсь профайлером, но это потому, что у меня большой опыт, и в части написания интерфейсов — особенно. Я и так знаю, где в системе ботлнеки, и что надо оптимизировать, а что — нет.
А вот тебе не помешало бы недельку покурить профайлер, чтобы не наваливать на парсер. Короче, надоело.
Здравствуйте, Alekzander, Вы писали:
A>Когда ты это писал, то помнил, что при использовании HTML для разметки альтернатива JS — взять Скайтер и манипулировать DOM снаружи (на C++). А теперь вдруг забыл.
Так Sciter — это тоже костыль и затаскивание в десктоп веб-технологий. Я не говорил, что к этому нужно стремить и правильно.
Но уж лучше это, чем все эти Electron, PWA и прочая дичь, когда веб-приложение делает вид, что оно десктопное.
A>Третий раз пишу: можно не валить всё в одну кучу?
Так ты мне тут всякое и наваливаешь не по теме, я лишь ответил
A>Я действительно нечасто пользуюсь профайлером, но это потому, что у меня большой опыт, и в части написания интерфейсов — особенно. Я и так знаю, где в системе ботлнеки, и что надо оптимизировать, а что — нет.
Молодец. Разработчикам фронтенд-фреймворков об этом расскажи, а то они постоянно что-то выдумывают. То какие-то VDOM прикручивают, чтобы быстрее работало, то ещё чего выдумывают.
Забили бы на микрооптимизации и занимались действительно важными вещами.
A>А вот тебе не помешало бы недельку покурить профайлер, чтобы не наваливать на парсер. Короче, надоело.
Не говори людям, что им делать и они не скажут куда тебе идти. Надоело — я не заставляю со мной диалог вести
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, Разраб, Вы писали:
Р>>PWA + FUGU буквально на днях доклад на тубе смотрел. чел двумя руками, значит можно на блазоре херачить. Р>>C#.
K>Ага. Мало нам .NET с его MSIL, нужно это ещё в WASM завернуть, чтобы современные процессоры не простаивали K>Человеки сошли с ума.
Ну так а где все эти крутые Сишники с приложениями на Sciter? Почему не понапишут своих супер-быстрых приложений чтобы все на них перешли и JS умер наконец-то?
Уж не потому ли что у них производительность труда ниже плинтуса?
