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

_>>>1. Дикая бедность. В этой библиотеке контролов выбор намного меньше, чем в какой-нибудь TurboVision под DOS!
НС>>Это не так. Контролы вполне себе пишутся на JS на основе готовых примитивов.
_>Что значит не так, если ты прямо в следующем предложение подтверждаешь, что их надо писать руками?

Странный ты. Если ты используешь библиотеку, то писать руками не надо.

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

Ну так голый HTML+JS это тоже не библиотека.

_>>>2. Доступ к библиотеке ограничен убогими html+js.
НС>>Пошли по кругу. Почему он убогий?
_>Прямо в следующем предложение было же объяснено про HTML.

Не было там ничего объяснено.

_> Ну а убогость JS как языка, мне кажется не нуждается ни в каких пояснениях.

Для целей GUI современный JS, а тем более TS вполне адекватны.

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

HTML5 вполне подходит для создания GUI и с прицелом на это создавался.

_> Он просто изначально был заточен на другое

Еще раз — неважно на что он был заточен изначально.

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

Это вранье.

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

Или не будет. По факту реакту уже 6 лет и своей актуальности он не потерял, а vue принципиально от него не отличается.
И ровно такая же история была с классическим гуем, пока десктопы не стали дохнуть и интерес к десктопному гую в целом не был потерян.

_>>>. В итоге получаем современных зоопарк уродцев
НС>>В чем уродство?
_>В том, что банальную задачу пытаются решить с помощью сочетания: недоразвитого (DOM) инструмента, неподходящего (HTML) инструмента и убого (JS) инструмента.

Убого потому что убого. Повторяешься.

_> В таких условиях в принципе никто кроме уродца не может родиться.

Тем не менее почему именно убого ты так ответить не смог. ЧТД.

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

И что?

_> Хотя даже с её помощью набор был далеко не полный.

У классических гуев тоже набор искаропки неполный. Но есть куча контор, выпускающих более поные наборы. С бутстрапом та же история.

_> Да и изнутри всё это выглядит крайне уродливо

Что именно там выглядит уродливо? Хотя и так понятно, что ты ответить не сможешь.

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

DM>>У wasm-апплета память — это линейный массив байтов. Про то, как в ней апплет размещает свои объекты, как делает кучу, как освобождает куски и т.д. — VM про это ничего не знает.

НС>До тех пор пока нам не понадобится DOM.

Разверни свою мысль, пожалуйста.

Для работы с DOM напрямую апплету придется как-то сообщать браузеру, какие DOM-объекты (живущие в куче браузера, а не апплета) он еще использует, а какие уже нет. Но про то, что внутри линейной памяти апплета происходит, как ее апплет для себя понимает и интерпретирует, этого VM все равно знать не будет. Как сейчас не знает, где именно скомпилированный в wasm интерпретатор Питона хранит счетчики ссылок для питоновских объектов.

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

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

M>Можно. Потому что во всех примерах,в которых wasm рисует что-либо, он делает это через элемент canvas (изредка — через webgl), к которому доступ имеет через JS-заглушку. Делаешь этот элменет не размером со всю страницу, у вуаля

M>У ютуб плеера нед доступа к кодекам. Он играет то, что может играть. Максимум, что он может узнать — это какие кодеки возможно доступны в системе: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType
Это понятно. Я как раз про это и говорю, ютуб не тянет кодеки сам, а использует то, что есть на хосте. Как это будет работать? Приходит видео поток который отправялется через браузер на декодирование через конкретный кодек, так? Вопрос, может ли также работать васм, может ли он юзать крипто апи, создавать вёб скоеты и т.п.

M>>У ютуб плеера нед доступа к кодекам. Он играет то, что может играть. Максимум, что он может узнать — это какие кодеки возможно доступны в системе: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType
K>Это понятно. Я как раз про это и говорю, ютуб не тянет кодеки сам, а использует то, что есть на хосте. Как это будет работать? Приходит видео поток который отправялется через браузер на декодирование через конкретный кодек, так? Вопрос, может ли также работать васм,

Как — так? Плеер Ютуба не делает ничего. Все, что доустпно в браузере, — это тонкая обертка над встроенным в систему плеером, который, собственно, и работает с видео. У плеера нет доступа ни к чему низкоуровневому. Ни к потоку, ни к кодекам — ни к чему. Вот полностью весь доступный API: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement

Максимум, что может быть когда нибудь будет у wasm'а — это доступ к этому же API. И то, это сильно под вопросом.

K>может ли он юзать крипто апи, создавать вёб скоеты и т.п.

Может уже сейчас через заглушку в JS. Вряд ли даже в будущем что-то сильно изменится по этому поводу. Пока что на горизонте ничего такого не предвидится, вроде.

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

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

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

M>>> Элементы никуда не уходят из этой плоской однослойной модели, а только притворяются, что они в ней не участвуют.
НС>>А что ты тогда скажешь об экранном битмапе, с которым еще недавно работали чуть менее чем все классические библиотеки и с которым работает сабжевый пример? Там тоже хак?
M>Ты сейчас на полном серьезе приравниваешь div'ы и span'ы к битмапам?

Нет конечно. Битмапы намного примитивнее и работа с ними, в твоей терминологии, еще больших хак.

НС>>>>Ну и в целом окна для веба — не лучшее в плане UX решение. С адаптивностью у окошек беда.
M>>>При чем тут окна и адаптивность?
НС>>При том что, к примеру, на смартфонах окна это так себе UX.
M>Еще раз. При чем тут окна и адаптивность?

При том что окно не сделаешь адаптивным.

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

M>>>Оно и сейчас «существует». Как видно, особо не помогает.
V>>Ну и где оно "видно"?

M>Везде. Одни и те же куски кода разными приложениями постоянно грузятся заново. Потому что cache partitioning. Из-за этого какой-нибудь React ты скачиваешь по двести раз заново.

200 разных приложений — это свистелки из 200 разных сайтов?
Нормальный у тебя охват. ))
ИМХО, вряд ли пользователь использует на постоянной основе 200 тяжелых приложений.

И да, выводы делать рано — мозилла использует общий кеш для скомпиллированных webasm бинарников.
Сама эта технология уже является песочницей, т.е., вполне возможно, что вопросы с кешем решат.
Есть же технологии подписей, есть схемы "доверенных источников" и т.д. и т.п.

Просто на сейчас еще вопрос толком не стоит, т.е. выводы делать рано.

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

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

И неважно, что прощай адаптивная верстка, ага

НС>Нет конечно. Битмапы намного примитивнее и работа с ними, в твоей терминологии, еще больших хак.

Как только браузеры предоставляют возможность работать с битмапами (то есть с пикселями, и вообще рисовать), как возникают проекты, которые силами HTML и JS создать невозможно. Например, Figma.

div и спан — примитивы только в том смысле, что примитивнее их в HTML нет. При этом они являются высокоуровневыми объектами с кучей поведения, которое хрен обойдешь, и на основе которого хрен построешь хоть какую-либо вменяемую функциональность.

M>>Еще раз. При чем тут окна и адаптивность?

НС>При том что окно не сделаешь адаптивным.

У тебя какое-то умопомрачение на окнах.

даже такая простая операция, как «показать модальный диалог с анимацией при открытии и закрытии» становится танцами с бубном.

Модальный диалог — это необязательно окно. Стоп. Про это я тоже говорил.

V>200 разных приложений — это свистелки из 200 разных сайтов?
V>Нормальный у тебя охват. ))
V>ИМХО, вряд ли пользователь использует на постоянной основе 200 тяжелых приложений.

Тебе не надо пользовать «тяжелые приложения», чтобы твой браузер внезапно наяал тянуть очередную версию реакта с очередного сайта, на который ты только что перешел.

V>И да, выводы делать рано — мозилла использует общий кеш для скомпиллированных webasm бинарников.

Про это не нашел, только тут: https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/

Там просто про кэш говорят. Хотя, помнится, что-то такое предлагалось: делать общий кэш для общих модулей.

M>// возможный результат: "", "maybe", "probably"

Восхитительно. Живо представил в каком-нибудь гуе диалоговое окно типа "Вы действительно хотите удалить эту запись?" и три кнопки с вариантами ответа: "Может быть", Скорее всего", и третья кнопка вообще без надписи

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

V>>И да, выводы делать рано — мозилла использует общий кеш для скомпиллированных webasm бинарников.
M>Про это не нашел

Я как-то смотрел АПИ их index DB — там нет аргументов для разделения кеша, записи кеша отличаются по URL.

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

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

Но это же чистая религия.

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

wl.>Foxit Reader, привык как-то к нему.

У них рендерер шрифтов — вырви глаз.

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

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

Лейаут панели уже отменили?
Вычисляемые св-ва тоже?

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

K>>Разве адекватный человек такое купит?
CC>Что, бабла не хватило?

-1
Топовые корейцы и китайцы подороже стоят. Причём, местами намного дороже.
Т.е. уже давно не в деньгах дело.

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

DM>>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.
vsb>Я думаю, они сделают опциональный сборщик мусора на уровне VM.

Для точного GC нужна метаинформация — разметка объектов в памяти и разметка переменных в стеке.
Это, в свою очередь, вешает гири на ноги оптимизаторам, которые могли бы ликвидировать переменные во фрейме стека и вообще сами фреймы, поля в объектах и даже целые объекты. Тем более, что llvm не мыслит категориями объектов.

Похоже, на подобный шаг они не готовы и вряд ли когда будут готовы.
Т.е. под wasm придётся накатать свой дотнет и свою джаву.

Т.е., получается возврат к тому, от чего пытались убежать, только теперь в еще более глупом исполнении, при взгляде с высоты птичьего полёта на получившийся "пирог" технологий.

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

НС>https://github.com/WebAssembly/proposals/issues/16
НС>Без GC не получится дать прямой доступ к DOM

Здра моя ра...
Унутре весь DOM живёт на счётчиках ссылок.
Поэтому, тот же Swift, Object-C, С++, Rust могут юзать его как родной.
Питоны, перлы, VB — аналогично.
Минимальная инфраструктура со "своей" VM джавы/дотнета — тоже.

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

DM>Интерпретаторам проще. Проще некуда. Это ж просто сишная программа. Сложно нативно компилируемым языкам

А в чём сложность?
В любых браузерах объекты DOM — это нейтивные объекты со счётчиком ссылок или хендлы с сопровожающим АПИ, через который можно сообщить о том, что хендл более не используется.

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

DM>>Интерпретаторам проще. Проще некуда. Это ж просто сишная программа. Сложно нативно компилируемым языкам

V>А в чём сложность?
V>В любых браузерах объекты DOM — это нейтивные объекты со счётчиком ссылок или хендлы с сопровожающим АПИ, через который можно сообщить о том, что хендл более не используется.

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