Defront — про фронтенд-разработку и не только – Telegram
Defront — про фронтенд-разработку и не только
13.3K subscribers
21 photos
1.09K links
Ламповый канал про фронтенд и не только. Всё самое полезное для опытных web-разработчиков

Обсуждение постов @defrontchat

Также советую канал @webnya
Download Telegram
Вчера вышла новая версия Chrome. Пит Лепаж рассказал про новые фичи релиза — "New in Chrome 84".

PWA приложения теперь могут регистрировать шорткаты (написать сообщение, перейти к непрочитанным сообщениям и т.п.), которые становятся доступны по правому клику на иконке приложения на десктопе или по длинному тапу на Android. Стал доступен Content Indexing API. Благодаря ему можно извлечь информацию о закэшированных элементах и отобразить её пользователю.

Стала доступна реализация Wake Lock API. Над этой спекой работали ребята из Яндекса и Microsoft. С помощью Wake Lock можно временно заблокировать отключение экрана устройства при неактивности пользователя (полезно для сайтов с кулинарными рецептами, галерей и т.п.) Обновлена реализация Web Animations API — animation.ready и animation.finished возвращают промисы, добавлены опции add и accumulate, улучшена производительность API. В рамках Origin Trials теперь доступен Idle Detection API для отображения статуса активности пользователя (будет полезно для чатов), а также стал доступен Web Assembly SIMD.

Много изменений в Chrome Dev Tools. Начата работа по вычищению консоли от предупреждений браузера — они потихоньку будут переезжать в таб "Issues". В попапе режима инспектирования теперь отображается информация о a11y. Обновлена панель производительности. Добавлено отображение метрик TBT (Total Blocking Time) и Cumulative Layout Shift (CLS), в событии "Layout Shift" можно проинспектировать произошедший сдвиг контента.

Возобновлён процесс выкатки SameSite для cookies, который был временно приостановлен из пандемии COVID-19. Удалена поддержка TLS 1.0 и TLS 1.1. Потенциально небезопасные запросы доступа к геолокации, отправки нотификаций и т.п. будут скрываться с помощью нового интерфейса.

#release #chrome

https://developers.google.com/web/updates/2020/07/nic84
Неделя релизов продолжается. Вчера компания Adobe представила свою библиотеку React-компонентов — "Introducing React Spectrum".

В React Spectrum каждый компонент поделён на две части, которые живут в отдельных библиотеках. В библиотеке React Aria находятся хуки для работы с a11y, i18n и поведением компонентов. В библиотеке React Stately — хуки для работы со стейтом компонентов. Такое разделение удобно для переиспользования кода между разными платформами. Эти библиотеки комбинируются под зонтиком библиотеки React Spectrum, которая имплементирует дизайн-систему от Adobe. Компонентов в библиотеке довольно много. Есть Calendar, Table, Tree и другие стандартные компоненты.

Интересное решение. Если нужен компонент с немного другим поведением, можно не форкать библиотеку, а просто переопределить необходимый хук.

#react #ui #release

https://react-spectrum.adobe.com/blog/introducing-react-spectrum.html
Станислав Черенков написал статью про использование роутинга в современных SPA-приложениях — "Your SPA doesn’t need a router".

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

В статье предлагается альтернативный подход с отделением представления от логики роутинга и использованием только самых необходимых библиотек, например, для сериализации url страницы в объект.

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

#musings #architecture

https://forweb.dev/en/blog/drop-the-router/
Хуссеейн Джирде из команды Chromium недавно представил инструмент для анализа метрик производительности js-фреймворков — "Perf Track".

Perf Track — это дашборд, на котором агрегируются метрики по популярным фреймворкам: общий размер js, использование сжатия, First Contentful Paint, Largest Contentful Paint, Cumulative Layout Shift и т.п. Данные для анализа берутся из HTTP Archive и Chrome User Experience Report. Из интересного: статистика по First Input Delay хуже всего у React и Ember, статистика по First Contentful Paint — у Angular и Polymer. Лучше всего показатели у Svelte, но размер выборки Svelte-проектов на порядки меньше выборки других фреймворков, поэтому могут быть сильные перекосы.

Надо понимать, что Perf Track показывает среднюю температуру по больнице. Тем не менее он может быть полезен для анализа общего положения дел.

#performance #tool #jsframeworks

https://perf-track.web.app/
Дэниэл Александерсен поделился результатами сравнения WebP и AVIF в статье "Comparing AVIF vs WebP file sizes at the same DSSIM".

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

При сравнении с оригинальными JPEG-изображениями медианное значение сокращения размера файлов при сжатии с помощью WebP составило 31.5%, у AVIF — 50.3%, на 85-ом перцинтиле 20% у WebP и 39.6% у AVIF. У WebP 2.7% изображений оказались больше оригинального изображения, у AVIF все изображения были меньше.

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

#graphics #optimization #benchmark

https://www.ctrl.blog/entry/webp-avif-comparison.html
Мэттью Виплайз написал статью про генерацию UUID на клиенте — "Generating UUIDs at scale on the Web".

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

Для генерации UUID рассматривались два варианта: Web Crypto API и URL.createObjectURL(). Остановились на последнем, так как для надёжного использования Web Crypto API требовалась инициализация кода в веб-воркере, из-за этого просаживалась скорость. Перед тем как внедрить новое решение был проведён A/B-тест, чтобы удостовериться, что нет коллизий при генерации UUID. Данные показали примерно пять коллизий на один миллион запросов. Это было гораздо больше чем в теории. Исследования показали, что основная проблема была в гугл-боте, меньшая часть проблем была связана с браузером в PS Vita и .Net-конверторами html в pdf.

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

#cryptography #internals

https://medium.com/teads-engineering/generating-uuids-at-scale-on-the-web-2877f529d2a2
Сегодня Defront Plus отмечает свой первый месяц. В нём уже было опубликовано двадцать новых постов (по пять дополнительных постов каждую неделю). Хочется поделиться тем, что там было опубликовано за последние две недели:
— Искусственный интеллект и будущее программирования
— Использование Bazel в монорепозитории
— Исследование блокировок Google Analytics
— Предзагрузка отзывчивых изображений
— Семантичное использование кнопок и ссылок
— Исследование дублирующихся запросов за html
— Критика книги "Чистый код"
— Использование Rust вместо TypeScript
— Почему браузеры не специфицируют UI, отвечающий за безопасность
— Исследование использования Cache-Control на разных сайтах

Поддержите канал на Patreon и получите доступ к Defront Plus!

https://www.patreon.com/myshov
Пару дней назад вышел Chrome 84, в нём был обновлён Lighthouse до шестой версии. Про все новинки этой версии рассказал Коннор Кларк в статье "What's New in Lighthouse 6.0".

Самые важные изменения касаются анализа производительности. Были добавлены новые метрики из набора Web Vitals: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) и Total Blocking Time (TBT) (самый близкий аналог First Input Delay). Обновление метрик повлияло на формулу оценки производительности страницы: в неё были добавлены метрики Web Vitals и удалены First Meaningful Paint, First CPU Idle и Max Potential FID. В статье подробно объясняются причины удаления старых метрик.

Были добавлены новые проверки в категории a11y (aria-hidden-body, aria-hidden-focus, aria-input-field-name и т.п.), по умолчанию включена визуализация неиспользуемого JavaScript, добавлена проверка элемента <meta charset="...">. В Node CLI и Lighthouse CI была добавлена поддержка бюджета для метрик производительности.

#performance #release

https://web.dev/lighthouse-whats-new-6.0/
Лия Веру написала небольшую статью про то как подружить между собой ESM и библиотеки, использующие другие подходы, — "Import non-ESM libraries in ES Modules, with client-side vanilla JS".

Все популярные браузеры поддерживают нативную модульную систему (ESM). Проблема в том, что есть очень много CommonJS-библиотек, которые были написаны давно и которые просто так нельзя взять и подключить к себе с помощью import. Для обхода этой проблемы Лия предлагает использовать небольшой трюк, суть которого заключается в использовании динамического импорта с предварительно застабленной переменной module:

async function require(path) {
let _module = window.module;
window.module = {};
await import(path);
let exports = module.exports;
window.module = _module;
return exports;
}


У такого подхода много ограничений, но он может пригодиться, если надо по-быстрому поэкспериментировать с библиотеками, которые распространяются как CommonJS/AMD-модули (для AMD надо стабить define).

#esm #trick #js

https://lea.verou.me/2020/07/import-non-esm-libraries-in-es-modules-with-client-side-vanilla-js/
Орта Терокс в блоге Svelte написал статью о поддержке TypeScript — "Svelte ❤️ TypeScript".

TypeScript в Svelte поддерживался и раньше с помощью набора независимых инструментов, работа с которыми была неудобна для рядовых разработчиков. Эти инструменты были перемещены в GitHub-организацию Svelte и в целом была улучшена эргономика работы с TS в Svelte.

Поддержку TS можно включить с помощью установки необходимых пакетов и добавления атрибута lang="ts" в noscript. Ручную проверку типов можно запустить с помощью svelte-check. В редакторах поддерживается автодополнение кода и проверка типов в том числе внутри разметки.

Очень хорошая новость. Полноценную поддержку TypeScript в Svelte ждали многие разработчики.

#svelte #typenoscript #jsframeworks

https://svelte.dev/blog/svelte-and-typenoscript
Гиллель Уэйн поделился своими мыслями о том, как можно улучшить подсветку синтаксиса — "Syntax highlighting is a waste of an information channel".

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

В теории всё это выглядит очень заманчиво, но имплементация упирается в суровую действительность. Такая семантичеcкая подсветка должна реализовываться для каждого языка в отдельности, при этом многие фишки возможно реализовать только тогда, когда доступно AST.

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

#programming #musings

https://buttondown.email/hillelwayne/archive/syntax-highlighting-is-a-waste-of-an-information/
Генрик Уорн написал статью про хорошее логирование — "Good Logging".

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

Логирование не должно быть слишком подробным или скупым. Хорошие сообщения в логах должны говорить не про абстрактные серверы и файлы, а про конкретные ip-адреса и имена файлов. Сообщения должны быть таким, чтобы по ним можно было удобно grep'ать. При логировании сложной логики все шаги можно поместить в список, и вывести его в лог как одну большую строку. В хороших сообщениях не должно быть специальных символов, чтобы подчеркнуть важность, лучше для этого использовать разные уровни логирования (DEBUR, ERROR, INFO etc.) Очень трудно с первого раза придумать хорошие сообщения, поэтому их нужно постепенно улучшать. Также нужно не забывать добавлять новые сообщения, если при отладке ошибки в логах нет всей нужной информации.

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

#debug #programming

https://henrikwarne.com/2020/07/23/good-logging/
Иан Бин рассказал, почему для своего блога он выбрал Eleventy, а не Gatsby — "Your blog doesn’t need a JavaScript framework".

Eleventy и Gatsby это наиболее популярные движки для статически генерируемых сайтов в JS-сообществе. Gatsby построен на базе React — это его основное преимущество (React знают многие разработчики) и недостаток (дополнительно добавляет несколько сотен килобайт JS). Иан задался вопросом: зачем для статически гененрируемого сайта в принципе нужен JS? В Gatsby можно отключить загрузку JS с помощью специального плагина, но такой JS-first подход несёт слишком много накладных расходов, поэтому Иан остановился на Eleventy. Eleventy быстрый движок для статически генерируемых сайтов. Он использует markdown для основного контента и традиционные шаблонизаторы (nunjucks, liquid) для всего остального.

Иан рекомендует при выборе инструментов пользоваться правилом наименьшей силы: если вся работа может быть сделана только с помощью HTML и CSS, то JS использовать не нужно.

P.S. Eleventy сейчас используется в Google (в блогах v8 и web.dev), CERN, Khan Academy, Netlify. Сайт Defront тоже работает на Eleventy.

#performance #web

https://iainbean.com/posts/2020/your-blog-doesnt-need-a-javanoscript-framework/
Пару дней назад в канале @juliarderity увидел сообщение, что на последней встрече TC39 на stage 2 продвинулся метод item. Ти-Джей Краудер написал статью про это новое предложение — "The item Method for Indexables".

Пропозал добавляет новый метод для индексируемых типов (строки, массивы, типизированные массивы). С помощью него можно получить элемент по переданному индексу, но в отличие от [] в item можно передавать отрицательные индексы для получения элементов с конца (как в Python). Использование нового метода помогает сократить работу, которая требуется для доступа к последним элементам массива, возвращаемого из функции:

// эти две строки кода:
const result = theFunction();
const last = result[result.length - 1];

// можно заменить одной:
const last = theFunction().item(-1);


Выбор названия метода (item) связан с наличием этого метода в DOM-коллекциях NodeList и HTMLCollection. Это было важно учесть, так как на данный момент идёт работа над тем, чтобы сделать из этих коллекций полноценные массивы.

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

#js #proposal

https://thenewtoys.dev/blog/2020/07/25/the-item-method-for-indexables/
https://github.com/tc39-transfer/proposal-item-method
Недавно Google обновил планы по переходу на mobile-first поиск — "Prepare for mobile-first indexing (with a little extra time)".

Количество пользователей интернета, использующих смартфоны, давно превысило количество пользователей десктопных платформ. Именно поэтому Google продвигает разные инициативы, улучшающие опыт работы с мобильным вебом. В том числе было запланировано включение mobile-first индексирования с сентября 2020 года, но из-за пандемии дата была перенесена на конец марта 2021 года.

Mobile-first индексирование означает, что поисковик будет использовать мобильные версии страниц для ранжирования. В статье есть рекомендации, что проверить и исправить, чтобы сайт не упал в результатах поисковой выдачи.

#seo #google #announcement

https://webmasters.googleblog.com/2020/07/prepare-for-mobile-first-indexing-with.html
Вчера вышел Firefox 79. Флориан Шольц и Гарольд Киршнер рассказали про все новинки релиза — "Firefox 79: The safe return of shared memory, new tooling, and platform updates".

В конце 2018 года из-за атаки Spectre во всех браузерах были отключены разделяемая память (SharedArrayBuffer) и таймеры с высоким разрешением. В Firefox 79 поддержка этих фич вернулась на место, но для их использования страница должна быть изолирована с помощью HTTP-заголовков Cross-Origin-Opener-Policy: same-origin и Cross-Origin-Embedder-Policy: require-corp. Возврат поддержки SharedArrayBuffer также позволил реализовать WebAssembly Threads.

Добавлена поддержка Promise.any(). При передаче коллекции промисов в any() метод возвращает промис, который разрезолвится в том случае, когда разрезолвится один из переданных промисов или вернёт AggreateError, если все промисы будут реджекнуты. Добавлена поддержка логических операторов присваивания, WeakRef и FinalizationRegistry.

Для предотвращения модификации window.opener Firefox теперь автоматически устанавливает rel=noopener для всех ссылок с target=_blank.

Очень много изменений в инструментах разработчика. Стектрейсы теперь показывают полноценный стек для асинхронного кода. Флоу перехода от js-ошибок из консоли в дебаггер стал более продуман: после перехода проблемный код будет подсвечен, а при наведении будет выведена подсказка с типом ошибки. Улучшена поддержка соурс мапов в DOM-инспекторе для SCSS и CSS-in-JS. В отладчике появилась новая фича “Restart Frame”, которая позволяет "путешествовать во времени" в рамках стека вызовов. Также отладчик снова получил порцию обновлений, улучшающих производительность.

#release #firefox

https://hacks.mozilla.org/2020/07/firefox-79/
Амелия Ваттенбергер написала интерактивную статью про использование процентов в CSS — "What does 100% mean in CSS?".

В статье есть хорошие интерактивные примеры и краткое описание поведения процентов для разных свойств:
- для height процент высчитывается относительно высоты родителя
- для width — относительно ширины родителя
- для top — относительно высоты родителя
- для left — относительно ширины родителя
- для margin-top — относительно ширины родителя
- для margin-left — относительно ширины родителя
- для padding-top — относительно ширины родителя
- для padding-left — относительно ширины родителя
- для translate-top — относительно высоты элемента
- для translate-left — относительно ширины элемента

Очень прикольная статья. Советую почитать всем, кто хочет разобраться с процентами в CSS.

#css

https://wattenberger.com/blog/css-percents
Гергели Орос — технический руководитель из Uber — рассказал про алгоритмы и структуры данных, с которыми ему приходилось сталкиваться на протяжении карьеры — "Data Structures & Algorithms I Actually Used Working at Tech Companies".

В статье есть много примеров использования алгоритмов: от обхода DOM-дерева для добавления поддержки голосового ввода для Skype на Xbox OS до гексогональных гридов с иерархическими индексами в Uber для оптимизации цены поездок. Интересная задача была в Skyskanner с поиском наиболее дешёвых билетов с маршрутом через несколько городов. Для её решения была использована модифицированная реализация алгоритма A*.

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

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

#algorithm #musings

https://blog.pragmaticengineer.com/data-structures-and-algorithms-i-actually-used-day-to-day/
На прошедшем WWDC 2020 была представлена внутренняя статистика о использовании протоколов интернета на устройствах Apple. На zdnet по этому поводу была опубликована небольшая статья.

Разработчики рассказали, что в мае 2020 года около 79% сайтов, которые открывались с помощью Safari, были загружены по HTTP/2. По сравнению с HTTP/1.1 страницы загружались на 80% быстрее. При использовании IPv6 медианное время установки соединения было на 40% быстрее чем при использовании IPv4. Такое уменьшение объясняется уменьшенным использованием NAT и улучшениями в маршрутизации. 49% всех сетевых соединений на современных устройствах Apple использовали TLS 1.3; HTTPS-соединение устанавливалось на 30% быстрее по сравнению c TLS 1.2.

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

#performance #apple

https://www.zdnet.com/article/apple-tells-app-devs-to-use-ipv6-as-its-1-4-times-faster-than-ipv4/
Крис Лили — технический директор W3C — рассказал о проблемных частях CSS — "Why is CSS... the way it is?".

В спецификации CSS у некоторых фич есть недостатки. Например, свойство float плохо специфицировано для сложных случаев. Работа с цветами неудобна при реализации дизайн систем или просто для определения цвета английскими словами ( gainsboro, orchid и т.п. ничего не говорят об оттенке). Есть проблемы при работе с диапазонами Unicode-значений в свойстве unicode-range.

Некоторые эти проблемы связаны с тем, что во времена зарождения спецификации было важно, чтобы язык был максимально простым. Простота реализации была важна для добавления CSS в Internet Explorer и Netscape Navigator. Другие проблемы были связаны с тем, что при ревью новых фич у проверяющих не было необходимого опыта.

Все эти проблемы известны. Над ними либо работают в данный момент (например, с цветами), либо эти проблемные фичи были заменены более продвинутыми альтернативами (например, вместо float для разметки страницы сейчас рекомендуется использовать flex и grid ).

Очень интересная статья. Рекомендую почитать всем, кто интересуется историей развития web'а.

#css #history

https://increment.com/frontend/ask-an-expert-why-is-css-the-way-it-is/
Джошуа Голдберг в своём блоге задокументировал процесс добавления новой фичи в TypeScript — "TypeScript Contribution Diary: // @ts-expect-error".

Джошуа добавил поддержку новой директивы // @ts-expect-error в TypeScript 3.9. С её помощью можно подавить конкретные ошибки компилятора. В статье очень подробно рассказывается, как была добавлена эта фича, что было изменено, почему это было сделано именно так, с какими проблемами столкнулись пользователи после релиза RC-версии, какие были фиксы и т.п. Например, в начальной реализации для JSX не учитывался случай использования директивы игнорирования ошибок подобным образом:

{/*
// @ts-ignore */}
<MissingRequiredProp />


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

#internals #typenoscript

http://blog.joshuakgoldberg.com/ts-expect-error/