эволюция ХТМЛ - отказ от ДОМ переход на ХОЛСТ
 

или это уже тогда революция?

поисковикам хер, а в остальном по моему охерительно

ДОМ предлагаю использовать только для видео и айфреймов

соответственно ЦСС исчезает как явление, и эволюционирует в нечто иное

Зачем?

Для полных даунов на пальцах.
Холст это и есть ДОМ просто новая его часть.
Дом предоставляет свойства и методы используя которые ты можешь работать с холстом.
Нет дома - нет возможности работать с canvas.
Для полных дибилоидов.
var ctx = canvas.getContext("2D")
getContext - это метод DOM т.е. используя этот метод объектной модели ты можешь создать новое свойство в объектной модели документа контекст т.е. свойство которое тоже находится в DOM

я об отказе использовать медленный остальной Дом и перенос всей тяжести приложения на Холст

Дом медленный и трудный

проще говоря - в документе используется только Холст Айфрейм и Видеоплеер - это сильно упрощает и ускоряет

Где код? Может хватит воздух сотряхать фантазируя на тему абстрактных коней в вакууме и начать что-то делать? Хочешь такую штуку - бери да пиши, т.к. за тебя это никто делать не будет.

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

Чо? DOM отрисовывается напрямую браузером. Гипотетический canvas-DOM будет сперва проходить обработку JS-движком, и только затем попадать на отрисовку к браузеру. Тебе не кажется, что первое несколько быстрее?

Справедливости ради, стоит отметить, что если написать низкоуровневую реализацию на cavas context webgl под конкретную задачу, то действительно можно добиться профита. Насколько мне известно, что последняя версия табличного процессора в Google Docs работает именно так. Также ещё можно привести в пример Google Maps, pdf.js ... вообще много где это юзается, НО

С точки зрения работы браузера, то когда он рендерит разметку, то он также работает с холстом, где всё также рисует (а нам даёт удобное абстрактное API), и более того, что все современные браузеры используют аппаратное ускорение графики для многих вещей (трансформации CSS, рендеринг картинок и т.д.), а в будущем будут применять для всего. Например новый браузерный двиг от Mozilla - Servo будет так делать.

Также следует отметить, что браузеры редко тормозят сами по себе, а по вине горе программистов :)

Вывод: для конкретных задач, где уже не помогают никакие оптимизации, то написания своего механизма рендеринга с очень ограниченными возможностями, но заточенные под определённую задачу безусловно даст профит, но если javascriptus-maximus-∆ хочет написать "браузер в браузере", то спешу его расстроить - это идиотизм, ибо если ты реализуешь весь уровень абстракции, который даёт браузер самостоятельно на canvas, то работать быстрее это не будет, а наборот, т.к. JS сам по себе медленней чем нативные реализации, нет нормальных потоков и ещё кучи всего.

А вообще javascriptus-maximus-∆ просто ещё супер зелёный, не может понять многих вещей - вот и фантазирует на тему "понни в астрале" :)

Ну а это уже просто бред совсем-совсем начинающего "разработчика" :)

быстрая - только потому, что видюха, верно? супер параллельность :)

скажу иначе - 2D-игры лучше писать на Холсте
соответствнно любое 2D приложение лучше делать на Холсте

лучше - в смысле быстрее работают

что такое интерфес - это графика и текст в произвольном сочетании - всё это прекрасно работает на канвасе
необходимое обязательное дополнение к канвасу - просмотр видео и айфреймов