Здравствуйте, Alekzander, Вы писали:
A>...Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
rich UI приложения вполне себе делась 15 лет назад на Delphi. Это строго типизированный язык, без динамиков и с ручным упралением памятью (полностью ручным — в C++ есть Spart-pointer's а в делфе нет). Притом это (то, что я видел) крутилось тогда на P4 — очень быстро работало.
В те годы когда я это видел и немножко ковырял, у меня друг в Ростове на Дону на плюсах разрабатывал трэйдерсую софтину. Там можно было вывести на экран миллиарды графиков и одновременно использовать тонны всяких всяких инструментов анализа. И это работало БЫСТРО, без каких-либо нареканий по скорости. Это всё было на тех же пнях 4-х. Это было время появления у людей Pentium-D и выхода первых Core-2.
Характерный объём памяти на машинах тогда было 512 MB — 1 Gb.
А ещё чуть-чуть раньше (2005 — 2006г) я наблюдал как человек в архикаде делает довольно сложный проект на компе, где стоял Athlon-XP 2500+. Я надеюсь, ты не осмелишся утверждать, что в CAD-системах слабенький IU, что он не Rich.
У меня прямо сейчас примерно столько (512 MB) отжирает соседняя с кывтом вкладка с ютубом. Притом она УЖЕ сожрала 38 минут CPU-time. А у меня тут далеко не Pentium, а целый i9.
Все эти ваши модные веб-технологии — суперпрожорливое говно.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Разраб, Вы писали:
Р>PWA + FUGU буквально на днях доклад на тубе смотрел. чел двумя руками, значит можно на блазоре херачить. Р>C#.
Ага. Мало нам .NET с его MSIL, нужно это ещё в WASM завернуть, чтобы современные процессоры не простаивали
Человеки сошли с ума.
Вместо того, чтобы пользоваться преимуществами десктопа, тащат на него скриптовые языки типа JS или замедляют до их уровня нативные языки через WASM.
Сначала в вебе придумали Single Page Application, теперь и в десктопе модно навигацию как в браузере делать и эмулировать диалоги через всякие popup.
Нравится HTML для разметки — ну, можно Sciter взять или аналогичный подход использовать, но нет же, человеки хотят тащить целый браузер, возиться с RPC и т.д. и т.п.
По-моему люди уже не понимают какие костыли городят и просто не могут уже остановиться, а когда-нибудь этот карточный домик рухнет.
Здравствуйте, 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 формировать?
Здравствуйте, Философ, Вы писали:
Ф>Я надеюсь, ты не осмелишся утверждать, что в CAD-системах слабенький IU, что он не Rich.
Очень удобно, что ты это выделил болдом. Сразу видно, что ты не понимаешь, что такое rich UI. CAD-система, Блокнот, почтовый клиент — все они могут обладать как rich UI (приятными излишествами), так и дельфийским говном спартанским интерфейсом. Я тут курсы дизайна для пенсионеров не веду и разжёвывать не буду. Скажу только, что со временем понятие приятных излишеств меняется. Когда-то всё, кроме командной строки, считалось приятными излишествами. А сейчас это, например, сложный градиент фона рабочего пространства (workspace) документов. Попишешь такие штуки императивно, быстро поймёшь, в чём фишка CSS. Но ты не будешь, потому, что застрял в прошлом. Будете с Карбофосом рассказывать, что это никому не надо. Мне норм, конкуренции меньше.
У MS не получилось в моб. оси — по этому претендовать что-либо они не могут, будут в хвосте. Производители моб. осей будут ставить палки в колеса — возможности есть. Т.е. делать так, чтобы их решение работало медленно.
Здравствуйте, Alekzander, Вы писали:
A>Когда ты это писал, то помнил, что при использовании HTML для разметки альтернатива JS — взять Скайтер и манипулировать DOM снаружи (на C++). А теперь вдруг забыл.
Так Sciter — это тоже костыль и затаскивание в десктоп веб-технологий. Я не говорил, что к этому нужно стремить и правильно.
Но уж лучше это, чем все эти Electron, PWA и прочая дичь, когда веб-приложение делает вид, что оно десктопное.
A>Третий раз пишу: можно не валить всё в одну кучу?
Так ты мне тут всякое и наваливаешь не по теме, я лишь ответил
A>Я действительно нечасто пользуюсь профайлером, но это потому, что у меня большой опыт, и в части написания интерфейсов — особенно. Я и так знаю, где в системе ботлнеки, и что надо оптимизировать, а что — нет.
Молодец. Разработчикам фронтенд-фреймворков об этом расскажи, а то они постоянно что-то выдумывают. То какие-то VDOM прикручивают, чтобы быстрее работало, то ещё чего выдумывают.
Забили бы на микрооптимизации и занимались действительно важными вещами.
A>А вот тебе не помешало бы недельку покурить профайлер, чтобы не наваливать на парсер. Короче, надоело.
Не говори людям, что им делать и они не скажут куда тебе идти. Надоело — я не заставляю со мной диалог вести
Здравствуйте, karbofos42, Вы писали:
K>Вместо того, чтобы пользоваться преимуществами десктопа, тащат на него скриптовые языки типа JS
Самое смешное, что идиоты пытаются весь десктопный софт загнать в браузер, в то время как на мобилах тенденция прямо противоположная — каждый говносайт хочет иметь свое собственное приложение вместо браузерной версии.
Здравствуйте, karbofos42, Вы писали:
K>Зачем нам GUI компилировать, мы будем в рантайме парсить HTML, дабы сформировать его DOM, чтобы и память сожрать и процессор не бездельничал. K>Современное железо конечно всё это перемелет
Да уже и топовое современное железо с трудом справляется со всем этим сраным цирком.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Alekzander, Вы писали:
A>>...Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
Ф>rich UI приложения вполне себе делась 15 лет назад на Delphi. Это строго типизированный язык, без динамиков и с ручным упралением памятью (полностью ручным — в C++ есть Spart-pointer's а в делфе нет). Притом это (то, что я видел) крутилось тогда на P4 — очень быстро работало.
Размер экрана. + фиксированный размер окошек. Отсюда и скорость.
глубина цветов. опять же.
Здравствуйте, Константин Б., Вы писали:
КБ>Да. Во первых потому что написанная программа всегда лучше не написанной. КБ>А во вторых "многопроцессное приложение с полноценным браузером, IPC и прочими плюшками" хоть и звучит страшно, но от разработчика не требует никаких затрат времени и усилий.
Так я как отдельно взятый разработчик вполне допускаю, что могу в каком-нибудь проекте использовать данный подход.
Понятно, что оно работает и можно реализовать ПО за разумные сроки.
Почему корпорации и сообщество подхватывают эту движуху и такие инструменты до продакшена дошли — это мне не понятно.
Технически нет проблем реализовать всё нативно. Просто нужно было разработать немного другие фреймворки, их было бы удобнее использовать и работало бы быстрее.
Я бы понял, если бы этот подход сильно упрощал жизнь, но по факту там проблема на проблеме.
Вот уже и WASM приходится затаскивать в веб, т.к. JS не вывозит и фронтенд фреймворки делают и переделывают постоянно, чтобы оно работало быстро у пользователей (серверный пре-рендеринг всякий и т.п.).
Здравствуйте, Alekzander, Вы писали:
A>Очень удобно, что ты это выделил болдом. Сразу видно, что ты не понимаешь, что такое rich UI. CAD-система, Блокнот, почтовый клиент — все они могут обладать как rich UI (приятными излишествами), так и дельфийским говном спартанским интерфейсом.
Не спартанским интефейсом, а сложносоставными контролами, частенько самостоятельно отрисованными. Rich-UI это в первую очередь сложности с layout'ом: у тебя одновременно может быть таблицы и стэки, притом динамически перекрывающие контролы на заднем плане. Например, на передний план (перекрывая основную рабочую область) может выводиться "табличка" со снипетами, притом не просто табличка, а хрень с несколькими стеками и flow-панелями внутри. Притом выводится она на передний план так, что частично затеняет основную рабочую область. Из массово-доступных примеров такого ты можешь взглянуть на инструмент добавления таблицы в Neat Office.
Rich-UI это, когда у тебя UI активно реагирует на то, что в данный момент делает пользователь: в том же Neat Office кнопки на тулбарах реагируют на то, что в данный момент делает пользователь с контентом, а статус-бар отображает состояние натыканного пользователем.
Rich-UI это Grid в Dev-Express компонентах — поищи в гуглокартинах и посмотри: там в гриде может быть всё что угодно.
Конечно же накидать кнопок на форму — не Rich — это элементарщина. Rich — это про поведение и layout и ещё немного про отрисовку.
У меня подгорает от таких разговоров, это особенно после того как у меня неоднократно спрашивали, как можно 2-3 дня упорно работать над одной формой ввода, особнно чуваку, который гуём больше пяти лет занимался. Обычно всё проясняется после того, как суперспециалисты показывают, что они могут за 15 минут. Вот ты мне скажи, может ли поле ввода выть Rich-UI?
A>А сейчас это, например, сложный градиент фона рабочего пространства (workspace) документов. Попишешь такие штуки императивно, быстро поймёшь, в чём фишка CSS.
Такие вещи всегда делались в векторных редакторах. Думаю, для тебя не секрет, что SVG нарисовать проблем никаких не составляет, да и не составляло никогда.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Rich-UI это в первую очередь сложности с layout'ом: у тебя одновременно может быть таблицы и стэки, притом динамически перекрывающие контролы на заднем плане.
Всё это было в DOS Navigator — и стеки, и таблицы, и перекрывающиеся контролы на заднем плане. В текстовом режиме, псевдографикой. Разумеется, никто не назовёт DOS Navigator приложением с Rich UI, а значит что-то не так с твоими критериями.
Ф>Вот ты мне скажи, может ли поле ввода выть Rich-UI?
Конечно, причём как на уровне внешнего вида, так и на уровне поведения. (Именно поэтому CSS и JS, как Маркс и Энгельс — два разных человека). Пример первого — это темы оформления. В медиплеерах часто можно увидеть. Пример второго — когда поле ввода ходит за подсказками на сервер.
A>>А сейчас это, например, сложный градиент фона рабочего пространства (workspace) документов. Попишешь такие штуки императивно, быстро поймёшь, в чём фишка CSS.
Ф>Такие вещи всегда делались в векторных редакторах. Думаю, для тебя не секрет, что SVG нарисовать проблем никаких не составляет, да и не составляло никогда.
Вот по таким вещам штрилицы сразу и палятся. Видно, кто реально работает с UI, а кто нет. Сделай мне в "векторном редакторе" простой линейный градиент от красного к синему, но в HCL. (Мы же не лохи, чтобы делать неестественные RGB-переходы, правда?). Для начала ты хотя бы найди в Inkscape (или в чём там ещё), как простой прямоугольник залить в HCL. В версии 1.22 Inkscape такой возможности вообще нет. Следующее упражнение на четыре балла: сделай тот же равномерный переход от красного к синему, но в HSV, который в 1.22 есть (ну, чтобы он был более эппл-стайл), а потом удивись, почему он там выглядит совсем не так, как в других программах (например, в браузере). Упражнение на пять баллов: сделай фон в диагональную полоску. ГРАДИЕНТОМ. (Да, "фон в диагональную полоску" это градиент, если ты не знал).
Далее, как ты сохранишь в SVG именно заливку (в т.ч. угол), а не залитый прямоугольник? Прямоугольник-то нельзя выводить на весь фон. Или фон останется недозалитым, или угол градиента нарушится.
Далее, как ты заменишь красный и синий на цветовые переменные, общие для всей темы? Напоминаю, в HCL/HSV! (Последнее означает, что если твой редактор на лету сконвертил двухстоповый HSV-градиент в N-стоповый RGB, то ты сразу приплыл — переменные уже не сделаешь никак).
Вот поэтому многие технические дизайнеры вообще не уважает WYSIWYG. Проще описать необходимый градиент одной-двумя строчками текста, чем решать все эти головняки. Тем более, к DOM'у обычно в комплекте идёт редактор, и можно сразу в живом приложении поглядеть варианты.
Но допустим. Сделал ты SVG. В векторном редакторе. (Хотя, ещё раз, адекватные люди не будут так делать). Как ты его выведешь? Тебе для этого понадобится движок SVG. И чтобы он, в отличие от Инкскейпа, не косячил при заливке в HSV. Теперь добавь к нему скрипты, чтобы поле могло ходить за подсказками на сервер в две строчки (а не двести). И что получится? Ой, как ни крути, а всё пулемёт собирается!
Здравствуйте, Skorodum, Вы писали:
A>>Декларативность — понятие очень многозначное. Есть декларативность разметки. S>Было бы интересно увидеть пример не декларативной разметки.
Ну чего дурачка-то валять? "Есть декларативность разметки[, противопоставляемая императивности создания контролов кодом]".
A>>Есть декларативность адресации контролов (селекторы). S>Что ты имеешь в виду? Привиди пример.
В старину были адреса: Кемская волость, село Пятаково, дом купца Калашникова (зелёный такой).
По аналогии, сейчас можно разыскивать секцию с обратной формой, поле для ввода текста, обязательно зелёное.
Если ты будешь перебирать контролы, пока не найдёшь обладающий всеми свойствами, это будет императивный подход. А можно получить одним декларативным запросом, если адресация селекторная (.feedback-form input.green). Сейчас синтаксис этих селекторов настолько развит, что это почти SQL уже
А если просто завести по переменной на каждый контрол и хранить ссылки, то это перестанет быть адресацией. Это будут шорткаты типа "доставьте посылку клиенту Васе".
A>>Есть декларативность на уровне языка управления (поддержка лямбд вместо циклов). S>Лямбды ортогональны циклам и к декларативности отношения не имеют.
Да неужели. Лямбды позволяют описывать задачу, типа "трансформируй коллекцию так-то", в отличие от циклов, где тебе надо её пошагово решать.
A>>Не знаю, кому там что приятно, но сравнивать с титаническим HTML какие-то местечковые технологии... всякие QML, XAML... Я подписан на несколько дайджестов, где постоянно выкладывают фокусы, связанные с UI, сделанные на HTML. Конкурсы проводятся, жизнь бурлит. А покажи хоть один дайджест для QML-девелоперов. Или конкурс S>Сядь в современный автомобиль: с выской вероятностью интерфейс написан на C++/QML.
Я лично делал два проекта для автомобильных интерфейсов, если что. А вообще, я, как бы, не об этом. Я о том, что сейчас именно HTML это cutting edge для интерфейсостроения. Просто не надо ассоциировать HTML исключительно с гугловским ожиревшим движком или, допустим, с сервером в отдельном процессе, про который тут выше ныли. Это вещи несвязанные. Бывает, что удобно делать веб-сервер, а бывает, что нет. Я вот думаю об одном проекте, где программа сможет подключаться к любым своим инстансам на любых машинах. Там, конечно, веб-сервер будет оправдан.
Вот на 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Мб после распаковки.
Повторно даже после принудительной очистки грузит мелочь. Хотя конечно было бы неплохо придумать общий кэш для сборок дотнета как было в винде.
Здравствуйте, 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 приложение, а не очередной хелло-ворлд.
Здравствуйте, 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 секунд — ну, значит всё норм, секунда погоды не делает?
Я действительно нечасто пользуюсь профайлером, но это потому, что у меня большой опыт, и в части написания интерфейсов — особенно. Я и так знаю, где в системе ботлнеки, и что надо оптимизировать, а что — нет.
А вот тебе не помешало бы недельку покурить профайлер, чтобы не наваливать на парсер. Короче, надоело.
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, Разраб, Вы писали:
Р>>PWA + FUGU буквально на днях доклад на тубе смотрел. чел двумя руками, значит можно на блазоре херачить. Р>>C#.
K>Ага. Мало нам .NET с его MSIL, нужно это ещё в WASM завернуть, чтобы современные процессоры не простаивали K>Человеки сошли с ума.
Ну так а где все эти крутые Сишники с приложениями на Sciter? Почему не понапишут своих супер-быстрых приложений чтобы все на них перешли и JS умер наконец-то?
Уж не потому ли что у них производительность труда ниже плинтуса?
Здравствуйте, Константин Б., Вы писали:
КБ>Ну так а где все эти крутые Сишники с приложениями на Sciter? Почему не понапишут своих супер-быстрых приложений чтобы все на них перешли и JS умер наконец-то?
Я не понимаю почему человечество идёт далеко не самым оптимальным путём.
Будешь убеждать, что создавать многопроцессное приложение с полноценным браузером, IPC и прочими плюшками — это производительнее и лучше, чем внедрить рендер в свой основной процесс, тащить с собой меньше библиотек и не загоняться с IPC?
КБ>Уж не потому ли что у них производительность труда ниже плинтуса?
Может это заговор корпораций, которые создают всякую дичь, чтобы пользователи покупали новые мощные компы
Фронтендеры не осилили даже какой-нибудь второй язык выучить, поэтому пришлось им лепить Node.js и пачку фреймворков, чтобы хоть как-то у них хоть что-то в вебе работало.
Конечно у них дикая производительность.
Здравствуйте, Константин Б., Вы писали:
КБ>Ну так а где все эти крутые Сишники с приложениями на Sciter? Почему не понапишут своих супер-быстрых приложений чтобы все на них перешли и JS умер наконец-то?
Здравствуйте, Shmj, Вы писали:
S>.Net применим для бекэнда. Однако в клиентской части практически уже все, полномочия закончились. Пытаются повторить Flutter в формате MAUI, но более убого получилось и, главное, у MS вообще не получилось в моб. платформу — по этому они не в теме (дело даже не в этом — производители моб. осей могут им ставить палки в колеса).
S>Кто что скажет?
А можно поподробнее про "полномочия закончились". Еще раз. В MAUI можно использовать как кросплатформенные, так и родные компоненты через условную компиляцию. https://learn.microsoft.com/ru-ru/xamarin/android/app-fundamentals/graphics-and-animation
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Alekzander, Вы писали:
A>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Я прогонял. Много, часто, упорно и долго этим занимался. У меня в профайлере были разные приложения, в т.ч. с кастомным layout'ом и местами с кастомной отрисовкой. В т.ч. я сам и выделял регионы, и рисовал через GDI, и битмапы через BitBlt гонял. Так что я тебе точно скажу что там тормозит: в половине случаев там тормозит обсчёт layut'а, в трети случаев кастомная отрисовка, а ещё в четверти стандартные контролы слишкмо часто рисуются.
И я тебе точно скажу, что компиляция имеет смысл. Более того, имеет смысл включение оптимизации при компиляции: тормоза в дебажной сборке — не страшно, а в релизной тормозить уже не должно.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, karbofos42, Вы писали:
K>Будешь убеждать, что создавать многопроцессное приложение с полноценным браузером, IPC и прочими плюшками — это производительнее и лучше, чем внедрить рендер в свой основной процесс, тащить с собой меньше библиотек и не загоняться с IPC?
Да. Во первых потому что написанная программа всегда лучше не написанной.
А во вторых "многопроцессное приложение с полноценным браузером, IPC и прочими плюшками" хоть и звучит страшно, но от разработчика не требует никаких затрат времени и усилий.
"тащить с собой меньше библиотек и не загоняться с IPC" — это просто какая-то сишная профдеформация.
Там и библиотеку добавить — приключение на неделю. И IPC — боль и страдания.
В нормальных языках добавлять библиотеки и работать с IPC — просто и приятно.
Здравствуйте, Философ, Вы писали:
A>>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Ф>Я прогонял. Много, часто, упорно и долго этим занимался. У меня в профайлере были разные приложения, в т.ч. с кастомным layout'ом и местами с кастомной отрисовкой. В т.ч. я сам и выделял регионы, и рисовал через GDI, и битмапы через BitBlt гонял. Так что я тебе точно скажу что там тормозит: в половине случаев там тормозит обсчёт layut'а, в трети случаев кастомная отрисовка, а ещё в четверти стандартные контролы слишкмо часто рисуются. Ф>И я тебе точно скажу, что компиляция имеет смысл. Более того, имеет смысл включение оптимизации при компиляции: тормоза в дебажной сборке — не страшно, а в релизной тормозить уже не должно.
Это две разные компиляции. Вот что он написал:
>мы будем в рантайме парсить HTML
Можно скомпилировать HTML, чтобы парсить в рантайме не приходилось. Чтобы вместо этого была тупо десериализация DOM. А ты говоришь, судя по "имеет смысл включение оптимизации при компиляции", о том, чтобы вообще выкинуть декларативное описание и заменить его 100% императивным кодом. Ты на этом, конечно, сможешь что-то выиграть, но только ценой снижения скорости разработки, причём очень высокой ценой (если разрабатывать что-то более-менее сложное). Это как отказаться от SQL и самому писать в файлы ДЛЯ ОПТИМИЗАЦИИ — где-то прокатит, но чтобы такие размены обсуждать, надо сначала пописать декларативные гуи, чтобы было с чем сравнивать.
Здравствуйте, Alekzander, Вы писали:
Ф>>Такие вещи всегда делались в векторных редакторах. Думаю, для тебя не секрет, что SVG нарисовать проблем никаких не составляет, да и не составляло никогда.
A>Вот по таким вещам штрилицы сразу и палятся. Видно, кто реально работает с UI, а кто нет. Сделай мне в "векторном редакторе" простой линейный градиент от красного к синему, но в HCL.
Ааа ну-ну Услышали SVG — требуем другое цветовое пространство. Я вот сижу гадаю: а в курсе ли ты, что в SVG только одно цветовое пространство? Наверное поэтому и захотел HCL.
Интересно, понимаешь ли что, что SRGB обычно хватает и для чертежей и для "объёмных" рисунков, типа вот такого: https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/Svg.svg/2560px-Svg.svg.png
Он потому прижился и выжил, что для большинства задач его с головой, и что горе тому браузеру, который его не поддерживает.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
A>>Вот по таким вещам штрилицы сразу и палятся. Видно, кто реально работает с UI, а кто нет. Сделай мне в "векторном редакторе" простой линейный градиент от красного к синему, но в HCL.
Ф>Ааа ну-ну Услышали SVG — требуем другое цветовое пространство. Я вот сижу гадаю: а в курсе ли ты, что в SVG только одно цветовое пространство? Наверное поэтому и захотел HCL. Ф>Интересно, понимаешь ли что, что SRGB обычно хватает и для чертежей и для "объёмных" рисунков, типа вот такого: https://upload.wikimedia.org/wikipedia/commons/thumb/1/15/Svg.svg/2560px-Svg.svg.png
Ааа, sRGB... Мог бы сразу сказать, что у большинства всё равно шестибитный монитор, и у него цветовой охват ещё меньше. Как ты протащишь двухстопный градиент из головы дизайнера на экран пользователя — вот о чём шла речь. И какие промежуточные шаги для этого годятся, а какие — нет.
Остальное, видимо, возражений не вызвало.
Ладно, что я тут время трачу на споры? Пишите с Карбофосом на чём хотите, хоть на ассемблере.
Здравствуйте, Alekzander, Вы писали:
A>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
В мире C++ богатый UI пишется на декларативном QML или Slint.
A>>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд. S>В мире C++ богатый UI пишется на декларативном QML или Slint.
В управляемых языках есть удобства в плане рефлексии и динамической компиляции тех же деревьев выражений итд
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Skorodum, Вы писали:
A>>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд. S>В мире C++ богатый UI пишется на декларативном QML
Это случайно не тот самый ML, где id, source, height и color смешаны в одном тазике? Как в HTML до разделения доменов по DSL'ям.
А вообще, я говорил исключительно про работу с UI, где удобно делать именно такие кунштюки ("в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов"). И где крайне неудобен C++. Про бизнес-логику я ничего не говорил. Связка (HTML + CSS + JS) + C++ очень хороша для многих задач. Я почти всегда её и использую.
Здравствуйте, Alekzander, Вы писали:
A>Это случайно не тот самый ML, где id, source, height и color смешаны в одном тазике? Как в HTML до разделения доменов по DSL'ям.
Стили для контролов и в QWidgets и в QML есть.
Другое дело, что очень часто в QML работа идет с более низкими примитивами типа Rectangle, и поддержку стилей надо самим реализовать при необходимости (это тривиально).
A>А вообще, я говорил исключительно про работу с UI, где удобно делать именно такие кунштюки ("в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов"). И где крайне неудобен C++.
Тут согласен: императивный подход для сложного UI не самое лучшее решение. Поэтому и придумали QML, Slint и т.п.
A>Про бизнес-логику я ничего не говорил. Связка (HTML + CSS + JS) + C++ очень хороша для многих задач. Я почти всегда её и использую.
Рабочее решение, но QML как язык куда приятнее HTML, IMHO. Плюс доп.расходы на порядом меньше.
Здравствуйте, Skorodum, Вы писали:
A>>Это случайно не тот самый ML, где id, source, height и color смешаны в одном тазике? Как в HTML до разделения доменов по DSL'ям. S>Стили для контролов и в QWidgets и в QML есть. S>Другое дело, что очень часто в QML работа идет с более низкими примитивами типа Rectangle, и поддержку стилей надо самим реализовать при необходимости (это тривиально).
A>>А вообще, я говорил исключительно про работу с UI, где удобно делать именно такие кунштюки ("в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов"). И где крайне неудобен C++. S>Тут согласен: императивный подход для сложного UI не самое лучшее решение. Поэтому и придумали QML, Slint и т.п.
Декларативность — понятие очень многозначное. Есть декларативность разметки. Есть декларативность адресации контролов (селекторы). Есть декларативность на уровне языка управления (поддержка лямбд вместо циклов).
Многие эти декларативности присутствуют в HTML, но не в QML. А другие, связанные с языковым уровнем, худо-бедно поддержаны в C++ без помощи Qt, но там нет автоматического управления памятью, который не менее важен для UI, чем декларативности. Поэтому я и дописал в конце: "И поуправляй памятью для всего этого дела".
Так-то, в скрипт (JS) вынесено всё самое императивное из связки HTML/CSS/JS. Декларативное оставлено в HTML, CSS и в языке селекторов. Сборщик мусора + намного более приятный синтаксис — вот чем, в первую очередь, зачётны скрипты в UI.
A>>Про бизнес-логику я ничего не говорил. Связка (HTML + CSS + JS) + C++ очень хороша для многих задач. Я почти всегда её и использую. S>Рабочее решение, но QML как язык куда приятнее HTML, IMHO. Плюс доп.расходы на порядом меньше.
Не знаю, кому там что приятно, но сравнивать с титаническим HTML какие-то местечковые технологии... всякие QML, XAML... Я подписан на несколько дайджестов, где постоянно выкладывают фокусы, связанные с UI, сделанные на HTML. Конкурсы проводятся, жизнь бурлит. А покажи хоть один дайджест для QML-девелоперов. Или конкурс
Здравствуйте, Alekzander, Вы писали:
A>Декларативность — понятие очень многозначное. Есть декларативность разметки.
Было бы интересно увидеть пример не декларативной разметки.
A>Есть декларативность адресации контролов (селекторы).
Что ты имеешь в виду? Привиди пример.
A>Есть декларативность на уровне языка управления (поддержка лямбд вместо циклов).
Лямбды ортогональны циклам и к декларативности отношения не имеют.
A>Многие эти декларативности присутствуют в HTML, но не в QML.
Декларативность в QML это просто и наглядно:
A>А другие, связанные с языковым уровнем, худо-бедно поддержаны в C++ без помощи Qt, но там нет автоматического управления памятью, который не менее важен для UI, чем декларативности. Поэтому я и дописал в конце: "И поуправляй памятью для всего этого дела".
Для связки C++/QML о памяти не нужно думать в 99%.
A>Так-то, в скрипт (JS) вынесено всё самое императивное из связки HTML/CSS/JS. Декларативное оставлено в HTML, CSS и в языке селекторов. Сборщик мусора + намного более приятный синтаксис — вот чем, в первую очередь, зачётны скрипты в UI.
Так это ровно также в QML: если нужно что-то императивное, то есть JS/Python/C++.
A>Не знаю, кому там что приятно, но сравнивать с титаническим HTML какие-то местечковые технологии... всякие QML, XAML... Я подписан на несколько дайджестов, где постоянно выкладывают фокусы, связанные с UI, сделанные на HTML. Конкурсы проводятся, жизнь бурлит. А покажи хоть один дайджест для QML-девелоперов. Или конкурс
Сядь в современный автомобиль: с выской вероятностью интерфейс написан на C++/QML.
