Но в этот раз происходящее вызывает несколько иные ощущения. А именно, появляется такое чувство, что рендеринг в и другие современные технологии, вроде WebAssembly, увели нас за точку невозврата. Все привыкли к схеме работы, когда страница загружает, в виде обычного текста, JavaScript-код, который выполняется, взаимодействуя с HTML-элементами, видимыми в «инструментах разработчика». Сейчас возникает такое впечатление, что это — лишь небольшой этап на пути постоянно развивающихся технологий веб-разработки.Или, если сказать иначе, мы принимаем как должное то, что можем читать тексты JavaScript-программ, которые выполняются в наших браузерах, то, что можем исследовать HTML-разметку и CSS-код, которые лежат в основе того, что мы видим на экранах. Но все эти аспекты веб-разработки могут быть не более чем коротким эпизодом истории программирования.
Что же сейчас происходит?
Лет 15 назад Google была первопроходцем в деле использования асинхронных JavaScript-вызовов (это потом назвали «AJAX»). Компания использовала какие-то новейшие для своего времени технологии в Gmail и Google Maps, а позже эти технологии превращались в фундаментальные основы веб-разработки. Теперь, благодаря переходу Google к выводу интерфейсов на , этот подход к формированию UI начинает выглядеть совершенно приемлемым в глазах веб-разработчиков нового поколения.
Прямо сейчас перед тем, кто хочет использовать для каких-то серьёзных дел, стоят довольно-таки высокие барьеры. В ходе работы над Google Docs специалисты компании сделали новые реализации целой кучи механизмов, которые многие программисты обычно воспринимают как нечто само собой разумеющееся. Это, например, точные инструменты для создания макетов, средства для выделения текста, системы проверки правописания, механизмы оптимизированной перерисовки экранных элементов. В наши дни в мире существует всего несколько компаний, которые способны провести работы такого масштаба лишь ради надежды на возможное улучшение производительности некоего решения.
И самой сложной и интересной задачей в этом проекте является обеспечение доступности сайтов и приложений для людей с ограниченными возможностями. Для того чтобы приложение выполняло бы указания нормативных документов по доступности, оно должно соответствовать определённым требованиям. Это нужно для компаний, которые должны соответствовать требованиям, необходимым для участия в правительственных контрактах, вроде Google, и, кроме того, важно для тех компаний, которые стремятся быть хорошими «жителями веба». Версия Google Docs, основанная на , несмотря ни на что, должна иметь отличную поддержку средств для чтения с экрана и инструментов для увеличения фрагментов экрана. Она должна поддерживать работу в режиме высокой контрастности, должна содержать механизмы, помогающие работать с ней людям с ограниченными двигательными возможностями. Один из способов реализации этих возможностей заключается в создании невидимой DOM, которая воспроизводила бы реальные данные, выводимые в , но существовала бы только ради обеспечения правильной работы ассистивных технологий. И, конечно, две эти модели должны быть идеально синхронизированы друг с другом.
В наши дни нет единого, стандартного решения, которым разработчики могли бы воспользоваться для реализации ассистивных возможностей приложения, которое использует для формирования интерфейса. Но по мере того, как этот подход к созданию интерфейсов будет набирать популярность, ситуация изменится в лучшую сторону. И никто не знает о том, насколько быстро произойдут эти изменения. То, что Google использует для создания интерфейсов, привлечёт к соответствующим вопросам внимание, этим заинтересуется множество разработчиков, будут развиваться сопутствующие технологии. Потом появятся библиотеки, а ещё через некоторое время, возможно, будут созданы соответствующие стандарты и API. К закону Этвуда можно сделать дополнение, с которым он будет выглядеть так:
Любое приложение, которое может быть написано на JavaScript, в конце концов будет написано на JavaScript, даже если для этого JavaScript понадобится усовершенствовать.
Самым драматическим моментом этого противостояния стала смерть XHTML — строгого (но нескладного) результата переосмысления веб-стандартов, призванного дать вебу семантическую чистоту такого уровня, до которого никогда не добирался классический веб. Стандарт XHTML был почти что провозглашён будущим веба, но потом он потерпел полное и внезапное поражение от стандарта, воплощающего иной взгляд на веб, от HTML5.
В соответствии с HTML5 в понятие «веб-стандарт» входит всё что угодно, по поводу чего пришли к согласию производители разных браузеров. В частности, речь идёт о множестве JavaScript-API, рассчитанных на решение различных практических задач. Из этих API можно, как из кирпичей, строить функционал веб-страниц. Среди этих API можно отметить, например Geolocation, Web Storage, WebSockets, Web Workers. В HTML5, конечно, появились и некоторые новые семантические описательные элементы, но единственным по-настоящему многообещающим новшеством стандарта, связанным с встраиванием информации в веб-страницы, была поддержка микроданных (microdata). Её, правда, довольно быстро из стандарта убрали (в основном из-за того, что Google и Apple не были заинтересованы в реализации этого новшества).
Рендеринг в — это, очевидно, полная противоположность веб-страницы, содержимое которой оформлено с помощью семантических элементов. Это — чёрный ящик, который не даёт браузеру никакой информации о том, что в нём может происходить или происходит.
Из-за этого вся власть оказывается в руках приложений. То, что управляет отдельными пикселями, может абсолютно всё: обходить автоматизированные инструменты, бороться с блокировщиками рекламы, ограничивать браузерные возможности вроде поиска по тексту или его копирования. Это — JavaScript-реинкарнация Flash и Silverlight, для работы которой не нужно устанавливать что-то, кроме самого браузера, и при использовании которой можно не думать о вопросах совместимости.
Если вы заглянете на страницу, работа которой основана на WebAssembly, то окажется, что на ней выполняется предварительно скомпилированный код, уровень которого лишь немногим выше уровня ассемблера. И такой код, определённо, если сравнить его даже с очень сильно минифицированным образцом JS-кода, гораздо сложнее прочесть человеку. WebAssembly используется для запуска в браузере игр, для декодирования генома, на WebAssembly основаны высокоуровневые фреймворки вроде Blazor. «Непрозрачные» веб-приложения, которые беспокоят пуристов, это — мелочь в сравнении с тем, что обещает нам WebAssembly. Речь идёт о выводе производительности веб-приложений, работающих в браузерной «песочнице», практически на уровень нативных приложений.
В наши дни WebAssembly-программам для доступа к DOM нужен корявый промежуточный JavaScript-слой. Но вспомним о проекте WebGPU, об оптимизированном последователе теперь заброшенного WebGL. У WebGPU и WebGL есть одна важная общая черта: и тот и другой проекты дают возможность оптимизированного рендеринга на . Если объединить это с аппаратным ускорением графики, которое реализовано в браузерах, то получится, что в нашем распоряжении оказался низкоуровневый механизм вывода графики, который можно использовать для создания веб-приложений нового поколения. Или, что больше похоже на правду, нового поколения библиотек и фреймворков, которые лягут в основу новых веб-приложений. Учитывая то, как много внимания к себе привлекает WebAssembly, сложно представить себе будущее веб-разработки, на которое не повлияют WebAssembly и WebGPU.
И почему нет? В конце концов, та модель, которую до сих пор использует Google Docs, это, определённо, не что-то такое, что здравомыслящий веб-разработчик выбрал бы, если бы ему нужно было с нуля написать текстовый редактор. Речь идёт о движке для формирования макетов документов, который основан на движке для формирования HTML-макетов, причём связаны эти движки с помощью абстракции, состоящей из кусков JavaScript-кода. Но Google Docs — это реальное приложение, которым, просто потому что это возможно, пользуется невообразимое количество людей. С точки зрения архитектуры программного обеспечения это — куча кода, которая работает лишь каким-то чудом, а не аккуратная, образцовая программа.
Вместо этого модель приложений полностью освободится от современных HTML/CSS-абстракций. Это изменение, вероятно, вернёт веб-разработчиков в свободный, но фрагментированный мир программирования. Там они, планируя работу над приложениями, смогут выбирать из широкого диапазона языков программирования и моделей построения пользовательских интерфейсов. И если принять во внимание историю вычислительных технологий, то вход в этот новый мир программирования гораздо ближе, чем нам кажется.
Как вы относитесь к веб-приложениям, интерфейс которых основан на ?
© Habrahabr.ru
