Нашёл интересную статью Яна Моншке из Soundcloud про оптимизацию потребления памяти в Redux-приложении — "Garbage Collection in Redux Applications".

При портировании Soundcloud на Xbox One разработчики столкнулись с тем, что операционная система закрывала работающее в фоне приложение, когда потребляемая память превышала 128Мб. Проблема оказалась в Redux-сторе — данные треков, которые уже были не нужны, продолжали лежать в памяти.

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

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

#statemanagement #performance #react

https://developers.soundcloud.com/blog/garbage-collection-in-redux-applications?ref=mdbootstrap.com

Сегодня в блоге v8 появилась вторая часть статьи про структуру спецификацию ECMAScript от Марьи Хёлтэ — "Understanding the ECMAScript spec, part 2".

В этой части Марья разбирает то, как в спецификации определён обход цепочки прототипов для получения значения свойства объекта. Объясняется всё в довольно доходчивой форме. Используя описанный подход, можно разобрать любую другую фичу языка на уровне спецификации. В статье дополнительно затрагивается понятие runtime semantics: грамматика спецификации определяет синтаксис языка, runtime semnatics определяет смысл этих синтаксических конструкций. В самом конце статьи есть ссылка на бонусную статью про то, почему obj.foo при передаче как аргумент, например, в console.log(obj.foo) становится AssignmentExpression.

Очень клёвая статья. Теперь жду третью часть.

#js #specification #tutorial

https://v8.dev/blog/understanding-ecmanoscript-part-2

Big news, everyone! Теперь вы можете поддержать канал на патреоне. Меня давно уже спрашивали про такую возможность, и вот вчера настроил страницу для пожертвований. Если вам нравится то, что я делаю, хотите продолжать читать канал без рекламы и хотите сделать что-то хорошее, то добро пожаловать в клуб патронов. Мне материальная поддержка, а вам большой плюс в карму.

Также ищу спонсора канала. Если вы представляете компанию и хотите проспонсировать канал, то пишите мне в личку @myshov. Все спонсорские плюшки (их много) перечислены на странице патреона.

В любом случае всем спасибо за то, что читаете канал!

#defront

https://www.patreon.com/myshov

Диего Гонзалес из команды разработки Samsung Internet рассказал про лучшие практики разработки веб сайтов для устройств с гнущимися экранами.

На данный момент по всему миру продано более одного миллиона Galaxy Fold. То есть девайсами с гнущимися экранами пользуются реальные люди. Самая большая проблема при разработке сайтов под такие устройства — доступное экранное пространство. Окно браузера в режиме многозадачности на Galaxy Fold может быть очень маленьким (229px x 187px). Диего рекомендует использовать отзывчивый дизайн с обязательной проверкой отображения в разных браузерах с маленькой шириной окна.

В статье есть упоминание полезной фичи Firefox Dev Tools — в режиме инспектора все элементы, у которых есть скролл, помечаются лейблом "scroll". Это удобно при фиксе проблем вёрстки, вызывающих двойной скролл на странице.

#mobile #ux #css

https://medium.com/samsung-internet-dev/current-web-on-galaxy-fold-ad12d7f57c26

Лукас Бомбак написал статью про то, как готовить частичную гидрацию для изоморфных приложений — "The case of partial hydration (with Next and Preact)".

Фронтенд-фреймворки, которые умеют рендерить приложение на сервере (React, Vue, Angular), должны гидрировать страницу (устанавливать обработчики событий на отрендеренную сервером вёрстку), чтобы она стала интерактивной. При таком подходе есть проблема — на клиент летит много ненужного кода, например, код неинтерактивных компонентов (заголовки, врезки, компоненты для типографики и т.п.). Поэтому команда Лукаса при работе над большим новостным порталом реализовала частичную гидрацию страницы. При таком подходе на клиент прилетает только тот код, который нужен для работы интерактивных элементов.

Идея несложная. Нужно отрендерить статичную вёрстку и отметить в ней элементы, которые нужно гидрировать. Для отметки таких элементов, ребята использовали тег <noscript type="application/hydration-marker" />. Далее клиентский скрипт находит такие элементы и гидрирует их. Таким образом на странице получается несколько независимых мини-приложений.

Статья очень полезная. Если вы разрабатываете большой проект с использованием SSR и большинство ваших компонентов неинтерактивны, то стоит обратить внимание на этот подход.

#ssr #performance #react

https://medium.com/@luke_schmuke/how-we-achieved-the-best-web-performance-with-partial-hydration-20fab9c808d5

Джеймс Снелл из команды разработки ядра Node.js написал статью про текущий статус поддержки QUIC в ноде — "A QUIC Update for Node.js".

QUIC — это транспортный протокол, который лежит в основе HTTP/3. Он решает проблему плохой утилизации канала связи в сетях с высокими задержками, ускоряет установку соединения между клиентом и сервером и решает другие проблемы. На данный момент в отдельном репозитории организации Node.js полным ходом идёт его внедрение.

Для работы с новым протоколом используется новый модуль quic; будет ли он доступен разработчикам в будущем, пока окончательно не решено. Этот модуль экспортирует одну функцию createServer, с помощью которой создаются как инстанс сервера, так и клиент. Под капотом используется библиотека ngtcp2, разрабатывающаяся рабочей группой, работающей над спецификацией QUIC.

Экспериментальная поддержка QUIC, доступная всем разработчикам, должна появиться в Node.js v14. Добавление полноценной поддержки протокола запланировано в Node.js v15.

#protocol #nodejs #net

https://www.nearform.com/blog/a-quic-update-for-node-js/
https://news.1rj.ru/str/defront/268

Зак Блум в блоге Cloudflare опубликовал статью про историю появления URL — "The History of the URL".

11 января 1982 года группа учёных собралась вместе, чтобы обсудить вопрос "компьютерной почты". На тот момент остро стоял вопрос адресации узлов в сети.

Первой сетью была ARPANET, но позже появились другие сети: COMSAT, CHAOSNET, UCLNET, INTELPOSTNET. Для того чтобы объединить их в одно целое, были разработаны протоколы интернета. Для адресации узлов новой сети существующее подход ARPANET не подходил. Список всех узлов сети хранился на центральном сервере в обычном файле. При каждом добавлении нового узла в сеть этот сервер должен был по ftp передавать всем узлам сети обновлённый файл. Решением было создание иерархической системы, в которой можно запрашивать только тот список узлов, который принадлежит определённому домену. Так появилось доменное имя.

Статья большая. В ней рассказывается про историю появления всех частей URL: протокол, порт, путь, параметры, якорь. Очень рекомендую почитать, если интересуетесь историей web'а.

#history #web

https://blog.cloudflare.com/the-history-of-the-url/

Пару дней назад в чате @defrontchat спросили про преимущества Styled Components. Я как фронтендер-пенсионер сказал, что не понимаю хайпа вокруг CSS-in-JS библиотек. И вот сегодня нашёл довольно хороший пост Санил Пая про преимущества CIJ-библиотек.

Стили, написанные с использованием CIJ можно проанализировать статически: если в имени класса есть опечатка TS/Flow про это скажут. При использовании CIJ-библиотек не надо волноваться про append-only стили. Удалил компонент — удалил стили. Контроль над селекторами делает простым извлечение критического CSS. Так как стили в CIJ это код, начинают работать оптимизации, использующиеся для JS (code splitting, dead code elimination). Ещё одно неочевидное преимущество касается того, что в SPA-приложениях, в которых используется асинхронная загрузка стилей и скриптов нельзя гарантировать порядок загрузки ассетов, что приводит к использованию !important.

The facebook codebase has thousands of !important statements, despite being written by competent engineers with solid engineering practices and deep relationships with design teams.

В общем, рекомендую почитать статью всем, у кого есть вопросы к CSS-in-JS. Многое встаёт на свои места.

#cssinjs #musings

https://gist.github.com/threepointone/731b0c47e78d8350ae4e105c1a83867d

Бенг Ю и Джонатан Империоси из Google рассказали, как добавление http-заголовка stale-while-revalidate повлияло на бизнес-метрики — "How Google improved ads performance with stale-while-revalidate".

Google Ad Manager для показа рекламы использует скрипт gpt.js. Этот скрипт находится в кеше браузера не более 15 минут. Как только проходит 15 минут запись в кеше устаревает и браузер делает синхронный запрос для получения свежей версиии gpt.js. В Chrome 75 появилась поддержка stale-while-revalidate. Команда разработки Ad Manager добавила к gpt.js http-заголовок

cache-control: private, max-age=900, stale-while-revalidate=3600

Он говорит о том, что если файл запрашивается между 15 и 60 минутами, после того как он попал в кеш, тогда будет использоваться устаревшая версия файла, но в фоне скрипт будет обновлён и закеширован для использования в будущем. Добавление заголовка ускорило начальную загрузку скрипта на 2% и на 0.5% увеличилио доход от показанной рекламы.

Stale-while-revalidate стоит использовать в тех случаях, когда наиболее быстрая загрузка файла важнее загрузки его самой свежей версии.

#performance #cache

https://web.dev/ads-case-study-stale-while-revalidate/

Чарльз Клермон опубликовал статью про влияние производительности на бизнес-метрики SPA-приложения — "The Impact of Web Performance".

Обычно считается, что пользователи дорогих устройств тратят больше, но это не совсем так. В статье на примере показано, что наиболее критичный показатель для SPA-приложений не мощность устройства, а отзывчивость приложения и плавность анимаций. Один и тот же сайт может показывать разные результаты для одного и того же устройства в зависимости от того, замедляет ли iOS CPU от состояния батареи.

Для измерения производительности пользователи были разделены на группы по разным категориям устройств. Для разделения пользователей по типу iPhone использовались значения device.screenResolution и device.mobileDeviceBranding (980x1000 это iPhone X/Xr). Измерялось количество отрендеренных браузером фреймов в течении первой секунды после клика (60 — отличный показатель, 0 — плохой).

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

#performance #mobile

https://simplified.dev/performance/impact-of-web-performance#ref-iphone-categories

Райан Аткинсон рассказал, почему он выбрал Svelte для большого проекта — "Why Svelte is our choice for a large web project in 2020".

В статье Райан рассказывает про объективные преимущества Svelte относительно других фреймворков (скорость работы, гибкость компилятора, встроенная поддержка создания производительных анимаций), так и субъективные (приятно работать, легко изучать, синтаксис и семантика). В недостатках усложнение процесса сборки (компилятор должен выполнять больше работы в отличии от компиляции JSX или Vue-компонентов), новый синтаксис для новичков, реактивный синтаксис работает только с компонентами, рендеринг блокирует основной поток. Ещё есть проблемы, вызванные молодостью проекта: скромная экосистема инструментов (плагины для редакторов, поддержка TypeScript), лучшие практики ещё не устоялись, молодая экосистема библиотек, с ростом количества компонентов может значительно вырасти объём бандла (решается с помощью code splitting), мало вакансий на сегодняшний день, на данный момент у проекта нет финансовой поддержки.

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

P.S. Спасибо @oleg_log за ссылку на статью.

#svelte

https://github.com/feltcoop/why-svelte

Эндрю Пардо рассказал про планы разработки Flow на 2020 год — "What we’re building in 2020".

В этом году работа будет сфокусирована на производительности, дальнейшем снижении потреблении памяти, улучшении системы типов и добавлении новых фич в language server protocol.

Запланировано добавление подсказок для параметров функций и методов, улучшение Quick Info для деклараций, будет идти на работа над ускорением отклика обработки запросов при редактировании и навигации по коду. Также планируют улучшить типизацию this в декларациях функций и работу с unsealed-объектами (будет корректно проверяться доступ к свойствам объекта). Переработают дизайн дженериков, для того чтобы избавиться от проблем, возникающих с областью видимости параметров. Можно будет выборочно подавлять ошибки с помощью $FlowFixMe.

Хотя я перешёл на TypeScript (и пока не жалею), искренне хочу, чтобы все планы были реализованы.

#flow #announcement

https://medium.com/flow-type/what-were-building-in-2020-bcb92f620c75

Вчера вышла новая версия Firefox. Крис Миллс рассказал про новый релиз — "Security means more with Firefox 74".

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

Также была включена поддержка http-заголовка Cross-Origin-Resource-Policy (CORP), с помощью которого накладываются дополнительные ограничения на кросс-доменные запросы. Эта фича была добавлена для того, чтобы владельцы сайтов могли противостоять атакам по сторонним каналам таким как Spectre, Meltdown.

В октябре 2018 года Mozilla, Google, Microsoft и Apple договорились о том, чтобы отключить поддержку небезопасных версий TLS 1.0/1.1. С 74-ой версии Firefox будет отображать предупреждение "Secure Connection Failed" для TLS 1.0/1.1 с возможностью перейти на сайт. Это первый шаг на пути к полному удалению старых версий TLS.

В CSS было добавлены свойство text-underline-position для управления позицией линии подчёркивания. Это очень полезная фича для языков с вертикальным письмом и математических формул. Была добавлена поддержка свойств text-underline-offset, text-decoration-thickness. В JS-движок добавлен optional chaining. У canvas был расширен метод measureText — теперь он возвращает геометрию ограничивающего прямоугольника.

В режиме отзывчивого дизайна был доработан механизм рендеринга, теперь при выборе Android-устройств сайт будет отображаться так же, как если бы он отображался на реальном устройстве. Теперь можно отлаживать вложенные web-воркеры. В CSS-инспекторе были добавлены дополнительные подсказки для неактивных свойств z-index, top, bottom, left, right. Улучшена интеграция с React Dev Tools — исправлена проблема с Go to definition для перехода к исходному коду компонента.

#firefox #release #announcement

https://hacks.mozilla.org/2020/03/security-means-more-with-firefox-74-2/

Аллен Вирфс-Брок (редактор спецификаций ES5 и ES2016) представил большую научную статью (190 страниц) про историю развития JavaScript, которую он написал в соавторстве с Бренданом Айком. Эта статья будет опубликована в журнале "Proceedings of the ACM on Programming Languages".

Немного полистал — в ней есть много всего интересного. Например, рассказывается, почему спецификация получила название ECMAScript. Это был долгий и сложный процесс — Sun не захотела передавать права на торговую марку "JavaScript" организации ECMA, когда началась работа над спецификацией. Эта же участь постигла другое название "LiveScript" — Netscape тоже не захотела передавать права на свою торговую марку. Тем не менее работа над спецификацией уже во всю шла, и как плейсхолдер использовался "ECMAScript". В конечном счёте участники TC39 не смогли выбрать другое подходящее название и сошлись на том, что оставят ECMAScript.

Аллен и Брендан проделали очень большую работу при написании статьи. Must read для всех, кто интересуется историей web'а и JavaScript.

#js #history

https://zenodo.org/record/3707008#.XmvrZ0MxWHo (preprint)

Крис Льюис и Брендан Дин из UberEats рассказали, почему они пошли по пути переписывания основного сайта проекта и какие плоды это им принесло.

Проблема с предыдущей версией сайта имела накопительный эффект. Это было React-Redux приложение, которое плохо поддавалось разделению на бандлы и имело сложности с поддержкой из-за усложнённого подхода к работе с данными и смешиванию кода для разных платформ (desktop/mobile). В новой версии они перешли на фреймворк fusion.js, созданный Uber на базе React (аналог Next.js). Благодаря ему они получили server side rendering и хорошую поддержку code splitting. Для слоя данных оставили Redux, но только как хранилище данных, которое может быть использовано разными роутами приложения. Для всего остального состояния используется локальное состояние компонентов. Благодаря работающему code splitting решили проблему со смешиванием кода разных платформ.

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

#react #performance #architecture

https://eng.uber.com/uber-eats-com-web-app-rewrite/

Увидел сегодня в ленте твиттера ссылку на серию статей Лео Фабриканта про оптимизацию производительности контрола автодополнения — "Secrets of JavaScript: A tale of React, Performance Optimization and Multi-threading".

Автор решал задачу отзывчивого автодополнения для названий научных организаций. Так как эти названия длинные, пользователь с большой вероятностью может сделать опечатку, поэтому важно было сделать поиск нечётким (fuzzy search), что увеличивало общее время поиска и создавало лаги при вводе текста. В статьях описаны разные подходы, которые Лео попробовал реализовать для уменьшения лагов: от setTimeout до пулла Web Worker'ов.

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

#performance #react #ux

https://levelup.gitconnected.com/secrets-of-javanoscript-a-tale-of-react-performance-optimization-and-multi-threading-9409332d349f

Ох, чую будут недовольные этим постом, но пройти мимо не могу.

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

Закрытие границ с другими странами, ввод карантина в некоторых регионах и просьба не выходить на улицу со стороны властей может выглядеть как глупость и банальная паника. Очень многие из нас имеют хороший иммунитет и проблема кажется не такой серьёзной: "Ну переболею этой ерундой, и что такого?" Как относительно молодой и здоровый человек, я с этим абсолютно согласен. Но есть люди, которые попадают в группу риска — чьи-то пожилые родители, люди с пониженным иммунитетом. Именно ради них стоит задуматься о том, чтобы уменьшить риск распространения вируса и сократить количество контактов с другими людьми.

Если вы владеете бизнесом, позвольте своим сотрудникам работать удалённо. Если вам всё-таки нужно идти в офис, будьте спокойны, если кто-то не пожмёт руку при встрече. А если кто-то кашляет или чихает рядом, просто порекомендуйте им переболеть дома.

В общем, желаю всем здоровья и, пожалуйста, помогайте друг другу.

#StayTheFuckHome

https://staythefuckhome.com/ru/

Сегодня во всех каналах прогремела новость — GitHub купил npm. В блоге GitHub появился пост Ната Фридмана о том, что это значит для сообщества — "npm is joining GitHub".

В ближайшем будущем усилия будут сфокусированы на инфраструктуре реестра. Также продолжается работа над седьмой версией npm — самая большая фича следующего релиза Workspaces (управление множеством пакетов из пакета верхнего уровня). Обещают активно сотрудничать с сообществом и ментейнерами пакетов — планируют расширить программу GitHub Sponsors на экосистему npm. Платные сервисы npm будут продолжать работать, но в этом году приватные пакеты npm можно будет переместить в GitHub Packages. Фокус в развитии npm смещается исключительно на публичный реестр.

Так как GitHub принадлежит Microsoft, это означает: что npm переходит под её крыло. Уж что-что, а инструменты для разработчиков Microsoft умеет делать хорошо.

#announcement #npm #github #microsoft

https://github.blog/2020-03-16-npm-is-joining-github/

Недавно Фрэнк Фаулкнер — участник рабочих групп W3C — обновил свою статью про проблемы доступности атрибута noscript — "Using the HTML noscript attribute".

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

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

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

#a11y #html

https://developer.paciellogroup.com/blog/2010/11/using-the-html-noscript-attribute/

Дэниэл Маккей рассказал как использовать проверку типов TypeScript в VSCode без добавления компилятора ts в процесс сборки приложения — "Using Typenoscript Without Typenoscript".

VSCode из коробки поддерживает проверку типов в JavaScript-файлах. Для этого нужно в редакторе включить опцию checkJs или использовать специальные комментарии в начале файла: // @ts-check — для пофайлового включения проверки типов и // @ts-nocheck для исключения файла из проверок. Типы подхватываются из определений JSDoc. Для определения пользовательских типов можно использовать @typedef, также можно вытащить описание типов в d.ts -файл и импортировать его внутри JSDoc:

/**
 * @param {import("./main").ISomeModel} req
 * @returns {Promise<import("./main").IApiResponse>}
 */

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

#typenoscript #bundlerfree

https://www.dandoescode.com/blog/using-typenoscript-without-typenoscript/

Берт Бос — можно сказать один из отцов CSS (участвует в разработке стандартов с 1996 года) — поделился своими мыслями по поводу версионирования CSS в статье "CSS X".

Последняя пронумерованная версия CSS была CSS3. CSS3 — это неофициальное название набора независимых спецификаций (модулей), которые были извлечены из монолитной спеки CSS2.1 с добавлением новых модулей. Такое разделение было удобно для рабочей группы и разработчикам браузеров, но стало неудобно для разработчиков: что было добавлено после CSS3, где можно найти систематизированную информацию в удобном виде и т.п.

В статье Берт пишет о том, что рабочая группа не будет брать на себя обязанности по определению того, что должно входить в CSS4. Если брать работу по версионированию, то возникает много вопросов: какие модули должны попасть в новую версию, с какой частотой подымать версию, как взаимодействовать с разработчиками браузеров и т.п. Он предлагает сообществу (будь это комитет из участников разных организаций или недавно сформированная CSS4 Community Group) независимо от рабочей группы сформировать независимый набор спецификаций — CSS4. Он не видит в этом ничего плохого.

CSS4 Community Group начала свою работу с февраля этого года. Вполне возможно, что эта инициатива будет успешна.

#css #specification #musings

https://www.w3.org/blog/2020/03/css-x/