В последнее время было немало горестных рассуждений о последствиях решения Google использовать HTML-элемент <canvas> для рендеринга всего, что видно на экране при работе с Google Docs. И то, что это многих беспокоит, вполне понятно. Когда-то веб был задуман как система для работы с тщательно структурированной информацией, полной осмысленных метаданных и рассчитанной на совместное её использование многими людьми. Но, вместо этого, тот веб, который мы видим сегодня, представляет собой довольно сложно и запутанно устроенные приложения, которые работают в браузерных «песочницах».
![](https://miro.medium.com/max/2448/1*ndZTk64e9TmkQL2l-ySNtg.png)
Решение Google, которое заключается в том, чтобы перейти от вывода на страницы HTML-элементов к рисованию пикселей на <canvas>, нельзя назвать чем-то таким, чего раньше никто не видел и не пробовал. Другие передовые веб-приложения уже вышли далеко за пределы традиционных схем работы с HTML-элементами. Так, в Google Maps вывод данных на <canvas> используется уже многие годы. В VS Code для отрисовки идеального интерфейса терминала тоже используется <canvas>. А в подающем надежды наборе инструментов Google Flutter, который позволяет создавать кросс-платформенные интерфейсы, в веб-браузере, по умолчанию, используется рендеринг с использованием <canvas>.
Но в этот раз происходящее вызывает несколько иные ощущения. А именно, появляется такое чувство, что рендеринг в <canvas> и другие современные технологии, вроде WebAssembly, увели нас за точку невозврата. Все привыкли к схеме работы, когда страница загружает, в виде обычного текста, JavaScript-код, который выполняется, взаимодействуя с HTML-элементами, видимыми в «инструментах разработчика». Сейчас возникает такое впечатление, что это — лишь небольшой этап на пути постоянно развивающихся технологий веб-разработки.
Или, если сказать иначе, мы принимаем как должное то, что можем читать тексты JavaScript-программ, которые выполняются в наших браузерах, то, что можем исследовать HTML-разметку и CSS-код, которые лежат в основе того, что мы видим на экранах. Но все эти аспекты веб-разработки могут быть не более чем коротким эпизодом истории программирования.
Что же сейчас происходит?
Говорят, что когда компания Google куда-то идёт, все остальные следуют за ней.
Лет 15 назад Google была первопроходцем в деле использования асинхронных JavaScript-вызовов (это потом назвали «AJAX»). Компания использовала какие-то новейшие для своего времени технологии в Gmail и Google Maps, а позже эти технологии превращались в фундаментальные основы веб-разработки. Теперь, благодаря переходу Google к выводу интерфейсов на <canvas>, этот подход к формированию UI начинает выглядеть совершенно приемлемым в глазах веб-разработчиков нового поколения.
Прямо сейчас перед тем, кто хочет использовать <canvas> для каких-то серьёзных дел, стоят довольно-таки высокие барьеры. В ходе работы над Google Docs специалисты компании сделали новые реализации целой кучи механизмов, которые многие программисты обычно воспринимают как нечто само собой разумеющееся. Это, например, точные инструменты для создания макетов, средства для выделения текста, системы проверки правописания, механизмы оптимизированной перерисовки экранных элементов. В наши дни в мире существует всего несколько компаний, которые способны провести работы такого масштаба лишь ради надежды на возможное улучшение производительности некоего решения.
И самой сложной и интересной задачей в этом проекте является обеспечение доступности сайтов и приложений для людей с ограниченными возможностями. Для того чтобы приложение выполняло бы указания нормативных документов по доступности, оно должно соответствовать определённым требованиям. Это нужно для компаний, которые должны соответствовать требованиям, необходимым для участия в правительственных контрактах, вроде Google, и, кроме того, важно для тех компаний, которые стремятся быть хорошими «жителями веба». Версия Google Docs, основанная на <canvas>, несмотря ни на что, должна иметь отличную поддержку средств для чтения с экрана и инструментов для увеличения фрагментов экрана. Она должна поддерживать работу в режиме высокой контрастности, должна содержать механизмы, помогающие работать с ней людям с ограниченными двигательными возможностями. Один из способов реализации этих возможностей заключается в создании невидимой DOM, которая воспроизводила бы реальные данные, выводимые в <canvas>, но существовала бы только ради обеспечения правильной работы ассистивных технологий. И, конечно, две эти модели должны быть идеально синхронизированы друг с другом.
В наши дни нет единого, стандартного решения, которым разработчики могли бы воспользоваться для реализации ассистивных возможностей приложения, которое использует <canvas> для формирования интерфейса. Но по мере того, как этот подход к созданию интерфейсов будет набирать популярность, ситуация изменится в лучшую сторону. И никто не знает о том, насколько быстро произойдут эти изменения. То, что Google использует <canvas> для создания интерфейсов, привлечёт к соответствующим вопросам внимание, этим заинтересуется множество разработчиков, будут развиваться сопутствующие технологии. Потом появятся библиотеки, а ещё через некоторое время, возможно, будут созданы соответствующие стандарты и API. К закону Этвуда можно сделать дополнение, с которым он будет выглядеть так:
Любое приложение, которое может быть написано на JavaScript, в конце концов будет написано на JavaScript, даже если для этого JavaScript понадобится усовершенствовать.
Если посмотреть на общую картину происходящего, то окажется, что шаг Google — это лишь один из этапов большого пути. Всё время существования веба амбициозные разработчики пытаются вырваться из ограничений, навязываемых им моделью веб-страницы, и отойти от абстракции HTML. Раньше это выражалось в использовании плагинов вроде Flash. Но с самого начала шла тихая, но никогда не прекращающаяся война между двумя точками зрения на веб, между теми, кто воспринимал его как хранилище структурированных документов, и теми, кто видел его платформой, обеспечивающей функционирование контейнеров для приложений.
Самым драматическим моментом этого противостояния стала смерть XHTML — строгого (но нескладного) результата переосмысления веб-стандартов, призванного дать вебу семантическую чистоту такого уровня, до которого никогда не добирался классический веб. Стандарт XHTML был почти что провозглашён будущим веба, но потом он потерпел полное и внезапное поражение от стандарта, воплощающего иной взгляд на веб, от HTML5.
В соответствии с HTML5 в понятие «веб-стандарт» входит всё что угодно, по поводу чего пришли к согласию производители разных браузеров. В частности, речь идёт о множестве JavaScript-API, рассчитанных на решение различных практических задач. Из этих API можно, как из кирпичей, строить функционал веб-страниц. Среди этих API можно отметить, например Geolocation, Web Storage, WebSockets, Web Workers. В HTML5, конечно, появились и некоторые новые семантические описательные элементы, но единственным по-настоящему многообещающим новшеством стандарта, связанным с встраиванием информации в веб-страницы, была поддержка микроданных (microdata). Её, правда, довольно быстро из стандарта убрали (в основном из-за того, что Google и Apple не были заинтересованы в реализации этого новшества).
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/e10/a18/310/e10a18310c6827ffe480a957c3a60206.jpg)
Что скрывается за маской HTML5?
Рендеринг в <canvas> — это, очевидно, полная противоположность веб-страницы, содержимое которой оформлено с помощью семантических элементов. Это — чёрный ящик, который не даёт браузеру никакой информации о том, что в нём может происходить или происходит.
Из-за этого вся власть оказывается в руках приложений. То, что управляет отдельными пикселями, может абсолютно всё: обходить автоматизированные инструменты, бороться с блокировщиками рекламы, ограничивать браузерные возможности вроде поиска по тексту или его копирования. Это — JavaScript-реинкарнация Flash и Silverlight, для работы которой не нужно устанавливать что-то, кроме самого браузера, и при использовании которой можно не думать о вопросах совместимости.
Если вам кажется, что широкое распространение рендеринга в <canvas> — это большое событие, то знайте, что оно выглядит не таким уж и значительным в сравнении с другими тенденциями веб-разработки. И самой крупной из таких тенденций, без сомнения, является применение WebAssembly, то есть — низкоуровневого бинарного формата инструкций, который понятен всем современным браузерам.
Если вы заглянете на страницу, работа которой основана на WebAssembly, то окажется, что на ней выполняется предварительно скомпилированный код, уровень которого лишь немногим выше уровня ассемблера. И такой код, определённо, если сравнить его даже с очень сильно минифицированным образцом JS-кода, гораздо сложнее прочесть человеку. WebAssembly используется для запуска в браузере игр, для декодирования генома, на WebAssembly основаны высокоуровневые фреймворки вроде Blazor. «Непрозрачные» веб-приложения, которые беспокоят пуристов, это — мелочь в сравнении с тем, что обещает нам WebAssembly. Речь идёт о выводе производительности веб-приложений, работающих в браузерной «песочнице», практически на уровень нативных приложений.
В наши дни WebAssembly-программам для доступа к DOM нужен корявый промежуточный JavaScript-слой. Но вспомним о проекте WebGPU, об оптимизированном последователе теперь заброшенного WebGL. У WebGPU и WebGL есть одна важная общая черта: и тот и другой проекты дают возможность оптимизированного рендеринга на <canvas>. Если объединить это с аппаратным ускорением графики, которое реализовано в браузерах, то получится, что в нашем распоряжении оказался низкоуровневый механизм вывода графики, который можно использовать для создания веб-приложений нового поколения. Или, что больше похоже на правду, нового поколения библиотек и фреймворков, которые лягут в основу новых веб-приложений. Учитывая то, как много внимания к себе привлекает WebAssembly, сложно представить себе будущее веб-разработки, на которое не повлияют WebAssembly и WebGPU.
И почему нет? В конце концов, та модель, которую до сих пор использует Google Docs, это, определённо, не что-то такое, что здравомыслящий веб-разработчик выбрал бы, если бы ему нужно было с нуля написать текстовый редактор. Речь идёт о движке для формирования макетов документов, который основан на движке для формирования HTML-макетов, причём связаны эти движки с помощью абстракции, состоящей из кусков JavaScript-кода. Но Google Docs — это реальное приложение, которым, просто потому что это возможно, пользуется невообразимое количество людей. С точки зрения архитектуры программного обеспечения это — куча кода, которая работает лишь каким-то чудом, а не аккуратная, образцовая программа.
Даже учитывая то, что веб-приложения эволюционируют, традиционные идеи веба будут жить на тех сайтах, где эти идеи имеют смысл. В частности — на сайтах, содержащих большие объёмы текстовых данных. Это может быть всё что угодно — от порталов с техническими статьями, до каталога товаров Amazon. У создателей таких сайтов нет причины изобретать колесо, переделывать системы рендеринга данных и попутно решать проблемы доступности контента. Но через некоторое время такие сайты больше не будут определяющим фактором, влияющим на наши ожидания того, как должен выглядеть веб.
Вместо этого модель приложений полностью освободится от современных HTML/CSS-абстракций. Это изменение, вероятно, вернёт веб-разработчиков в свободный, но фрагментированный мир программирования. Там они, планируя работу над приложениями, смогут выбирать из широкого диапазона языков программирования и моделей построения пользовательских интерфейсов. И если принять во внимание историю вычислительных технологий, то вход в этот новый мир программирования гораздо ближе, чем нам кажется.
Как вы относитесь к веб-приложениям, интерфейс которых основан на <canvas>?
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/fe0/411/6e6/fe04116e6f4217957b5c55be7f0f826b.jpg)
![](https://habrastorage.org/r/w1560/webt/ou/g5/kh/oug5kh6sjydt9llengsiebnp40w.png)
![](https://miro.medium.com/max/2448/1*ndZTk64e9TmkQL2l-ySNtg.png)
Решение Google, которое заключается в том, чтобы перейти от вывода на страницы HTML-элементов к рисованию пикселей на <canvas>, нельзя назвать чем-то таким, чего раньше никто не видел и не пробовал. Другие передовые веб-приложения уже вышли далеко за пределы традиционных схем работы с HTML-элементами. Так, в Google Maps вывод данных на <canvas> используется уже многие годы. В VS Code для отрисовки идеального интерфейса терминала тоже используется <canvas>. А в подающем надежды наборе инструментов Google Flutter, который позволяет создавать кросс-платформенные интерфейсы, в веб-браузере, по умолчанию, используется рендеринг с использованием <canvas>.
Но в этот раз происходящее вызывает несколько иные ощущения. А именно, появляется такое чувство, что рендеринг в <canvas> и другие современные технологии, вроде WebAssembly, увели нас за точку невозврата. Все привыкли к схеме работы, когда страница загружает, в виде обычного текста, JavaScript-код, который выполняется, взаимодействуя с HTML-элементами, видимыми в «инструментах разработчика». Сейчас возникает такое впечатление, что это — лишь небольшой этап на пути постоянно развивающихся технологий веб-разработки.
Или, если сказать иначе, мы принимаем как должное то, что можем читать тексты JavaScript-программ, которые выполняются в наших браузерах, то, что можем исследовать HTML-разметку и CSS-код, которые лежат в основе того, что мы видим на экранах. Но все эти аспекты веб-разработки могут быть не более чем коротким эпизодом истории программирования.
Что же сейчас происходит?
Подход к разработке веб-приложений с использованием рендеринга в <canvas> будет распространяться
Говорят, что когда компания Google куда-то идёт, все остальные следуют за ней.
Лет 15 назад Google была первопроходцем в деле использования асинхронных JavaScript-вызовов (это потом назвали «AJAX»). Компания использовала какие-то новейшие для своего времени технологии в Gmail и Google Maps, а позже эти технологии превращались в фундаментальные основы веб-разработки. Теперь, благодаря переходу Google к выводу интерфейсов на <canvas>, этот подход к формированию UI начинает выглядеть совершенно приемлемым в глазах веб-разработчиков нового поколения.
Прямо сейчас перед тем, кто хочет использовать <canvas> для каких-то серьёзных дел, стоят довольно-таки высокие барьеры. В ходе работы над Google Docs специалисты компании сделали новые реализации целой кучи механизмов, которые многие программисты обычно воспринимают как нечто само собой разумеющееся. Это, например, точные инструменты для создания макетов, средства для выделения текста, системы проверки правописания, механизмы оптимизированной перерисовки экранных элементов. В наши дни в мире существует всего несколько компаний, которые способны провести работы такого масштаба лишь ради надежды на возможное улучшение производительности некоего решения.
И самой сложной и интересной задачей в этом проекте является обеспечение доступности сайтов и приложений для людей с ограниченными возможностями. Для того чтобы приложение выполняло бы указания нормативных документов по доступности, оно должно соответствовать определённым требованиям. Это нужно для компаний, которые должны соответствовать требованиям, необходимым для участия в правительственных контрактах, вроде Google, и, кроме того, важно для тех компаний, которые стремятся быть хорошими «жителями веба». Версия Google Docs, основанная на <canvas>, несмотря ни на что, должна иметь отличную поддержку средств для чтения с экрана и инструментов для увеличения фрагментов экрана. Она должна поддерживать работу в режиме высокой контрастности, должна содержать механизмы, помогающие работать с ней людям с ограниченными двигательными возможностями. Один из способов реализации этих возможностей заключается в создании невидимой DOM, которая воспроизводила бы реальные данные, выводимые в <canvas>, но существовала бы только ради обеспечения правильной работы ассистивных технологий. И, конечно, две эти модели должны быть идеально синхронизированы друг с другом.
В наши дни нет единого, стандартного решения, которым разработчики могли бы воспользоваться для реализации ассистивных возможностей приложения, которое использует <canvas> для формирования интерфейса. Но по мере того, как этот подход к созданию интерфейсов будет набирать популярность, ситуация изменится в лучшую сторону. И никто не знает о том, насколько быстро произойдут эти изменения. То, что Google использует <canvas> для создания интерфейсов, привлечёт к соответствующим вопросам внимание, этим заинтересуется множество разработчиков, будут развиваться сопутствующие технологии. Потом появятся библиотеки, а ещё через некоторое время, возможно, будут созданы соответствующие стандарты и API. К закону Этвуда можно сделать дополнение, с которым он будет выглядеть так:
Любое приложение, которое может быть написано на JavaScript, в конце концов будет написано на JavaScript, даже если для этого JavaScript понадобится усовершенствовать.
Семантический веб мёртв
Если посмотреть на общую картину происходящего, то окажется, что шаг Google — это лишь один из этапов большого пути. Всё время существования веба амбициозные разработчики пытаются вырваться из ограничений, навязываемых им моделью веб-страницы, и отойти от абстракции HTML. Раньше это выражалось в использовании плагинов вроде Flash. Но с самого начала шла тихая, но никогда не прекращающаяся война между двумя точками зрения на веб, между теми, кто воспринимал его как хранилище структурированных документов, и теми, кто видел его платформой, обеспечивающей функционирование контейнеров для приложений.
Самым драматическим моментом этого противостояния стала смерть XHTML — строгого (но нескладного) результата переосмысления веб-стандартов, призванного дать вебу семантическую чистоту такого уровня, до которого никогда не добирался классический веб. Стандарт XHTML был почти что провозглашён будущим веба, но потом он потерпел полное и внезапное поражение от стандарта, воплощающего иной взгляд на веб, от HTML5.
В соответствии с HTML5 в понятие «веб-стандарт» входит всё что угодно, по поводу чего пришли к согласию производители разных браузеров. В частности, речь идёт о множестве JavaScript-API, рассчитанных на решение различных практических задач. Из этих API можно, как из кирпичей, строить функционал веб-страниц. Среди этих API можно отметить, например Geolocation, Web Storage, WebSockets, Web Workers. В HTML5, конечно, появились и некоторые новые семантические описательные элементы, но единственным по-настоящему многообещающим новшеством стандарта, связанным с встраиванием информации в веб-страницы, была поддержка микроданных (microdata). Её, правда, довольно быстро из стандарта убрали (в основном из-за того, что Google и Apple не были заинтересованы в реализации этого новшества).
![](https://habrastorage.org/getpro/habr/post_images/e10/a18/310/e10a18310c6827ffe480a957c3a60206.jpg)
Что скрывается за маской HTML5?
Рендеринг в <canvas> — это, очевидно, полная противоположность веб-страницы, содержимое которой оформлено с помощью семантических элементов. Это — чёрный ящик, который не даёт браузеру никакой информации о том, что в нём может происходить или происходит.
Из-за этого вся власть оказывается в руках приложений. То, что управляет отдельными пикселями, может абсолютно всё: обходить автоматизированные инструменты, бороться с блокировщиками рекламы, ограничивать браузерные возможности вроде поиска по тексту или его копирования. Это — JavaScript-реинкарнация Flash и Silverlight, для работы которой не нужно устанавливать что-то, кроме самого браузера, и при использовании которой можно не думать о вопросах совместимости.
Будущее — это WebAssembly и бинарные блобы
Если вам кажется, что широкое распространение рендеринга в <canvas> — это большое событие, то знайте, что оно выглядит не таким уж и значительным в сравнении с другими тенденциями веб-разработки. И самой крупной из таких тенденций, без сомнения, является применение WebAssembly, то есть — низкоуровневого бинарного формата инструкций, который понятен всем современным браузерам.
Если вы заглянете на страницу, работа которой основана на WebAssembly, то окажется, что на ней выполняется предварительно скомпилированный код, уровень которого лишь немногим выше уровня ассемблера. И такой код, определённо, если сравнить его даже с очень сильно минифицированным образцом JS-кода, гораздо сложнее прочесть человеку. WebAssembly используется для запуска в браузере игр, для декодирования генома, на WebAssembly основаны высокоуровневые фреймворки вроде Blazor. «Непрозрачные» веб-приложения, которые беспокоят пуристов, это — мелочь в сравнении с тем, что обещает нам WebAssembly. Речь идёт о выводе производительности веб-приложений, работающих в браузерной «песочнице», практически на уровень нативных приложений.
В наши дни WebAssembly-программам для доступа к DOM нужен корявый промежуточный JavaScript-слой. Но вспомним о проекте WebGPU, об оптимизированном последователе теперь заброшенного WebGL. У WebGPU и WebGL есть одна важная общая черта: и тот и другой проекты дают возможность оптимизированного рендеринга на <canvas>. Если объединить это с аппаратным ускорением графики, которое реализовано в браузерах, то получится, что в нашем распоряжении оказался низкоуровневый механизм вывода графики, который можно использовать для создания веб-приложений нового поколения. Или, что больше похоже на правду, нового поколения библиотек и фреймворков, которые лягут в основу новых веб-приложений. Учитывая то, как много внимания к себе привлекает WebAssembly, сложно представить себе будущее веб-разработки, на которое не повлияют WebAssembly и WebGPU.
И почему нет? В конце концов, та модель, которую до сих пор использует Google Docs, это, определённо, не что-то такое, что здравомыслящий веб-разработчик выбрал бы, если бы ему нужно было с нуля написать текстовый редактор. Речь идёт о движке для формирования макетов документов, который основан на движке для формирования HTML-макетов, причём связаны эти движки с помощью абстракции, состоящей из кусков JavaScript-кода. Но Google Docs — это реальное приложение, которым, просто потому что это возможно, пользуется невообразимое количество людей. С точки зрения архитектуры программного обеспечения это — куча кода, которая работает лишь каким-то чудом, а не аккуратная, образцовая программа.
Итоги
Даже учитывая то, что веб-приложения эволюционируют, традиционные идеи веба будут жить на тех сайтах, где эти идеи имеют смысл. В частности — на сайтах, содержащих большие объёмы текстовых данных. Это может быть всё что угодно — от порталов с техническими статьями, до каталога товаров Amazon. У создателей таких сайтов нет причины изобретать колесо, переделывать системы рендеринга данных и попутно решать проблемы доступности контента. Но через некоторое время такие сайты больше не будут определяющим фактором, влияющим на наши ожидания того, как должен выглядеть веб.
Вместо этого модель приложений полностью освободится от современных HTML/CSS-абстракций. Это изменение, вероятно, вернёт веб-разработчиков в свободный, но фрагментированный мир программирования. Там они, планируя работу над приложениями, смогут выбирать из широкого диапазона языков программирования и моделей построения пользовательских интерфейсов. И если принять во внимание историю вычислительных технологий, то вход в этот новый мир программирования гораздо ближе, чем нам кажется.
Как вы относитесь к веб-приложениям, интерфейс которых основан на <canvas>?
![](https://habrastorage.org/getpro/habr/post_images/fe0/411/6e6/fe04116e6f4217957b5c55be7f0f826b.jpg)
![](https://habrastorage.org/webt/ou/g5/kh/oug5kh6sjydt9llengsiebnp40w.png)