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

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

Также советую канал @webnya
Download Telegram
Иан Бин дал несколько рекомендаций по использованию шрифтов — "System fonts don’t have to be ugly".

Во всех операционных системах есть предустановленный набор очень качественных шрифтов. Они могут составить хорошую конкуренцию модным web-шрифтам. Иан предлагает по умолчанию использовать системные шрифты (Georgia, Charter, Palantino, Hoefler, San Francisco, Helvetica, Segoe UI, Arial и т.п.) для оформления текстов на сайте, а web-шрифты оставить только для редких случаев, когда системный шрифт не подходит. Благодаря такому подходу отпадает проблема оптимизации web-шрифтов, и в целом сайт будет загружаться быстрее.

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

#typography #performance

https://iainbean.com/posts/2021/system-fonts-dont-have-to-be-ugly/
Два года назад Зак Лезерман у себя в твиттере в качестве шутки предложил идею написать кому-нибудь статью, как сделать медленную HTML-страницу, которая бы была быстрой для Lighthouse. Барри Полларду удалось это сделать, о чём он рассказал в статье "Making the slowest 'fast' page".

Сделать медленную страницу, которая бы смогла заработать 100 баллов в Lighthouse, очень трудно. Барри пошёл другим путём — он сделал быструю страницу и "замедлил" её с помощью увеличения времени воспринимаемой производительности. Для этого он перекрасил текст сайта в белый цвет и, спустя 10 секунд, вернул его в нормальный вид.

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

#performance

https://www.tunetheweb.com/blog/making-the-slowest-fast-page/
Алон Кочба из Wix рассказал об опыте улучшения производительности сайтов, сделанных с помощью их конструктора — "How Wix improved website performance by evolving their infrastructure".

Несколько лет назад Wix-сайты представляли собой SPA-приложения, которые рендерились в браузере клиента. Это было основной причиной неудовлетворительной производительности. В прошлом году ребята добавили поддержку серверного рендеринга. Страницы сайтов теперь раздаются с помощью CDN и кэшируется на стороне браузера и сервера. Пользовательская информация больше не попадает на страницу, но подтягивается на стороне клиента. Также была добавлена поддержка HTTP/2 и brotli.

В статье нет информации о том, насколько улучшилась метрики Web Vitals, но в целом разработчики довольны проделанной работой.

#performance

https://web.dev/wix/
Алекс Котлярский из Facebook рассказал про историю развития React API — "React API evolution".

Прошло уже почти восемь лет с момента релиза первой публичной версии React. За этот период подход к написанию компонентов поменялся несколько раз. Сначала компоненты создавались с помощью React.createClass причём в версии 0.3.0 нужно было самостоятельно биндить методы, использующие this, с помощью React.autoBind. В 0.4.0 автобиндинг был включён по умолчанию. Затем официальным механизмом для создания компонентов стали ECMAScript классы и функциональные компоненты. По ходу дела разработчики стали использовать High Order Components (HOC) для композиции поведения компонентов. HOC не были идеальным решением для работы с поведением, поэтому в 2019 году ребята из команды React представили хуки.

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

#react #history

https://frantic.im/react-api-evolution
Майк Уэст в блоге Chromium написал статью про средства предотвращения неявных утечек данных между сайтами в пределах одного процесса браузера — "Mitigating Side-Channel Attacks".

Браузеры полагаются на концепцию origin для предотвращения явной утечки данных между сайтами. Но существуют атаки по сторонним каналам, которые могут обойти ограничения браузера и прочитать любые пользовательские данные любых сайтов. Например, с помощью атаки Spectre можно было читать данные сайтов-соседей, которые попадали в один браузерный процесс. Для этого небезопасный сайт example.com мог добавить на страницу ресурс другого сайта ( <img src="https://email.com/user_emails.json" /> ) и получить доступ к его содержимому через единое адресное пространство памяти процесса. Чтобы предотвратить Spectre, браузеры по умолчанию отключили небезопасные API и включают их лишь только для тех сайтов, которые можно изолировать между разными процессами (Site Isolation).

Для предотвращения атак подобного типа можно использовать другие методы, даже если браузер не поддерживает Site Isolation:

— Ограничение ответов со стороны сервера на основе анализа HTTP-заголовков Sec-Fetch-*,
— Ограничение возможности загружать ресурс как подресурс (то есть как в примере с img выше) с помощью cross-origin-resource-policy (CORP),
— Предотвращение загрузки документа в iframe'ах с помощью X-Frame-Options: SAMEORIGIN и CSP-политик,
— Ограничение доступа к window opener'а с помощью Cross-Origin-Opener-Policy (COOP),
— Предотвращение атак MIME-type confusion с помощью X-Content-Type-Options: nosniff и установки корректных заголовков Content-Type.

#security

https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html
Эмили Старк из команды Google Chrome поделилась советами о том, как эффективно читать спецификации web-стандартов — "Tips for reading web standards".

Многие стандарты обновляются часто по мере развития браузеров. Поэтому в первую очередь нужно смотреть последние черновики спецификаций (editor’s/latest draft), которые включают в себя все последние нововведения. Очень помогает в понимании спецификации вводная часть (explainer). Её Эмили советует читать от начала до конца, так как она содержит информацию для упрощения понимание спеки в целом. С другой стороны, чтобы разобраться в поведении какой-либо фичи, читать саму спецификацию от начала до конца не обязательно.

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

#spec

https://emilymstark.com/2021/03/14/tips-for-reading-web-standards.html
За прошедшие две недели в канале для патронов Defront было опубликовано десять постов:

— Ускорение рендеринга страниц сайта с помощью prefetch
— Ленивая загрузка компонентов React Native
— Лучшие практики и их влияние на производительность
— Опыт использования WebRTC в большом проекте
— Частые ошибки при работе с промисами и async/await
— Исследование производительности страницы с помощью Cloudflare Workers
— Тайпгарды TypeScript для валидации данных
— Мысли об управлении состоянием приложения
— Использование мобильного Safari для анализа производительности
— Влияние наложения элементов на лишние перерисовки

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

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

https://www.patreon.com/myshov
Хемант — делегат TC39 — опубликовал статью, посвящённую "Error Cause" — предложению о добавлении в стандарт ECMAScript.

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

Для того чтобы причину оригинальной ошибки можно было найти в предсказуемом месте, например это важно при разработке DevTools, в пропозале "Error Cause" предлагается передавать оригинальную ошибку с помощью объекта со свойством cause вторыми параметром в конструктор объекта Error:

throw new Error('There was a problem', {
cause: err
});


На данный момент пропозал "Error cause" находится на третьем этапе добавления в стандарт. Его поддержка уже есть в JS-движках Chakra и JavaScriptCore.

#js #proposal

https://dev.to/hemanth/error-cause-in-javanoscript-425d
В блоге DebugBear была опубликована статья, посвящённая распространённым проблемам при работе с <link rel="preload">, — "Common problems with rel='preload'".

Предзагрузка слишком большого числа ресурсов с большой вероятностью приведёт к медленной загрузке страницы. В этом случае канал будет перегружен, и в итоге страница загрузится медленнее по сравнению с тем, если бы на ней вообще не использовалась предзагрузка. Ещё одна частая проблема — предзагрузка шрифтов без атрибута crossorigin. Дело в том, что браузеры загружают шрифты в анонимном CORS-режиме (то есть без отправки кук). В случае с обычной предзагрузкой (без атрибута crossorigin ) куки отправляются, что приводит к расхождению запросов (один с куками, второй без кук), и из-за этого браузер будет загружать один и тот же шрифт два раза.

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

#performance

https://www.debugbear.com/blog/rel-preload-problems
Бен Фрейн рассказал о новом черновике спецификации вложенности в CSS — "CSS Nesting – the last piece of the puzzle".

Недавно Адам Аргайл представил сообществу черновик спецификации, над которым он работает вместе с Табом Аткинсом. В этой спецификации описывается синтаксис вложенности, который похож на аналогичный синтаксис из SASS и LESS. Основное отличие — нужно использовать @nest при размещения вкладываемого селектора в качестве потомка:

.selector {
width: 100%;
@nest .other-selector & {
color: #333;
}
}


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

#css #proposal

https://benfrain.com/official-css-nesting-the-last-piece-of-the-puzzle/
Big news everyone!

Я присоединился к Russian MDN Team — буду помогать поддерживать русскоязычную часть MDN (перевод сайта, перевод и улучшение документации, ревью входящих пулл реквестов и т.п.) Моя работа над MDN — это волонтёрская деятельность, и она была бы невозможна без вас.

Спасибо за то, что читаете и поддерживаете канал!
Эрик Лоуренс из команды разработки Edge рассказал про особенности работы метода window.close в разных браузерах — "window.close() Restrictions".

В спецификации написано, что окно может быть закрыто с помощью close только тогда, когда оно было открыто с помощью скрипта и когда в текущей истории посещений таба находится только один документ. Такие ограничения были добавлены, для того чтобы предотвратить негативные UX-паттерны, связанные с закрытием документа.

Все браузеры реализуют close немного по-разному. Это связано с тем, что стандарт был написан уже после того, как close появился браузерах. Chromium, например, не проверяет, была ли страница открыта с помощью JS, а смотрят на наличие opener.

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

#js

https://textslashplain.com/2021/02/04/window-close-restrictions/
Chrome 92 будет предотвращать небезопасный доступ к сервисам локальной сети. Обо всех подробностях рассказали Эиджи Китамура и Титуан Ригоди в статье "Private Network Access (CORS-RFC1918) updates".

Сейчас сайты могут без проблем обращаться к ресурсам из локальной сети. Например, внешний сайт компании может отправлять какую-нибудь статистику в интранет-сеть для тех пользователей, у которых есть к ней доступ. Такая политика небезопасна, так как любой внешний сайт может отправить любой запрос не только к внутреннем сайтам, но и к роутеру или принтеру пользователя. Подобным образом в 2014 году были взломаны более 300 тысяч роутеров по всему миру.

Начиная с Chrome 90 браузер будет предупреждать о небезопасных запросах при обращении к ресурсам локальной сети. В Chrome 92 такие запросы перестанут работать по умолчанию. Чтобы они продолжали работать, сайт-инициатор запроса и целевой сайт должны работать по HTTPS. Также в будущем будут проверяться CORS-заголовки, разрешающие доступ к ресурсу (пока эта часть спецификации находится на стадии обсуждения).

#security #chrome

https://developer.chrome.com/blog/private-network-access-update/
👍1
Джереми Вагнер рассказал о своём опыте использования сервис воркеров — "Now THAT’S What I Call Service Worker!".

Джереми работал с сайтом клиента, который часто посещают пользователи с ненадёжным подключением к сети. Добавление сервис воркера со стандартной схемой кэширования всего ответа улучшило метрики производительности на 10-20%. Дальнейшее его улучшение с помощью сохранения заголовка и подвала сайта в оффлайнт-кеше и динамического формирования всей страницы в сервис воркере улучшило FCP на 40%, а LCP на 51%. В статье есть пример с подробной реализацией этой стратегии.

Выводы из статьи. Даже самая базовая интеграция сервис воркера даёт преимущества по сравнению с обычным HTTP-кешированием.

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

#performance #serviceworker

https://alistapart.com/article/now-thats-what-i-call-service-worker/
One more big news everyone!

У канала появился генеральный спонсор — Зарплата.ру. Зарплата.ру будет поддерживать всю мою работу для сообщества (Defront, MDN и т.п.) С ребятами из Зарплаты я знаком уже несколько лет. Они из Новосибирска, смело экспериментируют с технологиями у себя в компании и принимают участие в жизни IT-сообщества.

Зарплата.ру согласилась поддерживать Defront с сохранением полной независимости канала. Единственное изменение — в канале будут появляться дополнительные сообщения от спонсора два раза в месяц.

Я очень рад нашему сотрудничеству. Надеюсь, что оно будет очень продуктивным!
На прошлой неделе Ингвар Степанян рассказал о новых фичах девятой версии V8 — "V8 release v9.0".

В регулярных выражениях появилась поддержка флага /d, благодаря которому в результате выполнения регулярки (match object) появляется свойство indicies с позициями текущих скобочных групп (capturing group).

На порядки ускорен доступ к полям родительского объекта с помощью super.

Последовательность токенов for ( async of теперь больше не парсится.

В WebAssembly появилась экспериментальная поддержка инлайна враппера JS-to-Wasm для более эффективного преобразования параметров функций при их передаче из JS в Wasm. Эта фича будет особенно полезна в тех случаях, когда вызов Wasm-функции находится на горячем участке JavaScript-кода.

На данный момент V8 v9.0 находится в бете. Стабильная версия выйдет вместе с Chrome 90.

#v8 #release

https://v8.dev/blog/v8-release-90
Channel name was changed to «Defront (при поддержке Зарплата.ру) — про фронтенд-разработку и не только»
Джаред Уайт рассказал о своей боли при работе с фронтенд-библиотеками и инструментами — "The Shocking Immaturity of JavaScript".

Джаред пишет, что в современном фронтенде среди авторов инструментов и библиотек есть тенденция уделять больше внимания маркетингу, а не проблемам пользователей. Из-за этого страдает вся экосистема, а новички, работающие с фронтендом, тонут в большом количестве багов, зачастую обвиняя себя в неспособности разобраться с проектом.

Решение проблемы — быть честнее со своими пользователями. Если библиотека находится в экспериментальном режиме, надо об этом рассказать в readme или добавить alpha к номеру версии. Если у инструмента или библиотеки есть ограничения, надо об этом тоже написать и в самом лучшем случае посоветовать подходящие альтернативы.

Не все проекты страдают от подобных проблем. Автор советует брать пример с LitElement, PostCSS, Shoelace и Webpack.

#musings #js #opensource

https://dev.to/jaredcwhite/the-shocking-immaturity-of-javanoscript-c70
Forwarded from Вебня (Sergey Rubanov)
Google в сотрудничестве с другими вендорами и партнёрами создали инициативу Compat2021

В рамках неё будет проведена работа по улучшению совместимости 5 критических для разработчиков CSS фич:
- Flexbox
- Grid
- position: sticky
- aspect-ratio
- transforms

Эти фичи выбраны на основе опросов разработчиков, статистики с HTTP Archive, анализа багов Chromium, Gecko и WebKit, результатов тестов Web Platform tests и самых популярных запросов Can I Use.

https://web.dev/compat2021/
Сегодня вышла новая версия Firefox. Крис Миллс рассказал о всех новинках релиза — "In March, we see Firefox 87".

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

Дефолтное значение Referrer-Policy было заменено на strict-origin-when-cross-origin. Это означает, что по умолчанию браузер не будет включать путь и GET-параметры в Referer.

В DevTools появилась поддержка prefers-color-scheme для эмуляции текущей выбранной темы операционной системы. В инспекторе страницы теперь можно удобно устанавливать псевдокласс :target на выбранном DOM-узле.

Добавлена фича "SmartBlock", которая стабилизирует работу сайтов при включении блокировки отслеживания. Для этого используются специальные трекеры-заглушки, которые подменяют настоящие скрипты трекеров.

Отключена поддержка Backspace для навигации по истории, чтобы предотвратить случайные переходы при заполнении форм. Для её включения (не делайте этого) нужно поменять опцию browser.backspace_action в about:config.

В версии для macOS была добавлена поддержка скринридера VoiceOver.

#firefox #release

https://hacks.mozilla.org/2021/03/in-march-we-see-firefox-87/
Джек Арчибальд начал писать серию статей про производительность сайтов команд Формулы-1 — "Who has the fastest F1 website in 2021? Part 1".

В первой части он рассказывает про сайт команды Альфа Таури. На медленном соединении и слабом устройстве страница загружается больше минуты. Одна из основных проблем связана с тем, что рендеринг блокируется CSS, который используется для трекинга используемых шрифтов. Также на сайте есть предзагрузка изображений, которые используются в карусели в верху страницы. Изображения загружаются с большим приоритетом и занимают канал, который мог бы быть использован для загрузки критических ресурсов. Также на сайте есть неоптимизированные изображения, на которых можно было бы сэкономить больше 200kb. Джек попробовал оптимизировать сайт — время его полной загрузки снизилось до 7 секунд.

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

#performance

https://jakearchibald.com/2021/f1-perf-part-1/