Здравствуйте, Константин Б., Вы писали:
КБ>Ну так а где все эти крутые Сишники с приложениями на 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
и солнце б утром не вставало, когда бы не было меня
У MS не получилось в моб. оси — по этому претендовать что-либо они не могут, будут в хвосте. Производители моб. осей будут ставить палки в колеса — возможности есть. Т.е. делать так, чтобы их решение работало медленно.
Здравствуйте, karbofos42, Вы писали:
K>Вместо того, чтобы пользоваться преимуществами десктопа, тащат на него скриптовые языки типа JS
Самое смешное, что идиоты пытаются весь десктопный софт загнать в браузер, в то время как на мобилах тенденция прямо противоположная — каждый говносайт хочет иметь свое собственное приложение вместо браузерной версии.
Здравствуйте, karbofos42, Вы писали:
K>Зачем нам GUI компилировать, мы будем в рантайме парсить HTML, дабы сформировать его DOM, чтобы и память сожрать и процессор не бездельничал. K>Современное железо конечно всё это перемелет
Да уже и топовое современное железо с трудом справляется со всем этим сраным цирком.
Здравствуйте, 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.
Все эти ваши модные веб-технологии — суперпрожорливое говно.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Alekzander, Вы писали:
A>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Я прогонял. Много, часто, упорно и долго этим занимался. У меня в профайлере были разные приложения, в т.ч. с кастомным layout'ом и местами с кастомной отрисовкой. В т.ч. я сам и выделял регионы, и рисовал через GDI, и битмапы через BitBlt гонял. Так что я тебе точно скажу что там тормозит: в половине случаев там тормозит обсчёт layut'а, в трети случаев кастомная отрисовка, а ещё в четверти стандартные контролы слишкмо часто рисуются.
И я тебе точно скажу, что компиляция имеет смысл. Более того, имеет смысл включение оптимизации при компиляции: тормоза в дебажной сборке — не страшно, а в релизной тормозить уже не должно.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Alekzander, Вы писали:
A>>...Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
Ф>rich UI приложения вполне себе делась 15 лет назад на Delphi. Это строго типизированный язык, без динамиков и с ручным упралением памятью (полностью ручным — в C++ есть Spart-pointer's а в делфе нет). Притом это (то, что я видел) крутилось тогда на P4 — очень быстро работало.
Размер экрана. + фиксированный размер окошек. Отсюда и скорость.
глубина цветов. опять же.
Здравствуйте, karbofos42, Вы писали:
K>Будешь убеждать, что создавать многопроцессное приложение с полноценным браузером, IPC и прочими плюшками — это производительнее и лучше, чем внедрить рендер в свой основной процесс, тащить с собой меньше библиотек и не загоняться с IPC?
Да. Во первых потому что написанная программа всегда лучше не написанной.
А во вторых "многопроцессное приложение с полноценным браузером, IPC и прочими плюшками" хоть и звучит страшно, но от разработчика не требует никаких затрат времени и усилий.
"тащить с собой меньше библиотек и не загоняться с IPC" — это просто какая-то сишная профдеформация.
Там и библиотеку добавить — приключение на неделю. И IPC — боль и страдания.
В нормальных языках добавлять библиотеки и работать с IPC — просто и приятно.
Здравствуйте, Константин Б., Вы писали:
КБ>Да. Во первых потому что написанная программа всегда лучше не написанной. КБ>А во вторых "многопроцессное приложение с полноценным браузером, IPC и прочими плюшками" хоть и звучит страшно, но от разработчика не требует никаких затрат времени и усилий.
Так я как отдельно взятый разработчик вполне допускаю, что могу в каком-нибудь проекте использовать данный подход.
Понятно, что оно работает и можно реализовать ПО за разумные сроки.
Почему корпорации и сообщество подхватывают эту движуху и такие инструменты до продакшена дошли — это мне не понятно.
Технически нет проблем реализовать всё нативно. Просто нужно было разработать немного другие фреймворки, их было бы удобнее использовать и работало бы быстрее.
Я бы понял, если бы этот подход сильно упрощал жизнь, но по факту там проблема на проблеме.
Вот уже и WASM приходится затаскивать в веб, т.к. JS не вывозит и фронтенд фреймворки делают и переделывают постоянно, чтобы оно работало быстро у пользователей (серверный пре-рендеринг всякий и т.п.).
Здравствуйте, Философ, Вы писали:
A>>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Ф>Я прогонял. Много, часто, упорно и долго этим занимался. У меня в профайлере были разные приложения, в т.ч. с кастомным layout'ом и местами с кастомной отрисовкой. В т.ч. я сам и выделял регионы, и рисовал через GDI, и битмапы через BitBlt гонял. Так что я тебе точно скажу что там тормозит: в половине случаев там тормозит обсчёт layut'а, в трети случаев кастомная отрисовка, а ещё в четверти стандартные контролы слишкмо часто рисуются. Ф>И я тебе точно скажу, что компиляция имеет смысл. Более того, имеет смысл включение оптимизации при компиляции: тормоза в дебажной сборке — не страшно, а в релизной тормозить уже не должно.
Это две разные компиляции. Вот что он написал:
>мы будем в рантайме парсить HTML
Можно скомпилировать HTML, чтобы парсить в рантайме не приходилось. Чтобы вместо этого была тупо десериализация DOM. А ты говоришь, судя по "имеет смысл включение оптимизации при компиляции", о том, чтобы вообще выкинуть декларативное описание и заменить его 100% императивным кодом. Ты на этом, конечно, сможешь что-то выиграть, но только ценой снижения скорости разработки, причём очень высокой ценой (если разрабатывать что-то более-менее сложное). Это как отказаться от SQL и самому писать в файлы ДЛЯ ОПТИМИЗАЦИИ — где-то прокатит, но чтобы такие размены обсуждать, надо сначала пописать декларативные гуи, чтобы было с чем сравнивать.
Здравствуйте, Философ, Вы писали:
Ф>Я надеюсь, ты не осмелишся утверждать, что в CAD-системах слабенький IU, что он не Rich.
Очень удобно, что ты это выделил болдом. Сразу видно, что ты не понимаешь, что такое rich UI. CAD-система, Блокнот, почтовый клиент — все они могут обладать как rich UI (приятными излишествами), так и дельфийским говном спартанским интерфейсом. Я тут курсы дизайна для пенсионеров не веду и разжёвывать не буду. Скажу только, что со временем понятие приятных излишеств меняется. Когда-то всё, кроме командной строки, считалось приятными излишествами. А сейчас это, например, сложный градиент фона рабочего пространства (workspace) документов. Попишешь такие штуки императивно, быстро поймёшь, в чём фишка CSS. Но ты не будешь, потому, что застрял в прошлом. Будете с Карбофосом рассказывать, что это никому не надо. Мне норм, конкуренции меньше.
Здравствуйте, 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. Теперь добавь к нему скрипты, чтобы поле могло ходить за подсказками на сервер в две строчки (а не двести). И что получится? Ой, как ни крути, а всё пулемёт собирается!
Здравствуйте, 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.
В управляемых языках есть удобства в плане рефлексии и динамической компиляции тех же деревьев выражений итд
и солнце б утром не вставало, когда бы не было меня
