Карл Джонсон рассказал, почему он отказался от поддержки IE11 в пользу улучшения работы сайта для браузеров с отключённым JS — "Dropping Support For IE11 Is Progressive Enhancement".

Основная мысль статьи. Число пользователей IE11 с каждым годом всё меньше и меньше, но мы продолжаем по инерции транспайлить код в ES5. В некоторых случаях надо прилагать дополнительные усилия, чтобы новая фича заработала под IE11 только для того, чтобы спустя полгода обнаружить, что она была сломана несколько месяцев назад.

Большинство команд без выделенного QA-отдела, постоянно проверяющего работу сайта в IE11, может без проблем дропнуть его поддержку. У пользователей IE11 скорее всего в системе установлен более современный браузер. Освободившиеся ресурсы можно отправить на улучшение доступности и работы сайта без JavaScript (progressive enhancement), это принесёт гораздо больше пользы.

Очень хорошая статья. Дайте её почитать вашим менеджерами, кто сомневается в пользе отказа от IE11.

#musings #ie

https://blog.carlmjohnson.net/post/2020/time-to-kill-ie11/

Неделя релизов продолжается. Вчера вышел TypeScript 4.1. Дениэл Розенвассер рассказал о всех изменениях в новой версии.

В TypeScript 4.1 были добавлены литеральные шаблонные типы (Template Literal Types). Благодаря им можно описывать типы, состоящие из нескольких строковых литеральных типов. Также они позволяют на уровне типов "извлекать" строковые литералы из других литералов. В рамках этой фичи были добавлены новые утилитарные типы для манипуляции строками — Uppercase, Lowercase, Capitalize , Uncapitalize.

С новой версии можно ремапить ключи в отображаемых типах (mapped types). Это можно использовать для фильтрации свойств объектных типов или создания новых объектных типов с ключами, использующими литеральные шаблонные типы.

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

Добавлен флаг --noUncheckedIndexedAccess для более строгой проверки доступа к элементам массивов или свойствам объектов. Параметр paths теперь можно использовать без указания baseUrl. Теперь необязательно включать allowJs при использовании опции checkJs. Добавлена поддержка фабрик jsx и jsxs из React 17 (используются транспиляторами).

Есть несколько ломающих изменений. Условные спрэды создают опциональные свойства. Нужно обязательно указывать параметр функции resolve у промисов. Абстрактные члены больше не могут объявляться с async. Если в условном выражении falsy-позиция возвращает тип any`/`unknown, то any`/`unknown будет распространено на всё выражение.

#release #typescript

https://devblogs.microsoft.com/typescript/announcing-typescript-4-1

Стэфани Стимак написала статью о том, почему элементы управления форм плохо кастомизируются и какие предпринимаются шаги, чтобы изменить эту ситуацию — "Standardizing <select> And Beyond: The Past, Present And Future Of Native HTML Form Controls".

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

Для решения этой проблемы была запущена инициатива Open UI в рамках Web Incubator Community Group. Open UI — это каталог элементов с описанием их семантики, поведения и структуры. Работа над Open UI будет служить основой для развития спецификаций элементов управления форм.

Работа над Open UI не завершена. Стефани приглашает всех желающих присоединиться к работе над проектом.

https://www.smashingmagazine.com/2020/11/standardizing-select-native-html-form-controls/

Летом на WWDC 2020 была представлена новая версия Safari, но только пару дней назад в блоге WebKit появился официальный пост с обзором нововведений — "New WebKit Features in Safari 14".

В Safari появилась поддержка Web Extensions — набора API для создания кроссбраузерных расширений с помощью стандартных web-технологий.

Сделано много изменений, улучшающих производительность браузера и сайтов. Загрузка новых страниц стала на 13% быстрее, загрузка ранее посещённых страниц — на 42-52% быстрее. Ускорено время закрытие табов с 3.5 секунд до 50 миллисекунд. Реализована поддержка инкрементальной загрузки PDF-файлов. Добавлена поддержка HTTP/3.

В Safari 14 появилась поддержка WebP. Теперь WebP поддерживается во всех актуальных браузерах.

Для предотвращения нежелательного сдвига контента во время загрузки отзывчивых изображений Safari определяет их размеры и резервирует место на основе значений атрибутов height и width. Таким же образом резервирует место Firefox (с версии 72) и Chrome (с версии 79).

Появилась поддержка CSS-свойства image-orientation, с её помощью можно отключить автоматическое изменение ориентации изображения. Были добавлены псевдоселекторы :is(), :where(). Добавлен line-break: anywhere для разбиения длинных строк.

В JavaScript движок был добавлен BigInt, были добавлены операторы логического присваивания &&=, ||=, ??=, реализована поддержка optional chaining. Добавлена поддержка EventTarget.

#release #safari

https://webkit.org/blog/11340/new-webkit-features-in-safari-14/

Нейт Шлосс и Эндрю Комминос рассказали про новое API для эффективной обработки событий пользователя — "Better JS scheduling with isInputPending()".

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

Новое API isInputPending, которое было предложено и реализовано в Chromium инженерами Facebook, позволяет разрешить эту дилемму. С помощью isInputPending можно проверить, есть ли в текущей очереди задач пользовательские события, которые требует немедленной обработки. Таким образом можно планировать новые итерации выполнения подзадач точечно, ускоряя общее время выполенения кода.

isInputPending был добавлен в Chrome 87. Разработчики других браузеров на данный момент не заинтересованы в его добавлении.

#performance #js

https://web.dev/isinputpending/

Прошло две недели с момента последней публикации про канал для патронов. За это время в Defront Plus было опубликовано много постов:

— Польза шаблонных литеральных типов в TypeScript
— Почему разработчики Sketch не переходят на web-платформу
— Сложности создания своего комбобокса
— Мгновенная навигация по истории браузера с помощью Back/Forward Cache
— Почему нужно использовать interface вместо type в TypeScript
— Принцип работы замены фона в Google Meet
— 5 самых надоедливых фич сайтов для незрячих пользователей
— Улучшение сжатия Brotli
— Пайплайн компиляции WebAssembly в V8
— 10 сценариев использования стандартного контрола загрузки файлов

Становитесь патроном канала на Patreon, чтобы получить доступ к дополнительным постам в Defront Plus. На данный момент Patreon мой единственный источник дохода; все донаты идут на покупку еды, оплату аренды квартиры и т.п.

Спасибо всем, кто читает и поддерживает Defront!

https://www.patreon.com/myshov

Михай Парпарита из Quip написал пост о том, как нестрогое сравнение в JS привело к повышенному потреблению CPU — "The Case of the Missing Equals Sign".

Михай столкнулся с проблемой высокого потребления CPU в production-сборке macOS приложения Quip. Quip построен на базе web-технологий и работает вунтри WebView.

С помощью профилировщика XCode был найден проблемный код — метод toString() у функции. JavaScriptCore — JS-движок, использующийся WebView, — при вызове этого метода вырезает подстроку с текстом функции из исходного кода и возвращает её как результат. Это объяснило, почему проблема не воспроизводилась до конкатенации всех файл в большой бандл. Если функция определена в очень большом файле, то выполнение этого метода приводит к повышенному потреблению CPU. Метод toString в свою очередь вызывался неявно при нестрогом сравнении. Проблема была решена заменой нестрогого сравнения на строгое сравнение.

#js #debug

http://blog.persistent.info/2020/11/the-case-of-missing-equals-sign.html

Вчера в репозитории csswg-drafts появилось предложение об отказе от HTML и CSS в пользу JavaScript. Автор предложения серьёзно подошёл к делу и подробно объяснил мотивацию (то есть это не было троллингом). Таб Аткинс предложение прикрыл с формулировкой, что оно противоречит фундаментальным принципам платформы. По мотивам произошедших событий Хид Де Врайс — участвует в разработке стандартов — написал статью "Why it's good for users that HTML, CSS and JS are separate languages".

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

Также в статье говорится о том, что иногда полезно абстрагировать какие-то концепции для упрощения разработки, и, возможно, закрытое предложение может в этом помочь. Но, с другой стороны, сохранение HTML, CSS и JavaScript как отдельных сущностей гораздо полезнее для обычных пользователей.

#web

https://hiddedevries.nl/en/blog/2020-11-25-why-its-good-for-users-that-html-css-and-js-are-separate-languages/

В блоге web.dev появилась статья про изменение семантики "same-site", и как это повлияет на передачу кук — "Schemeful Same-Site".

В будущем определение "same-site" будет включать в себя URL схему. То есть сайты https://example.com и http://example.com будут считаться разными, и передача кук между ними будет заблокирована для SameSite=Strict. Подробнее про SameSite можно почитать здесь.

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

На данный момент отправка кук работает без изменений. Для тестирования поведения сайтов с учётом новой семантики в браузерах были добавлены экспериментальные флаги: schemeful-same-site (Chrome 86) и network.cookie.sameSite.schemeful (Firefox 79). Также в инструментах разработчика будут появляться предупреждения о проблемах с такими куками.

#security

https://web.dev/schemeful-samesite/

В блоге Polypane была опубликована статья про новое медиавыражение prefers-reduced-data — "Creating websites with prefers-reduced-data".

В мобильных браузерах на базе Chromium пользователи могут включить опцию для уменьшения потребления траффика. На клиенте проверить статус этой опции можно с помощью navigator.connection.saveData. Проблема в том, что она доступна только из JS. Новое медиавыражение prefers-reduced-data расширяет возможности адаптации страниц, делая доступным текущий статус опции на уровне стилей.

В статье есть примеры использования prefers-reduced-data. С его помощью можно сделать условную загрузку шрифтов, изменить или отключить фон страницы, загрузить изображения меньшего объёма, отключить автовоспроизведение видео и аудио, отключить автоматическую загрузку новых данных при прокрутке страницы.

На данный момент prefers-reduced-data доступен в Chromium-based браузерах под экспериментальным флагом.

#performance #css #js

https://polypane.app/blog/creating-websites-with-prefers-reduced-data/

Увидел что Розенвассер активно работает над вики ТС и наткнулся на вот такое (советы по оптимизации скорости компиляции и editing experience)
https://github.com/microsoft/TypeScript/wiki/Performance

Марк Ноттингэм написал статью о текущем состоянии Early Hints — "Beyond Server Push: experimenting with the 103 Early Hints Status Code".

Обычно известно, какие ресурсы будут нужны на странице. Было бы полезно каким-то образом сообщить о них браузеру заранее, чтобы он мог начать загружать код, стили, шрифты, пока бэкенд выполняет свою работу. Для решения этой задачи предназначен Early Hints — стандарт, разработанный в 2018 году инженерами Fastly (RFC8297). По своей сути Early Hints это HTTP-ответ с кодом 103 и списком ресурсов, который браузер может начать загружать перед ответом бэкенда. В HTTP/2 есть похожий механизм Server Push, но по сравнению с Early Hints он гораздо сложнее в настройке и использовании.

Пока браузеры не поддерживают эту спеку, так как она сложна в реализации. Для оценки пользы её внедрения в Google Chrome начался сбор метрик с сайтов, отправляющих экспериментальный код 103 Early Hints. Марк призывает всех желающих поучаствовать в этом эксперименте.

#http #performance

https://www.fastly.com/blog/beyond-server-push-experimenting-with-the-103-early-hints-status-code

Андрей Печкуров — один из контрибьюторов Node.js — написал статью про оптимизацию Node.js-клиента Hazelcast — "Our Journey to a High-Performance Node.js Library".

В статье рассказывается про историю оптимизации Node.js-клиента для хранилища данных, от профилировки до конкретных оптимизаций в коде. Для профилировки они использовали библиотеку 0x. Оказалось, что в коде было много лишних аллокаций объекта Buffer. Потом нашли проблему в коде преобразования буфера в строку, решением стало использование обычного buf.toString(). Реализовали механизм батчинга сообщений клиента и много других мелких улучшений. После всех изменений количество обрабатываемых сообщений увеличилось в три раза.

Очень интересная статья. Рекомендую почитать всем, кто работает с Node.js.

#nodejs #performance

https://hazelcast.com/blog/our-journey-to-a-high-performance-node-js-library/

Реми Шарп поделился своими мыслями о влиянии JavaScript на доступность сайтов — "Please disable JavaScript to view this site".

Недавно Хэйдон Пикеринг — автор нескольких книг про фронтенд-разработку — сделал в своём блоге редизайн, который поставил на уши сообщество разработчиков. Если вы попробуете зайти на его сайт, с большой вероятностью вам будет предложено отключить JS, чтобы получить к нему доступ. Таким образом Хэйдон продемонстрировал своё отношение к текущим трендам web-разработки.

Для обычных разработчиков это может показаться дикостью — зачем заставлять пользователей отключать JS, чтобы попасть на сайт? Но при избыточном использовании JS подобным образом исключаются категории людей со слабыми устройствами, медленным интернетом, альтернативными средствами отображения веб-контента и т.п.

Основная мысль статьи: JavaScript настолько стал неотъемлем от веба, что мы перестали задумываться о его влиянии на доступность и воспринимаем его наличие как нечто само собой разумеющееся.

#js #musings #a11y

https://remysharp.com/2020/11/30/please-disable-javascript-to-view-this-site

Артём Захарченко рассказал про свой подход использования моков при тестировании кода — "When should I (not) use mocks in testing?".

В статье есть примеры хорошего и плохого использования моков. Разбирается вопрос использования моков на разных уровнях тестирования: в юнит-тестах, в интеграционных тестах, в E2E-тестах.

Самое главная идея статьи — не используйте моки, если без них можно обойтись. Иногда они могут быть полезны, например, при работе со временем, датами, внешними сервисами. Но в то же время не следует ими злоупотреблять, так как они могут замаскировать проблемы, которые могут возникнуть в проде.

Хорошая статья. Рекомендую почитать всем.

#testing

https://dev.to/kettanaito/when-should-i-not-use-mocks-in-testing-544e

Разработчики Blackbird рассказали, почему они перестали использовать Google Fonts и стали хостить шрифты на своём сервере — "Self-Hosting Google Fonts".

При использовании Google Fonts браузер сначала должен разрезолвить основной домен, установить SSL-соединение, а затем разрезолвить домен, на котором находятся статические ресурсы. Так как с Google Fonts грузится CSS, этот процесс блокирует рендеринг страницы. В статье говорится, что в худшем случае LCP (Largest Contentful Paint) из-за этого увеличивался на 1.3 секунды. Чтобы предотвратить блокировку рендеринга, шрифты можно перенести на свой сервер. В статье для этого рекомендуют использовать сервис Google Webfonts Helper Tool.

Полезная статья рекомендую почитать всем, кто интересуется производительностью.

#performance

https://tryblackbird.com/blog/self-hosting-google-fonts

Патрик Лаук опубликовал статью про использование медиафич для определения устройств ввода — "Interaction Media Features and Their Potential (for Incorrect Assumptions)".

В разделе Interaction Media Features CSS-спеки Media Queries Level 4 определяются несколько медиафич, с помощью которых можно проверить поддержку hover, тача, стилуса и соответствующим образом адаптировать интерфейс.

Медифичи pointer и hover предоставляют информацию о возможностях ввода того устройства, которое браузер считает основным. Медиафичи any-pointer и any-hover представляют обобщённую информацию о всех подключенных устройств ввода. Последние две медиафичи наиболее полезны, так как к девайсу, на котором отображается сайт, может быть подключено несколько устройств ввода. Например, к iPad могут быть одновременно подключены Apple Pencil, bluetooth-клавиатура и мышь.

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

Статья большая и полезная. Рекомендую почитать.

#css #mobile

https://css-tricks.com/interaction-media-features-and-their-potential-for-incorrect-assumptions/

История JavaScript в инфографике

Завтра JavaScript исполняется 25, и JetBrains опубликовали сайт с временной шкалой, на которой отражены основные вехи в развитии языка.

https://www.jetbrains.com/lp/javascript-25/

upd: есть ещё русскоязычная версия

В блоге Catchjs была опубликована статья про анализ производительности миллиона сайтов — "We rendered a million web pages to find out what makes the web slow".

В исследовании оценивается влияние на производительность разных факторов: используемая версия HTTP, количество запросов на странице, используемые библиотеки и т.п.

Для меня самым интересным показался анализ JS-библиотек. Список библиотек, которые встречаются чаще всего: на первом месте стоит jQuery, на втором — Google Analytics, на третьем — Google Ads. Список библиотек, которые больше всего влияют на TTI: jQuery, Froogaloop, WooCommerce, Swiper, Visual Composer prettyPhoto. Список библиотек, которые больше всего влияют на время полной загрузки страницы: Baidu Statistics, Amazon Publisher Services, jQuery, VK Open API, Zopim.

Интересная статья. Рекомендую всем, кто интересуется темой производительности.

#performance #research

https://catchjs.com/Blog/PerformanceInTheWild

В понятия "переменная" и "кастомное свойство" часто вкладывают один и тот же смысл, но на самом деле между ними есть разница. Шима Видас рассказал, чем они отличаются в статье "CSS custom properties are not variables".

В спецификации CSS эти два термина определяются так (моя интерпретация): "кастомное свойство" — это определение некоторого именованного значения, которое будет использоваться в будущем --primary-color: #fff, "переменная" — это механизм для получения по имени определённого ранее значения var(--primary-color). Такое отличие полезно, потому что благодаря ему мы можем говорить про "переменные с фоллбеком" var(--primary-color, #eee). У кастомных свойств, как и у любых других свойств, невозможно задать фоллбек. Также мы можем "определить кастомное свойство на элементе". Переменные в CSS не определяются, но используются в других свойствах.

В статье есть ещё несколько других примеров, рекомендую заглянуть.

#css

https://webplatform.news/issues/2020-12-04