Вчера Эдди Османи из Google написал в своём блоге про новый экспериментальный атрибут для ленивой загрузки изображений и iframe'ов – loading.

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

Раньше задачу отложенной загрузки можно было решить только с помощью JavaScript, например, используя библиотеку lazysizes. Сейчас в Chrome 73 с помощью флага можно включить поддержку нового атрибута loading. У атрибута есть три возможных значения: lazy (ленивая загрузка), eager (загрузка изображения сразу же), auto (будет ли изображение загружаться лениво, решает браузер):

<img src="img1.jpg" loading="lazy" />
<img src="img2.jpg" loading="eager" />
<img src="img3.jpg" loading="auto" />

Loading – это экспериментальный атрибут, стандарт которого находится на стадии черновика. Поддержка loading без флага должна появиться в Chrome 75.

#html #lazy #future #chrome

https://addyosmani.com/blog/lazy-loading/

Google в рамках проекта Fugu, который нацелен на устранением разрыва между нативными и web-приложениями, работает над добавлением имплементации чернового стандарта WebHID API для работы с HID-устройствами в Chromium. Робат Вильямс в статье "Upcoming WebHID API - access Bluetooth/USB HID devices in web applications" рассказывает о пользе этого API.

HID-протокол позволяет организовать работу с целыми классами устройств, избавляя от необходимости писать код для взаимодействия с разными устройствами. Например, код, использующий WebHID API для включения индикатора связи на гарнитуре, будет работать со всеми гарнитурами разных производителей, которые работают с этим протоколом.

В статье также разбирается работа с новым API, которое доступно с помощью navigator.hid. Есть пара примеров использования API. В них ничего необычного нет: подготовка устройства, считывание данных и отправка данных. В общем, web-платформа стремительно развивается. Скоро мы сможем делать с её помощью ещё более продвинутые приложения.

https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.html

#chromium #webplatform #future

Несколько дней назад в Firefox Nightly (версия 68) появилась поддержка Resize Observer. В принципе, я про него уже знал, но захотелось более подробно поразбираться в его особенностях. На сайте Web Fundamentals есть очень хорошая статья с описанием того, какие проблемы он решает и как с ним работать — "ResizeObserver: It’s Like document.onresize for Elements".

До появления этой спецификации отслеживание изменения размеров можно было реализовать с помощью getBoundingClientRect или getComputerStyle. Это очень непроизводительный подход, который приводит к лагам при взаимодействии со страницей. Resize Observer позволяет очень эффективно отслеживать и реагировать на изменение геометрии элементов на странице. Обработка событий изменения размеров в Resize Observer происходит сразу после этапа раскладки (layout) до стадии отрисовки (paint), таким образом это самое подходящее место для размещения логики изменения положения элементов или их размеров.

Resize Observer немного напоминает Media Queries и Element Queries из CSS, но они предназначены для разных целей. Media Queries и Element Queries задаются декларативно в CSS и определяют представление при изменении размеров. С помощью Resize Observer описывается необходимое поведение при изменении размеров. В статье есть очень показательный пример с окном чата, когда при изменении размера окна, список сообщений всегда должен быть "приклеен" к самому низу, но только в том случае, если пользователь не прокрутил список к другому сообщению.

На данный момент экспериментальная поддержка Resize Observer есть уже во всех актуальных браузерах. Для более старых версий браузеров можно использовать полифил.

#web #performance #future

https://developers.google.com/web/updates/2016/10/resizeobserver

В бете Chrome 77 за экспериментальным флагом #native-file-system-api появилась поддержка Native File System API.

С помощью этого API можно создавать приложения, которые имеют прямой доступ на чтение и запись файлов, например, полноценный текстовый или графический редактор, IDE и т.п. Много внимания уделяется безопасности нового API. Оно будет доступно только на тех сайтах, которые работают по https. Открытие окна выбора файлов возможно только со стороны пользователя, то есть программно вызвать это окно нельзя. Тем не менее появление доступа к файловой системе открывает новые возможности для атак на данные пользователей.

Native File System API является частью проекта capabilities, цель которого сделать возможным разработку таких типов web-приложений, которые доступны только на нативных платформах. Интересно наблюдать, как браузер постепенно превращается в полноценную платформу для запуска серьёзных приложений.

#future #chrome #experimental

https://developers.google.com/web/updates/2019/08/native-file-system

Франсуа Бофор из Google написал туториал про использование GPU-вычисления в web'е — "Get started with GPU Compute on the Web".

Возможности для GPU-вычислений предоставляет разрабатываемый стандарт WebGPU. Благодаря этому стандарту из web-приложений будут доступны все возможности современных видеокарт. После появления полноценной поддержки API в браузерах, наибольшую пользу получат те приложения, основная задача которых сводится к выполнению однотипных операций на большом количестве данных (например, приложения, использующие алгоритмы машинного обучения).

В статье очень подробно разбирается пример реализации умножения матриц. Объясняются понятия command encoder, bind group, bind group layout. Разбирается шейдер для перемножения матриц. Шейдеры пишутся на языке GLSL (в будущих версиях стандарта язык может поменяться).

Туториал хороший. Рекомендую посмотреть.

#webgpu #future

https://developers.google.com/web/updates/2019/08/get-started-with-gpu-compute-on-the-web

Пару дней назад в код v8 была добавлена реализация предложения "Top-level await" (Stage 3). Про этот пропозал в канале ещё ничего не было, поэтому хочу написать небольшое объяснение того, какую проблему он решает.

Top-level await добавляет поддержку await на верхнем уровне модуля, то есть вне асинхронных функций, которые декларируются с помощью async. Это позволяет превратить модуль в некое подобие большой асинхронной функции. При импорте такого модуля асинхронный код, помеченный с помощью ключевого слова await, будет останавливать выполнение импортирующего модуля до того момента, пока все зависимости не будут зарезолвлены. Вот пример преобразования "асинхронного модуля" с помощью top-level await:

// было
import { process } from "./some-module.mjs";
export default (async () => {
  const dynamic = await import(computedModuleSpecifier);
  const data = await fetch(url);
  const output = process(dynamic.default, data);
  return { output };
})();

// стало
import { process } from "./some-module.mjs";
const dynamic = import(computedModuleSpecifier);
const data = fetch(url);
export const output = process((await dynamic).default, await data);

Добавление в стандарт top-level await упростит работу с динамическими импортами и модулями, предоставляющими асинхронные ресурсы, например, соединение с базой данных.

#future #async #tc39

https://github.com/tc39/proposal-top-level-await

Грег Уитворт — участник рабочей группы CSS и разработчик MS Edge — рассказал про результаты исследования среди разработчиков для выявления проблем при работе с <select> — "Can we please style the <select> control?!"

Исследование проводилось среди 1400 разработчиков при этом оценивался масштаб пользователей, который будет затронут потенциальными нововведениями. Самыми желаемыми функциями оказались встроенный поиск элементов и полноценная возможность стилизации у элемента <select>. Грег пишет, что пока не известно, каким образом будут реализованы все пожелания. Для этого в рамках WICG OpenUI будет создан прототип элемента управления, он послужит основой для создания нового предложения в стандарт.

Очень круто, что ребята из Microsoft взяли на себе ответственность по улучшению <select>. Скорее всего первые прототипы элемента будут реализованы в Edge.

#future #html

http://gwhitworth.com/blog/2019/10/can-we-please-style-select/

На прошедшем Chrome Dev Summit Google представил Web Bundles — новый механизм для распространения web-приложений.

Представьте, что любое web-приложение можно положить на флешку, поделиться им по Bluetooth или захостить в своей локальной сети. Всё это становится возможным благодаря Web Bundles (формальное название Bundled HTTP Exchanges), которые являются частью предложения добавления в стандарт «Web Packaging». Предполагается, что запаковать можно будет любое приложение или сайт. В статье "Get started with Web Bundles" разбирается пример создания бандла для небольшого todo-приложения.

На данный момент экспериментальная поддержка Web Bundles есть только в Chrome 80 (Canary). Разработчики призывают потестировать новую фичу и поделиться своим фидбеком.

#future #web #offline

https://web.dev/web-bundles/

Недавно увидел твит от разработчика Chrome, в котором он написал, что перевод пропозала Temporal в stage 3 запланирован на февраль. Temporal — это современная замена объекта Date. В 2017 году Мэгги Джонсон-Пит написала две статьи про причины добавления в стандарт нового объекта — "Fixing JavaScript Date".

API существующего объекта Date было скопировано в 1995 году из Java. Это были ранние годы для Java, поэтому java.Util.Date там был плохо проработан. Всё было настолько плохо, что в Java 1.1, которая была выпущена в 1997 году, фактически все существующие методы были объявлены устаревшими и заменены новыми. В JavaScript не было исправлений Date из-за того, что это бы сломало web.

Спустя 20 лет было решено сделать независимую реализацию API для работы с датами и временем, которая получила название Temporal. Её ключевые отличия от Date: иммутабельность, исправленный парсинг строки в дату, исключение дополнительной секунды, добавлены методы для работы с временными зонами, предусмотрено будущее расширение спецификации для работы с негригорианскими календарями и т.п.

Библиотеки для работы со временем потеряют свою актуальность, после того как Temporal будет поддержан во всех браузерах. Для того чтобы не сломать старые браузеры, можно будет пользоваться полифиллом.

#date #tc39 #history #future

https://maggiepint.com/2017/04/09/fixing-javascript-date-getting-started/
https://maggiepint.com/2017/04/11/fixing-javascript-date-web-compatibility-and-reality/

Дмитрий Малышев из команды Firefox написал пост-апдейт про текущий статус разработки WebGPU — нового API для работы с видеокартами — "A Taste of WebGPU in Firefox".

Возможности WebGL не позволяют утилизировать весь потенциал современных видеокарт. Решить эту проблему призвано новое WebGPU API, над которым работают инженеры всех основных браузеров.

WebGPU предоставляет собой абстракцию над графическими API (DirectX12, Vulkan, Metal), изменяя подход к написанию приложений, которые используют вычислительные ресурсы видеокарт. Его основное отличие от WebGL — предоставление разработчикам большего количества рычагов для планирования и управления вычислениями. Например, благодаря ему можно распараллелить ресурсоёмкие задачи в web-воркерах, эффективно задействуя многоядерные процессоры. Или переиспользовать пакеты команд рендеринга, что открывает возможность портирования игр с открытым миром на web-платформу.

На данный момент рабочая группа WebGPU решила большую часть архитектурных проблем. Окончание основных работ над спецификацией и её имплементацией в браузерах планируется на конец 2020 года.

#webgl #webgpu #future

https://hacks.mozilla.org/2020/04/experimental-webgpu-in-firefox/