Продолжаю делиться своими мыслями по поводу прочитанных статей. Сегодня попалась статья Акселя Раушмайера "Future JavaScript: what is still missing?". Аксель в ней размышляет о том, каких возможностей пока ещё не хватает в JS. Текста много, поэтому остановлюсь на самых интересных пунктах.

В JS нет простого способа сравнить два объекта по значению. Аксель предлагает для этого новый синтаксис #{x: 1} === #{x: 1} или новые виды классов на базе экспериментального синтаксиса декораторов. Также нет возможности использовать обычные инструкции как выражения. Для этого предлагается использовать do-выражения, которые уже существуют в качестве предложения добавления в стандарт. Для более удобной работы с композицией функций предлагается использовать pipeline operator |>. Интересно то, что на данный момент существуют два конкурирующих предложения "F# Pipelines" и "Smart Pipelines". Также Аксель высказывает мысль, что было бы неплохо иметь более легковесную конструкцию (относительно Worker API) для работы с конкурентностью. В статье ещё есть очень интересная мысль про использование стандартной библиотеки вместо объектов определённых в стандарте (Object, Reflect, Math, JSON).

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

#js #future #musings

http://2ality.com/2019/01/future-js.html

Вчера Бенджамин Де Кок (участник рабочей группы CSS) твитнул про то, что их группа утвердила добавление в стнадарт много новых математических функций: calc(), min(), max(), clamp(), sin(), cos(), tan(), acos(), asin(), atan(), atan2(), hypot(), sqrt(), pow().

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

Я уверен, что перечисленные примеры далеко не полный список того, для чего могут быть полезны новые функции.

#css #future #cssfunctions #csswg

https://twitter.com/bdc/status/1100921258839953408

Бенедикт Мюрер - разработчик v8 - пару дней назад опубликовал дизайн-документ, посвящённый оптимизации конкатенации строк в JS.

Конкатенация строк - одна из основных операций над строками, у которой, как оказывается, есть хороший потенциал для ускорения. Если конкатенация будет оптимизирована, то решения для сервер сайд рендеринга станут ещё быстрее (именно на этом примере Бенедикт показывает важность оптимизации).

В документе также рассказывается про текущий механизм оптимизации строк - "ropes". Приводится пример того, как можно написать один вид конкатенации в двух разных вариантах: оптимизированном и неоптимизированном. Но разработчики v8 предупреждают, чтобы мы не кидались переписывать свой код. Движки будут учиться конкатенировать строки более эффективно самостоятельно, если с этим возникнут проблемы, тогда (возможно) в языке появится новый StringBuilder API.

#js #v8 #strings #future #performance

https://twitter.com/bmeurer/status/1102452256794906625

Павел Лаптев написал статью "Lesser-known CSS properties in GIFs" про малоизвестные CSS-свойства и функции, которые позволят в некоторых случаях отказаться от JavaScript. Каждое свойство в статье иллюстрируется gif-кой.

C помощью функции element() (поддерживается только в Firefox) можно "склонировать" в бэкграунд визуальное представление другого элемента. В Chrome и Safari TP доступны конические градиенты, с помощью которых можно делать красивые эффекты и круговые диаграммы. С помощью motion-path можно задать траекторию анимации. Очень полезное свойство, которое поддерживается почти во всех браузерах и которое позволяет делать отзывчивые карусели, scroll-snap. Ещё хочется отметить свойство line-height-step, с помощью которого можно задать вертикальный ритм текста (доступно в Chrome за флагом).

Некоторые CSS-фичи, перечисленные в статье, например, element() доступны уже долгое время. В то время как другие, например, @media (shape: rect), пока существуют на уровне чернового стандарта.

https://medium.com/@PavelLaptev/lesser-known-css-properties-in-gifs-966a143497ba

#css #future

Пару недель назад была большая новость о том, что в Chrome 74 в экспериментальном режиме включили поддержку built-in модуля для нового асинхронного key-value хранилища:

import {storage, StorageArea} from 'std:kv-storage';

Новое API разрабатывается с прицелом на то, чтобы улучшить developer experience при работе с данными в браузере. Проблема в том, что нативное API IndexedDB не очень тривиально, а localStorage из-за синхронного API, который блокирует главный поток, влияет на производительность приложения.

kv-storage – первая ласточка в будущем наборе built-in модулей. Основное преимущество API, поставляемых с помощью встроенных модулей, (они начинаются с префикса std:) – снижение потребления ресурсов системы. Браузеру в этом случае не надо загружать в память API, чтобы предоставить к нему доступ через глобальный скоуп.

Для использования новой фичи в тех браузерах, которые её не поддерживают, разработчики Google предлагают использовать progressive enhancement подход с использованием ещё одной экспериментальной фичи – import maps и полифилла для kv-storage.

#builtinmodule #kvstorage #chrome #future

https://developers.google.com/web/updates/2019/03/kv-storage

Вчера Эдди Османи из 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/