Здравствуйте, Alekzander, Вы писали:

A>Ты явно не в курсе, что в идеале, к которому стремятся все интерфейсники, UI'ная часть проекта **вообще не содержит скриптов**.
Все гуи что я когда либо делал именно такие.
Ты кстати что именно под скриптами тут понимаешь?

Здравствуйте, rFLY, Вы писали:

FLY>Здравствуйте, CreatorCray, Вы писали:
>>И floating тоже?
FLY>Да.
Это не то. Это просто ещё одно окошко.
Нету времени сейчас скрины делать, если не забуду то позже покажу что я имею в виду.

Здравствуйте, Shmj, Вы писали:

S>Но люди уже используют его как десктоп.
Тем не менее это не десктоп.
Ну а использовать его можно ещё и как доску для разделки рыбы.

S>А Apple умеет уже прямо сегодня.
Тем не менее не собирается заниматься извратами и из планшета делать десктоп.

Здравствуйте, Pauel, Вы писали:

P> R>Мода не имеет никакого отношения ни к скорости, ни к стоимости разработки, не выдумывай. (в последнее время вообще создается впечатление, что зависимость тут обратнопропорциональная)

P> Мода это значит, что у вас есть вагон желающих тащить вашу телегу забесплатно. А нишевые кресты — это полтора мейнтейнера на полсотни пакетов.

Да плевать мне, что это значит. Если вас устраивают модники вместо инженеров, совет вам да любовь.

Здравствуйте, novitk, Вы писали:

n> Как vscode рендерит основное окно редактирования с подсветками синтаксиса и т.д. На canvas? И вообще сколько там всего на canvas vs стандартыe web control.

Обычный DOM. span, div, вот это все. Canvas не используется, насколько я могу судить. Открой в браузере https://vscode.dev/ открой какой-нибудь файл и инспектором из web developer tools посмотри на редактор кода.

Есть еще пример на wasm: https://makepad.dev/ там все рендерится через canvas, но для редактируемого текста создается элемент textarea с абсолютным позиционированием.

Разница в подходах: вкладка с vscode.dev скромно кушает 630Mb, вкладка с makepad — 55Mb.

Здравствуйте, Alekzander, Вы писали:

A> Жалуясь на electron based software, это ты должен был тут всё примерами усыпать, и не в одной области, в которой конторы, пишущие хорошие софт, вообще не работают (криптокошельки), а в разных. Ты это сделал? Нет.

Я стаью по ГОСТу я не должен был оформить? Нет?

Здравствуйте, rFLY, Вы писали:

FLY> R>Если бы на электроне писали только вскод я бы даже не возражал

FLY> У тебя очень странные обоснования. Т.е. если есть корявая прога на плюсах, то плюсы говно, потому что кто-то решил на них написать не вижалстудио.

Это не у меня обоснования странные, это у тебя странные фантазии

Здравствуйте, rudzuk, Вы писали:

R>О божечки... Еще один. Специально для вас, обоих двух: для десктопа пиши, как для десктопа, не веба.

Тезис то понятен. Обоснование только у него странное. "У меня подгорело от двух софтин на электроне — не пишите на электроне".

Здравствуйте, CreatorCray, Вы писали:

S>>А Apple умеет уже прямо сегодня.
CC>Тем не менее не собирается заниматься извратами и из планшета делать десктоп.

Вы мыслите не масштабно.

Когда MS сделает ARM планшет с полноценной ARM Windows — то и Apple подтянется. Почему люди должны себя ограничивать? Если процессор потеняет, размер экрана достаточен + сенсорный экран — то в чем проблема дать разрешение поставить продвинутый софт???

Здравствуйте, rudzuk, Вы писали:

R>Обычный DOM. span, div, вот это все. Canvas не используется, насколько я могу судить. Открой в браузере https://vscode.dev/ открой какой-нибудь файл и инспектором из web developer tools посмотри на редактор кода.
+1. Пипец. Каждая строчка — div с абсолютным позиционированием. Зачем оно так!? Там же все равно не сделать "загрузил и забыл" и DOM надо все время править руками по каждому чиху мышки. На canvas разве не проще и быстрее? Видимо начали на реакте, а теперь переписывать неподьемно.

А у Гугла в доках так же? У меня оно на работе заблокировано.

Здравствуйте, novitk, Вы писали:

N>+1. Пипец. Каждая строчка — div с абсолютным позиционированием. Зачем оно так!? Там же все равно не сделать "загрузил и забыл" и DOM надо все время править руками по каждому чиху мышки. На canvas разве не проще и быстрее? Видимо начали на реакте, а теперь переписывать неподьемно.
Так абсолютное позиционирование как раз не вызывает пересчет остальных элементов.
PS: На 1 пробел 32 символа — это мощно

Здравствуйте, rFLY, Вы писали:

FLY>Так абсолютное позиционирование как раз не вызывает пересчет остальных элементов.
Имеется ввиду, что надо DOM постоянно менять при скролинге, миганиях курсора, проходах мышкой и т.д.

Здравствуйте, novitk, Вы писали:

N>+1. Пипец. Каждая строчка — div с абсолютным позиционированием. Зачем оно так!? Там же все равно не сделать "загрузил и забыл" и DOM надо все время править руками по каждому чиху мышки. На canvas разве не проще и быстрее?

Не проще и точно не быстрее. На канвасе хорошо делать вещи изолированные.
Дом же дает кране гибкую композицию.

Выписывать рич уи канвасом — ой как трудно. Вам же все равно надо предусмотреть некий аналог для стилей, маржинов, паддингов итд, сделать это настраиваемым, с адаптивной версткой
До кучи — слои, кеширование, скроллинг, скейлинг. У меня на шарпе такое заняло около 500кб компактного кода. Это только базовый набор.
В уи самое главное это быстро его переделывать под новые требования. Канвас сюда не лезет никак — ну нет столько разрабов, что бы влегкую 2Д графику могли.

Скажем, тот же драг — закодить такое можно на полном контроле происходящего, построив внятную модель автомата. С канвасом вы это все сами, и апи поверх этого тоже сами.

Вобщем, рано или поздно, вы приходите к своему ДОМ, только убогому и неоптимизированному

N>А у Гугла в доках так же? У меня оно на работе заблокировано.

Там уже на канвас вроде перешли. Там как раз проще немного. В иде уи намного тяжелее.

Здравствуйте, novitk, Вы писали:

n> А у Гугла в доках так же? У меня оно на работе заблокировано.

В гуглодоках тоже DOM. Но устроено по-другому. В режиме просмотра каждая страница документа лежит в элементе svg (правда без данных), в скриптах фигурирует offscreen canvas. Вкладка с 13-страничным документом потребляет около 180Mb. Глубже не копал.

Здравствуйте, Pauel, Вы писали:

P>До кучи — слои, кеширование, скроллинг, скейлинг.
Это в vscode разве не ручками надо все делать или никакой памяти не хватит? Например при скроллинг разве они не должны содержимое всех dim-ов перегрузить?

P>В уи самое главное это быстро его переделывать под новые требования. Канвас сюда не лезет никак — ну нет столько разрабов, что бы влегкую 2Д графику могли.
Думал для канваса есть куча фреймворков. Редактор с подсветкой вроде давно изученая область. Тут почитал в vscode терминал уже перевели кстати.

P>Вобщем, рано или поздно, вы приходите к своему ДОМ, только убогому и неоптимизированному
Фиг знает. Всегда думал, что чем больше деталей тем больше своя модель имеет смысл.

Здравствуйте, novitk, Вы писали:

R>>Обычный DOM. span, div, вот это все. Canvas не используется, насколько я могу судить. Открой в браузере https://vscode.dev/ открой какой-нибудь файл и инспектором из web developer tools посмотри на редактор кода.
N>+1. Пипец. Каждая строчка — div с абсолютным позиционированием. Зачем оно так!? Там же все равно не сделать "загрузил и забыл" и DOM надо все время править руками по каждому чиху мышки. На canvas разве не проще и быстрее? Видимо начали на реакте, а теперь переписывать неподьемно.

У DOM'а свои преимущества. В основном это, конечно, автоматическое (пере)позиционирование. Я как-то делал контрол, который представлял собой призму, каждая грань которой соответствовала слайду презентации. Юзер смотрел на неё сбоку, экран при этом совпадал с одной из её граней. Призму можно было крутить вокруг продольной оси так, чтобы после каждого вращения какая-нибудь грань совпадала с экраном (т.е. с шагом 2pi/n). Контрол, конечно, с довольно узкой областью применения (у меня он был для презентационного ПО). Так вот, каждый слайд можно было просто добавлять в контейнер, дальнейшее происходило полностью само. Когда я это писал, браузеры ещё не поддерживали тригонометрию в нужном мне объёме, и пришлось добавить пару скриптов, но сегодня это можно сделать на чистом CSS, вообще без императивного кода. Попробуй, сделай что-нибудь подобное рисованием по канвасу, чтобы оно так же просто и выразительно описывалось кодом (как простая вставка одного элемента в другой, и не вызовом функции, а текстом маркапа — т.е. перетащил код элемента в разметке в контейнер и получил новый слайд и полный перерасчёт трёхмерной геометрии).

На втором месте стоит стилизация. На одной из картинок видно переключение тем. Плюс колорирование синтаксиса. Плюс подсветка ошибок. Плюс операции с текстом. Если ты учтёшь все эти нюансы, и сделаешь всё по уму, ты в итоге и напишешь свои виртуальные узлы DOM и свой виртуальный CSS. А зачем, когда можно использовать специфицированный и стандартизированный?

В-третьих, это схема адресации, которая избавляет тебя от кучи полей со ссылками на то и на другое (все эти _currentFragment, _lineStart, _lineEnd и т.д. и т.п.).

У рисования по канвасу при наступлении события paint тоже есть свои преимущества перед DOM. Это когда нам ничего из перечисленного не надо, а мы просто хотим чего-нибудь закрасить или обвести. Поэтому самая писечка сейчас это сочетать оба подхода. Основу делать из позиционируемых и стилизуемых блоков в виде DOM'а, а для, скажем, операций редактирования, типа всяких обводящих рамок, рисовать по канвасу. Но для этого нужна поддержка со стороны браузера. В Электроне её нет, поэтому бедолаги и вынуждены были делать всё тяжёлой артиллерией. Реакт тут не при чём, как и в случае с TS их подводит отсутствие контроля за рендерингом, ведь браузерный движок они давно про..али. Пока они контролировали рендеринг, у них всё было в шоколаде, вплоть до встроенного DirectX'а было доступно много нативных плюшек, конечно, несовместимых ни с чем.

N>А у Гугла в доках так же? У меня оно на работе заблокировано.

Здравствуйте, Pauel, Вы писали:

P>Вобщем, рано или поздно, вы приходите к своему ДОМ, только убогому и неоптимизированному

Вот-вот.

N>>А у Гугла в доках так же? У меня оно на работе заблокировано.
P>Там уже на канвас вроде перешли. Там как раз проще немного. В иде уи намного тяжелее.

Сейчас они сделают свой DOM, только неубогий и оптимизированный (вот они это смогут себе позволить: они большая контора, которая вдобавок может подкрутить в коде браузера что угодно). И будут пользоваться им сами, а другим не дадут. При этом, формально это останется браузер, а код веб-приложения будет открытым и даже можно будет ДевТулсом туда посмотреть, похлопать глазами на обфусцированное нечто. Корпорация зла, что с них взять.

Здравствуйте, Shmj, Вы писали:

S>Вы мыслите не масштабно.


S>Когда MS сделает ARM планшет с полноценной ARM Windows — то и Apple подтянется.
Нет.

Здравствуйте, Shmj, Вы писали:

S>Там вот в чем дело — бюджет обычно не большой. Делать нужно быстро — иначе потеряет актуальность. Об удобстве думают в последнюю очередь.

Кроилово ведет к попадалову.

Здравствуйте, Pauel, Вы писали:

P>До кучи — слои, кеширование, скроллинг, скейлинг. У меня на шарпе такое заняло около 500кб компактного кода. Это только базовый набор.

Для базового набора норм. Только 500 кб кода — это типа много? Сейчас обычный средний вебсайт может выжрать в 10 раз больше на одну только загрузку страницы.