Александр Хованский опубликовал на хабре неплохую статью "Введение в Screen Capture API — Сканируем QR коды в браузере".

Автор статьи захотел написать приложение, с помощью которого можно распознавать qr-коды прямо на компьютере. Для этого он воспользовался Screen Capture API. Это API позволяет захватывать изображения с экрана монитора целиком, окна какого-то определённого приложения или определённой вкладки браузера (эта возможность доступна только в Chrome).

В статье есть пример кода захвата; он состоит из следующих частей:
1. Отправка потока в <video>
2. Периодическая отрисовка <video> в <canvas>
3. Захват изображения с помощью getImageData()

Ещё в статье есть ссылка на демо готового приложения. Проверил — всё работает замечательно. Но стоит иметь в виду, что Screen Capture API поддерживают только Firefox, Chrome и Edge.

#web #api #tutorial

https://habr.com/ru/post/460825/

В блоге web.dev была опубликована статья про изолированные окружения — "Making your website "cross-origin isolated" using COOP and COEP".

В web-платформе есть потенциально небезопасные, но мощные API: SharedArrayBuffer (требуется для WebAssembly Threads), performance.measureMemory (будет доступно в Chrome 83) и JS Self-Profiling API (пока нет поддержки в браузерах). Чтобы понять насколько опасно может быть их использование, можно вспомнить 2018 год, когда SharedArrayBuffer использовался для реализации атаки Spectre. Как противодействие Spectre SharedArrayBuffer был по умолчанию отключён во всех браузерах.

Для получения возможности использовать эти API ребята из Google разработали концепцию изолированного окружения (cross-origin isolated environment). Чтобы его включить, нужно отправить с документом http-заголовки:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Изолированное окружение (cross-origin isolated environment) полностью запрещает доступ к странице сторонним скриптам через window.opener или iframe и отключает изменение свойства document.domain. Благодаря чему семейство атак по сторонним каналам (например, Spectre) перестают работать.

Включение COOP и COEP на больших сайтах может быть нетривиально, поэтому в статье есть инструкции, как найти и исправить возникшие проблемы. Поддержка изолированных окружений ожидается в Chrome 83.

#security #api

https://web.dev/coop-coep/

Томас Штейнер из Google опубликовал пост про новое API — "The requestVideoFrameCallback API".

Метод requestVideoFrameCallback() находится у элемента <video>. Он позволяет регистрировать колбэк, который будет выполняться при отправке каждого кадра видеопотока в композитор, то есть на этапе рендеринга изображения. Эта фича предназначена для эффективной обработки видео в браузере, для синхронизации с внешними звуковыми источниками, для видео-анализа и "зеркалирования" видео в canvas. Частота, с которой вызывается колбэк, минимальное значение от частоты экрана и частоты кадров видео.

На данный момент поддержка requestVideoFrameCallback API есть только в Chromium, разработчики Firefox тоже заинтересованы в реализации этой фичи. Если всё взлетит, то вполне возможно, что через пару лет в браузере будет работать Adobe Premiere.

#video #api

https://blog.tomayac.com/2020/05/15/the-requestvideoframecallback-api/

Джек Арчибальд написал статью "Event listeners and garbage collection". В ней рассказывается про способ прерывания любого асинхронного API и объясняется, почему этот способ не приводит к утечкам памяти.

Все современные браузеры поддерживают отмену fetch-запросов с помощью AbortController API. В статье есть код небольшого хелпера, который позволяет использовать AbortController с любым асинхронным API:

async function abortable(signal, promise) {
  if (signal.aborted) {
    throw new DOMException('AbortError', 'AbortError');
  }
  return Promise.race([
    promise,
    new Promise((_, reject) => {
      signal.addEventListener('abort', () => {
        reject(new DOMException('AbortError', 'AbortError'));
      });
    }),
  ]);
}

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

Очень хорошая статья. Рекомендую посмотреть примеры, особенно если вы раньше не работали с AbortController.

#web #api

https://jakearchibald.com/2020/events-and-gc/

Сурма написал статью про новое расширение ResizeObserver, с помощью которого можно получить размер элемента в физических пикселях — "Pixel-perfect rendering with devicePixelContentBox".

Иногда возникают ситуации, в которых размеры блока в пикселях могут получаться дробными. При рендеринге таких элементов CSS-пиксели "подгоняются" браузером к физическим пикселями с помощью pixel snapping. Проблема в том, что не было надёжного способа получения размера элемента в реальных физических пикселях. Из-за этого невозможно было реализовать pixel-perfect отрисовку в canvas — изображения могли получаться нечёткими, на них мог проявляться эффект Муара.

В Chrome 84 была добавлена новая опция ResizeObserver ['device-pixel-content-box']. С её помощью можно получить размер любого элемента в физических пикселях и добиться pixel-perfect рендернига canvas.

#rendering #api

https://web.dev/device-pixel-content-box/

Рйо Ота рассказал, как можно сделать SSH-клиент, VNC-клиент и мессенджер без использования веб сокетов и WebRTC — "The Power of Pure HTTP – screen share, real-time messaging, SSH and VNC".

Обычно HTTP используется для передачи относительно небольших объёмов данных. Разработчики браузеров сейчас работают над возможностью отправки по сети ReadableStream с помощью fetch, то есть создания канала для передачи бесконечного потока данных. В статье разбираются примеры, как использовать эту фичу вместе с piping server, который позволяет организовать взаимодействие между двумя браузерами с помощью обычных GET- и POST-запросов. С помощью такого подхода можно сделать приложение просмотра удалённого рабочего стола, SSH-клиенты и другие подобные приложения, которые работают внутри браузера и используют обычный HTTP-канал в качестве транспорта.

На данный момент возможность передачи ReadableStream с помощью fetch есть только в Chrome в экспериментальном режиме.

#experimental #http #api

https://dev.to/nwtgck/the-power-of-pure-http-screen-share-real-time-messaging-ssh-and-vnc-5ghc

Андрей Мелихов на канале ДевШахты рассказал про Server-Sent Events API — "Server-Sent Events: Простая замена веб-сокетов".

Если вам нужно читать данные с сервера в реальном времени, то не обязательно для этого использовать веб-сокеты. Для этой цели хорошо подходит Server-Sent Events API (SSE API). В отличие от веб-сокетов он используется для создания однонаправленного канала связи с сервером и не так сложен в использовании.

Для работы с SSE на клиенте используется класс EventSource, которому нужно передать url сервера. Сервер в свою очередь должен отправлять поток данных с метаинформацией обычным текстом, так как SSE работает поверх HTTP. Поддержка SSE есть во всех современных браузерах.

Рекомендую посмотреть видео, если раньше не приходилось работать с SSE.

#api #video

https://www.youtube.com/watch?v=CJrmK3IXC8o

Андрей Мелихов на канале ДевШахты опубликовал вторую часть видео, посвящённую Server-Sent Events — "Server-Sent Events: Снимаем ограничения".

В первой части Андрей рассказывал про основные концепции использования API и про решаемые ей задачи (простая альтернатива веб-сокетам, однонаправленный канал связи с сервером). Вторая часть посвящена использованию SSE в реальных проектах.

При использовании SSE поверх первой версии HTTP есть ограничение на максимальное количество подключений к источнику данных — в рамках одной страницы нельзя сделать больше шести подключений. Эту проблему можно обойти переходом на HTTP/2. Также при создании подключения с помощью конструктора EventSource нет возможности передать дополнительные HTTP-заголовки, например, для авторизации. Это ограничение можно обойти с помощью кук.

Рекомендую посмотреть видео, если хотите узнать больше подробностей про нюансы работы с SSE.

#api #nodejs #video

https://www.youtube.com/watch?v=v6Fc4FQwNa4

Томас Штайнер написал статью про Storage Foundation API — "High performance storage for your app: the Storage Foundation API".

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

Эту проблему призван решить Storage Foundation API. Он предоставляет средства для производительной работы с хранилищем данных и включает в себя набор примитивов, работа с которыми напоминает работу с обычной файловой системой. С его помощью можно получать информацию о доступном месте, создавать/удалять/переименовывать файлы, производить запись/чтение данных со смещением и т.п.

На данный момент экспериментальная поддержка Storage Foundation API есть только в Chrome в рамках программы Origin Trial.

#api #chrome #experimental

https://web.dev/storage-foundation/

Бесшовные переходы между экранами SPA с помощью shared element transition API

Джейк Арчибальд рассказал о новом пропозале для создания бесшовных переходов между экранами SPA — "Smooth and simple page transitions with the shared element transition API".

Бесшовные переходы сложны в реализации. При их создании нужно обеспечить плавность анимации, корректность обработки событий при изменении состояний и убедиться в том, что одновременное присутствие двух экранов не ломает доступность.

Эти проблемы призван решить shared element transition API. С его помощью можно легко создавать простые переходы между экранами и сложные переходы с разделяемыми элементами. Вот так реализуется простой переход:

async function navigateToSettingsPage() {
  await document.documentTransition.prepare({
    rootTransition: 'cover-left',
  });
  updateDOMForSettingsPage();
  await document.documentTransition.start();
}

Shared element transition API пока доступен в Chrome в экспериментальном режиме. Также на данный момент его можно использовать только в рамках одной страницы, но у авторов спецификации есть планы по его расширению для обеспечения бесшовных переходов между разными страницами сайта.

#chrome #api #spa

https://developer.chrome.com/blog/shared-element-transitions-for-spas/

Взаимодействие с веб-воркером без прерывания цикла событий

Михай Парпарита поделился эффективным способом общения с веб-воркером без использования SharedArrayBuffer — "Communicating With a Web Worker Without Yielding To The Event Loop".

Автор статьи работал над веб-версией эмулятора ОС старых Макинтошей. Архитектура эмулятора разделена на две основные части: UI и поток эмуляции, работающий в веб-воркере. Чтобы эмуляция работала плавно, для обмена данными между UI и веб-воркером используется SharedArrayBuffer. Поддержка SharedArrayBuffer на данный момент отключена в Safari. Михай нашёл альтернативное решение.

Веб-воркер может подгружать дополнительный код с помощью importScrips. importScripts работает синхронно, открывая возможность передачи команд из основного потока с помощью динамически формируемого JavaScript-кода. JavaScript-код создаётся внутри сервис-воркера и сохраняется в файл, который в цикле загружается в веб-воркере.

Такой подход медленнее SharedArrayBuffer, но быстрее решения с остановкой цикла событий и позволяет достичь хорошей отзывчивости ввода в эмуляторе.

#api #webworkers

https://blog.persistent.info/2021/08/worker-loop.html

App History API — улучшенный роутинг для SPA

Cэм Торогуд рассказал про новое экспериментальное API для упрощения реализации клиентского роутинга в SPA — "Modern client-side routing: the App History API".

Для управления роутингом в SPA используется History API. History API отвечает за историю браузера, всё остальное (обработка событий навигации, управление переходами между экранами, сохранение временного состояния) ложится на плечи разработчика. App History API устраняет эти недостатки, связывая историю браузера, событие навигации и переходы между экранами.

Работа с App History API происходит с помощью объекта appHistory. Для обработки событий навигации нужно установить обработчик на событие navigate. Обработчик будет перехватывать все события навигации, в том числе при отправке POST-запросов и при программном изменении истории. В API есть встроенные средства для управления процессом перехода на новые экраны SPA с возможностью установки обработчиков на успешный переход или переход с ошибкой.

На данный момент App History API доступен только в бете Chrome 95 за экспериментальным флагом.

#spa #api #experimental

https://web.dev/app-history-api/

VirtualKeyboard API — управление поведением виртуальной клавиатуры

Томас Штайнер написал статью про VirtualKeyboard API — "Full control with the VirtualKeyboard API".

По умолчанию открытие виртуальной клавиатуры на смартфонах и планшетах приводит к уменьшению области просмотра страницы. Иногда это не то, что бывает нужно. Например, на устройствах с несколькими экранами такое поведение приводит к изменению вьюпорта на экране без клавиатуры.

VirtualKeyboard API решает подобные проблемы. С его помощью можно отслеживать открытие и закрытие клавиатуры, получать её размеры и адаптировать необходимым образом страницу. Для этого используется объект navigator.virtualKeyboard. В рамках этого API также появилась возможность настройки поведения виртуальной клавиатуры для полей ввода с помощью атрибута virtualkeyboardpolicy.

В данный момент поддержка VirtualKeyboard API есть только в бете Chrome 94.

#api #mobile

https://web.dev/virtualkeyboard/

VirtualKeyboard API на практике

Брамус Ван Дамм написал статью про практическое применение VirtualKeyboard API — "Prevent content from being hidden underneath the Virtual Keyboard by means of the VirtualKeyboard API".

В статье рассказывается о том, как реализовать раскладку элементов страницы с адаптацией под открытие виртуальной клавиатуры. Для решения подобных задач можно использовать переменные окружения CSS, которые были добавлены в рамках VirtualKeyboard API: keyboard-inset-top, keyboard-inset-right, keyboard-inset-bottom и т.п. Например, адаптация нижнего блока под открытие клавиатуры на CSS может выглядеть так:

.bottom-box {
  position: fixed;
  bottom: 0;
  margin-bottom: calc(20px + env(keyboard-inset-height));
}

Есть небольшой нюанс. Чтобы воспользоваться VirtualKeyboard API, браузеру необходимо сообщить о своём намерении управлять перекрытием с помощью вызова кода
navigator.virtualKeyboard.overlaysContent = true. Это не очень удобно, поэтому Брамус завёл ишью с обсуждением альтернативных механизмов включения VirtualKeyboard API.

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

#css #api #mobile

https://www.bram.us/2021/09/13/prevent-items-from-being-hidden-underneath-the-virtual-keyboard-by-means-of-the-virtualkeyboard-api/

Спекулятивный пререндеринг в Chrome

Лина Сохони и Эдди Османи рассказали про новый способ пререндеринга страниц — "Bringing instant page-loads to the browser through speculative prerendering".

Хинт производительности prerender сообщает браузеру о необходимости отрендерить новую страницу заранее (спекулятивно). Если браузер неактивен и если в нём отключен режим сохранения траффика, то он загрузит необходимые ресурсы и запустит процесс рендеринга, тем самым страница будет открываться быстрее.

В Chrome 94 в рамках origin trail появилась поддержка Speculation Rules API. В отличии от хинта prerender c помощью API можно гибко управлять пререндером страниц и предзагрузкой ресуров. На данный момент реализована только часть API — возможно пререндерить только заранее указанный список URL. В будущем появится возможность пререндеринга набора URL по шаблону. Также можно будет указать вероятность открытия страницы, чтобы браузер оптимально тратил вычислительные ресурсы пользователя.

#chrome #performance #api

https://web.dev/speculative-prerendering/

Sanitizer API — безопасная работа с DOM

В блоге web.dev была опубликована статья, посвящённая Sanitizer API — "Safe DOM manipulation with the Sanitizer API".

Sanitizer API — это реализация полноценного санитайзера данных на уровне веб-платформы. Он предназначен для удаления из пользовательского ввода нежелательных HTML-тегов и аттрибутов, которые эксплуатируются в XSS. Можно сказать, что это аналог библиотеки DOMPurify, но без накладных расходов на лишний парсинг.

В Sanitizer API используется контекст парсинга. Благодаря этому структура кода всегда остаётся валидной. Например, Sanitizer API не позволит вставить внутрь <div></div> результат парсинга строки <td>lorem</td>, так как получилась бы невалидная HTML-разметка.

Поддержка Sanitizer API на данный момент есть только в Chrome и Firefox в экспериментальном режиме.

#api #security

https://web.dev/sanitizer/

Использование AbortController и AbortSignal в Node.js

Джеймс Снелл — контрибьютор Node.js — написал статью про использование AbortController и AbortSignal в Node.js — "Using AbortSignal in Node.js".

Последние два года разработчики Node.js работают над добавлением разных API web-платформы. Результатом этой работы стала реализация AbortController, который появился в стабильной версии Node.js 16.

AbortController и AbortSignal реализуют интерфейс для отмены выполнения асинхронных операций. С его помощью можно прерывать таймеры, асинхронные запросы, отписываться от событий, добавленных с помощью интерфейса EventTarget, который поддерживают некоторые API Node.js. В статье рассказывается о том как использовать AbortController и AbortSignal на примере прерывания асинхронного события по таймауту.

Рекомендую почитать статью всем, так как AbortController доступен не только в Node.js, но и во всех актуальных браузерах.

#nodejs #async #api

https://www.nearform.com/blog/using-abortsignal-in-node-js/

Улучшение веба с помощью OffscreenCanvas

Брайан Карделл из Igalia рассказал о преимуществах OffscreenCanvas — "Making the whole web better, one canvas at a time".

HTML-элемент canvas по статистике HTTPArchive используется чаще чем тег video. Он используется для разных целей: для отрисовки карт, для создания графических редакторов и отображения любой сложной графики.

Canvas бывает большим источником проблем производительности, так как выполнение кода отрисовки и процесс рендеринга в canvas происходят в главном потоке. Для решения этой проблемы был придуман новый API — OffscreenCanvas. С его помощью тяжёлые вычисления можно вынести в воркер. Передача готовой картинки из воркера в главный поток очень быстрый процесс и не влияет на отзывчивость страницы. Также благодаря OffscreenCanvas можно распараллелить рендеринг по нескольким воркерам, открывая новые возможности для веба.

На данный момент полноценная поддержка OffscreenCanvas есть только в Chrome. В Firefox его можно включить с помощью флага gfx.offscreencanvas.enabled. В WebKit он находится на этапе разработки.

#performance #api #webgl

https://bkardell.com/blog/OffscreenCanvas.html

Глубокое клонирование объектов с помощью structuredClone

Сурма из Google рассказал про новое API для глубокого клонирования JavaScript-объектов — "Deep-copying in JavaScript using structuredClone".

Самым популярным решением для глубокого клонирования объектов был JSON-хак:

const myDeepCopy = JSON.parse(JSON.stringify(myOriginal));

Он стал настолько популярен, что в браузерах были добавлены специальные оптимизации для этого хака. На данный момент он остаётся самым быстрым способом для глубокого клонирования небольших объектов. Однако он не поддерживает объекты с циклическими ссылками, Map, Set, Date, RegExp и ArrayBuffer.

Структурное клонирование — это другое название для глубокого клонирования. Оно использовалось браузерами неявно при передаче объектов с помощью postMessage и сохранении объектов в IndexedDB. Новый метод structuredClone открывает удобный доступ к этому механизму клонирования без недостатков JSON-хака:

const myDeepCopy = structuredClone(myOriginal);

Поддержка strucutredClone на данный момент есть в Firefox 94, в nightly-версии Chrome и Safari TP.

#js #api

https://web.dev/structured-clone/

Self-Profiling API на практике

Ник Джансма написал статью про новое экспериментальное API для профилировки производительности сайтов на устройствах пользователей — "JS Self-Profiling API In Practice".

Self-Profiling API предоставляет программный доступ к семплирующему профилировщику для получения детальной информации о выполнении JavaScript-кода у пользователей сайта. API можно использовать как для анализа производительности кода сайта, так и для анализа производительности скриптов внешних сервисов. Проанализировать выполнение кода можно на любом этапе жизни страницы. Доступ к Self-Profiling API включается с помощью HTTP-заголовка Document-Policy: js-profiling. Оно оказывает минимальный эффект на производительность сайта у пользователей.

Несмотря на экспериментальный статус Facebook и Microsoft уже начали использовать Self-Profiling API в своих сервисах для поиска проблем производительности.

На данный момент поддержка Self-Profiling API есть только в Chrome версии 94 и выше.

#performance #api #experimental

https://calendar.perfplanet.com/2021/js-self-profiling-api-in-practice/