Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Что значит не так, если ты прямо в следующем предложение подтверждаешь, что их надо писать руками?
НС>Странный ты. Если ты используешь библиотеку, то писать руками не надо.

Писать новые контролы? Ну иногда бывает, но это скорее исключение, чем практика. В то время как под браузер даже базовое приложение не сделаешь без этого.

_>>Ну как бы и на фреймбуфере голом тоже можно писать любые контролы — он этого стал GUI библиотекой? )))
НС>Ну так голый HTML+JS это тоже не библиотека.

Я именно про это и говорю. GUI библиотека браузера — это DOM (во всяком случае большая его часть). И она крайне бедная.

_>> Ну а убогость JS как языка, мне кажется не нуждается ни в каких пояснениях.
НС>Для целей GUI современный JS, а тем более TS вполне адекватны.

Угу, особенно на нём хорошо выходит делать классические расширяемые с помощью ООП иерархий библиотеки... )))

_>>HTML хорош для создания документов, но не для создания GUI.
НС>HTML5 вполне подходит для создания GUI и с прицелом на это создавался.

Если бы это было так, то не существовало бы множества библиотек под браузер, добавляющих к нему самые базовые контролы (чтобы он стал хотя бы отдалённо сравним с TurboVision из DOS!). Вот что мешало записать хотя бы эти https://getbootstrap.com/docs/4.3/components контролы в HTML5, если он по твоим словам, создавался для GUI? Я уж не говорю про чуть более серьёзные вещи типа TreeView, ListView и т.п...

И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое. Большинство сайтов в интернете и вообще html страниц — это не приложения, а именно документы!

_>> и с тех пор у него почти не появилось ничего нового в этой области.
НС>Это вранье.

Ну давай, расскажи о колоссальном прогрессе у HTML в области GUI... )))

НС>>>Количество велосипедов в итоге не так уж велико и сократилось до angular/react/vue.
_>>Это в этом году. В следующем их тоже будет не много
НС>Или не будет. По факту реакту уже 6 лет и своей актуальности он не потерял, а vue принципиально от него не отличается.

Надейся, надейся. ) Кстати, помнится самым мощным GUI фреймворком для приложений (а не для сайтиков!) был ExtJS — и что это ты её не упомянул, а? )

_>>Помнится у нас использовалась библиотечка Bootstrap, чтобы расширить убогий набор контролов, предоставляемых DOM.
НС>И что?

Это я так сказать пояснил, в какой степени я в курсе данной области. )))

_>> Да и изнутри всё это выглядит крайне уродливо
НС>Что именно там выглядит уродливо? Хотя и так понятно, что ты ответить не сможешь.

Вот как будто бы ты сам не видел внутренности всех этих html/css/js фреймворков. На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты! Хуже чем эти JS фреймворки, наверное только PHP фреймворки (в которых опять же есть html/css/js)...

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

K>Это понятно. Я как раз про это и говорю, ютуб не тянет кодеки сам, а использует то, что есть на хосте. Как это будет работать? Приходит видео поток который отправялется через браузер на декодирование через конкретный кодек, так? Вопрос, может ли также работать васм, может ли он юзать крипто апи, создавать вёб скоеты и т.п.

В принципе, после добавления в wasm поддержки simd, все нужные кодеки можно будет уже писать (а точнее просто скомпилировать, т.к. большинство их них написаны на C/C++ и только некоторые используют ещё и ассемблер для ускорения) прямо на wasm.

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

_>>И как вы все это делаете то? ))) Я как ни елозил, не смог добиться загрузки процессора даже на 1%!
FLY>У меня наотбучный кор ай5 с интеловской графикой, запускал в хроме

Не, ну у меня конечно же топовый комп и видеокарта, а браузер Firefox. Но всё равно по идее не должно быть такой разницы. В разы — да. Но не в десятки или сотни раз!

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Не, я как раз предпочитаю вообще накидать контролы в графическом редакторе, который потом сгенерирует мне описание GUI (не важно в каком формате)
НС>И неважно, что прощай адаптивная верстка, ага

Эм, до автоматических контроллёров разметки (https://doc.qt.io/qt-5/layout.html), которые можно без проблем накидать мышкой на форму, в мире JS библиотек ещё не доросли? )

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

__>>>А теперь объясни, что это за сайтик такой с исходниками на расте, и в каком месте надо восхищаться.
_>>Восхищаться надо тем, что этот сайтик целиком работает без использования богомерзких html/js/css.
A>Но это же чистая религия.

А если я скажу, что мне больше нравится кататься на мерседесе, чем на запорожце, то это тоже будет чистая религия? )))

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

_>Не, ну у меня конечно же топовый комп и видеокарта, а браузер Firefox. Но всё равно по идее не должно быть такой разницы. В разы — да. Но не в десятки или сотни раз!
Ну чёрт его знает, может он часть вычислений/прорисовку на видюху переводит и встроенное граф.едро от интела этого не поддерживает.

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

_>>>Восхищаться надо тем, что этот сайтик целиком работает без использования богомерзких html/js/css.
A>>Но это же чистая религия.
_>А если я скажу, что мне больше нравится кататься на мерседесе, чем на запорожце, то это тоже будет чистая религия? )))

Если ты скажешь, что «Запорожец» богомерзкий, а катающимися на «Мерседесе» надо восхищаться — да.

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

A>а катающимися на «Мерседесе» надо восхищаться — да.

А про это речи и не было.

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

_>Вот как будто бы ты сам не видел внутренности всех этих html/css/js фреймворков. На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты! Хуже чем эти JS фреймворки, наверное только PHP фреймворки (в которых опять же есть html/css/js)...

Пощупав недавно эти "чудеса дизайна", подумалось — а не пора ли просто отправить html/css на помоечку, и сделать фреймворк на одних плавающих дивах и абсолютном позиционировании?

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

НС>>Странный ты. Если ты используешь библиотеку, то писать руками не надо.
_>Писать новые контролы? Ну иногда бывает, но это скорее исключение, чем практика.

Ровно как и в современном вебе.


_>>>Ну как бы и на фреймбуфере голом тоже можно писать любые контролы — он этого стал GUI библиотекой? )))
НС>>Ну так голый HTML+JS это тоже не библиотека.
_>Я именно про это и говорю. GUI библиотека браузера — это DOM (во всяком случае большая его часть).

Так библиотека или не библиотека, ты уж определись.

_>>> Ну а убогость JS как языка, мне кажется не нуждается ни в каких пояснениях.
НС>>Для целей GUI современный JS, а тем более TS вполне адекватны.
_>Угу, особенно на нём хорошо выходит делать классические расширяемые с помощью ООП иерархий библиотеки... )))

А зачем на нем делать классические библиотеки?

_>>>HTML хорош для создания документов, но не для создания GUI.
НС>>HTML5 вполне подходит для создания GUI и с прицелом на это создавался.
_>Если бы это было так, то не существовало бы множества библиотек под браузер, добавляющих к нему самые базовые контролы

Ровно как существует множество библиотек под С++, добавляющих ...

_>Вот что мешало записать хотя бы эти https://getbootstrap.com/docs/4.3/components контролы в HTML5

Зачем?

_>И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое.

Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок.

_>>> и с тех пор у него почти не появилось ничего нового в этой области.
НС>>Это вранье.
_>Ну давай, расскажи о колоссальном прогрессе у HTML в области GUI... )))

Возьми спеку HTML5 и почитай.

НС>>Или не будет. По факту реакту уже 6 лет и своей актуальности он не потерял, а vue принципиально от него не отличается.
_>Надейся, надейся. )

Да мне пофигу, в моих проектах фронта не очень много, мне пока одного фронтендера за глаза. Ну будет вместо реакта чего еще — ради бога.

_> Кстати, помнится самым мощным GUI фреймворком для приложений (а не для сайтиков!) был ExtJS — и что это ты её не упомянул, а? )

ExtJS это как раз от таких как ты любителей старого подхода. Потому и сдох. Реакт сильно лучше.

_>>>Помнится у нас использовалась библиотечка Bootstrap, чтобы расширить убогий набор контролов, предоставляемых DOM.
НС>>И что?
_>Это я так сказать пояснил, в какой степени я в курсе данной области. )))

Да это и без пояснений понятно.

_>>> Да и изнутри всё это выглядит крайне уродливо
НС>>Что именно там выглядит уродливо? Хотя и так понятно, что ты ответить не сможешь.
_>Вот как будто бы ты сам не видел внутренности всех этих html/css/js фреймворков.

Видел. Ничего космического там нет.

_> На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты!

С точностью до наоборот.

_> Хуже чем эти JS фреймворки, наверное только PHP фреймворки (в которых опять же есть html/css/js)...

Ох уж эти теоретики.

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

A>>а катающимися на «Мерседесе» надо восхищаться — да.
C>А про это речи и не было.

Именно про это и речь.

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

A>Именно про это и речь.

На самом деле, конечно, нет. Там речь про "Мерседес", а не про "тех, кто на нем катается".

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

DM>Я не про DOM. Я про сложность нормально компилировать в wasm нативные языки с GC, т.к. нельзя сканировать стек.

Это нейтивный стек вызовов нельзя сканировать, а стек данных можно:

For this C function:

void foo() {
    int x;
    bar(&x);
}

The asm.js code looks like this:

function _foo() {
 var $x = 0, label = 0, sp = 0;
 sp = STACKTOP;
 STACKTOP = STACKTOP + 16|0; if ((STACKTOP|0) >= (STACK_MAX|0)) abort();
 $x = sp;
 _bar($x);
 STACKTOP = sp;return;
}

В любом случае, в чистом нейтиве бывают только пессимистичные GC, т.е. если в стеке лежат только данные — это даже еще лучше.

А если брать что-то типа .Net/Java с точным GC, то для такого GC в любом случае надо размечать фреймы стека и связывать их с метаинформацией, поэтому, отсутствие доступа к адресам возвратов мешать не должно — указатель на текущий фрейм можно протягивать как неявный аргумент любого вызова.

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

DM>>Я не про DOM. Я про сложность нормально компилировать в wasm нативные языки с GC, т.к. нельзя сканировать стек.

V>Это нейтивный стек вызовов нельзя сканировать, а стек данных можно:

Хм, можно ссылку на описание "стека данных" в WebAssembly?
Если что, мы тут про WebAssembly говорим, а не про ASM.js.

V>В любом случае, в чистом нейтиве бывают только пессимистичные GC, т.е. если в стеке лежат только данные — это даже еще лучше.

Что такое "пессимистичные GC"?
Консервативные? Нет, это не так совершенно.

V>А если брать что-то типа .Net/Java с точным GC, то для такого GC в любом случае надо размечать фреймы стека и связывать их с метаинформацией, поэтому, отсутствие доступа к адресам возвратов мешать не должно — указатель на текущий фрейм можно протягивать как неявный аргумент любого вызова.

Если текущий фрейм не в куче, то на него не бывает указателей в WebAssembly.

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

_>В принципе, после добавления в wasm поддержки simd, все нужные кодеки можно будет уже писать (а точнее просто скомпилировать, т.к. большинство их них написаны на C/C++ и только некоторые используют ещё и ассемблер для ускорения) прямо на wasm.

Говно получится. Современные кодеки стандартных форматов давно используют GPU-ускорение, без него на одном CPU получается очень грустно даже с SIMD.

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

_>На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты!

Кстати, а что плохого в Qt?

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

A>>Именно про это и речь.
C>На самом деле, конечно, нет. Там речь про "Мерседес", а не про "тех, кто на нем катается".

Там религиозный экстаз. А то, что вы какие-то «Мерседесы» придумали и пытаетесь на них выехать, к делу отношения не имеет.

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

$>Могло бы быть альтернативой флешу, но нет, на ослике не работает.

Он где-то еще остался? Последние динозавры с него слезают, потому что нужные им сайты перестают там работать. Пора бы окончательно закопать стюардессу.

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

_>Ну и да, это плохо для случая потребности высокой производительности таких вызывов.

Это плохо потому, что любое действие с DOM надо либо оборачивать в JS, либо на нем и писать, размазывая логику. Это очень неудобно при написании, даже неудобнее использования монструозных js-фреймворков.

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

V>>Это нейтивный стек вызовов нельзя сканировать, а стек данных можно:
DM>Хм, можно ссылку на описание "стека данных" в WebAssembly?

Одной ссылки у меня нет (мне её искать столько же, сколько и тебе), из обсуждений в баг- и пул-реквестов проекта стало понятно, что под стек "песочницы" выделяется просто область памяти из той же кучи, из которой выделяется обычная динамическая память для данного экземпляра "песочницы". По-умолчанию 256 К, вроде бы.

С другой стороны, вряд ли тут требуется какое-либо особое описание, бо в классике стеков всегда два — стек данных и стек возвратов.

Это мы так привыкли, что в мейнстримовом фон-неймановском железе эти стеки совмещены, что, с одной стороны удобнее (экономится один регистр процессора и требуется управлять одной областью памяти, а не двумя), с другой стороны — чинит препятствия стековым вычислениям, где состояние стека в результате пред. вычислений одновременно является входным аргументом для последующих вычислений. Такие вычисления в кол-ве операций эффективнее по сравнению со совмещённым стеком, требующим возврата состояния стека после вызова подпрограмм.

Так-то сейчас есть всё более растущая область гарвардского embedded, там стеки всегда раздельные.

Ну и, есть та гарантия, что то, что не является UB в С/C++, не будет являться UB и в бинарнике под WebAssembly.
Т.е. указатели и ссылки на локальные переменные — это вполне себе доступные адреса памяти.

На всякий случай напомню, что преобразование указателя на ф-ию в указатели на данные (например в void*) и обратно — UB в С/С++.
Тем самым можно соблюсти гарантию того, что адрес ф-ий будет невозможно рассматривать как адрес данных.


DM>Если что, мы тут про WebAssembly говорим, а не про ASM.js.

У них есть взаимно-однозначно отображаемая модель.
Походу, ASM.js показан для демонстрации, т.к. llvm не так чтобы бегло читается с листа. ))

Вполне может быть, что "расшифровывать" происходящее с помощью ASM.js — вполне себе норма в этом проекте.
По крайней мере в обсуждении баг- и пул- реквестов я видел это более одного раза.


V>>В любом случае, в чистом нейтиве бывают только пессимистичные GC, т.е. если в стеке лежат только данные — это даже еще лучше.
DM>Что такое "пессимистичные GC"?

Консервативные.

The collector has to make pessimistic assumptions if a memory slot can contain both a pointer or an integer value

DM>Консервативные? Нет, это не так совершенно.

Еще и "совершенно"? ))
Объем сканируемой памяти данных резко уменьшается, если стек данных отделить от стека возврата.


V>>А если брать что-то типа .Net/Java с точным GC, то для такого GC в любом случае надо размечать фреймы стека и связывать их с метаинформацией, поэтому, отсутствие доступа к адресам возвратов мешать не должно — указатель на текущий фрейм можно протягивать как неявный аргумент любого вызова.
DM>Если текущий фрейм не в куче, то на него не бывает указателей в WebAssembly.

Фреймы стека данных живут в стеке данных, т.е. на куче в исполнении WebAssembly.