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

— Использование статистических методов для анализа производительности
— Строгая проверка на null в кодовой базе Figma
— Исправление сдвига контента из-за появляющегося баннера
— Советы про разработку от инженера из GitHub
— Альтернативный подход для упрощения работы с асинхронным кодом
— Оптимизация доставки изображений с помощью Cloudflare Workers
— Интересные факты из web-альманаха за 2020 год
— Производительность веба в 2021 году
— Обзор видеоформатов HEVC и AV1
— Сравнение производительности Puppeteer, Selenium и Playwright

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

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

https://www.patreon.com/myshov

Антуан Квин в блоге WebKit рассказал о преимуществах использования индивидуальных CSS-свойств для трансформации объектов — "CSS Individual Transform Properties".

Все современные браузеры поддерживают трансформацию объектов с помощью CSS-свойства transform и CCS-функций translate(), rotate(), scale(), skew(), matrix(). Первые три используются в разработке чаще всего. Для упрощения работы с ними в спецификацию CSS Transform Level 2 были добавлены CSS-свойства translate, rotate, scale. Ими удобнее пользоваться по сравнению с transform, а также они облегчают создание и переопределение сложных анимаций.

Индивидуальные свойства для трансформации — это новая фича. На данный момент её поддержка есть в Firefox, Chrome Canary и Safari Technology Preview 117.

#css #specification

https://webkit.org/blog/11420/css-individual-transform-properties/

Давид Хейнемейер Ханссон — автор веб-фреймворка Ruby on Rails — вчера представил Hotwire — альтернативный подход для создания SPA-подобных приложений, который использовался для создания почтового клиента hey.com.

Hotwire предоставляет набор из трёх библиотек: Turbo, Stimulus и Strada — для создания современных web-приложений без упора на JavaScript. Stimulus — это JavaScript-фреймворк, который был предоставлен пару лет назад. Его особенность заключается в HTML-центричном подходе для описания состояния и поведения приложения в браузере. Strada — это библиотека, облегчающие создание гибридных мобильных приложений. На данный момент она находится в стадии активной разработки, и более подробной информаци о ней нет. Turbo — это новая библиотека, помогающая в создании интерактивных страниц. Turbo интегрирует между собой бэкенд, который для обновляемых частей приложения вместо JSON отправляет отрендеренный HTML, и клиент, который подписывается на обновления с бэкенда по web-сокету и подменяет части приложения прилетевшими кусочками HTML-кода.

Видел в твиттере и на hackernews разные мысли по поводу этого подхода. Кто-то пишет о том, что ребята переизобрели Laravel Lifewire. Кто-то хвалит за продвижение идеи минимального использования JavaScript. Кто-то ругает за то, что отказ от JSON смешивает между собой слои представления и приложения. Подход, как минимум, интересный, но будет ли он развиваться за пределами Ruby-экосистемы, пока остаётся вопросом.

#jsframeworks #announcement

https://hotwire.dev/
https://twitter.com/dhh/status/1341420143239450624

Андрей Ситник в блоге Злых Марсиан написал статью о современных практиках создания фавиконок сайта — "How to Favicon in 2021: Six files that fit most needs".

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

// HTML
<link rel="icon" href="/favicon.ico" /><!-- 32×32 -->
<link rel="icon" href="/icon.svg" type="image/svg+xml" sizes="any" />
<link rel="apple-touch-icon" href="/apple.png" /><!-- 180×180 -->
<link rel="manifest" href="/manifest.webmanifest" />

// manifest.webmanifest
{
  "icons": [
    { "src": "/192.png", "type": "image/png", "sizes": "192x192" },
    { "src": "/512.png", "type": "image/png", "sizes": "512x512" }
  ]
}

Формат ico нужен для поддержки RSS-ридеров. Формат SVG будет использоваться в браузерах (в статье есть пример, как в SVG сделать изменение цвета иконки в зависимости от текущей темы ОС). Иконка с rel="apple-touch-icon" нужна для того, чтобы ваш сайт красиво выглядел на домашнем экране iPhone. Файл манифеста нужен для добавления иконок, которые будут использоваться в Android.

Очень полезная статья. Рекомендую почитать.

#web

https://evilmartians.com/chronicles/how-to-favicon-in-2021-six-files-that-fit-most-needs

Владимир Агафонкин — автор библиотеки leaflet — написал туториал про создание мини-версии библиотеки для отображения географических карт — "A Web Map from Scratch".

Все растровые web-карты работают по похожему принципу. Сначала карта разбивается на тайлы (изображения размера 256x256 пикселей). На нулевом уровне масштаба будет один тайл, на первом — четыре, на втором — 16, а на пятнадцатом — 32768. Потом для заданного уровня масштаба, широты и долготы географической точки выбирается необходимый тайл. Для этого используются формулы вариации проекции Меркатора — Web Mercator projection. Для полученного тайла выбираются несколько соседних тайлов, и затем все они размещаются на странице с помощью абсолютного позиционирования.

Рекомендую посмотреть туториал, если интересно узнать принцип работы растровых версий Google-карт, Яндекс-карт и 2GIS.

#map #tutorial

https://observablehq.com/@mourner/simple-web-map

Дженс Оливер Маейерт написал небольшой пост о том, почему нужно забыть о AMP (Accelerated Mobile Pages) — "Ignore AMP".

В 2015 году Google предложил использовать AMP — технологию для ускорения доставки страниц. Намерение было благое, но сообщество выступило против этой инициативы с резкой критикой, в первую очередь из-за того, что AMP должен был распространяться с домена Google. По прошествии пяти лет AMP не получил большого распространения, более того Google начал продвигать другую инициативу с похожей целью — Web Vitals.

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

Советую заглянуть в статью, если задумывались о внедрении AMP в свой проект.

#google #web

https://meiert.com/en/blog/ignore-amp/

Энтони Рикод на perfplanet написал обзор HTML- и CSS-фич, которые могут помочь в уменьшении размера JS-бандла — "HTML and CSS techniques to reduce your JavaScript".

В статье рассказывается про то, как без использования JavaScript отобразить нужное количество строк в контейнере. Рассказывается про использование position: sticky для создания эффекта прилипающих к границам экрана элементов, про плавную прокрутку, про использование CSS Scroll Snap для создания слайдеров и про ленивую загрузку изображений.

Полезный обзор. Почитайте, если ещё не встречались с этим фичами.

#performance #html #css

https://calendar.perfplanet.com/2020/html-and-css-techniques-to-reduce-your-javascript/

Райан Карниато — автор библиотеки Solid.js — сравнил производительность популярных ui-фреймворков/библиотек и опубликовал результаты в статье "JavaScript Frameworks, Performance Comparison 2020".

Райан поделил все фреймворки на четыре группы. В группе с небольшим упором на производительность первые места взяли Alpine, Marko и React. В группе с большим упором на производительность на первых местах Riot, Preact и LitElement. В группе с очень большим упором на производительность лучшие результаты показали HyperApp, Svelte, Elm. В группе с максимальным упором на производительности с незначительным разрывом победил Solid.js, следом за ним идёт Inferno.

Выводы из статьи. Маркетинг не всегда отражает реальность, так как в разных проектах разные особенности. При выборе ui-фреймворка нужно делать свои бенчмарки; в одном случае будет лучше работать решение с Virtual DOM, в другом случае — DSL, компилируемый в JavaScript.

#jsframeworks #performance

https://medium.com/javascript-in-plain-english/javascript-frameworks-performance-comparison-2020-cd881ac21fce

Йехуда Катц — один из отцов Ember, cargo и участник W3C — написал в твиттере большой тред, о распространённом заблуждении, что фронтенд — это специализация для джуниоров.

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

Разнообразие тулинга во фронтенде объясняется не уровнем подготовки специалистов, а, снова, враждебной средой, в которой должен работать код. Код нужно транспилировать, чтобы поддержать разные браузеры; можно, конечно, использовать старые версии языка, но это больно. Большие проекты используют PostCSS для использования новых фич CSS, добавления вендорных префиксов и для автоматического обхода ошибок в браузерах. Чтобы код был доставлен пользователю как можно быстрее, он должен быть собран сборщиком и минифицирован. Код нужно оптимизировать, потому что основная масса пользователей используют мобильные устройства на слабых процессорах.

В общем, хороший тред. Очень рекомендую почитать.

#musings #web

https://twitter.com/wycats/status/1342484366279098369

Мальте Юбэл из Google написал статью про современные практики работы с изображениями в web — "Maximally optimizing image loading for the web in 2021".

В статье рассказывается про то, как избежать сдвига контента при работе с отзывчивыми изображениями, про ленивую загрузку изображений, кэширование, новый формат AVIF, использование тега <picture> и работу с размытыми заглушками.

Самым интересным в статье для меня было описание техник для снижения потребления и оптимизации CPU. Например, вставка изображений с атрибутом decoding="async" даёт сигнал браузерам о том, что декодировать изображение можно вне главного потока (в твиттере в обсуждении статьи, лид, отвечающий за рендеринг в Chrome, говорит о том, что этот атрибут не включён по умолчанию, так как загружаемый контент моргал бы при загрузке). Ещё в статье есть описание трюка с использованием размытия с помощью SVG-фильтров, благодаря этому подходу изображения размываются только один раз при загрузке, а не на каждый layout страницы как при использовании CSS-фильтров.

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

#graphics #web

https://www.industrialempathy.com/posts/image-optimizations/

Дорогие подписчики, с Новым Годом! Желаю всего самого наилучшего, будьте сильными, верьте в себя и пусть вам всегда улыбается удача!

Рйо Ота рассказал, как можно сделать 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

Саймон Вики рассказал, почему нужно перестать загружать шрифты с CDN Google — "Time to Say Goodbye to Google Fonts".

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

Саймон пишет о том, что раньше загрузка шрифтов Google не была большой проблемой, потому что закэшированный файл шрифта мог использоваться другими сайтами. С включением изолированного кэша в Chrome 86 сайты загружают шрифты повторно, сводя на нет одно из основных преимуществ CDN. В Firefox тоже есть планы на добавление изолированного кэша, а в Safari он работает уже с 2013 года.

#fonts #performance

https://wicki.io/posts/2020-11-goodbye-google-fonts/

Дэвид Нолэн — ведущий разработчик ClojureScript — рассказал про свой путь в разработке, про ClojureScript и о том, как он стал его основным майнтейнером.

Дэвид говорит, что самое ценное, что он перенял от Ричарда Хикки (автор Clojure), умение говорить "нет". При работе над проектами, которые используют большое количество людей, нужно уметь говорить "нет", чтобы иметь силы продолжать работать над важными фичами. Но не нужно просто отказывать, нужно мотивировать находить своё решение. Если пользователи приходят с багами, самое лучшее, что можно сделать — помочь им самим исправить проблемный код. Также работа над проектом должна приносить радость, иначе можно быстро выгореть.

Интересная статья. В первую очередь рекомендую почитать всем, кто поддерживает open source проекты.

#opensource #clojurescript #history

https://github.com/readme/david-nolen

Стэрен Джианнини решил отказаться от модных технологий и стал вести свой блог на чистом HTML и CSS без использования CMS, генераторов статических сайтов и т.п. Про это он написал статью "My stack will outlive yours".

Стэрен пишет о том, что концептуально в web'е существуют два вида страниц: web-страницы с простым содержанием и web-приложения. Обычный HTML и CSS покрывает всё необходимое, что может потребоваться для создания простых web-страниц: лендингов, сайтов-портфолио, блогов и сайтов с документацией. При разработке простого сайта не требуется настраивать сборку, устанавливать зависимости и использовать тяжёлые IDE. Он будет прекрасно работать и через 10 лет. Использование семантичной вёрстки поможет не заблудиться в коде, а если нужно будет поменять однотипные места на нескольких похожих страницах, то для этого можно использовать функцию редактора ”Replace in files”.

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

#html #css #musings

https://blog.steren.fr/2020/my-stack-will-outlive-yours/

Петер Перлепес написал статью про обработку событий перехода страницы в фоновый режим — "Exploring the Page Visibility API for Detecting Page Background State".

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

Все браузеры поддерживают события beforeunload и unload, с помощью которых можно отловить закрытие страницы, но они ненадёжны на мобильных платформах. Ещё эти события могут негативно влиять на Back/Forward Cache браузера. Современный подход — использование событий Page Visibility API: pagehide и visibilitychange. С ними есть сложности, связанные с кроссбраузерностью. В статье рассказывается о том, как лучше всего их использовать.

#js #web

https://tech.trivago.com/2020/11/17/exploring-the-page-visibility-api-for-detecting-page-background-state/

За прошедшие две недели в канале для патронов Defront было опубликовано много интересных постов:

— Великая стагнация индустрии разработки ПО
— Улучшение производительности cайта с помощью фасадов
— Влияние CSS-свойства content-visibility на доступность сайтов
— Как использовать web-шрифты, не ухудшая производительность
— Использование api-extractor в TypeScript-проектах
— React core team изнутри
— Как разработчики curl используют git
— Доступность ссылок на якоря
— Влияние data URI на производительность сайтов
— Как Discord добавил поддержку навигации с клавиатуры

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

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

https://www.patreon.com/myshov

Майкл Линч написал статью о том, в каком виде лучше всего отправлять код на код ревью, чтобы оно прошло максимально быстро — "How to Make Your Code Reviewer Fall in Love with You".

Самое важное правило для автора кода — ценить время ревьювера. Прежде чем отправить код на ревью, попробуйте сделать ревью самостоятельно. Если набор изменений слишком большой, его лучше разбить на несколько частей. Также вместе с пулл реквестом желательно давать дополнительную информацию о изменениях, чтобы проверяющие не тратили время на разбор кода, пытаясь понять почему проблема была решена именно так, а не иначе. Этот контекст может пригодиться автору кода и его коллегам в будущем.

Очень полезная статья. Must read для всех, кто работает в команде.

#programming

https://mtlynch.io/code-review-love/

В прошлом году самой горячей темой стало усилившееся разногласие в отношении будущего веба между Apple, Google и Mozilla. Google продвигает идею "нативного" веба, добавляя в Chromium экспериментальные API для доступа К Bluetooth/USB-устройствам, файловой системе пользователя и т.п. Apple и Mozilla придерживаются консервативной позиции и не хотят добавлять некоторые API, предлагаемые Google, объясняя это заботой о приватности и безопасности пользователей.

Ноам Розенталь — участвует в разработке стандартов и движков браузеров — постарался объективно разобраться в этой теме и поделился своим видением решения возникшей проблемы — "Should The Web Expose Hardware Capabilities?".

В первой части статьи Ноам пытается понять обе стороны спора и пишет о том, что по-своему правы и Google, и Apple с Mozilla. С одной стороны мы хотим видеть развитие платформы, с другой стороны мы не хотим жертвовать безопасностью пользователей. Это очень серьёзный вопрос, например, в 2018 году исследователи в области безопасности рассказали о способе компроментации USB-ключей доступа с помощью WebUSB (Google эту проблему устранил). Чтобы избежать подобных проблем в будущем во второй части статьи автор предлагает внедрить модель доверия, в которой разработчики железа и браузеров могут ограничить урон, который может быть нанесён потенциально небезопасными API.

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

#web #specification

https://www.smashingmagazine.com/2021/01/web-expose-hardware-capabilities/