Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро. Размер кода полмегабайта. Для мини-IDE на мой взгляд очень неплохо.
ИМХО это то, что действительно можно называть Web 2.0. Не эволюционное развитие HTML/CSS/JavaScript, тянущееся с 90-х годов, а революционное, причём прекрасно работающее здесь и сейчас во всех браузерах, даже в Safari на айфоне. Наслаждайтесь взглядом в будущее.
Чувствую, скоро для обычного HTML достаточно будет написать <script src="https://mozilla.org/firefox.wasm"></script> который отрисует весь HTML и отработает весь JavaScript на движке, написанном на WASM. А написание полноценного браузера наконец-то станет реалистичной задачей, а не как сейчас, когда гигантские корпорации вроде Microsoft выбрасывают свои движки, т.к. это слишком сложно.
Здравствуйте, vsb, Вы писали:
vsb>Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро. Размер кода полмегабайта. Для мини-IDE на мой взгляд очень неплохо.
В фаирфоксе подвисло в состоянии "Loading". В гуглохроме прокрутка идет с такой скоростью, что лучше бы ее и вовсе не было.
Здравствуйте, Pzz, Вы писали:
Pzz>В фаирфоксе подвисло в состоянии "Loading".
У меня работает. Может скрипты что-то блокирует?
Pzz>В гуглохроме прокрутка идет с такой скоростью, что лучше бы ее и вовсе не было.
Хз, о чём ты. Прокручивает как любой другой редактор. Ну ты придираешься уже к ерунде. Скорость прокрутки это константа в коде — сколько строк прокручивать на одно нажатие колёсика.
Здравствуйте, vsb, Вы писали:
Pzz>>В фаирфоксе подвисло в состоянии "Loading".
vsb>У меня работает. Может скрипты что-то блокирует?
А у меня не работает. Скрипты я не блокирую.
Pzz>>В гуглохроме прокрутка идет с такой скоростью, что лучше бы ее и вовсе не было.
vsb>Хз, о чём ты. Прокручивает как любой другой редактор. Ну ты придираешься уже к ерунде. Скорость прокрутки это константа в коде — сколько строк прокручивать на одно нажатие колёсика.
Здравствуйте, vsb, Вы писали:
vsb>Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро. Размер кода полмегабайта. Для мини-IDE на мой взгляд очень неплохо.
Кажется мне, что мартышки всё равно будут делать всё на HTML/CSS/JS
Здравствуйте, Pzz, Вы писали:
Pzz>А у меня не работает. Скрипты я не блокирую.
Pzz>Сама отрисовка при прокрутке очень медленно идет.
Ну сорри, значит не всё идеально. У меня и на телефоне скролл абсолютно как нативное приложение: очень быстро, на компьютере тем более и вообще ощущение действительно как от запущенного приложения, чем как от веб-приложения (сложно объяснить, почему, возможно отзыв на ввод быстрей). Ещё можно Alt понажимать и посмотреть на очень быструю и плавную анимацию сворачивания блоков.
Здравствуйте, vsb, Вы писали:
vsb>Ну сорри, значит не всё идеально.
Кстати, с другой машинки в фирефоксе запустилось, и скролируется достаточно шустренько, что в гуглохроме, что в фоксе. При том, что другая машинка объективно слабее первой.
vsb>ИМХО это то, что действительно можно называть Web 2.0. Не эволюционное развитие HTML/CSS/JavaScript, тянущееся с 90-х годов, а революционное, причём прекрасно работающее здесь и сейчас во всех браузерах, даже в Safari на айфоне. Наслаждайтесь взглядом в будущее.
Прекрасно в том плане, что отрабатывает некоторый минимум вещей. Но при этом, например, рушит подавляющее большинство вещей, которые ожидаешь от бразуера. Например, клавиатурную навигацию, right-click, тултипы. Половина кнопок на основной странице половина кнопок то ли не работает, то ли непонятно, что делает. Наверняка нулевой accessibility.
Хотя работы проделано тонны.
vsb>Чувствую, скоро для обычного HTML достаточно будет написать <script src="https://mozilla.org/firefox.wasm"></script> который отрисует весь HTML и отработает весь JavaScript на движке, написанном на WASM.
Зачем? Что это даст?
vsb>А написание полноценного браузера наконец-то станет реалистичной задачей, а не как сейчас, когда гигантские корпорации вроде Microsoft выбрасывают свои движки, т.к. это слишком сложно.
Каким образом из того, что wasm'ом можно отрисовать HTML (что?) следует легкость создания браузерного движка?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, vsb, Вы писали:
vsb>>Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро. Размер кода полмегабайта. Для мини-IDE на мой взгляд очень неплохо.
Pzz>В фаирфоксе подвисло в состоянии "Loading". В гуглохроме прокрутка идет с такой скоростью, что лучше бы ее и вовсе не было.
у меня несколько NUC'ов с древним атомом и вынь7 / 8 гб рам), в FF бегает идеально
Здравствуйте, vsb, Вы писали:
А написание полноценного браузера наконец-то станет реалистичной задачей, а не как сейчас, когда гигантские корпорации вроде Microsoft выбрасывают свои движки, т.к. это слишком сложно.
простите за оффтоп. После того как MS выкинула свой движок в последнем обновлении виндовс, Edge перестал открывать .epub, чем сейчас техническую литературу в этом формате открывать? Чтобы без всяких свистоперделок, и код не разбивался на абзацы.
Пока что обхожусь онлайн-конвертацией в .pdf, но это как-то тупо
Здравствуйте, wl., Вы писали:
wl.>простите за оффтоп. После того как MS выкинула свой движок в последнем обновлении виндовс, Edge перестал открывать .epub, чем сейчас техническую литературу в этом формате открывать? Чтобы без всяких свистоперделок, и код не разбивался на абзацы. wl.>Пока что обхожусь онлайн-конвертацией в .pdf, но это как-то тупо
А pdf ты чем читаешь? SumatraPDF читает и epub.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, wl., Вы писали:
wl.>простите за оффтоп. После того как MS выкинула свой движок в последнем обновлении виндовс, Edge перестал открывать .epub, чем сейчас техническую литературу в этом формате открывать? Чтобы без всяких свистоперделок, и код не разбивался на абзацы. wl.>Пока что обхожусь онлайн-конвертацией в .pdf, но это как-то тупо
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, wl., Вы писали:
wl.>>простите за оффтоп. После того как MS выкинула свой движок в последнем обновлении виндовс, Edge перестал открывать .epub, чем сейчас техническую литературу в этом формате открывать? Чтобы без всяких свистоперделок, и код не разбивался на абзацы. wl.>>Пока что обхожусь онлайн-конвертацией в .pdf, но это как-то тупо
Ops>А pdf ты чем читаешь? SumatraPDF читает и epub.
Foxit Reader, привык как-то к нему.
SumatraPDF — попробовал, да открывает .epub. Подтормаживает при отрисовке страницы
Здравствуйте, wl., Вы писали:
wl.>Foxit Reader, привык как-то к нему. wl.>SumatraPDF — попробовал, да открывает .epub. Подтормаживает при отрисовке страницы
А фоксит когда-то необоснованно распух и начал тормозить при загрузке что тот акробат, вроде еще реклама появилась, тогда-то я его и выкинул.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vsb, Вы писали:
vsb>https://makepad.github.io/makepad/ vsb>Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро. Размер кода полмегабайта. Для мини-IDE на мой взгляд очень неплохо. vsb>ИМХО это то, что действительно можно называть Web 2.0. Не эволюционное развитие HTML/CSS/JavaScript, тянущееся с 90-х годов, а революционное, причём прекрасно работающее здесь и сейчас во всех браузерах, даже в Safari на айфоне. Наслаждайтесь взглядом в будущее.
Ого, вот это реально круто. Вообще несравнимо по скорости загрузки и работы с известными демками на Qt скомпилированной под JS. Правда тут и функционал GUI библиотечки пока очень ограниченный. Но думаю это только вопрос времени.
P.S. Я надеялся (и писал об этом на форуме) именно на такое развитие ситуации ещё несколько лет назад. JavaScript — пока, пока!
_>Ого, вот это реально круто. Вообще несравнимо по скорости загрузки и работы с известными демками на Qt скомпилированной под JS. Правда тут и функционал GUI библиотечки пока очень ограниченный. Но думаю это только вопрос времени.
И тогда скорость работы и загрузки будет такая же, как у известных демок на Qt. Магии не существует.
Здравствуйте, Pzz, Вы писали:
Pzz>Кстати, с другой машинки в фирефоксе запустилось, и скролируется достаточно шустренько, что в гуглохроме, что в фоксе. При том, что другая машинка объективно слабее первой.
А версии браузера какие на той и на этой?
Ещё может WebGL acceleration не работает на той где тормозит.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, bzig, Вы писали:
B>>А не мартышки для каждого сайта будут писать сначала свой HTML/CSS/JS, а потом уже сайт? Ну ок.
C>Зачем снова городить костыли
HTML/CSS довольно стройный подход, неоднократно скопированный на десктопных фрэймворках. Костылями эту связку называть как минимум неумно.
C>если можно без костылей?
Конечно, можно. Нагородить своих библиотек, только гордо не называть их костылями. Ну или вообще без библиотек, надо же куда-то девать всех джедаев, которые писали на ассемблере, только чтобы не пользоваться костылями в виде языков программирования.
Да и вообще, отказ от HTML/CSS будет катастрофой, во всяком случае для меня. Сейчас я могу копи/пастить с любой страницы, что хочу; менять отображение, масштаб, шрифты; дописывать свою функциональность через внедренные скрипты. Когда начнут рисовать напрямую в канвас, этому всему придёт конец. Будет как в эпоху десктопных приложений, что авторы не поленились сделать, только то и доступно.
Здравствуйте, bzig, Вы писали:
B>HTML/CSS довольно стройный подход, неоднократно скопированный на десктопных фрэймворках. Костылями эту связку называть как минимум неумно.
Это крайне жирный подход, из-за которого сейчас уже примитивный список пары десятков комментариев еле ворочается на топовом железе.
Не понимать этого — крайне неумно.
B>Сейчас я могу копи/пастить с любой страницы
Здравствуйте, vsb, Вы писали:
vsb>ИМХО это то, что действительно можно называть Web 2.0. Не эволюционное развитие HTML/CSS/JavaScript, тянущееся с 90-х годов, а революционное, причём прекрасно работающее здесь и сейчас во всех браузерах, даже в Safari на айфоне. Наслаждайтесь взглядом в будущее.
)
Господи, ему что, так никто и не рассказал про Java???????????????
Здравствуйте, Kolesiki, Вы писали:
K>Господи, ему что, так никто и не рассказал про Java???????????????
Ох млять не напоминай. Я на жабе писал в начале 2К, когда все носились с идеей жаба в браузере.
Не, нахрен!
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alex_public, Вы писали:
_>Ого, вот это реально круто. Вообще несравнимо по скорости загрузки и работы с известными демками на Qt скомпилированной под JS. Эти?
Здравствуйте, Mamut, Вы писали:
M>Каким образом из того, что wasm'ом можно отрисовать HTML (что?) следует легкость создания браузерного движка?
Он имеет в виду, что браузерный движок будет уметь только один тег canvas, а CSS не будет уметь вообще.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, se_sss, Вы писали:
_>Интересно, а чем это глобально отличается от апплетов, которые 20 лет назад умели что-то подобное же
Глобально отличается тем, что апплеты это внешняя программа, а Wasm это встроенный в браузер стандарт, реализованный в каждом браузере по отдельности. Ещё у апплетов была странная система безопасности, которая позволяла подписанному апплету иметь любые права в системе (фейсбук, который молча шуршит по диску, индексируя фотографии). Ещё у апплетов было столько уязвимостей, что все только вздохнули с облегчением, когда их наконец выкинули из браузеров.
А так по сути то же самое. Только, вроде бы, реализованное получше и в правильном открытом виде.
В>>Круто, конечно. Но почему до сих пор никто не заменил явускрипт на что-то более приличное? vsb>Ну дык я же линканул сайт, в котором явускрипт заменили на Rust.
Учитывая, что у WebAssembly нет доступа ни к чему внутри окна браузера, предлагаю самому догадаться, каким образом webassembly создает canvas и рисует не нем.
Здравствуйте, Mamut, Вы писали:
_>>Ого, вот это реально круто. Вообще несравнимо по скорости загрузки и работы с известными демками на Qt скомпилированной под JS. Правда тут и функционал GUI библиотечки пока очень ограниченный. Но думаю это только вопрос времени. M>И тогда скорость работы и загрузки будет такая же, как у известных демок на Qt. Магии не существует.
Вряд ли. Компиляция в wasm — это всё же по эффективности ближе к машинным кодам (особенно, когда они simd допилят), чем к JS. Да и Qt — это огромный жирный монстр родом из 90-ых, который добился звания лучшей GUI библиотеки исключительно экстенсивными методами (человеко-годами). Если строить новую GUI библиотеку на современных подходах, то это будет в разы более красивый и стройный результат.
Здравствуйте, Skorodum, Вы писали:
_>>Ого, вот это реально круто. Вообще несравнимо по скорости загрузки и работы с известными демками на Qt скомпилированной под JS. S>Эти?
И кстати QML приложения в wasm — это тоже несколько сомнительная идея на мой взгляд. Получается тот же самый подход (язык разметки + JS), просто другой реализации. Со всеми проблемами и тормозами такого подхода. Смысл тогда городить компиляцию в wasm и т.п. — проще тогда уж привычным html+js обойтись. А вот полноценная GUI библиотека, написанная на таких языках как C++ или Rust, и скомпилированная в wasm — это будет совсем другой уровень работы. Собственно обсуждаемая демка из первого сообщения это отлично демонстрирует.
Здравствуйте, se_sss, Вы писали:
_>Интересно, а чем это глобально отличается от апплетов, которые 20 лет назад умели что-то подобное же
Идея буквально та же, а вот реализация на порядки лучше:
1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java).
2. Исполняющей VM создаётся гарантированная песочница, полностью отрезающая wasm код от остальной части исполняющего процесса (в отличие от апплетов с их неадекватными политиками безопасности).
3. Это разработка консорциума всех "браузеров", так что по сути это официальный новый стандарт, поддерживаемый всеми современными браузерами на уровне внутренности движка (а не как некий внешний плагин, который ещё ставить отдельно надо, как было у апплетов).
Здравствуйте, student__, Вы писали:
__>А теперь объясни, что это за сайтик такой с исходниками на расте, и в каком месте надо восхищаться.
Восхищаться надо тем, что этот сайтик целиком работает без использования богомерзких html/js/css. Т.е. не то, что он просто написан каким-то другим инструментом (типа GWT) и потом транслируется в html/js/css, а вообще тут таких сущностей нет в природе (ну не считая стандартной заглушки, грузящей wasm), даже прямо у тебя в браузере.
Здравствуйте, bzig, Вы писали:
C>>Это крайне жирный подход, из-за которого сейчас уже примитивный список пары десятков комментариев еле ворочается на топовом железе.
B>Ну брешешь же.
Здравствуйте, vsb, Вы писали:
vsb>А так по сути то же самое. Только, вроде бы, реализованное получше и в правильном открытом виде.
Еще у апплетов была крупная проблема с версиями стандартных библиотек, которые устанавливались только как единый пакет на уровне системы, а скачать нужные библиотеки с сервера — ни-ни.
Здравствуйте, alex_public, Вы писали: _>Восхищаться надо тем, что этот сайтик целиком работает без использования богомерзких html/js/css. Т.е. не то, что он просто написан каким-то другим инструментом (типа GWT) и потом транслируется в html/js/css, а вообще тут таких сущностей нет в природе (ну не считая стандартной заглушки, грузящей wasm), даже прямо у тебя в браузере.
*trollmode* А что если взять sciter и писать приложения с его помощью?
Здравствуйте, alex_public, Вы писали:
_>1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java).
На любых клонах Си.
Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.
(только про Blazor не надо, там интерпретатор байткода из моно, без джита, в 50 раз медленнее обычного дотнета)
Здравствуйте, D. Mon, Вы писали:
DM>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.
Я думаю, они сделают опциональный сборщик мусора на уровне VM.
Здравствуйте, student__, Вы писали:
__>Т.e. я правильно понимаю, что backend и frontend написаны на одном единственном языке?
Думаю да, но это тут не самое интересное. Такое можно было давно делать. И на JavaScript писать бэкэнд и кучу языков, например Java транслировать во фронтэнд. По-моему особого профита от такого подхода нет. Слишком мало общего кода между бэкэндом и фронтэндом.
DM>>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.
vsb>Я думаю, они сделают опциональный сборщик мусора на уровне VM.
Опциональный сборщик мусора, одинаковый для всех языков с GC, которые будут компилироваться в WebAssembly? Маловероятно.
Здравствуйте, D. Mon, Вы писали:
_>>1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java). DM>На любых клонах Си. DM>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm. DM>(только про Blazor не надо, там интерпретатор байткода из моно, без джита, в 50 раз медленнее обычного дотнета)
Про Blazor ничего не знаю (хотя какая связь gc и jit непонятно), а вот например Питон без проблем работает в wasm: https://github.com/iodide-project/pyodide. Вот https://alpha.iodide.io/notebooks/300/ живая демка научного блокнотика, исполняемого прямо в браузере. Более того, они там прикрутили уже и работу с DOM (понятное дело, что пока оно внутри работает через вызовы JS).
M>>И тогда скорость работы и загрузки будет такая же, как у известных демок на Qt. Магии не существует. V>Существует кеширование/переиспользование кода (библиотек).
Оно и сейчас «существует». Как видно, особо не помогает.
DM>>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm. vsb>Я думаю, они сделают опциональный сборщик мусора на уровне VM.
Каждый раз практически в любых разговорах про WebAssembly поражает насколько нихера люди не знают про предмет обсуждения. Не только на РСДН, кстати.
Языки без GC не спешат компилиться в wasm, вы все не поверите, потому что в wasm'е нет поддержки GC (это так же причина, почему в wasm'е нет доступа к DOM'у и нормальной интеграции с JS). Дотнетовский Blazor, компилирующийся в wasm, сначала грузит в браузер половину реализации дотнета, включая GC, а потом грузит приложения. Понятно, что никому это даром не надо.
Здравствуйте, Mamut, Вы писали:
M>Языки без GC не спешат компилиться в wasm, вы все не поверите, потому что в wasm'е нет поддержки GC
Здесь то ли не хватает слов, то ли наоборот есть лишние. Меня всегда поражает, насколько люди нихера не могут выразить свои мысли, а потом негодуют, что их не поняли.
Здравствуйте, alex_public, Вы писали:
_>Идея буквально та же, а вот реализация на порядки лучше:
_>1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java). _>2. Исполняющей VM создаётся гарантированная песочница, полностью отрезающая wasm код от остальной части исполняющего процесса (в отличие от апплетов с их неадекватными политиками безопасности). _>3. Это разработка консорциума всех "браузеров", так что по сути это официальный новый стандарт, поддерживаемый всеми современными браузерами на уровне внутренности движка (а не как некий внешний плагин, который ещё ставить отдельно надо, как было у апплетов).
И чтобы принять необходимость этого, договориться и начать что-то делать в этом направлении понадобилось 20 лет
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vsb, Вы писали:
vsb>https://makepad.github.io/makepad/
vsb>Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро.
IE11
cx_webgl.js (10,5) Syntax error.
Могло бы быть альтернативой флешу, но нет, на ослике не работает.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Kolesiki, Вы писали:
K>>Господи, ему что, так никто и не рассказал про Java???????????????
vsb>Куда тыкать, чтобы запустить Java на айфоне?
эээ... в мозг? Хотя постой... разве он есть у владельцев Эппл-продукции?
В моём понимании вещи, производимые в Apple не имеют отношения к повседневной ИТ-технике. Это просто технологические "гаджеты", аксессуары, что-то вроде Vertu — ну то есть он является как бы телефоном (как и айфон), но физически служит не более, чем дорогущей пустышкой. В которой ты ещё и "никто", потому что за тебя там всё уже решили — что тебе инсталлировать, что слушать, как тыкать, как держать... Разве адекватный человек такое купит?
M>>Языки без GC не спешат компилиться в wasm, вы все не поверите, потому что в wasm'е нет поддержки GC
C>Здесь то ли не хватает слов, то ли наоборот есть лишние. Меня всегда поражает, насколько люди нихера не могут выразить свои мысли, а потом негодуют, что их не поняли.
Все слова на месте. Ты сядь. Почитай вдумчиво. Авось, поймешь. Можешь вслух прочитать, это помогает.
Здравствуйте, alex_public, Вы писали:
_>А вот полноценная GUI библиотека, написанная на таких языках как C++ или Rust, и скомпилированная в wasm — это будет совсем другой уровень работы.
Чем отличается полноценная библиотека от неполноценной?
Здравствуйте, alex_public, Вы писали:
_>1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java).
Под JVM тоде много всяких языков.
_>2. Исполняющей VM создаётся гарантированная песочница, полностью отрезающая wasm код от остальной части исполняющего процесса (в отличие от апплетов с их неадекватными политиками безопасности).
В апплетах точно такая же песочница.
_>3. Это разработка консорциума всех "браузеров", так что по сути это официальный новый стандарт, поддерживаемый всеми современными браузерами на уровне внутренности движка (а не как некий внешний плагин, который ещё ставить отдельно надо, как было у апплетов).
Здравствуйте, Masterspline, Вы писали:
M>Опциональный сборщик мусора, одинаковый для всех языков с GC, которые будут компилироваться в WebAssembly? Маловероятно.
Здравствуйте, Mamut, Вы писали:
M>>>И тогда скорость работы и загрузки будет такая же, как у известных демок на Qt. Магии не существует. V>>Существует кеширование/переиспользование кода (библиотек). M>Оно и сейчас «существует». Как видно, особо не помогает.
Ну так ты вникни.
Если идёт обращение к одному и тому же ресурсу, где расположено некоторое тяжеловесное приложение, то с кешированием ноу проблема — долго грузиться оно будет лишь однажды.
ИМХО, функциональность кеша будут еще допиливать, чтобы кешировать в том числе уже скомпиллированные бинарные образы.
Здравствуйте, vsb, Вы писали:
DM>>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm.
vsb>Я думаю, они сделают опциональный сборщик мусора на уровне VM.
У wasm-апплета память — это линейный массив байтов. Про то, как в ней апплет размещает свои объекты, как делает кучу, как освобождает куски и т.д. — VM про это ничего не знает. Где там указатели, а где числа и строки — тоже. Разные нативные языки делают это очень по-разному. При желании можно сделать какой-то GC, который будет управлять такой кучей и знать про ее структуру, но тогда разные языки надо будет специально сильно переделывать внутри, чтобы они могли использовать это фиксированное представление объектов и указателей. Получится как в JVM, когда одни языки (клоны джавы) легко на нее ложатся, а некоторые другие — с большим скрипом.
Здравствуйте, Codealot, Вы писали:
DM>>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей?
C>shadow stack
Да, пока это первое, что приходит на ум. Но это требует серьезной переделки рантайма для некоторых нативных языков. Реализуемо, просто затратно, еще одно препятствие.
Здравствуйте, Ops, Вы писали:
_>>Идея буквально та же, а вот реализация на порядки лучше: _>>1. Выбран низкоуровненый байткод (типа llvm), позволяющий писать под него код на любых языках программирования (а не как у апллетов, привязанных к Java). _>>2. Исполняющей VM создаётся гарантированная песочница, полностью отрезающая wasm код от остальной части исполняющего процесса (в отличие от апплетов с их неадекватными политиками безопасности). _>>3. Это разработка консорциума всех "браузеров", так что по сути это официальный новый стандарт, поддерживаемый всеми современными браузерами на уровне внутренности движка (а не как некий внешний плагин, который ещё ставить отдельно надо, как было у апплетов). Ops>И чтобы принять необходимость этого, договориться и начать что-то делать в этом направлении понадобилось 20 лет
На самом деле в это время были ещё другие конкурирующие попытки (ActiveX например, Silverlight и т.п.) и пока они ещё были живы, договориться было трудновато. А вот как только их трупики окончательно застыли, то... )))
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>А вот полноценная GUI библиотека, написанная на таких языках как C++ или Rust, и скомпилированная в wasm — это будет совсем другой уровень работы. НС>Чем отличается полноценная библиотека от неполноценной?
Неполноценная — это построенная поверх html+js. ) Ну если это конечно не решение типа прорисовки всего самостоятельно с помощью WebGL.
Здравствуйте, Ночной Смотрящий, Вы писали:
M>>Опциональный сборщик мусора, одинаковый для всех языков с GC, которые будут компилироваться в WebAssembly? Маловероятно. НС>https://github.com/WebAssembly/proposals/issues/16 НС>Без GC не получится дать прямой доступ к DOM, а без этого wasm так и останется очередной реинкарнацией апплетов.
Вообще говоря, если не требуется особое быстродействие (т.е. wasm используется только для того, чтобы привнести на браузерную платформу нормальный язык), то вполне достаточно и не прямого доступа к DOM: https://alpha.iodide.io/notebooks/300/ — может там повыполнять команды в блокнотике слева и будут изменения в DOM справа.
Но на мой взгляд вообще вся эта тема с DOM является тупиковой, в случае если мы обсуждаем реальное приложение (пускай и web), а не просто сайтик. И как раз изначальный обсуждаемый пример отлично это демонстрирует. От браузера требуется только предоставить WebGL поверхность и захват пользовательского ввода, а всё остальное должна делать современная GUI библиотека, без всяких HTML DOM.
Здравствуйте, D. Mon, Вы писали:
_>> например Питон без проблем работает в wasm DM>Интерпретаторам проще. Проще некуда. Это ж просто сишная программа. Сложно нативно компилируемым языкам, которые хотят быть эффективными.
Если требуется именно эффективность, то всё равно не вижу смысла брать что-то помимо C/C++ или Rust (в будущем). А если эффективность не важна, то тогда уж лучше сразу взять Питон, для максимальной скорости разработки. )
Здравствуйте, Masterspline, Вы писали:
M>Kotlin Native вполне себе может в WebAssembly. И там GC (а не просто ARC, как в Swift).
О, спасибо. Только не понял отличия от Свифта. В Kotlin Native тоже подсчет ссылок плюс сборка оставшихся циклов (как в питоне каком). Чтобы стек не сканировать, они указатели на стеке не размещают, а фреймы функций в куче живут, если я правильно понял. В принципе, вполне разумный подход в рамках ограничений wasm. Интересно на скорость посмотреть. Нативный Kotlin Native очень медленный был, намного хуже JVM-ного.
Здравствуйте, vsb, Вы писали:
vsb>https://makepad.github.io/makepad/
vsb>Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро. Размер кода полмегабайта. Для мини-IDE на мой взгляд очень неплохо.
Штука — огонь. Смешивать её и HTML5/Ангула можно? Это же можно напилить часть UI стандартно, а часть через WASM.
M>>Kotlin Native вполне себе может в WebAssembly. И там GC (а не просто ARC, как в Swift).
DM>О, спасибо. Только не понял отличия от Свифта.
GC в Kotlin Native умеет собирать циклические ссылки, а Swift нет.
Насчет скорости. Kotlin Native ориентировали для написания прикладных приложений, в первую очередь как замена Swift на iOS. Там скорость работы не приоритет (в разумных пределах). Поэтому для написания серверных приложений лучше использовать вариант Kotlin JRE. Например, их Ktor, асинхронный клиент и сервер для Web, не умеет работать на сервере в варианте Native, может только клиентом быть, а JRE вариант может быть и сервером и клиентом.
M>>Опциональный сборщик мусора, одинаковый для всех языков с GC, которые будут компилироваться в WebAssembly? Маловероятно.
НС>https://github.com/WebAssembly/proposals/issues/16
НС>Без GC не получится дать прямой доступ к DOM, а без этого wasm так и останется очередной реинкарнацией апплетов.
Спасибо за ссылку. Теперь я понимаю, про какой GC ты говоришь.
Здравствуйте, Mamut, Вы писали:
M>>>Языки без GC не спешат компилиться в wasm, вы все не поверите, потому что в wasm'е нет поддержки GC
M>Все слова на месте. Ты сядь. Почитай вдумчиво. Авось, поймешь. Можешь вслух прочитать, это помогает.
Хороший совет, попробуй применить на практике.
Дам подсказку — каким образом отсутствие GC может помешать языкам, которым GC и не нужен?
Здравствуйте, Masterspline, Вы писали:
M>Насчет скорости. Kotlin Native ориентировали для написания прикладных приложений, в первую очередь как замена Swift на iOS. Там скорость работы не приоритет (в разумных пределах).
Я так понимаю, там просто у них еще руки не дошли заняться оптимизацией, первая задача была — чтобы хоть как-то заработало. Потом если дойдут руки, займутся и скоростью.
Здравствуйте, alex_public, Вы писали:
_>Ого, вот это реально круто. Вообще несравнимо по скорости загрузки и работы с известными демками на Qt скомпилированной под JS. Правда тут и функционал GUI библиотечки пока очень ограниченный. Но думаю это только вопрос времени.
Нифига не круто. Только что выглядит получше чем AWT 1.0, или на чем там рисовали в 90-е, но тут надо учесть что железо стало круче на порядок.
Поразительное хождения по одним и тем же граблям в течении десятков лет. Это не Web 2.0, a апплеты 2.0 с абсолютно одинаковыми проблемами:
a) Медленно, очень медленно. Так медленно, что пользоваться нельзя от слова совсем и это на демке. Для реализации на нативном языке — позор.
б) Wеb-инфраструктура потеряна: хороших урлов нет, поиска нет, шорткаты не работают, скрэпинг не работает, кроулеры не индексирует
Но теперь есть еще и новая проблема: все преписывать на языках без gc и просадить продуктивность на порядок. Если что я знаю про блейзер, но тащить громадную и скорее всего плохо совместимую VM по проводу не есть гуд.
P.S. Последнее "круто", которое было в вебе у меня до сих пор гуглмэпс.
Здравствуйте, novitk, Вы писали:
N>a) Медленно, очень медленно. Так медленно, что пользоваться нельзя от слова совсем и это на демке. Для реализации на нативном языке — позор.
Что именно медленно? У меня всё потрясающе быстро и плавно. Причём даже на слабом андроиде, что особенно поразило. На котором тот же РСДН тормозит больше, чем этот редактор. Может у тебя тоже проблемы с драйверами? Собственно скорость меня тут и поразила. Я такую скорость в нативных приложениях далеко не всегда встречаю, а в вебе и подавно.
N>б) Wеb-инфраструктура потеряна: хороших урлов нет, поиска нет, шорткаты не работают, скрэпинг не работает, кроулеры не индексирует
Ничего не потеряно, всё на месте. Урлы прикручивай как душе угодно, апи никуда не девалось. Шорткаты прикручивай какие угодно. Кроулеры приложениям не нужны.
N>Но теперь есть еще и новая проблема: все преписывать на языках без gc и просадить продуктивность на порядок.
Зачем тебе переписывать на языках без GC? Пиши на чём угодно. Это же возможность, а не обязательство.
Здравствуйте, vsb, Вы писали:
vsb>Что именно медленно? У меня всё потрясающе быстро и плавно. Причём даже на слабом андроиде, что особенно поразило.
Слабом андроиде? Как ты там скорость мерил без клавы? Ессно с деревом все нормально, там рендерить нечего, а вот клавометания по файлу тормозят.
Google Chrome 78.0.3904.87 (Official Build) (32-bit)
Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz 6
64GB
Графическая карта говно(NVidia NVS 310), но это же не Fortnight.
vsb>На котором тот же РСДН тормозит больше, чем этот редактор. Может у тебя тоже проблемы с драйверами? Собственно скорость меня тут и поразила. Я такую скорость в нативных приложениях далеко не всегда встречаю, а в вебе и подавно.
РСДН не тормозит, N++ не тормозит, Sublime не тормозит, Емакс не тормозит, IntelliJ не тормозит.
N>>Но теперь есть еще и новая проблема: все преписывать на языках без gc и просадить продуктивность на порядок. vsb>Зачем тебе переписывать на языках без GC? Пиши на чём угодно. Это же возможность, а не обязательство.
Затем, что если раст в демке тормозит, то что тогда говорить о Яве.
K>>Штука — огонь. Смешивать её и HTML5/Ангула можно? Это же можно напилить часть UI стандартно, а часть через WASM.
M>Нельзя. У wasm'а нет доступа к DOM'у
А если встроить его в html через тэг вроде <wasm></wasm>? Я далёк от всего этого, но всякие видео плееры или интерактивные графики было бы очень круто делать через васм когда остальной UI рисуется старндартным способом. У васм есть доступ к кодекам браузера, например, или к апи шифрования и т.п.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Неполноценная — это построенная поверх html+js. НС>В чем неполноценность js+html?
JS+HTML — это вообще не GUI библиотека. Основная GUI библиотека в браузере — это грубо говоря большая часть DOM. По сути это абсолютно классическая ОПП библиотека, написанная на C++ (на все эти классы в стиле MFC можно легко глянуть например в исходниках Хрома). Но у неё есть два существенных отличия:
1. Дикая бедность. В этой библиотеке контролов выбор намного меньше, чем в какой-нибудь TurboVision под DOS!
2. Доступ к библиотеке ограничен убогими html+js. Точнее HTML убогий естественно не сам по себе, а именно в применение для создания GUI, т.к. изначально он создавался совсем для другого (презентации научных отчётов, ну и в современности отлично подходит для статических сайтов).
В сочетание этих факторов получаем современный ад в разработке под браузер. Базовых возможностей естественно никому не хватает и каждый пилит свой велосипед, причём убогими средствами (html+js). В итоге получаем современных зоопарк уродцев, меняющихся каждый год — уже давно даже разбираться лень, кто в этом году считается наименее уродливым...
Здравствуйте, novitk, Вы писали:
_>>Ого, вот это реально круто. Вообще несравнимо по скорости загрузки и работы с известными демками на Qt скомпилированной под JS. Правда тут и функционал GUI библиотечки пока очень ограниченный. Но думаю это только вопрос времени. N>Нифига не круто. Только что выглядит получше чем AWT 1.0, или на чем там рисовали в 90-е, но тут надо учесть что железо стало круче на порядок. N>Поразительное хождения по одним и тем же граблям в течении десятков лет. Это не Web 2.0, a апплеты 2.0 с абсолютно одинаковыми проблемами: N>a) Медленно, очень медленно. Так медленно, что пользоваться нельзя от слова совсем и это на демке. Для реализации на нативном языке — позор.
А где конкретно медленно? Я там особо не тестировал специально, так, полазил немного. Но вроде ни единого торможение не увидел. Может у тебя там тоже с OpenGL проблемы (например сидишь под Линухом и не ставил родные драйверы от карты)?
N>б) Wеb-инфраструктура потеряна: хороших урлов нет, поиска нет, шорткаты не работают, скрэпинг не работает, кроулеры не индексирует
Так оно вроде не для обычных сайтиков, а для приложений...
N>Но теперь есть еще и новая проблема: все преписывать на языках без gc и просадить продуктивность на порядок. Если что я знаю про блейзер, но тащить громадную и скорее всего плохо совместимую VM по проводу не есть гуд.
Как насчёт продуктивности скажем Питона? Он уже без проблема доступен в браузере именно через wasm...
Здравствуйте, Kernan, Вы писали:
K>>>Штука — огонь. Смешивать её и HTML5/Ангула можно? Это же можно напилить часть UI стандартно, а часть через WASM. M>>Нельзя. У wasm'а нет доступа к DOM'у K>А если встроить его в html через тэг вроде <wasm></wasm>? Я далёк от всего этого, но всякие видео плееры или интерактивные графики было бы очень круто делать через васм когда остальной UI рисуется старндартным способом. У васм есть доступ к кодекам браузера, например, или к апи шифрования и т.п.
Ой, да есть там весь доступ (wasm код может вызывать любую js функцию на странице и наоборот, можно вызывать wasm функции из js), только он пока не прямой (типа нормального нативного API, в стиле CreateWindow в WIN32), а через вызов функций JS. Именно это имел в виду Mamut. Ну и да, это плохо для случая потребности высокой производительности таких вызывов. Но если таких требований нет, то всё отлично работает и прямо сейчас. Я же кидал уже ссылку на пример.
Правда лично я считаю, что лучше бы полностью забывать про html и js (оставим им нишу статических сайтов) для подобных веб-приложений и рисовать целиком всю область экрана только через WebGL (как и сделано в обсуждаемом примере).
Здравствуйте, alex_public, Вы писали:
_>>>Неполноценная — это построенная поверх html+js. НС>>В чем неполноценность js+html? _>JS+HTML — это вообще не GUI библиотека.
Почему?
_> Основная GUI библиотека в браузере — это грубо говоря большая часть DOM.
Что в лоб, что по лбу.
_>1. Дикая бедность. В этой библиотеке контролов выбор намного меньше, чем в какой-нибудь TurboVision под DOS!
Это не так. Контролы вполне себе пишутся на JS на основе готовых примитивов.
_>2. Доступ к библиотеке ограничен убогими html+js.
Пошли по кругу. Почему он убогий?
_> Точнее HTML убогий естественно не сам по себе, а именно в применение для создания GUI, т.к. изначально он создавался совсем для другого
Это неважно для чего он создавался изначально, и не является ответом на заданный вопрос.
_>В сочетание этих факторов получаем современный ад в разработке под браузер.
В чем состоит этот ад?
_> Базовых возможностей естественно никому не хватает и каждый пилит свой велосипед
Количество велосипедов в итоге не так уж велико и сократилось до angular/react/vue.
_>, причём убогими средствами (html+js)
Они убоги потому что они убоги. Отличный ответ.
_>. В итоге получаем современных зоопарк уродцев
Здравствуйте, alex_public, Вы писали:
_>А где конкретно медленно? Я там особо не тестировал специально, так, полазил немного. Но вроде ни единого торможение не увидел. Может у тебя там тоже с OpenGL проблемы (например сидишь под Линухом и не ставил родные драйверы от карты)?
Текстовый редактор конечно, там больше и нет ничего. Винда, нормальное железо, видеокарта не топ.
_>Так оно вроде не для обычных сайтиков, а для приложений...
Граница имхо довольно тонкая. Например много умельцев сделают на этом таблички, которые будут красиво выглядеть и возможно даже быстро ездить, только в них будет не работать поиск, зум или буффер обмена, как у этого чуда.
_>Как насчёт продуктивности скажем Питона? Он уже без проблема доступен в браузере именно через wasm...
ppci? Никак, это наколенная поделка, которая такой и останется пока нет доступа к DOM-u.
_>>1. Дикая бедность. В этой библиотеке контролов выбор намного меньше, чем в какой-нибудь TurboVision под DOS! НС>Это не так. Контролы вполне себе пишутся на JS на основе готовых примитивов.
Каких таких примитивов?
_>>2. Доступ к библиотеке ограничен убогими html+js.
НС>Пошли по кругу. Почему он убогий?
Браузеры предоставляют только одну модель: однослойное 2D-окно с некоторыми хаками эмуляции многослойности (z-index, float и position: absolute/fixed). И все — в едином глобальном пространстве. Для создания банального модального диалога.
То есть даже такая простая операция, как «показать модальный диалог с анимацией при открытии и закрытии» становится танцами с бубном.
M>>Нельзя. У wasm'а нет доступа к DOM'у K>А если встроить его в html через тэг вроде <wasm></wasm>?
Что значит «встроить»? wasm выполняется в отдельном процессе, и у него нет ничего, кроме собственно выполнения кода. Весь доступ к окну браузера происходит через JS-заглушки.
K>У васм есть доступ к кодекам браузера, например, или к апи шифрования и т.п.
Здравствуйте, novitk, Вы писали:
N>a) Медленно, очень медленно. Так медленно, что пользоваться нельзя от слова совсем и это на демке. Для реализации на нативном языке — позор.
Что именно медленно? Я ничего медленного не заметил.
N>б) Wеb-инфраструктура потеряна: хороших урлов нет, поиска нет, шорткаты не работают, скрэпинг не работает, кроулеры не индексирует
Что нифига не мешает повальному распространению SPA.
N>Но теперь есть еще и новая проблема: все преписывать на языках без gc и просадить продуктивность на порядок.
Здравствуйте, 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>Откуда доступ к кодекам у ютуб плеера? Вот оттуда и васм должен получать.
Здравствуйте, 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 бинарников.
Восхитительно. Живо представил в каком-нибудь гуе диалоговое окно типа "Вы действительно хотите удалить эту запись?" и три кнопки с вариантами ответа: "Может быть", Скорее всего", и третья кнопка вообще без надписи
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, alex_public, Вы писали:
__>>А теперь объясни, что это за сайтик такой с исходниками на расте, и в каком месте надо восхищаться. _>Восхищаться надо тем, что этот сайтик целиком работает без использования богомерзких html/js/css.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Не, я как раз предпочитаю вообще накидать контролы в графическом редакторе, который потом сгенерирует мне описание GUI (не важно в каком формате) НС>И неважно, что прощай адаптивная верстка, ага
Лейаут панели уже отменили?
Вычисляемые св-ва тоже?
Здравствуйте, vsb, Вы писали:
DM>>Они отделили стек от "памяти", как теперь языкам с GC сканировать стек на предмет указателей? Кажися, это одна из причин, почему языки с GC пока не спешат компилиться в wasm. vsb>Я думаю, они сделают опциональный сборщик мусора на уровне VM.
Для точного GC нужна метаинформация — разметка объектов в памяти и разметка переменных в стеке.
Это, в свою очередь, вешает гири на ноги оптимизаторам, которые могли бы ликвидировать переменные во фрейме стека и вообще сами фреймы, поля в объектах и даже целые объекты. Тем более, что llvm не мыслит категориями объектов.
Похоже, на подобный шаг они не готовы и вряд ли когда будут готовы.
Т.е. под wasm придётся накатать свой дотнет и свою джаву.
Т.е., получается возврат к тому, от чего пытались убежать, только теперь в еще более глупом исполнении, при взгляде с высоты птичьего полёта на получившийся "пирог" технологий.
Здра моя ра...
Унутре весь DOM живёт на счётчиках ссылок.
Поэтому, тот же Swift, Object-C, С++, Rust могут юзать его как родной.
Питоны, перлы, VB — аналогично.
Минимальная инфраструктура со "своей" VM джавы/дотнета — тоже.
Здравствуйте, D. Mon, Вы писали:
DM>Интерпретаторам проще. Проще некуда. Это ж просто сишная программа. Сложно нативно компилируемым языкам
А в чём сложность?
В любых браузерах объекты DOM — это нейтивные объекты со счётчиком ссылок или хендлы с сопровожающим АПИ, через который можно сообщить о том, что хендл более не используется.
Здравствуйте, vdimas, Вы писали:
DM>>Интерпретаторам проще. Проще некуда. Это ж просто сишная программа. Сложно нативно компилируемым языкам
V>А в чём сложность? V>В любых браузерах объекты DOM — это нейтивные объекты со счётчиком ссылок или хендлы с сопровожающим АПИ, через который можно сообщить о том, что хендл более не используется.
Я не про DOM. Я про сложность нормально компилировать в wasm нативные языки с GC, т.к. нельзя сканировать стек.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Что значит не так, если ты прямо в следующем предложение подтверждаешь, что их надо писать руками? НС>Странный ты. Если ты используешь библиотеку, то писать руками не надо.
Писать новые контролы? Ну иногда бывает, но это скорее исключение, чем практика. В то время как под браузер даже базовое приложение не сделаешь без этого.
_>>Ну как бы и на фреймбуфере голом тоже можно писать любые контролы — он этого стал 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>>Но это же чистая религия. _>А если я скажу, что мне больше нравится кататься на мерседесе, чем на запорожце, то это тоже будет чистая религия? )))
Если ты скажешь, что «Запорожец» богомерзкий, а катающимися на «Мерседесе» надо восхищаться — да.
Здравствуйте, 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 и с прицелом на это создавался. _>Если бы это было так, то не существовало бы множества библиотек под браузер, добавляющих к нему самые базовые контролы
Зачем?
_>И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое.
Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок.
_>>> и с тех пор у него почти не появилось ничего нового в этой области. НС>>Это вранье. _>Ну давай, расскажи о колоссальном прогрессе у HTML в области GUI... )))
Возьми спеку HTML5 и почитай.
НС>>Или не будет. По факту реакту уже 6 лет и своей актуальности он не потерял, а vue принципиально от него не отличается. _>Надейся, надейся. )
Да мне пофигу, в моих проектах фронта не очень много, мне пока одного фронтендера за глаза. Ну будет вместо реакта чего еще — ради бога.
_> Кстати, помнится самым мощным GUI фреймворком для приложений (а не для сайтиков!) был ExtJS — и что это ты её не упомянул, а? )
ExtJS это как раз от таких как ты любителей старого подхода. Потому и сдох. Реакт сильно лучше.
_>>>Помнится у нас использовалась библиотечка Bootstrap, чтобы расширить убогий набор контролов, предоставляемых DOM. НС>>И что? _>Это я так сказать пояснил, в какой степени я в курсе данной области. )))
Да это и без пояснений понятно.
_>>> Да и изнутри всё это выглядит крайне уродливо НС>>Что именно там выглядит уродливо? Хотя и так понятно, что ты ответить не сможешь. _>Вот как будто бы ты сам не видел внутренности всех этих html/css/js фреймворков.
Видел. Ничего космического там нет.
_> На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты!
С точностью до наоборот.
_> Хуже чем эти JS фреймворки, наверное только PHP фреймворки (в которых опять же есть html/css/js)...
В любом случае, в чистом нейтиве бывают только пессимистичные 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.
Здравствуйте, 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.
_>>И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое.
НС>Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок.
Нифига оно не реализуется «прекрасно». Сложность создания новых компонентов зашкаливает все разумные пределы. Собственно, это и етс одна из причин, что подавляющее большинство «компонентных библиотек» максимум осиливают табы и «аккордионы», а все, что сложнее, обычно стоит невменяемыхденег.
Здравствуйте, rFLY, Вы писали:
FLY>Здравствуйте, alex_public, Вы писали:
_>>Не, ну у меня конечно же топовый комп и видеокарта, а браузер Firefox. Но всё равно по идее не должно быть такой разницы. В разы — да. Но не в десятки или сотни раз! FLY>Ну чёрт его знает, может он часть вычислений/прорисовку на видюху переводит и встроенное граф.едро от интела этого не поддерживает.
UPDT: Дома глянул, опять же на ноуте и опять же кор ай 5, но 8 поколения. Разницы с обычным хтмл по загрузке проца нет.
Здравствуйте, Mamut, Вы писали:
НС>>Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок. M>Нифига оно не реализуется «прекрасно». Сложность создания новых компонентов зашкаливает все разумные пределы.
Это потому что ты не делал контролы для классических библиотек.
Здравствуйте, Codealot, Вы писали:
_>>Вот как будто бы ты сам не видел внутренности всех этих html/css/js фреймворков. На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты! Хуже чем эти JS фреймворки, наверное только PHP фреймворки (в которых опять же есть html/css/js)... C>Пощупав недавно эти "чудеса дизайна", подумалось — а не пора ли просто отправить html/css на помоечку, и сделать фреймворк на одних плавающих дивах и абсолютном позиционировании?
Ну собственно рисование всего через canvas (не важно из wasm или js) — это и есть конечная точка этого направления. Правда при этом возникают проблемы с поиском, но это актуально только для классических сайтов, а не для веб-приложений.
M>>Нифига оно не реализуется «прекрасно». Сложность создания новых компонентов зашкаливает все разумные пределы. НС>Это потому что ты не делал контролы для классических библиотек.
Что такое «классические библиотеки»? На дворе 2019-й год. Набор примитивов для веба сейчас хуже и беднее, чем Дельфи или там Qt образца 2000-го.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Странный ты. Если ты используешь библиотеку, то писать руками не надо. _>>Писать новые контролы? Ну иногда бывает, но это скорее исключение, чем практика. НС>Ровно как и в современном вебе.
Даа? Ну покажи какой объём кода на чистом JS (без всяких дополнительных библиотек) тебе понадобится, чтобы реализовать банальное меню.
НС>>>Ну так голый HTML+JS это тоже не библиотека. _>>Я именно про это и говорю. GUI библиотека браузера — это DOM (во всяком случае большая его часть). НС>Так библиотека или не библиотека, ты уж определись.
Повторяюсь последний раз:
DOM — это слабенькая GUI библиотека (написанная на C++).
HTML/CSS/JS — это единственный (и кривой) интерфейс к ней.
Плюс к этому всему, JS — это единственное (и крайне убогое) средство расширения этой библиотеки.
НС>>>Для целей GUI современный JS, а тем более TS вполне адекватны. _>>Угу, особенно на нём хорошо выходит делать классические расширяемые с помощью ООП иерархий библиотеки... ))) НС>А зачем на нем делать классические библиотеки?
Потому что ООП подход — это пока лучшее, что придумали в отрасли, для задач модульности и расширяемости.
_>>>>HTML хорош для создания документов, но не для создания GUI. НС>>>HTML5 вполне подходит для создания GUI и с прицелом на это создавался. _>>Если бы это было так, то не существовало бы множества библиотек под браузер, добавляющих к нему самые базовые контролы НС>Ровно как существует множество библиотек под С++, добавляющих ...
Причём тут вообще C++? ) Мы говорим про GUI библиотеки, а они точно не входят в стандарт C++. А вот в стандарте HTML5 GUI часть вполне имеется, но крайне убогая.
_>>Вот что мешало записать хотя бы эти https://getbootstrap.com/docs/4.3/components контролы в HTML5 НС>Зачем?
Что бы на HTML5 можно было делать приличный GUI (ты же говорил, что это была одна из целей! ), без дополнительных диких библиотек.
_>>И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое. НС>Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок.
Так вообще всё реализуется прикладным кодом. У нас же есть canvas и js — больше по идее ничего не надо! Зачем тогда в html насовали всяких там button, editbox (input), listbox (select) и т.п...
_>>Ну давай, расскажи о колоссальном прогрессе у HTML в области GUI... ))) НС>Возьми спеку HTML5 и почитай.
Вот кстати как раз это я и делал в момент выхода html5. И тогда она меня в принципе порадовала. Только вот дальше развитие пошло совсем не туда. Точнее там просто нет никакого развития с точки зрения html, а всё пошло в js. А html так и остался убогеньким с точки зрения GUI.
НС>>>Или не будет. По факту реакту уже 6 лет и своей актуальности он не потерял, а vue принципиально от него не отличается. _>>Надейся, надейся. ) НС>Да мне пофигу, в моих проектах фронта не очень много, мне пока одного фронтендера за глаза. Ну будет вместо реакта чего еще — ради бога.
Хы, у нас "фронтенда" нет вообще, в тех продуктах, которые покупают пользователи. Однако у нас есть свои сайты, которые мы делаем и обслуживаем сами (хотя это несколько не наш профиль), а не заказываем аутсорсом кому-то. Поэтому приходится в этом более менее разбираться, так сказать для внутренних целей.
_>> Кстати, помнится самым мощным GUI фреймворком для приложений (а не для сайтиков!) был ExtJS — и что это ты её не упомянул, а? ) НС>ExtJS это как раз от таких как ты любителей старого подхода. Потому и сдох. Реакт сильно лучше.
Очень забавно эта твоя фраза звучит, на фоне факта продаж (причём за очень приличные деньги) такого продукта как ExtReact. Кстати, а ещё у них там есть ExtAnglular...
И кто-то там ещё заикался о слабом знание темы или любителях старых подходов...
_>>Вот как будто бы ты сам не видел внутренности всех этих html/css/js фреймворков. НС>Видел. Ничего космического там нет.
Космического конечно нет. Там только мусорное и адское.
_>> На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты! НС>С точностью до наоборот.
Ну давай перейдём к деталям. И так, допустим нас есть такой готовый контрол как кнопка (есть и в Qt и в MFC и в HTML). Но её поведение и внешний вид нас не устраивают.
Что мы делаем в классических ООП библиотеках? Наследуемся от этого контрола и переопределяем ему функции, отвечающие за требующее коррекцию поведение.
Что мы делаем в случае html/css/js? Сделать, как описано выше, мы банально не можем по определению. Можем только слегка кастомизировать поведение с помощью css и пары callback'ов, но в крайне узких рамках. Ну или же мы можем наплевать на стандартный код и написать новый контрол с нуля, на базе div/span/canvas, что требует гораздо больших усилий. И главное, что для разных контролов в рамках одного и того же кода могут применяться разные подходы, потому как написать button с нуля не так уж сложно, а вот сделать editbox (со всеми корректными копированиями, способами ввода и т.п.) уже гораздо сложнее и чаще предпочитают всё же как-то переиспользовать стандартный. В итоге имеем адский говнокод из смеси использования html, своих велосипедов и всё это на убогом языке с кривой модульностью и ООП.
И да, описанное выше — это описание не какого-то проекта, а большинства JS фреймворков...
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, $$, Вы писали:
Ops>$>Могло бы быть альтернативой флешу, но нет, на ослике не работает.
Ops>Он где-то еще остался? Последние динозавры с него слезают, потому что нужные им сайты перестают там работать. Пора бы окончательно закопать стюардессу.
Здравствуйте, D. Mon, Вы писали:
_>>В принципе, после добавления в wasm поддержки simd, все нужные кодеки можно будет уже писать (а точнее просто скомпилировать, т.к. большинство их них написаны на C/C++ и только некоторые используют ещё и ассемблер для ускорения) прямо на wasm. DM>Говно получится. Современные кодеки стандартных форматов давно используют GPU-ускорение, без него на одном CPU получается очень грустно даже с SIMD.
Ну SIMD в любом случае нужен хотя бы для банальных эффективных memcpy... А если говорить про GPU, то вычисления на нём уже давно доступны в браузере, и без wasm. Благо WebGL — это OpenGL ES 3.0 и там поддерживаются вполне себе современные шейдеры. Кстати, я тут ещё пару лет назад показывал тест, который как раз игрался с шейдерами из wasm.
Здравствуйте, Codealot, Вы писали:
_>>На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты! C>Кстати, а что плохого в Qt?
Кроме того, что это ожиревший монстр-всемогутер? Лично мне больше всего не нравится то, что это C++ библиотека, написанная в стиле Java. Понятно что это всё наследие 90-ых, в которые библиотека родилась, и в которых по другому просто не умели. Но в сравнение с современными C++ библиотеками она выглядит крайне печально. Ну это естественно речь о внутренней архитектуре. А так сказать по итоге применения она по прежнему на голову опережает всех других. Только вот это всё исключительно благодаря экстенсивному подходу (затраченным человеко-часам). Вот если бы кто-то вдруг сподобился вложить столько же денег, сколько потрачено на Qt, в GUI библиотеку, написанную на современном C++ — это было бы на порядки красивее и эффективнее. Но думаю такого уже никогда не случится по бизнес-причинам.
_>Ну собственно рисование всего через canvas (не важно из wasm или js) — это и есть конечная точка этого направления. Правда при этом возникают проблемы с поиском, но это актуально только для классических сайтов, а не для веб-приложений.
Там много других проблем возникает: accessibility, рисовка шрифтов, вообще работа с текстом на canvas... В общем там вагон и маленькая тележка.
Здравствуйте, Mamut, Вы писали:
M>Что такое «классические библиотеки»? На дворе 2019-й год. Набор примитивов для веба сейчас хуже и беднее, чем Дельфи или там Qt образца 2000-го.
Здравствуйте, alex_public, Вы писали:
_>Даа? Ну покажи какой объём кода на чистом JS (без всяких дополнительных библиотек) тебе понадобится, чтобы реализовать банальное меню.
Банальное меню можно вообще без JS реализовать.
НС>>>>Ну так голый HTML+JS это тоже не библиотека. _>>>Я именно про это и говорю. GUI библиотека браузера — это DOM (во всяком случае большая его часть). НС>>Так библиотека или не библиотека, ты уж определись. _>Повторяюсь последний раз: _>DOM — это слабенькая GUI библиотека (написанная на C++). _>HTML/CSS/JS — это единственный (и кривой) интерфейс к ней.
Т.е. GDI в винде это такая слабенькая GUI библиотека, да?
_>Плюс к этому всему, JS — это единственное (и крайне убогое) средство расширения этой библиотеки.
В чем убогое?
НС>>>>Для целей GUI современный JS, а тем более TS вполне адекватны. _>>>Угу, особенно на нём хорошо выходит делать классические расширяемые с помощью ООП иерархий библиотеки... ))) НС>>А зачем на нем делать классические библиотеки? _>Потому что ООП подход — это пока лучшее, что придумали в отрасли
Докажи
_>Что бы на HTML5 можно было делать приличный GUI (ты же говорил, что это была одна из целей! ), без дополнительных диких библиотек.
Чем тебе мешают библиотеки? И почему в С++ библиотеки тебе не мешают? Почему бы не потребовать контролов от драйвера видеокарты?
_>>>И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое. НС>>Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок. _>Так вообще всё реализуется прикладным кодом.
Да. И никто не требует реализации контролов от библиотечки для рисования.
_>Хы, у нас "фронтенда" нет вообще
Заметно.
_>>>Вот как будто бы ты сам не видел внутренности всех этих html/css/js фреймворков. НС>>Видел. Ничего космического там нет. _>Космического конечно нет. Там только мусорное и адское.
Давай конкретнее. Ты уже пятое сообщение выдаешь кучу эмоциональных эпитетов и не можешь их никак обосновать.
_>Что мы делаем в классических ООП библиотеках? Наследуемся от этого контрола и переопределяем ему функции, отвечающие за требующее коррекцию поведение.
Всяко бывает. В WPF, к примеру, совсем не так.
_>, но в крайне узких рамках. Ну или же мы можем наплевать на стандартный код и написать новый контрол с нуля, на базе div/span/canvas, что требует гораздо больших усилий.
Уверен? И почему именно с нуля? Почему в случае JS нельзя взять готовую библиотеку?
Здравствуйте, Ops, Вы писали:
_>>Ну и да, это плохо для случая потребности высокой производительности таких вызывов. Ops>Это плохо потому, что любое действие с DOM надо либо оборачивать в JS, либо на нем и писать, размазывая логику. Это очень неудобно при написании, даже неудобнее использования монструозных js-фреймворков.
Ну вот для Питона уже сделали полную обёртку в готовой библиотеке. Т.е. я просто пишу:
from js import document
elt = document.getElementById("targetElement")
elt.innerText = "I am changed!"
elt.style.backgroundColor = '#ffcccc'
и всё работает — никаких знаний JS не надо. Понятно, что это внутри DOM вызывается через вызoв JS функции, и это архитектурно некрасиво и не эффективно. Но с точки зрения разработчика на Питоне, он про это может даже не знать. Ну а эффективнось и Питон...
M>>Что такое «классические библиотеки»? На дворе 2019-й год. Набор примитивов для веба сейчас хуже и беднее, чем Дельфи или там Qt образца 2000-го. НС>Ты компоненты для Дельфи пробовал сам писать?
Ты компоненты для веба пробовал сам писать? Не убогое примитивное говно типа «еще одна панелька, которая скрывается по клику», а нормальный полноценный компонент. Ну какой-нибудь Tree Grid, который можно просто взять и вставить в любое место на странице.
Здравствуйте, Mamut, Вы писали:
M>>>Что такое «классические библиотеки»? На дворе 2019-й год. Набор примитивов для веба сейчас хуже и беднее, чем Дельфи или там Qt образца 2000-го. НС>>Ты компоненты для Дельфи пробовал сам писать? M>Ты компоненты для веба пробовал сам писать?
Да. Ты на вопрос ответишь?
M> Не убогое примитивное говно типа «еще одна панелька, которая скрывается по клику», а нормальный полноценный компонент. Ну какой-нибудь Tree Grid, который можно просто взять и вставить в любое место на странице.
В том числе TreeGrid. А еще я TreeGrid писал для винформсов, так что есть с чем сравнить.
Да я про осла. Если где-то его еще используют, то для легаси, где никакого развития или нового софта не предвидится. А привыкшие к нему люди с него уходят, т.к. куча ресурсов в нем уже не работает.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Ну вот для Питона уже сделали полную обёртку в готовой библиотеке. Т.е. я просто пишу: _>
_>from js import document
_>elt = document.getElementById("targetElement")
_>elt.innerText = "I am changed!"
_>elt.style.backgroundColor = '#ffcccc'
_>
_>и всё работает — никаких знаний JS не надо. Понятно, что это внутри DOM вызывается через вызoв JS функции, и это архитектурно некрасиво и не эффективно. Но с точки зрения разработчика на Питоне, он про это может даже не знать. Ну а эффективнось и Питон...
Это для wasm? Клево. А с эвентами и исключениями что?
Но вообще это надо решать не "для питона", а в общем виде, и не обертками, а прямым доступом, пусть даже где-то с потерей типизации. Но такое впечатление, что это никому не интересно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
M>>Ты компоненты для веба пробовал сам писать? НС>Да. Ты на вопрос ответишь?
Для Дельфи — нет. Что не мешало делать на Дельфи приложения хоть правой пяткой, не приходя в сознание. Потому что все, что требовалось — это положить компонент в окно. Удачи сделать то же самое с любым «компонентом» в вебе.
M>> Не убогое примитивное говно типа «еще одна панелька, которая скрывается по клику», а нормальный полноценный компонент. Ну какой-нибудь Tree Grid, который можно просто взять и вставить в любое место на странице.
НС>В том числе TreeGrid. А еще я TreeGrid писал для винформсов, так что есть с чем сравнить.
Ну и расскажи, насколько прекрасно и удобно вручную бороться с div'ами для отображения даже не самых сложных вещей, когда любой css-reset порушит люые самые лучшие начинания (если только, конечно, не прибивать все гвоздями к пискелям с помощью !important)
Здравствуйте, Mamut, Вы писали:
НС>>В том числе TreeGrid. А еще я TreeGrid писал для винформсов, так что есть с чем сравнить. M>Ну и расскажи, насколько прекрасно и удобно вручную бороться с div'ами для отображения даже не самых сложных вещей, когда любой css-reset порушит люые самые лучшие начинания (если только, конечно, не прибивать все гвоздями к пискелям с помощью !important)
Намного проще чем делать TreeGrid на основе стандартных виндовых контролов.
Здравствуйте, Codealot, Вы писали:
A>>А то, что вы какие-то «Мерседесы» придумали и пытаетесь на них выехать, к делу отношения не имеет. C>Их придумал ты, я только воспользовался твоей же аналогией.
M>>Они убоги, и на их основе «делать компоненты на основе этих примитивов» — это себя не любить. A>А делать компоненты на чистом WinAPI, например — это любить себя?
Нет, конечно. И это, помнится, многих бесило, что встроенных в систему компонентов — полторы штуки, и те убогие. Не знаю, как ситуация с контролами в винде сейчас.
Здравствуйте, vdimas, Вы писали:
V>Ну и, есть та гарантия, что то, что не является UB в С/C++, не будет являться UB и в бинарнике под WebAssembly. V>Т.е. указатели и ссылки на локальные переменные — это вполне себе доступные адреса памяти.
Здравая мысль. Надо будет посмотреть, как сейчас это реализовано.
V>>>В любом случае, в чистом нейтиве бывают только пессимистичные GC, т.е. если в стеке лежат только данные — это даже еще лучше. DM>>Консервативные? Нет, это не так совершенно. V>Еще и "совершенно"? ))
Ну, из четырех приходящих на ум языков с GC, компилируемых в нативный код, у трех GC не консервативный сейчас. (Haskell, OCaml, Go)
А ты про какие?
DM>>Если текущий фрейм не в куче, то на него не бывает указателей в WebAssembly. V>Фреймы стека данных живут в стеке данных, т.е. на куче в исполнении WebAssembly.
Разверни мысль, пожалуйста. У васм апплета есть линейный кусок памяти, там он устраивает себе кучу, туда он может ходить по "указателям". У него также есть стек, над которым оперируют все арифметические и логические инструкции. Он живет отдельно от того линейного массива, у его данных нет "адресов" в том пространстве. Что я упускаю?
Здравствуйте, Mamut, Вы писали:
M>>>Они убоги, и на их основе «делать компоненты на основе этих примитивов» — это себя не любить. A>>А делать компоненты на чистом WinAPI, например — это любить себя? M>Нет, конечно. И это, помнится, многих бесило, что встроенных в систему компонентов — полторы штуки, и те убогие. Не знаю, как ситуация с контролами в винде сейчас.
Так вот ситуация та же самая. Поверх примитивов создаются библиотеки компонентов и далее все пишут GUI, используя их. Для браузеров такие библиотеки уже есть, и никому не надо каждый раз делать компоненты, и не любить себя.
Здравствуйте, D. Mon, Вы писали:
DM>Разверни мысль, пожалуйста. У васм апплета есть линейный кусок памяти, там он устраивает себе кучу, туда он может ходить по "указателям". У него также есть стек, над которым оперируют все арифметические и логические инструкции. Он живет отдельно от того линейного массива, у его данных нет "адресов" в том пространстве. Что я упускаю?
У wasm 2 стека.
Первый стек — "обычный", используется как стек возвратов или как стек для внутренних/системных вызовов.
Второй стек — это участок в куче, эдакий рукотворный стек данных.
Используется для аргументов при вызове процедур/ф-ий/методов песочницы.
Стек данных тоже растёт в обратную сторону, но это не принципиально, ИМХО.
Принципиально то, что этот стек живёт в обычной куче и адресуется из кода песочницы.
Там идея в том, что не должно быть доступа к памяти кода, поэтому стек возврата не адресуем.
Здравствуйте, D. Mon, Вы писали:
DM>Ну, из четырех приходящих на ум языков с GC, компилируемых в нативный код, у трех GC не консервативный сейчас. (Haskell, OCaml, Go) DM>А ты про какие?
Как минимум Go нельзя назвать нейтивным языком — каждая программа на Go содержит в себе весь Go рантайм + метаинформацию для GC.
В этом смысле и .Net является "нейтивным" после ngen, но ведь нет.
Здравствуйте, bzig, Вы писали:
C>>Зачем снова городить костыли
B>HTML/CSS довольно стройный подход, неоднократно скопированный на десктопных фрэймворках. Костылями эту связку называть как минимум неумно.
Эммммммммммммм... нет, это именно что костыли. Я буквально на днях напоролся на очередной выверт CSS: нужно отобразить модальный диалог на странице, при этом диалог должен подстраиваться под размер контента — если контента мало, то окно уменьшается под него, если много, то окно масштабируется до максимально разрешённого размера, а внутри появляется прокрутка. Казалось бы — просто добавить свойство max-height? Хрен вам — max-height хоть формально и задаёт максимальную высоту, но для ограничения размера контента может использоваться только height — без вариантов. В результате родился хак: если размер контента становится больше, чем области отображения — то скриптом добавляем стиль "height:100%;" (к существующему max-height:75vh). Костылище. А ведь это обычный layouting, над которым на любом нормальном фреймворке даже задумываться не надо. И такие проблемы возникают постоянно — HTML/CSS просто не предназначен для разработки приложений.
Здравствуйте, Codealot, Вы писали:
B>>HTML/CSS довольно стройный подход, неоднократно скопированный на десктопных фрэймворках. Костылями эту связку называть как минимум неумно. C>Это крайне жирный подход, из-за которого сейчас уже примитивный список пары десятков комментариев еле ворочается на топовом железе.
Это целиком зависит от разработчика: сделать тормозной интерфейс можно на любом фреймворке.
Здравствуйте, vdimas, Вы писали:
V>Как минимум Go нельзя назвать нейтивным языком — каждая программа на Go содержит в себе весь Go рантайм + метаинформацию для GC.
Тогда и С++ не нативный, там программа содержит рантайм + метаинформацию о типах. Это смешной аргумент.
Здравствуйте, vdimas, Вы писали:
DM>>Разверни мысль, пожалуйста. У васм апплета есть линейный кусок памяти, там он устраивает себе кучу, туда он может ходить по "указателям". У него также есть стек, над которым оперируют все арифметические и логические инструкции. Он живет отдельно от того линейного массива, у его данных нет "адресов" в том пространстве. Что я упускаю?
V>У wasm 2 стека. V>Первый стек — "обычный", используется как стек возвратов или как стек для внутренних/системных вызовов. V>Второй стек — это участок в куче, эдакий рукотворный стек данных. V>Используется для аргументов при вызове процедур/ф-ий/методов песочницы. V>Стек данных тоже растёт в обратную сторону, но это не принципиально, ИМХО. V>Принципиально то, что этот стек живёт в обычной куче и адресуется из кода песочницы.
Ну вот смотрю я в спеку и вижу совершенно иное: https://webassembly.github.io/spec/core/bikeshed/index.html
Куда мне надо смотреть? Как для значения на operand stack получить его memidx? Или для значения в locals из localidx получить memidx?
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Даа? Ну покажи какой объём кода на чистом JS (без всяких дополнительных библиотек) тебе понадобится, чтобы реализовать банальное меню. НС>Банальное меню можно вообще без JS реализовать.
Эмм, мы же говорим не про сайтики (для них я тебе и без css даже менюшку сделаю, просто выстроив набор ссылок в ряд), а про приложения! Т.е. под меню подразумевается такая вполне себе классическая выпадающая штука, в которой есть такие же выпадающие подменю и т.д. Такое кстати и на больших сайтах тоже иногда встречается, но реально необходимо оно для приложений.
_>>Повторяюсь последний раз: _>>DOM — это слабенькая GUI библиотека (написанная на C++). _>>HTML/CSS/JS — это единственный (и кривой) интерфейс к ней. НС>Т.е. GDI в винде это такая слабенькая GUI библиотека, да?
GDI? Нет конечно, это инструмент для кастомизации существующих в Win32 контролов. А вот уже они — это и есть стандартная GUI библиотека винды, которая просто на порядки мощнее того, что предлагает в этой области HTML5.
_>>Плюс к этому всему, JS — это единственное (и крайне убогое) средство расширения этой библиотеки. НС>В чем убогое?
Ну JS и сам по себе убог, как язык. Но в данном конкретном вопросе это даже не главное. Тут важнее то, что сами контролы, предоставляемые браузером, написаны не на JS — к ним есть только интерфейс на JS. И в итоге, мы не можем применить к этим контролам даже убогие методы расширения, присущие JS. Т.е. как ни странно, но в данном случае архитектурно было бы лучше, если бы DOM был написан на убогом JS, а не на C++ — тогда бы это ещё можно было расширять более менее стройным образом. Но тогда бы это дико тормозило, так что на такой подход естественно не пошли. В итоге имеем почти не расширяемую GUI библиотеку, предоставляемую браузером.
_>>Потому что ООП подход — это пока лучшее, что придумали в отрасли НС>Докажи
Угу, сейчас прямо побежал.
_>>Что бы на HTML5 можно было делать приличный GUI (ты же говорил, что это была одна из целей! ), без дополнительных диких библиотек. НС>Чем тебе мешают библиотеки? И почему в С++ библиотеки тебе не мешают? Почему бы не потребовать контролов от драйвера видеокарты?
Ещё раз и по пунктам? В стандарт C++ входит GUI? Нет. В Vulcan входит GUI? Нет. В HTML входит GUI? Да, правда очень убогий. И на мой взгляд он убогий потому, что авторы стандарта никогда не позиционировали его для GUI.
_>>>>И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое. НС>>>Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок. _>>Так вообще всё реализуется прикладным кодом. НС>Да. И никто не требует реализации контролов от библиотечки для рисования.
Так ты уже определись, для чего предназначен HTML. Для документов или для рисования или для GUI? У тебя прямо столько версий на ходу возникает... )))
_>>Что мы делаем в классических ООП библиотеках? Наследуемся от этого контрола и переопределяем ему функции, отвечающие за требующее коррекцию поведение. НС>Всяко бывает. В WPF, к примеру, совсем не так.
Ну расскажи, как в WPF расширяются контролы. )
_>>, но в крайне узких рамках. Ну или же мы можем наплевать на стандартный код и написать новый контрол с нуля, на базе div/span/canvas, что требует гораздо больших усилий. НС>Уверен? И почему именно с нуля? Почему в случае JS нельзя взять готовую библиотеку?
Эм, мы же вообще то как раз и обсуждаем написание таких библиотек и почему внутри них творится адский ужас. Понятно, что если ты возьмёшь топовую библиотечку и свой "hello world" проект (в котором точно не понадобится писать свои контролы, т.к. в библиотечке уже есть всё ходовое), то там код будет простенький и красивый.
Ну а насчёт уверенности в гораздо больших усилиях... А ты точно представляешь себе, что требуется, чтобы написать банальный editbox с нуля (т.е. имея только canvas)? Ну что бы он ни в чём не уступал системному...
Здравствуйте, alex_public, Вы писали:
_>Эмм, мы же говорим не про сайтики (для них я тебе и без css даже менюшку сделаю, просто выстроив набор ссылок в ряд), а про приложения! Т.е. под меню подразумевается такая вполне себе классическая выпадающая штука, в которой есть такие же выпадающие подменю и т.д.
По ссылке такое есть. Недостающие фичи легко добавляются небольшим количеством простого JS.
НС>>Т.е. GDI в винде это такая слабенькая GUI библиотека, да?
_>GDI? Нет конечно
Ну вот и голый HTML тоже нет.
_>Ну JS и сам по себе убог, как язык.
Чем?
_> Но в данном конкретном вопросе это даже не главное.
Данный конкретный вопрос как раз в том чем убог HTML и JS. Но ты с него постоянно хочешь сползти.
_>>>Потому что ООП подход — это пока лучшее, что придумали в отрасли НС>>Докажи _>Угу, сейчас прямо побежал.
ЧТД.
_>>>Что бы на HTML5 можно было делать приличный GUI (ты же говорил, что это была одна из целей! ), без дополнительных диких библиотек. НС>>Чем тебе мешают библиотеки? И почему в С++ библиотеки тебе не мешают? Почему бы не потребовать контролов от драйвера видеокарты? _>Ещё раз и по пунктам? В стандарт C++ входит GUI? Нет.
При чем тут стандарт С++?
_> В Vulcan входит GUI? Нет. В HTML входит GUI? Да, правда очень убогий.
И? Чем он тебе мешает?
_>И на мой взгляд он убогий потому, что авторы стандарта никогда не позиционировали его для GUI.
Это не ответ. Речь не про замшелые времена NN, а про текущую ситуацию. Чем убог, скажем, Vue?
НС>>Да. И никто не требует реализации контролов от библиотечки для рисования. _>Так ты уже определись, для чего предназначен HTML.
Язык разметки для движка лейаута.
_> Для документов или для рисования или для GUI?
Современный — и для того и для другого.
_>>>Что мы делаем в классических ООП библиотеках? Наследуемся от этого контрола и переопределяем ему функции, отвечающие за требующее коррекцию поведение. НС>>Всяко бывает. В WPF, к примеру, совсем не так. _>Ну расскажи, как в WPF расширяются контролы. )
Долго рассказывать. Гугли про display model, content model, behaviors и т.п.
_>>>, но в крайне узких рамках. Ну или же мы можем наплевать на стандартный код и написать новый контрол с нуля, на базе div/span/canvas, что требует гораздо больших усилий. НС>>Уверен? И почему именно с нуля? Почему в случае JS нельзя взять готовую библиотеку? _>Эм, мы же вообще то как раз и обсуждаем написание таких библиотек и почему внутри них творится адский ужас.
Ну так переходи уже к адскому ужасу то. Вы тут с Мамутом уже кучу сообщений с намеками понаписали, а ничего привести в пример не можете.
_> Понятно, что если ты возьмёшь топовую библиотечку и свой "hello world" проект (в котором точно не понадобится писать свои контролы, т.к. в библиотечке уже есть всё ходовое), то там код будет простенький и красивый.
Ровно как и с гуями. Внутри классических контролов еще более суровый ужас. Одна дрисня с invalidate rectangles чего стоит, который рукожопые контролописатели порой даже не реализуют.
_>Ну а насчёт уверенности в гораздо больших усилиях... А ты точно представляешь себе, что требуется, чтобы написать банальный editbox с нуля (т.е. имея только canvas)?
Да. И даже писал. А ты сколько контролов для веба написал? Такой же теоретик как и Мамут?
Здравствуйте, Ops, Вы писали:
_>>и всё работает — никаких знаний JS не надо. Понятно, что это внутри DOM вызывается через вызoв JS функции, и это архитектурно некрасиво и не эффективно. Но с точки зрения разработчика на Питоне, он про это может даже не знать. Ну а эффективнось и Питон... Ops>Это для wasm? Клево. А с эвентами и исключениями что?
Про исключения не смотрел. А события естественно работают классическим образом (код из их демки):
Ops>Но вообще это надо решать не "для питона", а в общем виде, и не обертками, а прямым доступом, пусть даже где-то с потерей типизации. Но такое впечатление, что это никому не интересно.
С этим я конечно же согласен... Но думаю что ждать пока все "браузеры" договорятся между собой в комитете wasm придётся очень долго... ))) Поэтому народ предпочитает не ждать, а выкручиваться самим уже прямо сейчас.
Здравствуйте, D. Mon, Вы писали:
V>>Как минимум Go нельзя назвать нейтивным языком — каждая программа на Go содержит в себе весь Go рантайм + метаинформацию для GC. DM>Тогда и С++ не нативный, там программа содержит рантайм + метаинформацию о типах. Это смешной аргумент.
Мде? ))
Если этот аргумент "смешной", тогда управляемых языков в природе не существует, все нейтивные.
Не нейтивными являются только интерпретируемые...
В общем, сам определись, сначала, прежде чем с окружающими спорить.
Здравствуйте, anonymous, Вы писали:
M>>Они убоги, и на их основе «делать компоненты на основе этих примитивов» — это себя не любить. A>А делать компоненты на чистом WinAPI, например — это любить себя?
Ну вообще говоря в Win32 попроще, т.к. оно заметно мощнее (и функции прорисовки и обработка сообщений). Но в любом случае сделать банальный editbox своими силами будет весьма сложно и там и там. Тут главная разница совсем в другом. Даже если ты программируешь на голом Win32, то для очень многих приложений тебе просто не надо будет создавать свои контролы, т.к. стандартных более чем достаточно (https://docs.microsoft.com/en-us/windows/win32/controls/individual-control-info — где аналог хотя бы этого базиса в DOM?). А вот в браузере стандартных контролов не хватит даже на "hello word" (мы естественно говорим про приложения, а не про сайтики)!
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>В том числе TreeGrid. А еще я TreeGrid писал для винформсов, так что есть с чем сравнить. M>>Ну и расскажи, насколько прекрасно и удобно вручную бороться с div'ами для отображения даже не самых сложных вещей, когда любой css-reset порушит люые самые лучшие начинания (если только, конечно, не прибивать все гвоздями к пискелям с помощью !important) НС>Намного проще чем делать TreeGrid на основе стандартных виндовых контролов.
Только вот TreeGrid — это довольно специфическая штука, которая нужна далеко не в каждом приложение. А вот TreeView — это уже гораздо более нужная вещь. И вот "сюрприз", в винде его не надо делать руками, а вот в браузере его даже не в каждой библиотеке найдёшь, не то что в базовом API.
Здравствуйте, D. Mon, Вы писали:
DM>Ну вот смотрю я в спеку и вижу совершенно иное:
Я вижу всё то же:
Conversely, non-address taken values which are usually on the stack are instead represented as locals inside functions. This effectively means that WebAssembly has an infinite set of registers, and can choose to spill values as it sees fit in a manner unobservable to the hosted code. This implies that there's a separate stack, unaddressable from hosted code, which is also used to spill return values. This allows strong security properties to be enforced, but does mean that two stacks are maintained (one by the VM, the other by the compiler which targets WebAssembly)
Хотя и здесь ерунда написана.
Какие узколобые ребятки пишут спеки на webasm, js-фрики заполонили... что они вообще видели в своей жизни, что выродили ТАКОЕ? ))
По твоей ссылке кач-во спеки тоже
Я не был в курсе, что там, оказывается, всё так плохо.
После просмотра спеки склоняюсь к мысли, что webasm будет готов для широкого использования намного позже, чем планировали ранее (минимум лет на 5 позже, могу на ящик коньяка забиться).
Вот вполне обычный пример:
struct SomeStruct { /* a lot of fields */};
SomeStruct getSomeStruct() {...}
void processSomeStruct(const SomeStruct & value) {...}
...
processSomeStruct(getSomeStruct());
В случае RVO "место" под возвращаемое значение создаётся до вызова getSomeStruct(..), адрес этого "места" де-факто подаётся как аргумент.
Спеки в помоечку... ))
Здравствуйте, alex_public, Вы писали:
A>>А делать компоненты на чистом WinAPI, например — это любить себя? _>Ну вообще говоря в Win32 попроще, т.к. оно заметно мощнее (и функции прорисовки и обработка сообщений). Но в любом случае сделать банальный editbox своими силами будет весьма сложно и там и там. Тут главная разница совсем в другом. Даже если ты программируешь на голом Win32, то для очень многих приложений тебе просто не надо будет создавать свои контролы, т.к. стандартных более чем достаточно (https://docs.microsoft.com/en-us/windows/win32/controls/individual-control-info — где аналог хотя бы этого базиса в DOM?).
Аналогично для веб.
_>А вот в браузере стандартных контролов не хватит даже на "hello word" (мы естественно говорим про приложения, а не про сайтики)!
Здравствуйте, alex_public, Вы писали:
НС>>Намного проще чем делать TreeGrid на основе стандартных виндовых контролов. _>Только вот TreeGrid — это довольно специфическая штука
Не я этот пример придумал.
_>А вот TreeView — это уже гораздо более нужная вещь. И вот "сюрприз", в винде его не надо делать руками, а вот в браузере его даже не в каждой библиотеке найдёшь
Знаешь почему? Потому что такая примитивщина легко реализуется вообще без JS. Я уж не говорю о том, что развесистые TreeView не особо годятся для WebUI. Попробуй на мобилке им попользоваться и все поймешь.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Данный конкретный вопрос как раз в том чем убог HTML и JS.
Я пока не видел ни одного реального приложения на HTML и JS, которым можно пользоваться без зубовного скрежета и с трудом сдерживаемого желания биться головой об клавиатуру.
Этого недостаточно?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, D. Mon, Вы писали:
_>>>В принципе, после добавления в wasm поддержки simd, все нужные кодеки можно будет уже писать (а точнее просто скомпилировать, т.к. большинство их них написаны на C/C++ и только некоторые используют ещё и ассемблер для ускорения) прямо на wasm. DM>>Говно получится. Современные кодеки стандартных форматов давно используют GPU-ускорение, без него на одном CPU получается очень грустно даже с SIMD.
_>Ну SIMD в любом случае нужен хотя бы для банальных эффективных memcpy... А если говорить про GPU, то вычисления на нём уже давно доступны в браузере, и без wasm. Благо WebGL — это OpenGL ES 3.0 и там поддерживаются вполне себе современные шейдеры. Кстати, я тут ещё пару лет назад показывал тест, который как раз игрался с шейдерами из wasm.
Дык добавили же SIMD (и pthread) недавно? На демке перекомпилированная OpenCV с SIMD + THREAD заработала в 30 раз быстрее
Здравствуйте, Codealot, Вы писали:
C>Я пока не видел ни одного реального приложения на HTML и JS, которым можно пользоваться без зубовного скрежета и с трудом сдерживаемого желания биться головой об клавиатуру. C>Этого недостаточно?
Здравствуйте, alex_public, Вы писали:
_>Ну вообще говоря в Win32 попроще, т.к. оно заметно мощнее
Ага, конечно. Даже чтобы у кнопки цвет поменять или уголки закругленные делать нужно owner draw делать. Моща неописуемая.
_>т.к. стандартных более чем достаточно
Стандартность — штука относительная. Если ограничится user32 — выбор не так чтобы широк.
_>А вот в браузере стандартных контролов не хватит даже на "hello word"
Каких именно контролов тебе не хватит на hello world?
Здравствуйте, alex_public, Вы писали:
_>P.S. Я надеялся (и писал об этом на форуме) именно на такое развитие ситуации ещё несколько лет назад. JavaScript — пока, пока!
Вопрос что вы хотите сделать. Разработчику/профессиональному пользователю в разы удобнее иметь локальный софт. Он и без васм тормозит. А для легкого контента — wasm и webgl рендеринг и аппаратное ускорение — просто не нужно. Если кто-то использует реакт непойми зачем, просто потому что FB — так оно в большинстве случаев тоже не нужно (при том тяжеловатое).
А теперь берём предоставленный пример... загрузился он долговато. Ну ладно, это один раз. А дальше получаем, то, что скроллить "фрейм" (прокручиваемую область) на андроиде в хроме... оказывается, что скролить надо полоски, а стандартные жесты не работают. Мы все видели как развиваются не родные UI фреймворки на десктопах: коряво, не системно и порою с косяками.
Вы посмотрите, люди далеко не всегда, могут сделать кнопку, которая ведет себя так же как обычная (системная) в виндовс. Это справедливо и для десктопа: VSCode, например, имеет иконку приложения на своем месте, а вот системное меню не открывается там, хоть закликайся. Это всё мелочи, но из них и строится UX.
Т.е., очевидно, что мы получим в итоге ещё бОльший разброд "вебдванольных" интерфейсов и фантазии дизайнеров. Оно правда уже так, по 3 слова на страницу...
В общем такое себе.
PS: Но для каких-то спец приложений — вещь безусловно полезная.
S>Эммммммммммммм... нет, это именно что костыли. Я буквально на днях напоролся на очередной выверт CSS: нужно отобразить модальный диалог на странице, при этом диалог должен подстраиваться под размер контента — если контента мало, то окно уменьшается под него, если много, то окно масштабируется до максимально разрешённого размера, а внутри появляется прокрутка. Казалось бы — просто добавить свойство max-height? Хрен вам — max-height хоть формально и задаёт максимальную высоту, но для ограничения размера контента может использоваться только height — без вариантов. В результате родился хак: если размер контента становится больше, чем области отображения — то скриптом добавляем стиль "height:100%;" (к существующему max-height:75vh). Костылище.
Ну т.е. опять всё свелось к модальным диалогам, но пусть.
S>А ведь это обычный layouting, над которым на любом нормальном фреймворке даже задумываться не надо. И такие проблемы возникают постоянно — HTML/CSS просто не предназначен для разработки приложений.
А как это будет выглядеть в нормальном фрэймворке (можно, кстати, список?)? Те же самые вычисления и простановка какого-нибудь проперти. В чём принципиальная разница? Кроме той, что (я подозреваю) в нормальном фрэймворке-то и "em/ex" поддерживаться не будет, а будут пиксели и плевать, что там у юзера выставлено в настройках броузера 120%.
C>Я пока не видел ни одного реального приложения на HTML и JS, которым можно пользоваться без зубовного скрежета и с трудом сдерживаемого желания биться головой об клавиатуру.
Здравствуйте, bzig, Вы писали:
B>Таких приложений точно больше одного (gmail, google calendar, github), правда чтобы тебя опровергнуть хватило бы и одного.
Ох, сказочники такие сказочники.
Начнем с того, что они тупо тормозят. Продолжим тем, что функционал всех трех этих сайтов довольно убог по меркам десктопных приложений даже 20-летней давности. Например, в гов%о-мейле показ сообщений максимум по 50 за раз, да и тот тормозит, как указано в пункте 1.
Здравствуйте, bzig, Вы писали:
B>Ну т.е. опять всё свелось к модальным диалогам, но пусть.
Вот тебе другой пример. Есть набор из n элементов, каждый содержит одну картинку (разных размеров и пропорций) и текст (разной длины). Задача — каждый элемент отформатировать и вывести все эти элементы в виде грида, построчно.
Форматировать элементы и размещать по строкам в гриде надо так, чтобы максимально эффективно использовать площадь экрана — и при условии, что каждая картинка не должна занимать больше половины своего элемента по ширине, но не нужно ее растягивать, если она исходно меньше половины.
Расскажи ка мне, как в "охренительно замечательном" html/css это сделать.
C>Расскажи ка мне, как в "охренительно замечательном" html/css это сделать.
Покажи как ты пытался, а я посмотрю, где ты ошибся.
Скрытый текст
Впрочем, как и ожидалось, всё просто. А вот покажи тоже самое на "любом нормальном фрэймворке".
<html>
<head>
<style>
table {
table-layout: fixed;
width: 100%;
}
td {
width: 25%;
}
td.img {
text-align: center;
}
img {
max-width: 50%;
}
</style>
</head>
<body>
<table border="1">
<tr>
<td>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</td>
<td>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</td>
<td class="img">
<img src="https://images.unsplash.com/photo-1535498730771-e735b998cd64?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&w=1000&q=80"/>
</td>
<td>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. </td>
</tr>
<tr>
<td>Lorem ipsum dolor sit amet</td>
<td class="img"><img src="https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQKAgmI3dtwfFzoqZsjilBzUluN_lXcveBRL2icgitmvMv1qAlv&s"/></td>
<td>?</td>
<td>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</td>
</tr>
</table>
</body>
</html>
Здравствуйте, bzig, Вы писали:
B>Впрочем, как и ожидалось, всё просто.
Ну во первых, таблицы устарели и вообще это жуткий моветон, коллеги говном закидают.
Во вторых, ты не выполнил условия задачи — 1) в каждом элементе картинка и текст 2) размещение по строкам должно быть таким, чтобы эффективно использовать площадь экрана, а не фиксированным — у тебя же там дофига пустого места
Здравствуйте, bzig, Вы писали:
B>Ну т.е. опять всё свелось к модальным диалогам, но пусть.
Что значит "свелось к модальным диалогам"? Тупо не работает свойство "max-height", независимо от того как используется.
S>>А ведь это обычный layouting, над которым на любом нормальном фреймворке даже задумываться не надо. И такие проблемы возникают постоянно — HTML/CSS просто не предназначен для разработки приложений.
B>А как это будет выглядеть в нормальном фрэймворке (можно, кстати, список?)? Те же самые вычисления и простановка какого-нибудь проперти. В чём принципиальная разница? Кроме той, что (я подозреваю) в нормальном фрэймворке-то и "em/ex" поддерживаться не будет, а будут пиксели и плевать, что там у юзера выставлено в настройках броузера 120%.
В нормальном фреймворке (абсолютно любой WPF, AWT, что-угодно с поддержкой layouts), не потребуются кодовые костыли для реализации базовой функциональности.
Здравствуйте, Somescout, Вы писали:
S>Что значит "свелось к модальным диалогам"? Тупо не работает свойство "max-height", независимо от того как используется.
Если мне память не изменяет, то оно работает только в том случае, если у родителя задан абсолютный размер. Хотя, и в этом случае ничего толком не гарантируется, в зависимости от браузера
Здравствуйте, Codealot, Вы писали:
S>>Что значит "свелось к модальным диалогам"? Тупо не работает свойство "max-height", независимо от того как используется.
C>Если мне память не изменяет, то оно работает только в том случае, если у родителя задан абсолютный размер. Хотя, и в этом случае ничего толком не гарантируется, в зависимости от браузера
Сейчас проверил — нет, даже если задавать абсолютный размер не работает. На счёт браузеров в точку: у меня max-height даже в разных версиях хрома по разному глючил.
Здравствуйте, Codealot, Вы писали:
C>Ну во первых, таблицы устарели и вообще это жуткий моветон, коллеги говном закидают.
Во-первых устарели не таблицы, а табличная верстка. Для отображения табличных данных ничего лучше таблиц нет. А во-вторых span с display: table-cell твоих коллег должен удовлетворить.
Здравствуйте, Codealot, Вы писали:
A>>При чём тут твой ник, если ты утверждал: C>При том, что ты утверждал, что это придумал я
Слушай, ты не способен даже признать, что ошибся, заявив, что аналогию придумал я. Какой смысл тогда тратить на тебя время и пытаться обсуждать с тобой что-либо по теме? Ты точно так же упрёшься по любому вопросу. Поэтому с тобой я закончил.
A>Так вот ситуация та же самая. Поверх примитивов создаются библиотеки компонентов и далее все пишут GUI, используя их.
почти та же самая. Ну то есть такая же, как земля и небо.
A>Для браузеров такие библиотеки уже есть, и никому не надо каждый раз делать компоненты, и не любить себя.
Ага-ага. Только вот незадача: любой чих, и эти компоненты ломаются. Любой компонент — с кучей ограничений нато, где, как и почему он может появляться, строгие требования к разметке и т.п. А крупные (типа той же sencha) просто банально берут на себя контроль за всем, практически не позволяют ничего стороннего, и все равно имеют кучу собственных ограничений на то, где как и почему какой-либо элемент может находиться.
И все равно. Любой залетный html * { padding: 2em } убьет любой «компонент».
Здравствуйте, vdimas, Вы писали:
V>В случае RVO "место" под возвращаемое значение создаётся до вызова getSomeStruct(..), адрес этого "места" де-факто подаётся как аргумент. V>Спеки в помоечку... ))
Персонально для НС добавлю:
ничего смешного, при возврате value types шириной более машинного слова в .Net после JIT или NetNative происходит ровно то же.
Здравствуйте, Codealot, Вы писали:
S>>Это целиком зависит от разработчика: сделать тормозной интерфейс можно на любом фреймворке.
C>Но на некоторых из них, невозможно не сделать тормозной.
На связке HTML/CSS/JS возможно. А что использовать над этим — это уже выбор разработчика. Некоторым и статический сайт-визитка без ангуляра с реактом не годится.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Somescout, Вы писали:
S>Эммммммммммммм... нет, это именно что костыли. Я буквально на днях напоролся на очередной выверт CSS
Костыли подпирают кучу легаси. Все боятся сломать совместимость, хотя при этом вводят новые фичи, которые в принципе не поддерживаются артефактами вроде IE.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
S>>Эммммммммммммм... нет, это именно что костыли. Я буквально на днях напоролся на очередной выверт CSS
Ops>Костыли подпирают кучу легаси. Все боятся сломать совместимость, хотя при этом вводят новые фичи, которые в принципе не поддерживаются артефактами вроде IE.
IE уже не актуален давно, на него никто и не смотрит. То же поведение max-(width|height) зафиксировано в стандарте, и пинать за это (так же как и за box-sizing) нужно W3C. И да, само собой сами они оправдываются тем, что "надо ничего не сломать", только вот по факту при этом вводят изначально кривые фичи.
S>IE уже не актуален давно, на него никто и не смотрит. То же поведение max-(width|height) зафиксировано в стандарте, и пинать за это (так же как и за box-sizing) нужно W3C. И да, само собой сами они оправдываются тем, что "надо ничего не сломать", только вот по факту при этом вводят изначально кривые фичи.
Здравствуйте, Somescout, Вы писали:
S>IE уже не актуален давно, на него никто и не смотрит. То же поведение max-(width|height) зафиксировано в стандарте, и пинать за это (так же как и за box-sizing) нужно W3C. И да, само собой сами они оправдываются тем, что "надо ничего не сломать", только вот по факту при этом вводят изначально кривые фичи.
ИЕ лишь пример. CSS-grid тоже в стандарте, однако поддерживаться начал совсем недавно, и до сих пор есть браузеры, в которых сайт с ним будет сломанным. Так почему, вместе с введением его (или чего-то подобного) поддержки, не поломать старые идиотские правила, назвав новым стандартом? А новые браузеры пусть обрабатывает оба случая, пока новый стандарт не вытеснит старый.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vdimas, Вы писали:
DM>>Ну вот смотрю я в спеку и вижу совершенно иное: V>Я вижу всё то же
Вот, спасибо за ссылку на нужный документ. Ключевой момент:
Since WebAssembly's local variables are outside the address space, C/C++ compilers implement address-taken variables by creating a separate stack data structure within linear memory. This stack is sometimes called the "aliased" stack, since it is used for variables which may be pointed to by pointers.
Я говорил про первое — "WebAssembly's local variables are outside the address space", а ты — про второе, про то, как конкретный компилятор С++ обходит это ограничение. Теперь все на своих местах.
Здравствуйте, Mamut, Вы писали:
M>Языки без GC не спешат компилиться в wasm, вы все не поверите, потому что в wasm'е нет поддержки GC (это так же причина, почему в wasm'е нет доступа к DOM'у и нормальной интеграции с JS). Дотнетовский Blazor, компилирующийся в wasm, сначала грузит в браузер половину реализации дотнета, включая GC, а потом грузит приложения. Понятно, что никому это даром не надо.
Тут такая КВС идет, и по теме, в которой я даже не достиг уровня теоретика. Я когда-то Hello, World на JS немного допилил, и на этом все. И хотелось бы, может, немного побредить, но бреда тут и без меня хватает.
Здравствуйте, anonymous, Вы писали:
A>Слушай, ты не способен даже признать, что ошибся, заявив, что аналогию придумал я. Какой смысл тогда тратить на тебя время и пытаться обсуждать с тобой что-либо по теме? Ты точно так же упрёшься по любому вопросу. Поэтому с тобой я закончил.
А ты заявил, что ее придумал я, причем раньше того сообщения. И?
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Ад там уже не в языке, а в экосистеме. Все эти наслоения, включая TS, создают жутко хрупкую конструкцию из говна и палок.
НС>К счастью оно потихоньку фиксится.
Что, быстрее, чем это говно плодится? Меня в свое время удивил leftpad, и не тем, что он все сломал, а тем, что эта ерунда не часть осмысленной библиотеки, а отдельный модуль.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
C>>Например, в гов%о-мейле показ сообщений максимум по 50 за раз, да и тот тормозит, как указано в пункте 1.
Ops>Я вообще от него давно отказался, пользуюсь десктопным почтовиком, что намного удобнее, в т.ч. из-за тормознутости.
А каким, если не секрет?
Тоже вот хочу, но чтобы он на телефоне тоже был.
Вот представь себе, есть 5 аккаунтов IMAP, и идеально было бы, чтобы оно с ними синхронизировало почту и показывало бы некий объединенный inbox.
На телефоне, в браузере, и на десктопе. GMail такое не умеет (только pop), Outlook тоже (только раздельно)
Здравствуйте, D. Mon, Вы писали:
DM>Вот, спасибо за ссылку на нужный документ. Ключевой момент: DM>
Since WebAssembly's local variables are outside the address space, C/C++ compilers implement address-taken variables by creating a separate stack data structure within linear memory. This stack is sometimes called the "aliased" stack, since it is used for variables which may be pointed to by pointers.
DM>Я говорил про первое — "WebAssembly's local variables are outside the address space", а ты — про второе, про то, как конкретный компилятор С++ обходит это ограничение. Теперь все на своих местах.
Я же говорю — низкое кач-во спеки.
Аналогично ведь происходит с value-type в .Net, когда те передаются по ref/in/out.
Аналогично в Rust, аналогично в Хаскель, где структуры данных унутре передаются по ссылке.
В общем, С++ тут не при чём, этот список бесконечный.
Здравствуйте, bnk, Вы писали:
bnk>А каким, если не секрет? bnk>Тоже вот хочу, но чтобы он на телефоне тоже был.
bnk>Вот представь себе, есть 5 аккаунтов IMAP, и идеально было бы, чтобы оно с ними синхронизировало почту и показывало бы некий объединенный inbox. bnk>На телефоне, в браузере, и на десктопе. GMail такое не умеет (только pop), Outlook тоже (только раздельно)
Thunderbird, но что у него с телефоном я не знаю, с мобилы 2 раза в году захожу стандартным приложением, чаще не требуется, поэтому не озаботился.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vdimas, Вы писали:
DM>>Я говорил про первое — "WebAssembly's local variables are outside the address space", а ты — про второе, про то, как конкретный компилятор С++ обходит это ограничение. Теперь все на своих местах.
V>Я же говорю — низкое кач-во спеки.
Ну нет, спека WebAssembly описывает именно ВМ WebAssembly, это уровень ассемблера, и там никакого aliased stack'a нет, как нет и структур.
То, как отдельные языки будут выкручиваться, — уже спеку WebAssembly не волнует. Она ничего не знает и знать не хочет ни про структуры, ни про требования GC отдельных языков.
Здравствуйте, D. Mon, Вы писали:
DM>>>Я говорил про первое — "WebAssembly's local variables are outside the address space", а ты — про второе, про то, как конкретный компилятор С++ обходит это ограничение. Теперь все на своих местах. V>>Я же говорю — низкое кач-во спеки. DM>Ну нет, спека WebAssembly описывает именно ВМ WebAssembly, это уровень ассемблера, и там никакого aliased stack'a нет, как нет и структур.
Состояние спеки WebAssembly на сегодня — ну это примерно как схема функциональная.
Паять по такой схеме еще нельзя, надо разработать схему принципиальную.
А её нет.
DM>То, как отдельные языки будут выкручиваться, — уже спеку WebAssembly не волнует.
Мде? ))
Но С/С++ упоминает более одного раза (что ес-но, ведь дотнетные, джавовские, хаскель и чуть не все прочие рантаймы будут написаны под webasm на С или С++).
Однако, такое усердное упоминание создаёт видимость того, что проблема касается только С++, но это достоверно НЕ так.
DM>Она ничего не знает и знать не хочет ни про структуры, ни про требования GC отдельных языков.
Верно. Проблема в авторах спеки.
Там орудют птички, скажем прямо, не самого высокого полёта.
Нет таких как Герб Саттер в плюсах (а таких как Саттер в плюсах огромное кол-во людей), нет спецов сравнимого уровня с уровнем разработчиков того же дотнета когда-то.
Более того, описывать модель webasm в терминах JS...
это не просто роспись в нубстве, это днище.
Это махание своей профнепригодностью на весь интернет.
Как грится, куда вы соколики лезете, что пытаетесь проглотить...
И это они когда-то к 2015-му году хотели "повсеместно перейти", потом к 2018-му.
ИМХО, даже 2025-й сильно под вопросом, потому что это край современного нубства, а в таких случаях награда лишь одна — долгострой.
==============
Скажу так.
Идея мне импонировала, пока с твоей подачи я не полез в самые кишки как грится...
В нашей конторе такие нубы сидели бы на поддержке продуктов, разработанных другими коллегами.
И ни боже упаси руками трогать то, чего не понимают.
Здравствуйте, vdimas, Вы писали:
DM>>То, как отдельные языки будут выкручиваться, — уже спеку WebAssembly не волнует.
V>Мде? )) V>Но С/С++ упоминает более одного раза (что ес-но, ведь дотнетные, джавовские, хаскель и чуть не все прочие рантаймы будут написаны под webasm на С или С++).
Здравствуйте, Codealot, Вы писали:
V>>Идея мне импонировала, пока с твоей подачи я не полез в самые кишки как грится... C>Достаточно посмотреть на сроки и прогресс. Идея в общем мне нравится, но к сожалению — не думаю, что эти люди смогут ее вытянуть.
+1
Да. В этом же и заключается суть софтового долгостроя.
Сами разработчики должны пройтись по всем граблям, "вырасти", накопить опыта.
Некоторые из разрабов "отвалятся" в процессе, ниасилив, их заменят на более квалифицированных.
В общем, долгострой продолжается ровно до тех пор, пока команда разрабов не подтянется до уровня решаемых задач.
Как только подтянется — можно отсчитывать примерно 9 месяцев до первого вменяемого релиза.
Судя по-спеке — на сейчас еще происходит этап активного обучения, через пляски по граблям, ес-но.
Здравствуйте, D. Mon, Вы писали:
V>>Но С/С++ упоминает более одного раза (что ес-но, ведь дотнетные, джавовские, хаскель и чуть не все прочие рантаймы будут написаны под webasm на С или С++). DM>Нет. Вот спека DM>https://webassembly.github.io/spec/core/bikeshed/index.html
Я тебе давал выдержки из более принципиального документа — Design Rationale.
Как там говорил Козьма Прутков — смотри в корень! ))
А по твоей ссылке всё слишком сыро пока мест.
Сравни с описаниями стандартов VM .Net, или языка С++ (который идёт с описанием подразумеваемой абстрактной машины исполнения).
Это совершенно несравнимое кач-во спецификаций, даже лень тут что-либо обсуждать, сорри.
В общем, это серьёзный факап... запасайтесь терпением...
Других адекватных выводов пока мест быть не может.
Здравствуйте, Mamut, Вы писали:
A>>Для браузеров такие библиотеки уже есть, и никому не надо каждый раз делать компоненты, и не любить себя. M>Ага-ага. Только вот незадача: любой чих, и эти компоненты ломаются. Любой компонент — с кучей ограничений нато, где, как и почему он может появляться, строгие требования к разметке и т.п. А крупные (типа той же sencha) просто банально берут на себя контроль за всем, практически не позволяют ничего стороннего, и все равно имеют кучу собственных ограничений на то, где как и почему какой-либо элемент может находиться.
Есть ограничения, да. И что? Я напомню, что речь изначально шла о том, что всем нужно себя не любить и пилить собственные компоненты на основе span и div. А теперь ты вынужден согласиться с тем, что это не обязательно, но тут же меняешь тактику: нужно подчиняться некоторым ограничениям и, видимо, снова не любить себя.
M>И все равно. Любой залетный html * { padding: 2em } убьет любой «компонент».
А какой-нибудь залётный exec("rm -rf /") убьёт систему. Зачем вообще обсуждать залёты?
Здравствуйте, bzig, Вы писали:
B>А как это будет выглядеть в нормальном фрэймворке (можно, кстати, список?)? Те же самые вычисления и простановка какого-нибудь проперти. В чём принципиальная разница? Кроме той, что (я подозреваю) в нормальном фрэймворке-то и "em/ex" поддерживаться не будет, а будут пиксели и плевать, что там у юзера выставлено в настройках броузера 120%.
В нормальных фреймворках вообще не надо беспокоиться о таких вопросах. Там размер окна автоматически масштабируется так, чтобы вместить весь контент. Если же требуемый для этого размер, будет превышать максимально возможный, то автоматически появятся полосы прокрутки. Даже странно видеть такие вопросы в 2019-ом году, а не в начале 90-ых. Хотя да, Web GUI действительно так и не дорос пока хотя бы до уровня стандартных контролов Window95...
Здравствуйте, Mamut, Вы писали:
A>>Так вот ситуация та же самая. Поверх примитивов создаются библиотеки компонентов и далее все пишут GUI, используя их.
M>почти та же самая. Ну то есть такая же, как земля и небо.
A>>Для браузеров такие библиотеки уже есть, и никому не надо каждый раз делать компоненты, и не любить себя.
M>Ага-ага. Только вот незадача: любой чих, и эти компоненты ломаются. Любой компонент — с кучей ограничений нато, где, как и почему он может появляться, строгие требования к разметке и т.п. А крупные (типа той же sencha) просто банально берут на себя контроль за всем, практически не позволяют ничего стороннего, и все равно имеют кучу собственных ограничений на то, где как и почему какой-либо элемент может находиться.
M>И все равно. Любой залетный html * { padding: 2em } убьет любой «компонент».
С другой стороны, когда надо изменить где-нибудь какую-то визуальную мелочь внутри, можно написать что-то типа:
В WPF\UWP для такого иногда приходится переделывать километровые шаблоны для целой иерархии. И при мелких обновлениях компонентов, переделывать по новой.
Мне вот сейчас надо переписать шаблоны кнопок в UWP-приложении, потому, что мои сломались после очередного обновления винды, а в стандартных захордкожены размеры иконок
И кода там будет на несколько экранов.
Я вот совсем не фанат html, но есть ощущение, что с появлением flex, grid раскладок как-то с этим стало можно жить.
В конце-концов VSCode сейчас чуть ли не самый популярный редактор кода, а от Figma тащатся знакомые дизайнеры.
M>>И все равно. Любой залетный html * { padding: 2em } убьет любой «компонент». A>А какой-нибудь залётный exec("rm -rf /") убьёт систему. Зачем вообще обсуждать залёты?
exec("rm -rf /") просто так в твое приложение не залетит. А любой CSS в твое веб-приложение может залететь очень легко. По той причине, что все эти «компоненты» валяются в плоском глобальном неймспейсе.
Простейший пример, где банально размер шрифта твоего «компонента» напрямую зависит от того, сколько дивов стоит до него.
<css>
div > div { font-size: 0.8em }
div { font-size: 1em }
</css>
<div>
hello
<div>
hello
<div>
hello
</div>
</div>
</div>
Поэтому любые сторонние «компоненты» засраны !important'ами по самое немогу. И все равно ломаются от любого левого взгляда. За исключением, повторюсь, полутора полноценных систем типа sencha, в которых все управляется JS'ом и каждый прыжок в сторону карается расстрелом.
ЕА>Я вот совсем не фанат html, но есть ощущение, что с появлением flex, grid раскладок как-то с этим стало можно жить. ЕА>В конце-концов VSCode сейчас чуть ли не самый популярный редактор кода, а от Figma тащатся знакомые дизайнеры.
Здравствуйте, Mamut, Вы писали:
ЕА>>Я вот совсем не фанат html, но есть ощущение, что с появлением flex, grid раскладок как-то с этим стало можно жить. ЕА>>В конце-концов VSCode сейчас чуть ли не самый популярный редактор кода, а от Figma тащатся знакомые дизайнеры.
M>Угу. Только в Фигме ровно ноль HTML и CSS и им пришлось с нуля реализовывать свой собственный движок: https://www.figma.com/blog/building-a-professional-design-tool-on-the-web/
Ты ее хоть запускал? Весь UI там на html\css и он не сказать чтоб сильно простой.
На WebAssembly\WebGL — там только непосредственно графический редактор.
Здравствуйте, Mamut, Вы писали:
M>Угу. Только в Фигме
Сорри, но постоянно приводить в качестве аргумента один довольно специфичный и не так чтобы суперпопулярный продукт это перебор. Ты там работаешь что ли?
Здравствуйте, Mamut, Вы писали:
M>exec("rm -rf /") просто так в твое приложение не залетит. А любой CSS в твое веб-приложение может залететь очень легко. По той причине, что все эти «компоненты» валяются в плоском глобальном неймспейсе.
Ну вообще-то shadow dom для этого уже давно придуман и реализован. Никто не заставляет валять компоненты в плоском неймспейсе. В самых популярных фреймворках (react, angular) эта проблема тоже решена по-своему. Я даже не совсем понимаю, о каких компонентах ты говоришь. jQuery? Ну это уровень 10-летней давности. Те проблемы уже решены.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Mamut, Вы писали:
M>>Угу. Только в Фигме
НС>Сорри, но постоянно приводить в качестве аргумента один довольно специфичный и не так чтобы суперпопулярный продукт это перебор. Ты там работаешь что ли?
Да он ее даже не видел
Фигма — это как раз идеальный аргумент за веб-интерфейсы. Весь гуй там чисто на html, и что удивительно, он более навороченный и работает более шустро, чем у десктопных конкурентов.
Но вот на счёт специфичности/непопулярности не соглашусь — очень популярная тулза сейчас для проектирования/дизайна интерфейсов
M>>Угу. Только в Фигме
НС>Сорри, но постоянно приводить в качестве аргумента один довольно специфичный и не так чтобы суперпопулярный продукт это перебор. Ты там работаешь что ли?
Потому что это один из немногих действительно сложных продуктов, по возможности сопоставимых с десктопными продуктами, которые а) существуют в вебе б) работают на ура и г) достаточно открыто рассказывают о том, как они его разрабатывают.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Но вот на счёт специфичности/непопулярности не соглашусь — очень популярная тулза сейчас для проектирования/дизайна интерфейсов
Почему то те дизайнеры, с которыми последнее время приходилось работать, предпочитают zeplin и invisio.
Здравствуйте, alex_public, Вы писали:
_>В нормальных фреймворках вообще не надо беспокоиться о таких вопросах. Там размер окна автоматически масштабируется так, чтобы вместить весь контент. Если же требуемый для этого размер, будет превышать максимально возможный, то автоматически появятся полосы прокрутки. Даже странно видеть такие вопросы в 2019-ом году, а не в начале 90-ых.
+
_>Хотя да, Web GUI действительно так и не дорос пока хотя бы до уровня стандартных контролов Window95...
Тут две точки зрения: с одной стороны фичи вроде шаблонизации и биндинга angular/react/blazor невероятно крутые, фактически магия (вот правда, когда асинхронно подгружаешь данные и у тебя обновляется только нужная часть страницы, и ничего больше — это выглядит невероятно). Но при этом всё это базируется на кривокосой связке HTML/CSS, из которых всё пытаются слепить что-то подходящее для приложений.
M>>exec("rm -rf /") просто так в твое приложение не залетит. А любой CSS в твое веб-приложение может залететь очень легко. По той причине, что все эти «компоненты» валяются в плоском глобальном неймспейсе.
vsb>Ну вообще-то shadow dom для этого уже давно придуман и реализован. Никто не заставляет валять компоненты в плоском неймспейсе.
Ага-ага. Тот самый shadow dom, в котором столько проблем, что текущее мнение звучит как «по возможности избегайте»?
Коротенькое описание лишь части проблем (связанных не только с Shadow DOM'ом):
Вот смотри. Открываешь ты, не знаю, Qt Creator 20-летней давности. Берешь кнопку и кладешь ее на панель X. Берешь всю панель X и кладешь ее на панель Y. Не понравилось, берешь кнопку с панели X и кладешь ее на панель Z.
Кнопка и панели как были, так и остались.
В случае с вебом в общем случае это банально невозможно. Потому что достаточно не такой комбинации миллиона параметров, и твоя кнопка (не говоря о более сложных компонентах) расползется по размерам, получит неправильные шрифты и т.д. и т.п.
Что именно и как эта проблема решена? Ах да, можно сделать вид, что у нас есть shadow dom, но ты даже форму с ним нормально сделаешь (да и без него, Custom Elements в целом только в этом году наконец-то начали участовать в Form Events, с кучей условностей).
vsb>jQuery? Ну это уровень 10-летней давности. Те проблемы уже решены.
Здравствуйте, Mamut, Вы писали:
M>exec("rm -rf /") просто так в твое приложение не залетит. А любой CSS в твое веб-приложение может залететь очень легко. По той причине, что все эти «компоненты» валяются в плоском глобальном неймспейсе.
Я утрирую. А ты описываешь обычный баг, выдавая его за принципиальное ограничение, которое не позволяет пользоваться библиотеками компонентов.
Здравствуйте, Mamut, Вы писали:
M>Это не «обычный баг», а суровая реальность веба. И да, каждая первая «библиотека компонентов» страдает именно из-за этих «обычных багов».
В чем страдание заключается? Кто тот вредитель, что запрещает тебе использовать reset.css, или скрытно после него добавляет какие то глобальные правила?
M>>Это не «обычный баг», а суровая реальность веба. И да, каждая первая «библиотека компонентов» страдает именно из-за этих «обычных багов». НС>В чем страдание заключается? Кто тот вредитель, что запрещает тебе использовать reset.css, или скрытно после него добавляет какие то глобальные правила?
Есть приложение. Со своими стилями. Ты в него собираешься добавить в произвольное место «компонент». Давай, расскажи мне, как все прекрасно и сразу будет работать и как reset поможет избавиться от влияющих на компонент стилей приложения.
Здравствуйте, Mamut, Вы писали:
A>>А ты описываешь обычный баг, выдавая его за принципиальное ограничение, которое не позволяет пользоваться библиотеками компонентов. M>Это не «обычный баг», а суровая реальность веба. И да, каждая первая «библиотека компонентов» страдает именно из-за этих «обычных багов».
Суровая реальность такая суровая, что нет ни одного приложения с использующего стороннюю библиотеку компонентов, а все разработчики пишут свои компоненты с нуля поверх дивов и не любят себя.
A>Суровая реальность такая суровая, что нет ни одного приложения с использующего стороннюю библиотеку компонентов, а все разработчики пишут свои компоненты с нуля поверх дивов и не любят себя.
Этого я не говорил. Но раз ты завел свою стандартную унылую шарманку перевирания моих слов, то adieu.
Здравствуйте, Mamut, Вы писали:
A>>Суровая реальность такая суровая, что нет ни одного приложения с использующего стороннюю библиотеку компонентов, а все разработчики пишут свои компоненты с нуля поверх дивов и не любят себя. M>Этого я не говорил. Но раз ты завел свою стандартную унылую шарманку перевирания моих слов, то adieu.
Да, не говорил. Но что ты хотел сказать своей суровой реальностью, и какое она имеет отношение в обсуждаемому вопросу, мы так и не узнаем.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, bzig, Вы писали:
B>>Ну т.е. опять всё свелось к модальным диалогам, но пусть.
C>Вот тебе другой пример. Есть набор из n элементов, каждый содержит одну картинку (разных размеров и пропорций) и текст (разной длины). Задача — каждый элемент отформатировать и вывести все эти элементы в виде грида, построчно. C>Форматировать элементы и размещать по строкам в гриде надо так, чтобы максимально эффективно использовать площадь экрана — и при условии, что каждая картинка не должна занимать больше половины своего элемента по ширине, но не нужно ее растягивать, если она исходно меньше половины.
C>Расскажи ка мне, как в "охренительно замечательном" html/css это сделать.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Ну во первых, таблицы устарели и вообще это жуткий моветон, коллеги говном закидают.
НС>Во-первых устарели не таблицы, а табличная верстка. Для отображения табличных данных ничего лучше таблиц нет. А во-вторых span с display: table-cell твоих коллег должен удовлетворить.
Вообще-то нет, таблица тут просто не подходит ни в каком виде: она изначально предусматривает фиксированное количество столбцов и строк, и не может менять расположение элементов при изменении размеров контейнера.
Здравствуйте, Mamut, Вы писали:
M>Есть приложение. Со своими стилями. Ты в него собираешься добавить в произвольное место «компонент». Давай, расскажи мне, как все прекрасно и сразу будет работать и как reset поможет избавиться от влияющих на компонент стилей приложения.
Это же обычная практика: взять первое попавшееся приложение и в произвольное место впихнуть первый попавшийся компонент — именно так и разрабатывается ПО.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Somescout, Вы писали:
S>>https://codepen.io/mcraiganthony/pen/NxGxqm
C>- все картинки одинакового размера C>- все описания одинакового размера
Можете попробовать расширить любое описание или задарть размер изображения и посмотреть что будет.
Вот тут это очевиднее (задайте размеры через style= для вложенных div элементов и поменяйте размеры окна).
Здравствуйте, Somescout, Вы писали:
S>Можете попробовать расширить любое описание или задарть размер изображения и посмотреть что будет. S>Вот тут это очевиднее (задайте размеры через style= для вложенных div элементов и поменяйте размеры окна).
Дык уже пробовал. Если картинка маленькая, то она растягивается до размеров ячейки. А это неправильно.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Kernan, Вы писали:
K>>Это понятно. Я как раз про это и говорю, ютуб не тянет кодеки сам, а использует то, что есть на хосте. Как это будет работать? Приходит видео поток который отправялется через браузер на декодирование через конкретный кодек, так? Вопрос, может ли также работать васм, может ли он юзать крипто апи, создавать вёб скоеты и т.п.
_>В принципе, после добавления в wasm поддержки simd, все нужные кодеки можно будет уже писать (а точнее просто скомпилировать, т.к. большинство их них написаны на C/C++ и только некоторые используют ещё и ассемблер для ускорения) прямо на wasm.
Написать декодер и энкодер очень не тривиальная задача безотносительно есть ли там simd или даже GPU (на которых уже есть реализация кодеков, только АПИ дёргай).
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, Ночной Смотрящий, Вы писали:
C>>>Ну во первых, таблицы устарели и вообще это жуткий моветон, коллеги говном закидают.
НС>>Во-первых устарели не таблицы, а табличная верстка. Для отображения табличных данных ничего лучше таблиц нет. А во-вторых span с display: table-cell твоих коллег должен удовлетворить.
S>Вообще-то нет, таблица тут просто не подходит ни в каком виде: она изначально предусматривает фиксированное количество столбцов и строк, и не может менять расположение элементов при изменении размеров контейнера.
Где там в исходной задаче про нефиксированное кол-во столбцов?
B>Где там в исходной задаче про нефиксированное кол-во столбцов?
Задача — каждый элемент отформатировать и вывести все эти элементы в виде грида, построчно. Форматировать элементы и размещать по строкам в гриде надо так, чтобы максимально эффективно использовать площадь экрана — и при условии
Если у вас фиксированное количество столбцов, то это условие не выполняется.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, bzig, Вы писали:
B>>Где там в исходной задаче про нефиксированное кол-во столбцов?
S>
Задача — каждый элемент отформатировать и вывести все эти элементы в виде грида, построчно.
S>Форматировать элементы и размещать по строкам в гриде надо так, чтобы максимально эффективно использовать площадь экрана — и при условии
Как ты будешь делать динамичекское кол-во колонок для текста "разной длины"? Просто абзацы сверху вниз? Ну тоже грид, да
Здравствуйте, bzig, Вы писали:
B>>>Где там в исходной задаче про нефиксированное кол-во столбцов?
S>>
Задача — каждый элемент отформатировать и вывести все эти элементы в виде грида, построчно.
S>>Форматировать элементы и размещать по строкам в гриде надо так, чтобы максимально эффективно использовать площадь экрана — и при условии
B>Как ты будешь делать динамичекское кол-во колонок для текста "разной длины"? Просто абзацы сверху вниз? Ну тоже грид, да
Я в соседнем комментарии примеры приводил (flex-wrap).
Задача — каждый элемент отформатировать и вывести все эти элементы в виде грида, построчно.
S>>>Форматировать элементы и размещать по строкам в гриде надо так, чтобы максимально эффективно использовать площадь экрана — и при условии
B>>Как ты будешь делать динамичекское кол-во колонок для текста "разной длины"? Просто абзацы сверху вниз? Ну тоже грид, да
S>Я в соседнем комментарии примеры приводил (flex-wrap).
Ты (ну или автор) ввёл понятие минимального размера ячейки, которого не было в исходном задании (которое было очень размыто само по себе). В любом случае, Кодеалот тут много чепухи нагородил про невозможность и в свою задачу сформулировал достаточно размыто, чтобы потом было куда слиться.
Здравствуйте, vsb, Вы писали:
vsb>Чувствую, скоро для обычного HTML достаточно будет написать <script src="https://mozilla.org/firefox.wasm"></script> который отрисует весь HTML и отработает весь JavaScript на движке, написанном на WASM. А написание полноценного браузера наконец-то станет реалистичной задачей, а не как сейчас, когда гигантские корпорации вроде Microsoft выбрасывают свои движки, т.к. это слишком сложно.
Создать WASM, чтобы запускать его в браузере вместо отображения HTML, на WASMе написать... хм... браузер для отображения HTML?
Здравствуйте, Marty, Вы писали:
M>Создать WASM, чтобы запускать его в браузере вместо отображения HTML, на WASMе написать... хм... браузер для отображения HTML?
Или настраиваемое семейство браузеров требуемой тяжеловесности для каждой конкретной задачи. ))
Можно же посмотреть, сколько элементов опрашивается в процессе рендеринга при раздаче CSS — этот как тот маляр с Z-строками в Си, сплошная бесполезная беготня по двум графам — графу DOM и графу CSS.
Как ни крути, но сама система рендеринга в современных браузерах неэффективна by desing.
Для каждой такой страницы подобное сопоставление могло бы происходить еще на этапе разработки, на стадии компиляции, а не в рантайме.
А для сильно динамических страниц более уместным было бы оперирование предвычисленными объектами-стилями, а не строковыми идентификаторами их классов, провоцирующими повторную беготню по двум графам.
vsb>https://makepad.github.io/makepad/ vsb>ИМХО это то, что действительно можно называть Web 2.0. Не эволюционное развитие HTML/CSS/JavaScript, тянущееся с 90-х годов, а революционное, причём прекрасно работающее здесь и сейчас во всех браузерах, даже в Safari на айфоне. Наслаждайтесь взглядом в будущее.
Какое-то вырвиглазное издевательство светло-серым текстом по тёмно-серому фону, надписи разблурены до нечитаемости, в бездействии выжирает на 80% все ядра. Ещё и анимации меееееееедленно продрыгиваются по 3 секунды на каждое нажатие в дереве. Это надо чтобы трансгейдеры покусали, чтобы таким начать восхищаться?
Здравствуйте, Osaka, Вы писали:
O>Какое-то вырвиглазное издевательство светло-серым текстом по тёмно-серому фону
Всё хорошо видно.
O>надписи разблурены до нечитаемости
Рендеринг шрифта отличный.
O>в бездействии выжирает на 80% все ядра
У меня 2% от одного ядра. Если беспрерывно щёлкать по элементам, чтобы оно всё там скакало, до 6% растёт.
O>Ещё и анимации меееееееедленно продрыгиваются по 3 секунды на каждое нажатие в дереве.
У меня примерно за полсекунды проходит анимация, очень плавно.
>Это надо чтобы трансгейдеры покусали, чтобы таким начать восхищаться?
Лучше скажи, что ты сделал со своим компьютером, если этот сайт у меня прекрасно работал на старом смартфоне 7-летней давности.
vsb>Лучше скажи, что ты сделал со своим компьютером, если этот сайт у меня прекрасно работал на старом смартфоне 7-летней давности.
Проапгрейдил до 5950, запустил в виртуалке через которую 10 лет читаю все г-сайты.
Здравствуйте, vsb, Вы писали:
vsb>...Чувствую, скоро для обычного HTML достаточно будет написать <script src="https://mozilla.org/firefox.wasm"></script> который отрисует весь HTML и отработает весь JavaScript на движке, написанном на WASM. А написание полноценного браузера наконец-то станет реалистичной задачей, а не как сейчас, когда гигантские корпорации вроде Microsoft выбрасывают свои движки, т.к. это слишком сложно.
раз уж подняли тему через 3,5 года.
Может кто рассказать или кинуть обзор, что с wasm в 2023? насколько технология улучшилась? продвинулась ли в массы? Какие у неё перспективы?
Здравствуйте, AntoxaM, Вы писали:
AM>Может кто рассказать или кинуть обзор, что с wasm в 2023? насколько технология улучшилась? продвинулась ли в массы? Какие у неё перспективы?
Не совсем про wasm, но релевантно — недавно зарелизили WebGPU в хроме. Это гораздо более близкий к железу способ работы с видеокартой, чем WebGL. Помимо очевидной работы с графикой позволяет на видеокарте считать. Пока ничего интересного с ним не видел, но в целом это потенциально позволяет уже релизить игры AAA уровня в браузере. Конечно падение производительности, в сравнение с нативной программой, неизбежно, за безопасность надо платить. Но, как мне кажется, вполне приемлемая цена.
Про wasm — слышал только, что с GC всё потихоньку идёт к завершению. А так, если не считать GC, то там уже всё давно готово, улучшать можно только мелочи. Про массы — хз, мои вселенские прогнозы пока остаются фантастикой, а так своё место он занял. Когда GC зарелизят, ожидаю всплеск — будут переносить практически все языки с GC на wasm. И лет через 5-10 это даст качественное изменение инструментария, когда уже локально какой-нибудь питон ставить просто не нужно будет, всё будет в браузере, от среды выполнения до IDE.
Здравствуйте, vsb, Вы писали:
vsb>Про wasm — слышал только, что с GC всё потихоньку идёт к завершению. А так, если не считать GC, то там уже всё давно готово, улучшать можно только мелочи. Про массы — хз, мои вселенские прогнозы пока остаются фантастикой, а так своё место он занял. Когда GC зарелизят, ожидаю всплеск — будут переносить практически все языки с GC на wasm. И лет через 5-10 это даст качественное изменение инструментария, когда уже локально какой-нибудь питон ставить просто не нужно будет, всё будет в браузере, от среды выполнения до IDE.
Угу чем это будет отличаться от выполнения .exe в песочнице?
Тот же MAUI?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
vsb>>Про wasm — слышал только, что с GC всё потихоньку идёт к завершению. А так, если не считать GC, то там уже всё давно готово, улучшать можно только мелочи. Про массы — хз, мои вселенские прогнозы пока остаются фантастикой, а так своё место он занял. Когда GC зарелизят, ожидаю всплеск — будут переносить практически все языки с GC на wasm. И лет через 5-10 это даст качественное изменение инструментария, когда уже локально какой-нибудь питон ставить просто не нужно будет, всё будет в браузере, от среды выполнения до IDE.
S>Угу чем это будет отличаться от выполнения .exe в песочнице?
Я не знаю, что такое песочница для .exe.
1. Браузер есть здесь и сейчас и устанвлен у всех. Про песочницу даже я, программист, не знаю, а уж рядовой пользователь и подавно.
2. К браузеру у людей есть доверие. К запуску непонятных exe доверия нет.
3. До браузеров (пока?) антивирусы не добрались. exe сегодня запустить это целая эпопея.
4. exe работает на windows с определённой архитектурой. Браузер работает везде, включая айфоны. Любая ОС, любая архитектура. Это то, о чём мечтала Java: write once, run anywhere.
5. Песочница браузера это самая мощная защита в мире. Лично у меня даже к изоляции виртуальных машин такого доверия нет, как к песочнице браузера. В браузере я готов открывать любой сайт. В виртуальной машине я не готов запускать любую программу.
S>Тот же MAUI?
Ну для кросс-платформенных приложений подходов миллион. Начиная от древних Delphi и Qt. Это всё же другое.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Serginio1, Вы писали:
vsb>>>Про wasm — слышал только, что с GC всё потихоньку идёт к завершению. А так, если не считать GC, то там уже всё давно готово, улучшать можно только мелочи. Про массы — хз, мои вселенские прогнозы пока остаются фантастикой, а так своё место он занял. Когда GC зарелизят, ожидаю всплеск — будут переносить практически все языки с GC на wasm. И лет через 5-10 это даст качественное изменение инструментария, когда уже локально какой-нибудь питон ставить просто не нужно будет, всё будет в браузере, от среды выполнения до IDE.
S>>Угу чем это будет отличаться от выполнения .exe в песочнице?
vsb>Я не знаю, что такое песочница для .exe.
Да ну? То есть Браузер с плагинами это что?
При этом для мобильных устройств предпочитают именно приложения, а не сайты в виде приложений.
vsb>1. Браузер есть здесь и сейчас и устанвлен у всех. Про песочницу даже я, программист, не знаю, а уж рядовой пользователь и подавно.
Браузер и есть песочница не более. А wASM это тот же исполняемый файл в песочницею vsb>2. К браузеру у людей есть доверие. К запуску непонятных exe доверия нет.
У людей есть доверие к песочнице, а как это будет называться не важно. vsb>3. До браузеров (пока?) антивирусы не добрались. exe сегодня запустить это целая эпопея.
Еще раз на то и нужна песочница, что бы приложение не лезло куда не надо.
Но вот плагины нужны, что бы обходить запреты. В том числе для скачивания и отправки файлов.
vsb>4. exe работает на windows с определённой архитектурой. Браузер работает везде, включая айфоны. Любая ОС, любая архитектура. Это то, о чём мечтала Java: write once, run anywhere.
Под exe я подразумевал исполняемый файл. Есть куча кроссплатформенных приложений тот же MAUI.
Уже есть куча виртуалок. Те же Docker ы vsb>5. Песочница браузера это самая мощная защита в мире. Лично у меня даже к изоляции виртуальных машин такого доверия нет, как к песочнице браузера. В браузере я готов открывать любой сайт. В виртуальной машине я не готов запускать любую программу.
То есть ты не доверяещь виртуалке, а браузерам с плагинами да? S>>Тот же MAUI?
vsb>Ну для кросс-платформенных приложений подходов миллион. Начиная от древних Delphi и Qt. Это всё же другое.
Ты спутал с лазарусом. Но там нет единого гуя.
Я про то, что суть браузера это по сути песочница для выполнения JS и плагинов или отображения HTML.
Если будет кросплатформенный ГУЙ то для него сделают песочницу и будет называться Web 3.0
Или можешь выполнить приложение на сервере, а от него получать экраны как в Cloud играх или терминальных сессиях.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали:
vsb>https://makepad.github.io/makepad/
vsb>Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро. Размер кода полмегабайта. Для мини-IDE на мой взгляд очень неплохо.
Здравствуйте, Pauel, Вы писали:
vsb>>https://makepad.github.io/makepad/
vsb>>Код написан на Rust и скомпилирован в WASM. Интерфейс рисуется на Canvas через WebGL (т.е. никакого HTML, всё включая рендеринг шрифтов и моргание курсора рисуется кодом). Работает действительно быстро. Размер кода полмегабайта. Для мини-IDE на мой взгляд очень неплохо.
P>А как там редактировать?
Ну берёшь и редактируешь, кнопки жмёшь. У меня вроде работает.
Здравствуйте, Pauel, Вы писали:
P>>>А как там редактировать?
vsb>>Ну берёшь и редактируешь, кнопки жмёшь. У меня вроде работает.
P>Я понял. Вобщем, эта мулька в качестве редактора использует TextArea. Т.е. не совсем честная ide.
Да, прикольно, сейчас увидел, как-то подставляют textarea туда, где курсор. Но похоже, что только для ввода используется, рендерят — сами.
Здравствуйте, vsb, Вы писали:
vsb>Да, прикольно, сейчас увидел, как-то подставляют textarea туда, где курсор. Но похоже, что только для ввода используется, рендерят — сами.
А где у них этот рендерер находится? шота я не могу понять.
Здравствуйте, Pauel, Вы писали:
vsb>>Да, прикольно, сейчас увидел, как-то подставляют textarea туда, где курсор. Но похоже, что только для ввода используется, рендерят — сами.
P>А где у них этот рендерер находится? шота я не могу понять.
Ну <canvas> на всю страницу, это оно. Если вопрос про код — то в makepad_wasm.wasm на 460 kB.
)
У тебя монитор расположен вертикально? Или же у тебя шрифт, который надо разглядывать в лупу? ))) У меня там строк 50 влезает где-то. 
