Том МакРайт поделился мыслями про текущее состояние дел в современном вебе — "Second-guessing the modern web".

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

В статье нет призывов к уничтожению SPA-приложений, но есть призыв задуматься. В современном вебе при оптимизации используемых абстракций мы получаем в результате те преимущества, которые можно получить, просто не используя эти абстракции. Отсюда возникает вопрос. Действительно, ли есть ценность во всей сложности построения современных web-приложений? Универсального ответа нет и не может быть. У каждого проекта есть свой набор уникальных проблем — где-то больше подходит SPA-подход, а где-то достаточно обычного html и css.

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

#web #performance #musings

https://macwright.org/2020/05/10/spa-fatigue.html

Джек Арчибальд написал статью "Event listeners and garbage collection". В ней рассказывается про способ прерывания любого асинхронного API и объясняется, почему этот способ не приводит к утечкам памяти.

Все современные браузеры поддерживают отмену fetch-запросов с помощью AbortController API. В статье есть код небольшого хелпера, который позволяет использовать AbortController с любым асинхронным API:

async function abortable(signal, promise) {
  if (signal.aborted) {
    throw new DOMException('AbortError', 'AbortError');
  }
  return Promise.race([
    promise,
    new Promise((_, reject) => {
      signal.addEventListener('abort', () => {
        reject(new DOMException('AbortError', 'AbortError'));
      });
    }),
  ]);
}

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

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

#web #api

https://jakearchibald.com/2020/events-and-gc/

Иан Бин рассказал, почему для своего блога он выбрал 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-javascript-framework/

Сэм Торогуд из Google опубликовал статью про события загрузки в web — "Understanding Load Events on the Web".

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

Для обработки события DOMContentLoaded необходимо всегда выполнять небольшой реверанс с проверкой document.readyState. Если необходимо выполнить код скрипта после того, как будет доступен DOM, проще пометить этот скрипт с помощью defer. Единственное место, где нельзя обойтись без DOMContentLoaded, — код библиотек, так как такой код не знает был ли он загружен с помощью defer или async.

#web

https://whistlr.info/2020/understanding-load/

Еиджи Китамура на web.dev рассказал о том, как упростить процесс обновления данных для аутентификации с помощью менеджеров паролей — "Help users change passwords easily by adding a well-known URL for changing passwords".

Менеджеры паролей в Safari и Chrome (с версии 86) предоставляют элемент управления для быстрого перехода к изменению пароля. Чтобы он правильно работал, на вашем сайте должен быть настроен редирект со страницы /.well-known/change-password на страницу изменения пароля. Для редиректа лучше всего использовать: 302 Found, 303 See Other или 307 Temporary Redirect.

Редирект для /.well-known/change-password уже поддержали Google, Facebook, GitHub и другие сайты. Если на вашем сайте ещё нет редиректа, то его очень рекомендуется добавить.

#web #security

https://web.dev/change-password-url/

Дэйв Руперт поделился своим мнением про важность разнообразия браузеров — "What is the Value of Browser Diversity?".

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

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

#web #musings

https://daverupert.com/2020/09/the-value-of-browser-diversity/

Вчера в репозитории 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/

HTTP Archive второй год подряд публикует отчёт о текущем состоянии веба — "Web Almanac 2020".

Альманах поделён на 22 главы, которые посвящены текущему состоянию дел в вебе: контенту (CSS, JavaScript, шрифты), пользовательскому опыту (доступность, производительность, SEO, приватность, безопасность, мобильный web), инструментам публикации (CMS, ecommerce, Jamstack) и распространению контента (сжатие, кеширование, Resource Hints, HTTP/2). Над проектом работали 116 специалистов, среди которых есть Рик Вискоми, Лия Веру, Тим Кадлек, Гарри Робертс и другие. Общий объём статей около 500 страниц.

В альманахе есть много информации и разных инсайтов, например, в самом большом HTML-атрибуте alt содержится 15 миллионов символов. На август 2020 года по HTTP/2 было передано 64% запросов. Средний объём страниц вместе со всем содержимым (CSS, JS, изображения) — 1.9Мб.

#report #web

https://almanac.httparchive.org/en/2020/

Андрей Ситник в блоге Злых Марсиан написал статью о современных практиках создания фавиконок сайта — "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

Дженс Оливер Маейерт написал небольшой пост о том, почему нужно забыть о 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/

Йехуда Катц — один из отцов 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/

Петер Перлепес написал статью про обработку событий перехода страницы в фоновый режим — "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/