Объясните, пожалуйста, как формальная верификация (ФВ) сочетается с проблемой остановки. Если в общем случае нельзя даже доказать, что программа не зависнет, то как ФВ вообще работает? Все наши программы принадлежат к какому-то отдельном узкому классу, или что? Спасибо.
Это очень широкий вопрос, тогда как StackOverflow отдает предпочтение более конкретным. Собственно, ответом на него может быть работа уровня диссертации.
В ответ на любой вопрос можно написать диссертацию, если есть писательский зуд и исследовательская жилка. Равно как и короткий ответ. Для примера предлагаю взять другие оптимизации: оптимизации HTTP, которые были актуальны лет 15 назад. Сколько я видел диссертаций, статей и т.п. на эту тему. А суть-то ведь простая. Там в основе один главный принцип — уменьшаем число соединений — и несколько приёмов (например, спрайты). Это очень конкретный вопрос, и мне не нужны подводки, графики и история исследований Хрома, начинающаяся со слова «Смеркалось».
Очень бы хотелось посмотреть на конкретную формулировку. Она может быть между "решите задачу за меня" до "как получить dom объект для вкладки хрома, зная pid этой вкладки".
Как два разработчика, мы оба, надеюсь, понимаем, что «получить dom объект для вкладки хрома, зная pid этой вкладки» это как раз одно из решений (потому, что pid легко получить из чего угодно, в том числе енумерированием, легко построить дерево для корневого процесса и дочерних, в соответствии с тем как устроен CEF3 и другие многопоточные Хромиумы). Меня это решение, разумеется, устроит и раз оно пришло вам в голову — значит с вопросом всё в порядке. Другое дело, что это решение к жизни, как мне кажется, вряд ли имеет отношение. Там же пулы и прочая такая техника. Вряд ли надо исходить из соответствия pid — :root. Если задача вообще имеет универсальное решение (в чём я не уверен), то оно, как мне кажется, скорее где-нибудь на уровне «послали message под виндой» или «подсунули свою dll». Я НЕ ЗНАЮ (поэтому я и спросил). А когда я не знаю, я стараюсь не строить вопрос, исходя из неверных допущений. А вообще, дёрнул меня чёрт написать, что хочу исходники Стима посмотреть.
Во-первых. Мой вопрос закрыли не как дубликат этих двух, а как ненастоящий вопрос. Удивительно бесячая формулировка*, не находите? Особенно, когда вопрос для тебя самый настоящий.
Во-вторых, только во втором приводятся альтернативы (буст, что ещё хуже, и MS specific расширения, которые, кстати, выглядят хорошим решением… если только не нужна кросс-платформенность, хе-хе, из-за которой такие вопросы обычно и возникают). Но я понимаю, что пространство ответов ограничено реальностью, а не чьими-то желаниями. В любом случае, ответ «Я пытался и ничего лучше дурацкого инклюда не нашёл» меня бы устроил. А ещё больше меня бы устроило объяснение, почему до сих пор всё так печально. Потому что для меня это выглядит как невероятное упущение для начала двадцатых. Вот я думаю, в этом и секрет. Ведь такой ответ подразумевает критику языка и признание недостатков, а у кого-то, видать, сильно пригорело. Я на другом форуме потом спрашивал и там мне тоже ответили с плохо скрываемым раздражением: не нравится наш славный язык — не пользуйся. Но хоть сказали, что да, вариантов нет, придётся таскаться с этим инклудом.
UPD. *) Я перечитал бесячую формулировку. Она, как оказалось, ещё более бесячая. То ли они её потом поменяли, то ли это я такой невнимательный: This question is not reproducible or was caused by typos. By typos!!!1111одинодин Всё равно, что в лицо плюнуть. А ведь это наверняка стандартная формулировка из заданного списка. Toxicity is in their DNA. (А если кто-то скажет, что имела место первая часть, question is not reproducible, я сначала спрошу, как question вообще может быть reproducible, а потом добавлю, что это как раз и есть признак того, что SO это фастфуд и годится только для вопросов «как на языке Х сабстринг делать»).
Вам реально не нужно писать на SO, если хотите спросить, как на языке Х сабстринг делать. Приходите, когда что-то нетривиальное будет.
Какие есть принципы оптимизации CSS по перформансу? Известно же, что два декларативных SQL-запроса, дающих один результат, могут выполняться с чудовищной разницей во времени исполнения. Но про правила для SQL я знаю, где почитать, а про правила для декларативного CSS? Ненастоящий вопрос, закрыто.
Для IE когда-то был разработан инструментарий, который енумерировал все окна в системе, находил экземпляры браузера, подключался к ним и строил DOM. Есть ли такое для Хромиума? Как подключиться к его окну в готовой сборке для просмотра DOM, если автор при сборке не вывел DevTools наружу? Ненастоящий вопрос, закрыто, иди отсюда, грязный хакер.
Правильно ли я понимаю, что в плюсы так и не подвезли типы заданной битности? Есть ли альтернатива использованию int32_t с подключенным #include <cstdint> (меня удивляет зависимость для такой простой потребности)? Ненастоящий вопрос, закрыто.
Если у вас что-то нетривиальнее «как на языке Х сабстринг делать», SO просто не для вас. Он медленно деградировал с самого момента появления, когда там были интересные люди, а теперь, видимо, просто пересёк линию дна. Причём тут вообще какой-то ИИ?
Metotron0, --force-device-scale-factor, значит? Благодарю за ответ. Но меня смущает вот это =2. Я так понимаю, для 8K должно быть =4, а для FullHD должно быть =1. Пойду читать документацию, может это можно прописать без пачки условий.
RifleR, благодарю за ответ, о какой "функции изменения масштаба в браузере" идёт речь? О той, что выше, или transform, или ещё что-то?
Кстати, даже на 4К телевизорах интерфейс приложения будет FullHD — только само видео запускается в 4К.
Пользуясь случаем, хочу спросить. Как с этим в десктопных браузерах? Иными словами, можно ли прописыванием какого-то режима заставить Chrome на мониторах 4K/8K при масштабе dpi 100% в Windows отображать страницу полностью аналогично выводу на FullHD-монитор?
Крайне редко тут что-то пишу, но в данном случае не смог устоять.
2000-й или 2001-й год. Весёлое время WinAPI/ATL/MFC. А также Ultimate Toolbox, BCG, CodeJock и прочих улучшайзеров. Я ещё толком не знаю C++, но изучаю его по хардкору, на примерах из Direct3D (конечно же IM, а не RM) и пишу свой 3D Studio MAX, с блэкджеком, проекционным полиэкраном, импортом 3DS, окном свойств, редактором объектов и мегафичей — ТУМАНОМ.
Приложение написано за месяц, да вот беда — оно запускается слишком быстро, и сплэш-скрин с маскотом (низкополигональным ГНОМОМ), которого нарисовал коллега, не удаётся рассмотреть. А ещё на сплэш-скрине внизу есть компонент progress bar'а, который одна из библиотек (уже не помню, Ultimate Toolbox, кажется) слямзила из новинки тех времён, браузера Netscape Navigator. (Для самых маленьких радиослушателей: по горизонтальной полоске влево-вправо ездил серый градиент, точнее, его пик насыщенности). И его тоже не удаётся рассмотреть, что обидно вдвойне.
Тогда я добавляю в Init() кучу Sleep()'ов, но вдруг вижу, что градиент перестаёт ездить, а картинка при щелчке становится белой. Еду в библиотеку, зарываюсь в книжки, и узнаю, что есть, оказывается, такая штука — МНОГОПОТОЧНОСТЬ. И если сделать Sleep() в главном потоке UI, то градиент (как и картинка) перестаёт перерисовываться.
Архитектура срочно меняется на многопоточную. Заодно в свете новых знаний движок переписывается с нуля. И вот, наконец, сплэш-скрин висит секунд десять, всё тормозит, как в лучших домах Лондона и Парижа, сразу видно — СЕРЬЁЗНЫЙ ПРОДУКТ. Но чего-то не хватает. Чего? А вот чего: экран висит, градиент ползает, а индикатор жёсткого диска не моргает! Липа, короче. Фейк.
Штош, начинаю создавать в отдельном потоке кучу файлов и писать в них rnd(). Заодно узнаю, как правильно работать с папкой tmp, с каталогами юзерского профиля, что нельзя писать в Program Files и т.д. Опять переписываю движок.
Наконец, всё готово. Экран не только тормозит, но и отчаянно трещит жёстким диском. Ну прямо Microsoft Word и Adobe Photoshop. С этим приложением я иду в одну контору, показываю его на собеседосе, и меня берут, несмотря на малый возраст, писать софт для трёхмерной визуализации месторождений. Хэппи енд.
Её будет будет определять суд. Это и называется «судебная власть». Понятие, мало знакомое россиянам. Нет ничего страшного в том, чтобы избранный народом человек, которому доверяют, решал бы в каждом отдельном случае, пытался ты выдать игрушку за настоящее оружие или нет. Поскольку россияне по опыту знают, что суд не работает, они интуитивно начинают усложнять правила, расписывая количество заклёпок и оттенок RGB, начиная с которого подделка считается подделкой. Помогает это не очень.
Далее, назначать экспертизу на каждый чих это тоже российская фишка. В тех делах, в которых судья кровно не заинтересован, он просто тупо передаёт власть, доверенную ему для правосудия, каким-то левым людям, которые по хвосту кошки выводят педофилию. Как мне рассказывали, американский судья не будет звать эксперта, чтобы тот ответил за него, похож предмет на игрушку или муляж. Он сам будет судить, и всю ответственность возьмёт на себя.
Я думаю, что если бы большая часть приложений переехала на сервер, Chrome'у бы недолго осталось жить, как рендереру HTML. HTML на сервере рендерили бы чем-нибудь более вменяемым, что не тащило бы за собой такой чудовищный оверхед.
как же он на сервере всё это добро будет генерить? Увы, сложность не уменьшится, а переместится.
«Добро» генерирует не сервер, а разработчик. И он может захотеть просто не генерировать его. Как? А отдать, например, контекст/канвас в стороннюю библиотеку. Может быть, обернув его в wrapper. Всё это прекрасно работает, я могу хоть сейчас запустить по RDP что угодно, хоть WordStar через DOSBox. Потому, что RDC не задаёт глупых вопросов и не требует генерировать гипермедиа.
Что касается уменьшения сложности. В исходной статье речь шла о дублировании на клиенте и сервере. Это и есть та сложность (два набора данных вместо одного), которую уменьшают. Я предложил другой способ избавиться от дублирования и, следовательно, уменьшить сложность.
настоящая революция … обратная совместимость не позволит это сделать.
Обратная совместимость не позволит на сервере запускать сборку CEF, рендерить картинку и отправлять её клиенту? В том и прикол, что сделать это проще простого. Можно даже для начала только этим и ограничиться. Венчурные инвесторы, ау!
Если говорить о концептуальной разнице, она в следующем. В моём подходе разраб абстрагируется от любых гипермедий. Если в какой-то момент мы начинаем гонять примитивы вместо пикселей, или даже эти самые гипермедии (бывают, наверно, ситуации, когда мы таким образом существенно понизим трафик, незначительно повысив нагрузку на клиент, а если сделать гипермедии weak, то и разрыв не страшен), для разраба они будут деталями реализации низкоуровневого протокола, знать который он не обязан.
Есть ведь много подходов к построению GUI. Помимо DOM'овой (а гипермедиа на DOM-элементах означает неявное требование делать всё через DOM) есть ещё OnPaint()/Invalidate(), есть fps'ная (т.е. for (;;) Render();). Почему низкоуровневый протокол должен диктовать подход к созданию UI?
Т.е. по мнению автора, htmx здорово всё упросит. Хотя бы по причине ненадобности JS.
Развивая вышенаписанную мысль. Вот сейчас в некоторых браузерах добавляют такую фичу: переопределение у DOM-элемента отрисовки. Т.е. когда нам надо сделать групповое выделение объектов синей рамочкой, как в Windows Explorer, можно написать что-то типа такого (псевдокод):
Во-первых, это оптимизация, потому, что совершенно незачем создавать пачку элементов, с узлами в DOM, с применением правил CSS, и т.д. и т.п., когда надо, по сути, всего лишь добавить несколько графических команд в конвейер. Если активно использовать этот приём, в сумме оптимизация станет в разы. Особенно по памяти.
Во-вторых, это просто выразительно. Мы ведь не думаем о рамке как об объекте со временем жизни и свойствами. Зачем же писать в таких терминах?
Вот и пример того, что через этот HTMX не сделать (если я ничего не упускаю).
Собственно, выше я написал, что продуктивно было бы рассматривать HTML/CSS/JS как чисто GUI-шные языки (и использовать только там, где надо). Делать на элементах HTML транспорт (гипермедиа) — так себе идея.
Ближайший аналог — софт "удаленного рабочего стола", где многое из этого уже реализовано.
Когда я писал комментарий, я и держал в голове весьма позитивный опыт, полученный при многолетнем доступе через RDP к компьютеру, в т.ч. с очень слабых устройств (256 метров памяти, 1 ГГц процессора) и очень слабом интернете (3G ещё, а может и EDGE, не помню уже). Всё там прекрасно работает, но это доступ к ОС, а платформы, которая давала бы писать и разворачивать отдельные приложения, всё нет.
Возьмём только одно отличие. DOM для всей этой гипермудии строить надо? Какой там у него оверхед? Это во времена OLE_VARIANT и юнионов оверхед на переменную был 26 байт минус sizeof() от нативного размера. А сейчас, во времена DOM'ов — сам понимаешь. Возьми реальный документ, как мохнатые юзеры любят — упихать стопицот строк безо всякой нормализации в одну таблицу. Возьми недорогой мобильный аппарат, который конторе своим работникам купить не жалко. И засекай время, через сколько минут с таким подходом браузер у тебя просто молча закроется под пальцами.
Однако, я ещё на очень старых девайсах, с 256 мегабайт, ещё под WM со стилусом, гонял через RDP гигантские проекты в студии, в метро, в условиях крайне нестабильной связи! И проблем не знал!
Конечно, RDP это не для массы юзеров. Там надо админить машину. Доступ будет ко всей ОС. Разграничение прав между юзерами надо вводить. В общем, не хватает какой-то платформы, которая бы решала это всё, давая то же самое удобство, что и раньше, а не этот ваш HTMX.
P.S. И при рендеринге на сервере HTML (а не X) вполне бы пригодился, т.к. HTML (со всеми добавками в виде CSS и JS) это отличный набор языков для GUI, неважно, кто, где и как его рендерит.
Глядя на эту очередную странную идею о том, как избавиться от необходимости синхронизировать фронт/бэк, я в который раз думаю: когда уже приложения будут целиком и полностью исполняться на сервере, а клиенту тупо стримить картинку. Зачем эти полумеры, какие-то «гипермедиа»? Сделать так — и синхронизировать станет нечего, безопасность станет максимальной, а нагрузка на клиент — O(1). Серверные инстансы приложений можно пускать по модели десктопных ОС, которая давно отлажена и заоптимизирована — шарится всё, что только можно без ущерба для безопасности. И никаких больше стресс-тестов на разрыв соединения — он ведь ничего не может испортить!
Возможно. Но пока что всё, что я делал в FF 115, я продолжаю делать в FF 116. В частности, опубликовал этот текст и пишу этот комментарий.
Объясните, пожалуйста, как формальная верификация (ФВ) сочетается с проблемой остановки. Если в общем случае нельзя даже доказать, что программа не зависнет, то как ФВ вообще работает? Все наши программы принадлежат к какому-то отдельном узкому классу, или что? Спасибо.
В ответ на любой вопрос можно написать диссертацию, если есть писательский зуд и исследовательская жилка. Равно как и короткий ответ. Для примера предлагаю взять другие оптимизации: оптимизации HTTP, которые были актуальны лет 15 назад. Сколько я видел диссертаций, статей и т.п. на эту тему. А суть-то ведь простая. Там в основе один главный принцип — уменьшаем число соединений — и несколько приёмов (например, спрайты). Это очень конкретный вопрос, и мне не нужны подводки, графики и история исследований Хрома, начинающаяся со слова «Смеркалось».
Как два разработчика, мы оба, надеюсь, понимаем, что «получить dom объект для вкладки хрома, зная pid этой вкладки» это как раз одно из решений (потому, что pid легко получить из чего угодно, в том числе енумерированием, легко построить дерево для корневого процесса и дочерних, в соответствии с тем как устроен CEF3 и другие многопоточные Хромиумы). Меня это решение, разумеется, устроит и раз оно пришло вам в голову — значит с вопросом всё в порядке. Другое дело, что это решение к жизни, как мне кажется, вряд ли имеет отношение. Там же пулы и прочая такая техника. Вряд ли надо исходить из соответствия pid — :root. Если задача вообще имеет универсальное решение (в чём я не уверен), то оно, как мне кажется, скорее где-нибудь на уровне «послали message под виндой» или «подсунули свою dll». Я НЕ ЗНАЮ (поэтому я и спросил). А когда я не знаю, я стараюсь не строить вопрос, исходя из неверных допущений. А вообще, дёрнул меня чёрт написать, что хочу исходники Стима посмотреть.
Во-первых. Мой вопрос закрыли не как дубликат этих двух, а как ненастоящий вопрос. Удивительно бесячая формулировка*, не находите? Особенно, когда вопрос для тебя самый настоящий.
Во-вторых, только во втором приводятся альтернативы (буст, что ещё хуже, и MS specific расширения, которые, кстати, выглядят хорошим решением… если только не нужна кросс-платформенность, хе-хе, из-за которой такие вопросы обычно и возникают). Но я понимаю, что пространство ответов ограничено реальностью, а не чьими-то желаниями. В любом случае, ответ «Я пытался и ничего лучше дурацкого инклюда не нашёл» меня бы устроил. А ещё больше меня бы устроило объяснение, почему до сих пор всё так печально. Потому что для меня это выглядит как невероятное упущение для начала двадцатых. Вот я думаю, в этом и секрет. Ведь такой ответ подразумевает критику языка и признание недостатков, а у кого-то, видать, сильно пригорело. Я на другом форуме потом спрашивал и там мне тоже ответили с плохо скрываемым раздражением: не нравится наш славный язык — не пользуйся. Но хоть сказали, что да, вариантов нет, придётся таскаться с этим инклудом.
UPD. *) Я перечитал бесячую формулировку. Она, как оказалось, ещё более бесячая. То ли они её потом поменяли, то ли это я такой невнимательный: This question is not reproducible or was caused by typos. By typos!!!1111одинодин Всё равно, что в лицо плюнуть. А ведь это наверняка стандартная формулировка из заданного списка. Toxicity is in their DNA. (А если кто-то скажет, что имела место первая часть, question is not reproducible, я сначала спрошу, как question вообще может быть reproducible, а потом добавлю, что это как раз и есть признак того, что SO это фастфуд и годится только для вопросов «как на языке Х сабстринг делать»).
Какие есть принципы оптимизации CSS по перформансу? Известно же, что два декларативных SQL-запроса, дающих один результат, могут выполняться с чудовищной разницей во времени исполнения. Но про правила для SQL я знаю, где почитать, а про правила для декларативного CSS? Ненастоящий вопрос, закрыто.
Для IE когда-то был разработан инструментарий, который енумерировал все окна в системе, находил экземпляры браузера, подключался к ним и строил DOM. Есть ли такое для Хромиума? Как подключиться к его окну в готовой сборке для просмотра DOM, если автор при сборке не вывел DevTools наружу? Ненастоящий вопрос, закрыто, иди отсюда, грязный хакер.
Правильно ли я понимаю, что в плюсы так и не подвезли типы заданной битности? Есть ли альтернатива использованию int32_t с подключенным #include <cstdint> (меня удивляет зависимость для такой простой потребности)? Ненастоящий вопрос, закрыто.
Если у вас что-то нетривиальнее «как на языке Х сабстринг делать», SO просто не для вас. Он медленно деградировал с самого момента появления, когда там были интересные люди, а теперь, видимо, просто пересёк линию дна. Причём тут вообще какой-то ИИ?
Надеюсь, вы многому научились.
Как же тогда будет нервировать то, что 95% всех звёзд Вселенной уже зажглись, и газа осталось на 5%.
Metotron0,
--force-device-scale-factor, значит? Благодарю за ответ. Но меня смущает вот это=2. Я так понимаю, для 8K должно быть=4, а для FullHD должно быть=1. Пойду читать документацию, может это можно прописать без пачки условий.RifleR, благодарю за ответ, о какой "функции изменения масштаба в браузере" идёт речь? О той, что выше, или
transform, или ещё что-то?Пользуясь случаем, хочу спросить. Как с этим в десктопных браузерах? Иными словами, можно ли прописыванием какого-то режима заставить Chrome на мониторах 4K/8K при масштабе dpi 100% в Windows отображать страницу полностью аналогично выводу на FullHD-монитор?
Крайне редко тут что-то пишу, но в данном случае не смог устоять.
2000-й или 2001-й год. Весёлое время WinAPI/ATL/MFC. А также Ultimate Toolbox, BCG, CodeJock и прочих улучшайзеров. Я ещё толком не знаю C++, но изучаю его по хардкору, на примерах из Direct3D (конечно же IM, а не RM) и пишу свой 3D Studio MAX, с блэкджеком, проекционным полиэкраном, импортом 3DS, окном свойств, редактором объектов и мегафичей — ТУМАНОМ.
Приложение написано за месяц, да вот беда — оно запускается слишком быстро, и сплэш-скрин с маскотом (низкополигональным ГНОМОМ), которого нарисовал коллега, не удаётся рассмотреть. А ещё на сплэш-скрине внизу есть компонент progress bar'а, который одна из библиотек (уже не помню, Ultimate Toolbox, кажется) слямзила из новинки тех времён, браузера Netscape Navigator. (Для самых маленьких радиослушателей: по горизонтальной полоске влево-вправо ездил серый градиент, точнее, его пик насыщенности). И его тоже не удаётся рассмотреть, что обидно вдвойне.
Тогда я добавляю в Init() кучу Sleep()'ов, но вдруг вижу, что градиент перестаёт ездить, а картинка при щелчке становится белой. Еду в библиотеку, зарываюсь в книжки, и узнаю, что есть, оказывается, такая штука — МНОГОПОТОЧНОСТЬ. И если сделать Sleep() в главном потоке UI, то градиент (как и картинка) перестаёт перерисовываться.
Архитектура срочно меняется на многопоточную. Заодно в свете новых знаний движок переписывается с нуля. И вот, наконец, сплэш-скрин висит секунд десять, всё тормозит, как в лучших домах Лондона и Парижа, сразу видно — СЕРЬЁЗНЫЙ ПРОДУКТ. Но чего-то не хватает. Чего? А вот чего: экран висит, градиент ползает, а индикатор жёсткого диска не моргает! Липа, короче. Фейк.
Штош, начинаю создавать в отдельном потоке кучу файлов и писать в них rnd(). Заодно узнаю, как правильно работать с папкой tmp, с каталогами юзерского профиля, что нельзя писать в Program Files и т.д. Опять переписываю движок.
Наконец, всё готово. Экран не только тормозит, но и отчаянно трещит жёстким диском. Ну прямо Microsoft Word и Adobe Photoshop. С этим приложением я иду в одну контору, показываю его на собеседосе, и меня берут, несмотря на малый возраст, писать софт для трёхмерной визуализации месторождений. Хэппи енд.
Я извиняюсь за оффтоп, а RSDN работает? Третий день выдаёт мне 404, а на почту приходят ответы, как-то, значит, на него заходят. Через Home?
Её будет будет определять суд. Это и называется «судебная власть». Понятие, мало знакомое россиянам. Нет ничего страшного в том, чтобы избранный народом человек, которому доверяют, решал бы в каждом отдельном случае, пытался ты выдать игрушку за настоящее оружие или нет. Поскольку россияне по опыту знают, что суд не работает, они интуитивно начинают усложнять правила, расписывая количество заклёпок и оттенок RGB, начиная с которого подделка считается подделкой. Помогает это не очень.
Далее, назначать экспертизу на каждый чих это тоже российская фишка. В тех делах, в которых судья кровно не заинтересован, он просто тупо передаёт власть, доверенную ему для правосудия, каким-то левым людям, которые по хвосту кошки выводят педофилию. Как мне рассказывали, американский судья не будет звать эксперта, чтобы тот ответил за него, похож предмет на игрушку или муляж. Он сам будет судить, и всю ответственность возьмёт на себя.
Я думаю, что если бы большая часть приложений переехала на сервер, Chrome'у бы недолго осталось жить, как рендереру HTML. HTML на сервере рендерили бы чем-нибудь более вменяемым, что не тащило бы за собой такой чудовищный оверхед.
«Добро» генерирует не сервер, а разработчик. И он может захотеть просто не генерировать его. Как? А отдать, например, контекст/канвас в стороннюю библиотеку. Может быть, обернув его в wrapper. Всё это прекрасно работает, я могу хоть сейчас запустить по RDP что угодно, хоть WordStar через DOSBox. Потому, что RDC не задаёт глупых вопросов и не требует генерировать гипермедиа.
Что касается уменьшения сложности. В исходной статье речь шла о дублировании на клиенте и сервере. Это и есть та сложность (два набора данных вместо одного), которую уменьшают. Я предложил другой способ избавиться от дублирования и, следовательно, уменьшить сложность.
Обратная совместимость не позволит на сервере запускать сборку CEF, рендерить картинку и отправлять её клиенту? В том и прикол, что сделать это проще простого. Можно даже для начала только этим и ограничиться. Венчурные инвесторы, ау!
Я правильно посчитал, что плотность Бетельгейзе 1.42*18/(764^3) == 5.73E-8 г/см^3? Там как вообще реакции идут?
Если говорить о концептуальной разнице, она в следующем. В моём подходе разраб абстрагируется от любых гипермедий. Если в какой-то момент мы начинаем гонять примитивы вместо пикселей, или даже эти самые гипермедии (бывают, наверно, ситуации, когда мы таким образом существенно понизим трафик, незначительно повысив нагрузку на клиент, а если сделать гипермедии weak, то и разрыв не страшен), для разраба они будут деталями реализации низкоуровневого протокола, знать который он не обязан.
Есть ведь много подходов к построению GUI. Помимо DOM'овой (а гипермедиа на DOM-элементах означает неявное требование делать всё через DOM) есть ещё OnPaint()/Invalidate(), есть fps'ная (т.е. for (;;) Render();). Почему низкоуровневый протокол должен диктовать подход к созданию UI?
Развивая вышенаписанную мысль. Вот сейчас в некоторых браузерах добавляют такую фичу: переопределение у DOM-элемента отрисовки. Т.е. когда нам надо сделать групповое выделение объектов синей рамочкой, как в Windows Explorer, можно написать что-то типа такого (псевдокод):
Во-первых, это оптимизация, потому, что совершенно незачем создавать пачку элементов, с узлами в DOM, с применением правил CSS, и т.д. и т.п., когда надо, по сути, всего лишь добавить несколько графических команд в конвейер. Если активно использовать этот приём, в сумме оптимизация станет в разы. Особенно по памяти.
Во-вторых, это просто выразительно. Мы ведь не думаем о рамке как об объекте со временем жизни и свойствами. Зачем же писать в таких терминах?
Вот и пример того, что через этот HTMX не сделать (если я ничего не упускаю).
Собственно, выше я написал, что продуктивно было бы рассматривать HTML/CSS/JS как чисто GUI-шные языки (и использовать только там, где надо). Делать на элементах HTML транспорт (гипермедиа) — так себе идея.
Когда я писал комментарий, я и держал в голове весьма позитивный опыт, полученный при многолетнем доступе через RDP к компьютеру, в т.ч. с очень слабых устройств (256 метров памяти, 1 ГГц процессора) и очень слабом интернете (3G ещё, а может и EDGE, не помню уже). Всё там прекрасно работает, но это доступ к ОС, а платформы, которая давала бы писать и разворачивать отдельные приложения, всё нет.
Я десять лет назад работал через RDP в метро с такого вот девайса: https://www.gsmarena.com/lg_fathom_vs750-3356.php и никаких проблем не было.
Неправильное ощущение.
Возьмём только одно отличие. DOM для всей этой гипермудии строить надо? Какой там у него оверхед? Это во времена OLE_VARIANT и юнионов оверхед на переменную был 26 байт минус sizeof() от нативного размера. А сейчас, во времена DOM'ов — сам понимаешь. Возьми реальный документ, как мохнатые юзеры любят — упихать стопицот строк безо всякой нормализации в одну таблицу. Возьми недорогой мобильный аппарат, который конторе своим работникам купить не жалко. И засекай время, через сколько минут с таким подходом браузер у тебя просто молча закроется под пальцами.
Однако, я ещё на очень старых девайсах, с 256 мегабайт, ещё под WM со стилусом, гонял через RDP гигантские проекты в студии, в метро, в условиях крайне нестабильной связи! И проблем не знал!
Конечно, RDP это не для массы юзеров. Там надо админить машину. Доступ будет ко всей ОС. Разграничение прав между юзерами надо вводить. В общем, не хватает какой-то платформы, которая бы решала это всё, давая то же самое удобство, что и раньше, а не этот ваш HTMX.
P.S. И при рендеринге на сервере HTML (а не X) вполне бы пригодился, т.к. HTML (со всеми добавками в виде CSS и JS) это отличный набор языков для GUI, неважно, кто, где и как его рендерит.
Спасибо за ссылку.
А как он в работе?
Глядя на эту очередную странную идею о том, как избавиться от необходимости синхронизировать фронт/бэк, я в который раз думаю: когда уже приложения будут целиком и полностью исполняться на сервере, а клиенту тупо стримить картинку. Зачем эти полумеры, какие-то «гипермедиа»? Сделать так — и синхронизировать станет нечего, безопасность станет максимальной, а нагрузка на клиент — O(1). Серверные инстансы приложений можно пускать по модели десктопных ОС, которая давно отлажена и заоптимизирована — шарится всё, что только можно без ущерба для безопасности. И никаких больше стресс-тестов на разрыв соединения — он ведь ничего не может испортить!