Здравствуйте, Mamut, Вы писали:
_>>>1. Дикая бедность. В этой библиотеке контролов выбор намного меньше, чем в какой-нибудь TurboVision под DOS! НС>>Это не так. Контролы вполне себе пишутся на JS на основе готовых примитивов.
M>Каких таких примитивов?
div, span.
_>>>2. Доступ к библиотеке ограничен убогими html+js.
НС>>Пошли по кругу. Почему он убогий?
M>Браузеры предоставляют только одну модель: однослойное 2D-окно с некоторыми хаками эмуляции многослойности (z-index, float и position: absolute/fixed).
Почему это хаки?
M>То есть даже такая простая операция, как «показать модальный диалог с анимацией при открытии и закрытии» становится танцами с бубном.
Ты каждый раз это руками пишешь? Ну и в целом окна для веба — не лучшее в плане UX решение. С адаптивностью у окошек беда.
Здравствуйте, vsb, Вы писали:
vsb>Чувствую, скоро для обычного HTML достаточно будет написать <script src="https://mozilla.org/firefox.wasm"></script> который отрисует весь HTML и отработает весь JavaScript на движке, написанном на WASM. А написание полноценного браузера наконец-то станет реалистичной задачей, а не как сейчас, когда гигантские корпорации вроде Microsoft выбрасывают свои движки, т.к. это слишком сложно.
Открыл я страничку, потыкался и тут ноут зашумел кулером. Решил посмотреть что с процом. Если начать выделять и елозить туда-сюбда выделением, то загрузка проца до 45% дохоит, в то время как на обычном хтмл максимум до 25%. Скролинг до 75%, в обчном хтмл с картинками на странице 50%. Что он такой кушающий? У них конечно выделение своеобразное, с закругленными углами, но все же.
Здравствуйте, alex_public, Вы писали:
_>В сочетание этих факторов получаем современный ад в разработке под браузер.
Ад в современной разработке исключительно из за JS.
Рисование ручками, которое ты пропагандируешь, это что-то из 90-х. Markup подход уже давно используется даже в нативных приложениях (WPF,QML и т.д), так как он банально гибче, быстрее и лучше масштабируется в разработке. Если у HTML/CSS и есть проблемы, то именно их надо чинить, а не пытаться вернуть все в средневековье.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>a) Медленно, очень медленно. Так медленно, что пользоваться нельзя от слова совсем и это на демке. Для реализации на нативном языке — позор. НС>Что именно медленно? Я ничего медленного не заметил.
Oткрываешь файл на 1000 строк на большом экране, у меня влезает 160 строк. Нажимаешь down, потом отпускаешь, а оно продолжает скролить еще секунду. Бывают и просто замирания, но это надо ловить, похоже на GC.
Здравствуйте, novitk, Вы писали:
N>Oткрываешь файл на 1000 строк на большом экране, у меня влезает 160 строк. Нажимаешь down, потом отпускаешь, а оно продолжает скролить еще секунду.
У меня нет, даже на файле в 2000 строк.
N> Бывают и просто замирания, но это надо ловить, похоже на GC.
Здравствуйте, D. Mon, Вы писали:
DM>У wasm-апплета память — это линейный массив байтов. Про то, как в ней апплет размещает свои объекты, как делает кучу, как освобождает куски и т.д. — VM про это ничего не знает.
Они убоги, и на их основе «делать компоненты на основе этих примитивов» — это себя не любить.
M>>Браузеры предоставляют только одну модель: однослойное 2D-окно с некоторыми хаками эмуляции многослойности (z-index, float и position: absolute/fixed). НС>Почему это хаки?
Потому что это хаки Элементы никуда не уходят из этой плоской однослойной модели, а только притворяются, что они в ней не участвуют.
M>>То есть даже такая простая операция, как «показать модальный диалог с анимацией при открытии и закрытии» становится танцами с бубном. НС>Ты каждый раз это руками пишешь?
Нет, но какое отношение это имеет к убогости htmlя?
НС>Ну и в целом окна для веба — не лучшее в плане UX решение. С адаптивностью у окошек беда.
При чем тут окна и адаптивность? Модальный диалог — это, любой компонент, который показывается поверх страницы и не позволяет взаимодействовать с ней. Например, лайтбоксы.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Ад в современной разработке исключительно из за JS. НС>Да нет там никакого ада. JS, конечно, добавляет веселья, но TS большую его часть купирует, а остальное уж точно не делает платформу неполноценной.
Ад там уже не в языке, а в экосистеме. Все эти наслоения, включая TS, создают жутко хрупкую конструкцию из говна и палок.
Здравствуйте, Mamut, Вы писали:
M>>>Браузеры предоставляют только одну модель: однослойное 2D-окно с некоторыми хаками эмуляции многослойности (z-index, float и position: absolute/fixed). НС>>Почему это хаки? M>Потому что это хаки
Убедительно.
M> Элементы никуда не уходят из этой плоской однослойной модели, а только притворяются, что они в ней не участвуют.
А что ты тогда скажешь об экранном битмапе, с которым еще недавно работали чуть менее чем все классические библиотеки и с которым работает сабжевый пример? Там тоже хак?
НС>>Ну и в целом окна для веба — не лучшее в плане UX решение. С адаптивностью у окошек беда.
M>При чем тут окна и адаптивность?
При том что, к примеру, на смартфонах окна это так себе UX.
Здравствуйте, novitk, Вы писали:
N>Ад там уже не в языке, а в экосистеме. Все эти наслоения, включая TS, создают жутко хрупкую конструкцию из говна и палок.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>1. Дикая бедность. В этой библиотеке контролов выбор намного меньше, чем в какой-нибудь TurboVision под DOS! НС>Это не так. Контролы вполне себе пишутся на JS на основе готовых примитивов.
Что значит не так, если ты прямо в следующем предложение подтверждаешь, что их надо писать руками? Ну как бы и на фреймбуфере голом тоже можно писать любые контролы — он этого стал GUI библиотекой? )))
_>>2. Доступ к библиотеке ограничен убогими html+js. НС>Пошли по кругу. Почему он убогий?
Прямо в следующем предложение было же объяснено про HTML. Ну а убогость JS как языка, мне кажется не нуждается ни в каких пояснениях.
_>> Точнее HTML убогий естественно не сам по себе, а именно в применение для создания GUI, т.к. изначально он создавался совсем для другого НС>Это неважно для чего он создавался изначально, и не является ответом на заданный вопрос.
HTML хорош для создания документов, но не для создания GUI. Он просто изначально был заточен на другое и с тех пор у него почти не появилось ничего нового в этой области.
_>> Базовых возможностей естественно никому не хватает и каждый пилит свой велосипед НС>Количество велосипедов в итоге не так уж велико и сократилось до angular/react/vue.
Это в этом году. В следующем их тоже будет не много, но возможно это будут уже другие...
_>>. В итоге получаем современных зоопарк уродцев НС>В чем уродство?
В том, что банальную задачу пытаются решить с помощью сочетания: недоразвитого (DOM) инструмента, неподходящего (HTML) инструмента и убого (JS) инструмента. В таких условиях в принципе никто кроме уродца не может родиться.
_>>уже давно даже разбираться лень НС>Это заметно.
Помнится у нас использовалась библиотечка Bootstrap, чтобы расширить убогий набор контролов, предоставляемых DOM. Хотя даже с её помощью набор был далеко не полный. Да и изнутри всё это выглядит крайне уродливо (хотя я это не даже не писал, а только смотрел, но всё равно чуть не стошнило).
Здравствуйте, novitk, Вы писали:
_>>А где конкретно медленно? Я там особо не тестировал специально, так, полазил немного. Но вроде ни единого торможение не увидел. Может у тебя там тоже с OpenGL проблемы (например сидишь под Линухом и не ставил родные драйверы от карты)? N>Текстовый редактор конечно, там больше и нет ничего. Винда, нормальное железо, видеокарта не топ.
Просто я не смог никакими способами заставить его тормозить...
_>>Так оно вроде не для обычных сайтиков, а для приложений... N>Граница имхо довольно тонкая. Например много умельцев сделают на этом таблички, которые будут красиво выглядеть и возможно даже быстро ездить, только в них будет не работать поиск, зум или буффер обмена, как у этого чуда.
С зумом и буффером не вижу никаких проблем. )
_>>Как насчёт продуктивности скажем Питона? Он уже без проблема доступен в браузере именно через wasm... N>ppci? Никак, это наколенная поделка, которая такой и останется пока нет доступа к DOM-u.
И да, это сейчас всё работает через классических html+js, а wasm там только для собственно запуска движка Питона. Но при этом работает вполне себе стабильно и удобно.
Здравствуйте, rFLY, Вы писали:
vsb>>Чувствую, скоро для обычного HTML достаточно будет написать <script src="https://mozilla.org/firefox.wasm"></script> который отрисует весь HTML и отработает весь JavaScript на движке, написанном на WASM. А написание полноценного браузера наконец-то станет реалистичной задачей, а не как сейчас, когда гигантские корпорации вроде Microsoft выбрасывают свои движки, т.к. это слишком сложно. FLY>Открыл я страничку, потыкался и тут ноут зашумел кулером. Решил посмотреть что с процом. Если начать выделять и елозить туда-сюбда выделением, то загрузка проца до 45% дохоит, в то время как на обычном хтмл максимум до 25%. Скролинг до 75%, в обчном хтмл с картинками на странице 50%. Что он такой кушающий? У них конечно выделение своеобразное, с закругленными углами, но все же.
И как вы все это делаете то? ))) Я как ни елозил, не смог добиться загрузки процессора даже на 1%!
Здравствуйте, novitk, Вы писали:
N>Рисование ручками, которое ты пропагандируешь, это что-то из 90-х. Markup подход уже давно используется даже в нативных приложениях (WPF,QML и т.д), так как он банально гибче, быстрее и лучше масштабируется в разработке. Если у HTML/CSS и есть проблемы, то именно их надо чинить, а не пытаться вернуть все в средневековье.
Не, я как раз предпочитаю вообще накидать контролы в графическом редакторе, который потом сгенерирует мне описание GUI (не важно в каком формате), по которому можно собрать приложение. Проблема в том, что как раз для текущего HTML+JS это практически не реальный сценарий...
Здравствуйте, novitk, Вы писали:
N>>>a) Медленно, очень медленно. Так медленно, что пользоваться нельзя от слова совсем и это на демке. Для реализации на нативном языке — позор. НС>>Что именно медленно? Я ничего медленного не заметил. N>Oткрываешь файл на 1000 строк на большом экране, у меня влезает 160 строк. Нажимаешь down, потом отпускаешь, а оно продолжает скролить еще секунду. Бывают и просто замирания, но это надо ловить, похоже на GC.
Эмм, 160 строк? У тебя монитор расположен вертикально? Или же у тебя шрифт, который надо разглядывать в лупу? ))) У меня там строк 50 влезает где-то.
Да, но не думаю что количество строк критично для данного теста. А так, при любых прокрутках я не смог заметить ни единого торможения...
Здравствуйте, Mamut, Вы писали:
M>Что значит «встроить»? wasm выполняется в отдельном процессе, и у него нет ничего, кроме собственно выполнения кода. Весь доступ к окну браузера происходит через JS-заглушки.
Имеется ввиду использовать его для рисования в некоторой области страницы, а не всю страницу через него отрисовывать.
M>Откуда у него возьмется этот доступ?
Откуда доступ к кодекам у ютуб плеера? Вот оттуда и васм должен получать.
M>> Элементы никуда не уходят из этой плоской однослойной модели, а только притворяются, что они в ней не участвуют. НС>А что ты тогда скажешь об экранном битмапе, с которым еще недавно работали чуть менее чем все классические библиотеки и с которым работает сабжевый пример? Там тоже хак?
Ты сейчас на полном серьезе приравниваешь div'ы и span'ы к битмапам?
НС>>>Ну и в целом окна для веба — не лучшее в плане UX решение. С адаптивностью у окошек беда. M>>При чем тут окна и адаптивность? НС>При том что, к примеру, на смартфонах окна это так себе UX.
K>Имеется ввиду использовать его для рисования в некоторой области страницы, а не всю страницу через него отрисовывать.
Можно. Потому что во всех примерах,в которых wasm рисует что-либо, он делает это через элемент canvas (изредка — через webgl), к которому доступ имеет через JS-заглушку. Делаешь этот элменет не размером со всю страницу, у вуаля
M>>Откуда у него возьмется этот доступ? K>Откуда доступ к кодекам у ютуб плеера? Вот оттуда и васм должен получать.