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

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

Также советую канал @webnya
Download Telegram
Матиас Байненс — разработчик V8 и Chrome — написал статью о том, как была реализована симуляция недостатков зрения в Chrome DevTools — "Simulating color vision deficiencies in the Blink Renderer".

Результаты исследования WebAIM говорят о том, что контраст текста — самая распространённая проблема доступности сайтов. Вы скорее всего встречали его упоминание в DevTools или Lighthouse и с большой вероятностью удивлялись тому, что эти инструменты жаловались на плохой контраст, в то время как вы могли легко всё прочитать. Дело в том, что анализ контраста включает в себя разные особенности восприятия цвета: кто-то не видит красный цвет, кто-то зелёный и т.п.

Для реализации симуляции недостатков зрения разработчики сделали прототип на обычных web-технологиях. Для этого они воспользовались SVG-фильтром на root-элементе. В этом фильтре описывается преобразование цветов на основе научной работы "A Physiologically-based Model for Simulation of Color Vision Deficiency". Чтобы не внедрять на страницу лишние элементы, решение с SVG было перенесено в движок браузера.

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

#a11y #internals #chrome

https://developers.google.com/web/updates/2020/11/cvd
Томас Штайнер из Google рассказал, почему проект Excalidraw отказался от идеи создания десктопного приложения с помощью Electron — "Deprecating Excalidraw Electron in favor of the Web version".

Excalidraw — это клиентское web-приложение с открытым исходным кодом для создания диаграмм с возможностью совместного редактирования. Разработчики хотели сделать десктопную обёртку с помощью Electron для пубилкации в магазинах приложений, но это оказалось не очень простой задачей. В Electron нет поддержки автоматического обновления приложений на Linux, интеграция с нативными меню ОС не идеальна, для распространения приложения оно должно быть подписано цифровой подписью. Всё это решаемые проблемы, но у ребят не было желания заниматься поддержкой Electron-версии, поэтому они сфокусировались на добавлении в приложение PWA-фич.

В итоге по доступным возможностям получившееся приложение почти не уступает приложениям на Electron. В Excallidraw есть поддержка оффлайн-режима работы, простая установка и полноценная интеграция в ОС, прозрачная работа с файловой системой, поддержка drag'n'drop файлов, поддержка буфера обмена, есть регистрация приложения для открытия файлов с расширением .excalidraw.

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

#electron #pwa

https://web.dev/deprecating-excalidraw-electron/
Вчера случился фейл, и пост не был опубликован, поэтому сегодня будет два поста — сейчас и попозже.

Давайте продолжим тему PWA (Progressive Web App). Недавно Максимилиано Фиртман опубликовал свой традиционный пост с исследованием рынка PWA — "Progressive Web Apps in 2021".

Самое интересное из статьи. За прошедший год количество сайтов, доступных как PWA, выросло в два раза. Количество PWA стабильно растёт, но пока ещё очень сильно отстаёт от доступных приложений на нативных платформах.

В конце 2020 года Microsoft предоставила возможность публиковать в магазине приложений PWA на базе Chromium. Apple зарелизила новую фичу WKWebView — App-Bound Domains. Благодаря ей появилась возможность публикации PWA в AppStore для iOS 14, iPadOS 14 и macOS 11 Big Sur.

Многие компании в 2020 году стали распространять свои приложения как PWA: AppStore Connect (Apple), Hangouts/Duo/YouTube Music/Stadia (Google), Luna (Amazon) и другие.

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

#pwa

https://firt.dev/pwa-2021/
Стэфан Баумгартнер написал статью о том, почему не стоит использовать некоторые ООП-фичи TypeScript — "Tidy TypeScript: Avoid traditional OOP patterns".

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

Пространства имён (namespaces) были добавлены в TypeScript в первых версиях языка для удобства работы с кодом. Сейчас их могут прекрасно заменить модули. Неймспейсы иногда могут быть полезны во внешних файлах декларации, но их не следует использовать в коде проекта.

Ещё Стэфан предлагает отказаться от использования абстрактных классов. Абстрактные классы транспилируются в обычные классы, они могут быть без проблем инстанцированы в JavaScript, что может привести к проблемам.

Хорошая статья, но последний пункт про абстрактные классы мне кажется спорным.

#typescript

https://fettblog.eu/tidy-typescript-avoid-traditional-oop/
В блоге V8 Мартин Бидлингмайер опубликовал статью про новый вспомогательный движок регэкспов, который позволяет избежать катастрофических откатов — "An additional non-backtracking RegExp engine".

V8 по умолчанию использует регэксп-движок Irregexp, который в свою очередь использует алгоритм бэктрекинга для проверки паттернов регэкспов. Этот алгоритм может приводить к катастрофическим откатам (сatastrophic backtracking). Катастрофический откат — это ситуация, когда проверка регулярного выражения не может быть выполнена за разумное время из-за экспоненциального роста количества возможных вариантов, которые должны быть обработаны движком. Катастрофические откаты могут использоваться для совершения DOS-атак, когда web-сервис обрабатывает входные данные пользователей с помощью регулярных выражений.

В V8 версии v8.8 был добавлен новый экспериментальный движок, который не подвержен проблеме экспоненциального взрыва, но гораздо медленнее (на данный момент) Irregexp. Его можно включить с помощью экспериментальных флагов V8.

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

#v8 #security #internals

https://v8.dev/blog/non-backtracking-regexp
Нашёл статью Джона Регера, в которой он рассказывает о том, почему мы не замечаем баги в своих программах, в то время как пользователи находят их очень быстро — "Operant Conditioning by Software Bugs".

В психологии есть понятие "оперантное обусловливание" (operant conditioning) — адаптация поведения человека как ответ на последствия, возникающие в результате этого поведения. Этот эффект можно объяснить на примере. У автора статьи был ноутбук, который постоянно крэшился из-за быстрой прокрутки страницы в браузере (проблема была в видеодрайвере). Чтобы система постоянно не ломалась, Джон подсознательно выработал привычку прокручивать страницу по чуть-чуть. У всех опытных пользователей компьютера есть много похожих привычек: не прерывать процесс установки, терпеливо ждать ответа от операционной системы, если она подвисла, не использовать эзотерические опции конфигурации и т.п.

Этим эффектом также можно объяснить, почему при тестировании своих собственных программ разработчики находят меньше ошибок, чем тестировщики.

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

#debug #psychology

https://blog.regehr.org/archives/861
https://news.ycombinator.com/item?id=16863233 (обсуждение на HN)
Сегодня были опубликованы результаты ежегодного опроса JavaScript-сообщества (23 тысячи респондентов) — "State of JS 2020".

Из интересного. Среди фреймворков продолжают доминировать React, Vue и Angular. Набирает популярность Svelte — им удовлетворён наибольший процент разработчиков. Среди сборщиков наибольший показатель удовлетворённости у esbuild и Snowpack. GraphQL — самая популярная технология для управления данными. В этом году в категории бэкенд-фреймворков было добавлено много новых позиций, но самыми популярными фреймворками, как и в прошлом году, стали Next.js и Express. Redux и Relay продолжают терять свою популярность. Самый популярный транспилируемый язык — TypeScript.

#js #survey

https://2020.stateofjs.com/en-US/
https://2020.stateofjs.com/ru-RU/ (на русском языке)
Синдре Сорхус — автор большого количества npm-пакетов — поделился своими планами миграции на нативную модульную систему — "Get Ready For ESM".

В конце апреля 2021 года будет прекращена поддержка Node.js 10. Это означает, что майнтейнеры пакетов могут начать использовать все фичи Node.js 12 в том числе и ECMAScript Modules. ESM решает проблему интероперабельности модулей между Node.js и web, включает strict-режим по умолчанию и поддерживает три-шейкинг.

Синдре планирует в этом году перевести все свои npm-пакеты (более тысячи) на ESM и планирует полностью отказаться от CommonJS. Также он призывает всех майнтейнеров npm-пакетов присоединиться к этой инициативе, чтобы ускорить процесс миграции всей JavaScript-экосистемы.

#esm #nodejs

https://blog.sindresorhus.com/get-ready-for-esm-aa53530b3f77
Несколько дней назад вышла новая версия Snowpack. Фред Шотт — автор проекта — рассказал про все новинки релиза.

Snowpack — это инструмент для сборки фронтенд-приложений. В отличие от Webpack, Rollup и Parcel, приложения, использующие Snowpack, не нуждаются в пересборке бандла на каждое изменение файлов во время разработки. Snowpack транспилирует файлы точечно без бандлинга всех файлов, делегируя процесс создания графа зависимостей и его загрузки браузерам с помощью нативных JavaScript-модулей. То есть если вы пишете большое приложение и сделали изменения, например, в файле Header.tsx, то транспилироваться будет только он, тем самым уменьшая время обратной связи на каждое изменение файлов в разы по сравнению с другими бандлерами.

В Snowpack v3.0 были добавлены Streaming Imports. Благодаря им Snowpack может загружать и кэшировать npm-модули без явного использования npm install. С этой версии Snowpack может создавать оптимизированные production-билды с помощью esbuild (очень быстрый сборщик, написанный на Go). Реализован новый API, который уже используется в SvelteKit. Сгенерированные с помощью Snowpack файлы теперь можно без проблем импортировать в Node.js.

В общем, не релиз, а бомба. Рекомендую посмотреть в сторону Snowpack, если используете обычные сборщики и ждёте по несколько минут пересборки проекта при сохранении файлов.

#release #bundle #tool

https://www.snowpack.dev/posts/2021-01-13-snowpack-3-0
Дэниэл Дестефанис из Discord рассказал о том, как разработанные ими плагины для Figma упрощают жизнь разработчикам и дизайнерам — "Building open-source design tools to improve Discord’s design workflow".

Ребята из Discord сделали несколько плагинов для Figma, которые им помогают в работе. Плагин "Auto Theme" используется для автоматической генерации светлой/тёмной темы экранов приложения. Плагин "Design Lint" помогает быстро находить проблемные места в макете, когда в нём используются параметры, которых нет в дизайн-системе (цвет, радиус скругления углов и т.п.) Плагин "Table of Contents" генерирует список ссылок на основные части макета для помощи в навигации по документу. Плагин "Inspect" используется для упрощения разработки плагинов. Все плагины доступны на GitHub.

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

#ux #tool

https://blog.discord.com/building-open-source-design-tools-to-improve-discords-design-workflow-9a25c29f9143
На прошедшем Chrome Dev Summit Сэм Сороугуд рассказал про оптимальный подход кэширования ресурсов — "Love your cache".

В качестве дефолтного поведения Сэм предлагает использовать кэширование с ревалидацией: Cache-Control: max-age=0,must-revalidate,public. Этот подход используется в современных CDN, например, Netlify. Но стоит учитывать, что при ревалидации браузер отправляет дополнительный запрос на сервер.

Для ресурсов, которые обновляются редко, предлагается использовать хэши в именах файлов и длинное время жизни кэша: Cache-Control: max-age=31536000,immutable. Использования одной директивы max-age в Firefox и Safari не гарантирует, что будет использоваться кэш. Для того чтобы все браузеры всегда использовали кэш, нужно добавлять директиву immutable.

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

#performance #cache

https://www.youtube.com/watch?v=tprJYFkv4LU
https://web.dev/love-your-cache/ (расшифровка основного материала доклада)
Наверное, все по несколько раз в день сталкиваются с cookie-баннерами. Сегодня в посте Ната Фридмана (CEO GitHub) прочитал о том, что в некоторых случаях их можно не показывать — "No cookie for you".

Европейский Союз требует, чтобы владельцы сайтов отображали информацию о таких куках, которые необязательны для работы сайта (куки систем аналитики, рекламных сетей, настройки и т.п.) Но на сайте можно не показывать баннер, если используются только такие куки, без которых сайт будет работать некорректно (куки с идентификатором сессии, корзины и т.п.) В конце 2020 года GitHub полностью отказался от использования необязательных кук, и, соответственно, удалил с сайта cookie-баннер.

#web

https://github.blog/2020-12-17-no-cookie-for-you/
За прошедшие две недели в канале для патронов Defront было опубликовано десять постов:

— Выбор генератора статических сайтов для 2021 года
— Эмуляцая реалистичных сетевых условий
— Предотвращение повторной отправки форм на уровне спецификации HTML
— Anti-flicker snippets и их влияние на производительность
— Влияние количества прогонов тестов на разброс метрик производительности
— Использование API TypeScript для рефакторинга
— Код-сплиттинг React-приложений по типу устройства (десктоп/мобилки)
— Улучшение качества предупреждений о безопасности
— Почему сейчас никто не использует input type="image"
— Создание игрушечного языка с компиляцией в WebAssembly

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

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

https://www.patreon.com/myshov
Сегодня вышла новая версия Chrome. Пит Лепаж и Джеселин Ин рассказали про новинки релиза — "New in Chrome 88".

В Chrome 88 появилась поддержка Manifest V3 — новой платформы для создания расширений. Расширения, построенные на базе новой платформы, более прозрачны для пользователей, потребляют меньше системных ресурсов и проще для аудита (процесс ревью будет проходить быстрее). Предыдущая версия платформы расширений в будущем будет задеприкейчена.

С этой версии будет работать жёсткий троттлинг цепочек таймеров. Цепочка таймеров — это таймеры, создаваемые с помощью setInterval или с помощью setTimeout внутри коллбека другого setTimeout. Chrome будет троттлить на одну минуту цепочки более чем из 5 таймеров на неактивных страницах, которые не воспроизводят звук. Вместо цепочек таймеров разработчики Chrome предлагают использовать альтернативные API. Подробности можно почитать в статье Джека Арчибальда.

В CSS была добавлена поддержка явного указания соотношения сторон у любого элементе с помощью свойства aspect-ratio.

В HTML ссылки с атрибутом target="_blank" будут вести себя по умолчанию также как с установленным rel="no-opener".

Метод addEventListener теперь поддерживает удаление обработчиков с помощью AbortController.

Много изменений в инструментах разработчика. Они теперь открываются на 37% быстрее предыдущей версии. Появилась возможность эмуляции квот доступного места. На вкладке Performance можно включить отображение событий Web Vitals. Было улучшено отображение ошибок, связанных с CORS. Теперь можно эмулировать отсутствие поддержки WebP и AVIF.

#chrome #release

https://developers.google.com/web/updates/2021/01/nic88
https://developers.google.com/web/updates/2020/11/devtools
Недавно была опубликована ежегодная подборка самых популярных JavaScript-проектов — "Rising Stars 2020". В отличие от State of JS этот топ формируется на основе прироста количества звёзд за год.

Самые популярные проекты 2020 года:
1) Deno — серверный JavaScript- и TypeScript-рантайм (+30.2k звёзд);
2) Vue.js — фронтенд-фреймворк (+22.5k звёзд);
3) React — фронтенд-фреймворк (19.8k звёзд);
4) Playwright — node.js-библиотека для автоматизации браузеров (+19.7k звёзд);
5) VS Code — редактор кода (+19.1k звёзд).

В отчёте также можно найти самые популярные проекты, разделённые по категориям: фронтенд/Node.js фреймворки, экосистема React/Vue/Angular, инструменты сборки и т.п.

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

#js #report

https://risingstars.js.org/2020
https://risingstars.js.org/2020/ru (на русском языке)
Джон Снейерс из Cloudinary написал статью о проблемах адаптации новых форматов изображений, и как эти проблемы могут быть решены с помощью JPEG XL — "Legacy and Transition: Creating a New Universal Image Codec".

JPEG XL — это открытый формат изображений, разрабатываемый Joint Photographic Experts Group, Google и Cloudinary. JPEG XL предоставляет прогрессивную загрузку, лучшую скорость кодирования/декодирования и лучшее качество сжатия при сравнимом объёме файла по сравнению с WebP.

Любое JPEG-изображение — это валидный JPEG XL. Трансляция из одного формата в другой требует минимальных вычислительных ресурсов, тем самым JPEG XL можно транслировать в JPEG на лету и отдавать тем браузерам, которые не поддерживают JPEG XL. То есть сайтам не нужно хранить одно и то же изображение в разных форматах для разных клиентов.

Комитет JPEG планирует отправить последнюю версию черновика стандарта в ISO и IEC в этом месяце. Если у проверяющих организаций не будет вопросов, то черновик будет опубликован как международный стандарт в июле.

#graphics

https://cloudinary.com/blog/legacy_and_transition_creating_a_new_universal_image_codec
Пару дней назад был опубликован черновик спецификации CSS Cascading and Inheritance Level 5. Главное изменение спеки — добавление директивы @layer для гибкого управления каскадом. София Валитова разобралась с новой директивой и написала про неё статью в своём блоге — "Пара слов о layer".

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

@layer components, common;

@layer common {
button {
color: red;
}
}

@layer components {
button {
color: green;
}
}


Директива layer может пригодиться для структурирования стилей, при рефакторинге и темизации. Но на данный момент её поддержки нет ни в одном браузере.

#spec #css

https://ariarzer.dev/css-cascade-layer.html

P.S. София ведёт телеграм-канал с разбором спек CSS. Если хотите углубить свои знания в этой теме, очень рекомендую подписаться @css_mind.
Марк Эриксон — майнтейнер Redux — написал статью с подробным объяснением, почему Context в React не может заменить стейт-менеджеры — "Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)".

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

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

#react #statemanagement

https://blog.isquaredsoftware.com/2021/01/context-redux-differences/
Матиас Шэфер написал статью про опыт поддержки больших JavaScript-приложений — "Maintaining large JavaScript applications".

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

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

Интересная статья, рекомендую заглянуть.

#js

https://9elements.com/blog/maintaining-large-javascript-projects/
Матиас Шэфер написал продолжение статьи о работе с унаследованным кодом. В статье "Maintaining JavaScript applications in the long term" он рассказывает об опыте поддержки фронтенд-проекта на протяжении шести лет.

В 2014 году ребята сделали сайт для организации экономического сотрудничества и развития. Для разработки использовали популярные на тот момент CoffeeScript, D3, jQuery и Backbone. Так как сайт надо было постоянно дорабатывать, и клиент не был готов к глобальному рефакторингу, потихоньку проводилась модернизация кода. CoffeeScript был заменён на современный JavaScript. Для автоматической конвертации кода использовали утилиту decaffeinate, всё прошло без проблем. Для улучшения опыта разработки стали использовать TypeScript и описания типов в JSDoc. За всю жизнь проекта больше всего проблем было не с библиотеками, а с созданными абстракциями.

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

#js

https://9elements.com/blog/maintaining-javascript-applications-in-the-long-term/