Comments 49
Значит ли это, что в скором времени будут разработчики компилировать весь JavaScript в wasm для улучшения производительности? И канут в реку uglifier и подобные?
нет, не значит, wasm быстрый засчет более лёгкой среды исполнения. JS требует слишком много всего для исполнения, что бы его исполнить
Интересно как происходит hot-swapping одного работающего кода на другой.

Самый простой вариант: за счет трамплина.
Первой инструкцией неоптимизированной функции будет переход на следующую инструкцию.
Для замены на оптимизированную версию достаточно поменять адрес перехода.

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

Фактически меняется указатель на функцию.
Если в другом потоке выполняется старая версия, то она продолжит выполняться, нормально завершится и вернет управление тому, кто её вызвал.
Оптимизированная версия хранится по другому адресу.

А в Chrome есть что-то подобное? И та крутая технология рендеринга, которую добавили в FF недавно — в Chrome что-то предвидится из того же ряда?

Пока про инициативу RIIR'нуть Chromium не приходилось слышать. Там все больше на отладке сконцентрировались если не ошибаюсь
Было бы хорошо, что бы со временем была представлена хорошая альтернатива JS. JS и есть главный bottle neck, только об этом не говорят — боятся.

Да в общем-то альтернатива уже есть — AssemblyScript(более строго типизированный TypeScript), который компилируется в WASM.
Да, совсем с полпинка перекомпилить код действующего TS-проекта в WASM-код не выйдет, но в перспективе это проще, чем, например, переписать все на Swift | C++ | Python | etc.

Ну что Вы говорите такое?


Во-первых, язык сам по себе не может быть bottle neck, т.к. это всего лишь синтаксис и в таком случае bottle neck — это разработчик который не знает языка.


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


Ну и в-третьих про "все переписать заново" уже не мало статей написано и граблей истоптано. Не стоит оно того. Лучше приложить усилия для создания чего-то лучшего.

Вы так наехали на меня, будто бы я сказал, что от JS можно будет отказаться. Я имел ввиду, что стоит обратить внимание на TypeScript. Помимо очевидных преимуществ языка есть еще одно — возможность какую-то часть кода скомпилировать в WASM.

Во-первых, язык сам по себе не может быть bottle neck, т.к. это всего лишь синтаксис и в таком случае bottle neck — это разработчик который не знает языка.

Язык — это внезапно не только синтаксис, но и семантика. И если язык, например, слабо динамически типизированный (как JS), то JIT'ить его будет сильно труднее, чем сильно динамически типизированный язык (как какой-нибудь питон) или, тем более, чем сильно статически типизированный (тысячи их, и, если будет не лень, поинтересуйтесь, зачем нужен strict aliasing в плюсах).
Теперь можно изобретать собственный DOM и рисовать прямиком на canvas. То есть делать это с меньшей болью и большей производительностью, чем раньше.
Знаю попервой клоны MS Office тоже рисовали таблицы через канвас. J2ME это же Java-апплеты дл браузера или вы на бэкенде рисовали, а на фронт изменения картинки слали?

Уверены, что сможете сделать это быстрее и лучше, при этом соблюдая все те же требования? То есть: возможность копирования текстовых блоков, относительные размеры, чтобы на больших и маленьких экранах хорошо смотрелось и остальные возможности CSS?

UFO landed and left these words here

Тем, кому эти требования действительно не нужны (браузерные игры, например), уже давно переползли на Canvas.


А как вы будете реализовывать tab-навигацию по полям ввода, нарисованным на сanvas, да при этом чтобы не медленнее, чем на JS, я не представляю.

Я, конечно, только теоретически себе это представляю — но есть мысль, что можно скомпилировать целый графический фреймворк (Qt/wxWidgets/nuklear/...) в WebAssembly, снабдив его бэкендом для вывода на canvas. Получатся обычные приложения. Не уверен по поводу скорости навигации по полям, но подозреваю что layout и отрисовка во многих фреймворках проще и шустрее чем махина DOM с CSS.

но подозреваю что layout и отрисовка во многих фреймворках проще и шустрее чем махина DOM с CSS.

Интересно, чем вызвано такое подозрение? Всё, что не содержит ни грамма JS — автоматически становится быстрее?

На том что оно, в отличие от HTML, никогда не разрабатывалось для того чтобы форматировать текст, быть может? Должна быть разница между деревом DOM с CSS, где какая-нибудь неосторожная вставка элемента в таблицу будет постоянно вызывать reflow документа, и фреймворком, который консервативно обновит только один виджет. (Я просто напомню, что речь вовсе не о JS, а об отрисовке приложения в canvas или родными средствами браузера. Вы вполне можете использовать emscripten чтобы скомпилировать этот фреймворк в JS, кто вам мешает.)

Итак:


  1. Пишем на canvas, на котором нельзя сказать "передвиньте линию X на N пикселей вниз", только полный repaint
  2. Фреймворк, быстрый за счет того, что умеет инкрементально обновлять картинку.

Не видите в этих друх пунктах противоречия?

Не вижу. Просто к сведению, рендерер браузера тоже не может обойтись без формирования кадра перед тем как он (обычно аппаратно) будет брошен на экран. Если фреймворк использует WebGL, то, грубо говоря, он использует те же самые примитивы, что и сам браузер, и доступ к оборудованию.


Реальные затраты, о которых я говорю, это разница между фреймворком дать виджету команду обновить свой вид — например, кнопке себя перерисовать, когда фреймворк даже не будет заморачиваться layout и обновлением, скажем, дисплей-листов других виджетов — и reflow (не repaint) в браузере, когда вы неосторожно изменяете шрифт на кнопке и в ответ рендерер перелопачивает DOM, заново определяет координаты и границы для всего, прозрачность и прочая, и прочая.


Да, вы можете приложить усилия и попытаться минимизировать количество чихов, на которые ваша страница делает reflow. Но я не уверен, что вы, верстая страницу, серьёзно на этом сосредотачиваетесь. Вы постоянно держите в голове, что событие hover (проводка мыши) может вызвать reflow? А простой ввод данных в текстовом поле? А просто запрос ширины элемента? И ещё много-много всего, о чём пишут статьи и руководства по чёрной магии для оптимизации рендеринга сайтов. Не запрашивайте ширину. Остерегайтесь добавлять/удалять элементы DOM из JS. Не ходите к броду на полнолуние… Но если вы всё это держите в голове, и это не вызывает дискомфорта, то я рад.

И ещё много-много всего, о чём пишут статьи и руководства по чёрной магии для оптимизации рендеринга сайтов.

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


Это правило следует из банальной геометрии и логики, которая работает как для декстопных layout-фреймворков, так и для браузерных. Какого-то особого преимущества, позволяющего десктопным решениям делать это быстрее, я не вижу.

Как это правило соотносится с :hover? Как соотносится со вводом текста в поле? Как соотносится с использованием анимаций из CSS3, где каждый кадр вызывает reflow? Как соотносится с чтением (sic!) свойств ширины/высоты элементов? Всё это не изменяет / не обязано изменять геометрию, если что.


Преимущество десктопных фреймворков в том, что они проектировались для разработки приложений, а не эволюционировали из языка разметки текста. Вам ниже domix32 правильно написал, DOM/CSS — это бутылочное горлышко веба. Для одних задач он подходит хорошо, для других, таких как приложения — хуже.

Как это правило соотносится с :hover? Как соотносится со вводом текста в поле Как соотносится с использованием анимаций из CSS3, где каждый кадр вызывает reflow?

До тех пор, пока эти события не вызывают изменения размеров блоков, все происходит быстро, анимации и интерфейс в целом остается плавным.


Как соотносится с чтением (sic!) свойств ширины/высоты элементов?

Опять же, значения размеров можно читать сколько угодно, если они не меняются по 10 раз в секунду.


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

Декстопные декстопы и прилагательные приложения. А какие-то конкретные ноу-хау есть? Инкрементальная перерисовка не в счет, в это и браузеры умеют. Reflow, которым вы тут пугаете, не так страшен, как вам кажется.

Извините, но если выбирать между вашими совершенно неконкретными заверениями, что "в целом остаётся плавным" и "не так страшен как вам кажется" и массой статейдаже не могу сказать сколько их вокруг) по борьбе с лишними reflow и обилием нюансов, и конкретными заверениями Мозиллы и Гугла о том что reflow таки страшен (а гугл вдобавок ещё и противоречит вам, говоря что он обычно проводится для всего документа а не инкрементально), то я скорее прислушаюсь к Гуглу и Мозилле.


Декстопные декстопы и прилагательные приложения.

Вы бы так свою область знали как вы ёрничать умеете. Раз такие пироги, то и спорить больше не о чем — верьте чему хотите, я пас.

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


Возьмем, например, Хабрахабр, здесь справа есть кнопка обновления комментариев. Если на нее нажать, то произойдет перерисовка страницы, но ничего страшного не случится, система не затормозит, а вентиляторы не взвоют.


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

Возьмем, например, Хабрахабр, здесь справа есть кнопка обновления комментариев. Если на нее нажать, то произойдет перерисовка страницы, но ничего страшного не случится, система не затормозит, а вентиляторы не взвоют.

При этом набивать здесь комментарии после осеннего редизайна в тредах, где этих комментариев больше полутысячи, внезапно стало очень больно: буквы появлялись с ощутимым лагом. Не на микроволновке их писал, причём, а на i7 3930k.

Хотя, может, починили уже, не знаю.

Если использовать последню версию GL контекста, то если не ошибаюсь согласно поддерживаемому стандату OpenGL обновление линии будет происходить локально.
Интересно было бы посмотреть разницу между JS и WASM версиями quake в этом плане.

Ради формочки и табов можно поверх канваса ещё ноду показать. ЕМНИП ещё вроде можно повесить preventDefault() на обработчик и табать внутри канваса как заблагорассудится.
А вообще изначально шла речь о том что стандартный DOM является bottleneck и соственная реализация через какие-нибудь Scene Graph будут на порядок быстрее. Тем более что часть из обращений можно рассчитать на этапе компиляции.

реализация через какие-нибудь Scene Graph будут на порядок быстрее.

Если бы это действительно было так, то наверное крупные компании типа Facebook или Google уже бы выпустили свои подобные решения?


Единственное, что я видел в этом направлении, это PureQML, который рендерит QT-виджеты прямо в DOM.


Может быть, DOM не такой уж и медленный, как его принято в этом треде называть?

UFO landed and left these words here

Выпускали и выпускают. Настольные приложения называются. guai упомянул мобильные, но и без ограничений мобильных платформ — если у компании есть приложение, и они хотят его шустрым, то они выпускают обычное настольное. (Да, у веба есть преимущество, это платформа, которая есть везде и которая не требует средств распространения/инсталляции — поэтому некоторые жрут кактус и героически сражаются с DOM, создавая офисные пакеты в вебе, но если вы думаете, что они получаются быстрее настольных...)

Тут есть нюансы с поддерживаимость технологии разными системами/браузерами. Асинхронная подгрузка ресурсов туда же. И опять же — работа с собственым вариантом DOM может и быстрее, но есть ряд других проблем. Те же 60 FPS на канвасе сложно добиться при большом количестве графических элементов.

И все же: зачем свой велосипед, если нативная платформа нормально работает?


Давайте серьезно: вот эта самая дискуссия происходит на платформе с использованием обычного DOM, HTML, CSS и всё работает и не тормозит!

Запилить собственный DRM, например. Или вовсе игры, в том числе и 3D. Куча нод на экране нехило просаживает память из-за кучи свойств и если очень захочется редактировать гигантские таблицы а ля excel, да ешё и с хитрыми формулами на несколько листов, есть вероятность уронить вкладку. Можно вынести нагрузку на серверную сторону с меньшими потерями памяти и возвращать готовую картинку на фронт, например. Бегать с `querySelector` по DOM и на основе `value` вычислять значения вероятно более затратно нежели скажем в типизированном массиве по трем индексам проскочить.
Хотя и на чистом css тоже не так давно шутер сделали. Правда не каждая машина осиливает отрисовку.
Или вовсе игры, в том числе и 3D.

… и мы возвращаемся к моему изначальному комменту. Да, есть варианты, где рисование на canvas дает преимущество. Там уже есть готовые движки, они конечно же выиграют от WebAssembly.


Но мнение, что "WebAssembly придет, все напишут свой DOM с блекджеком, а об обычном DOM все забудут", я не разделяю.

Да никто не утверждал такого. Утверждалось что общение с DOM является бутылочным горлышком в производительности страницы и что собственная реализация + canvas могут быть производительнее. Естественно, что любой из имеющихся вариантов нужно применять к месту.
Так быстро ускорили, что пользоваться стало абсолютно не возможно. Пришлось откатиться до 55 версии и отключить обновления…
По прошествии тридцати лет — отрасль таки созрела?..
Михаэль Франц шлёт всем инноваторам горячий привет из поздних 80-х…
Если microsoft создаст ещë более быстрый и понятный интерфейс — мир создаст ещë более тупого пользователя )
Only those users with full accounts are able to leave comments. Log in, please.