Том МакРайт поделился мыслями про текущее состояние дел в современном вебе — "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/