Николас Гаутей опубликовал статью про использование WebPageTest с SPA-приложениями — "Recipes for Performance Testing Single Page Applications in WebPageTest".

При прогоне тестов на производительность у SPA-приложений недостаточно замерять обычную загрузку страницы, так как страница динамически меняет своё состояние в зависимости от пользовательского ввода. Ситуация усугубляется ещё тем, что при использовании React и Redux, нельзя просто менять элементы ввода с помощью innerText на уровне DOM API, так как при таком изменении текста не будет меняться состояние стора.

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

Статья будет полезна, если вы планируете отслеживать регресс клиентской производительности.

#performance #testing

https://css-tricks.com/recipes-for-performance-testing-single-page-applications-in-webpagetest/

Нашёл в твиттере ссылку на интересную статью Франсуа Шолле — "Notes to Myself on Software Engineering".

Статья представляет собой список "напоминалок" про процесс разработки софта, проектирование API и про карьеру. Хочу выделить из неё пять пунктов:

— Хороший софт делает трудные вещи простыми. Если на первый взгляд проблема кажется сложной, это не означает, что решение тоже должно быть сложным.
— При проектировании сценариев взаимодействия с API следует задать самому себе несколько вопросов. Какие это сценарии? Какая оптимальная последовательность действий для их достижения? Какой наиболее простой программный интерфейс может это реализовать?
— API создаётся для пользователей. Проявляйте эмпатию вне зависимости от того, пользуются ли им профессионалы или новички.
— Продуктивность сводится к высокой скорости принятия решений и к действию.
— Прогресс в карьерном росте выражается не количеством людей, которым вы управляете, а в том, какую ценность вы даёте миру.

В статье очень много хороших мыслей, рекомендую почитать.

#list #softwaredesign #career

https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d

Марк Ноттингэм — участвует в разработке протоколов HTTP и QUIC — написал пост про возможности, которые предоставляет HTTP/2 при проектировании классических HTTP API — "How Multiplexing Changes Your HTTP APIs".

HTTP API подвержен проблеме избыточной детализации. Например, при запросе большого количества однотипных сущностей каждый запрос будет отправляться независимо ( /widgets/id1, /widgets/id2 ). Такой подход неоптимален. Для решения этой проблемы создают дополнительные эндпойнты, которые могу обрабатывать запросы "батчами" ( /widgets/id1,id2,id3 ). Ещё можно использовать GraphQL, описывая список необходимых сущностей с помощью специального синтаксиса.

Марк пишет о том, что появление мультиплексирования в HTTP/2 (отправка множества параллельных запросов в рамках одного соединения), позволяет избавиться от необходимости создания специальных API для обработки батч-запросов. В статье, есть пример синтетического теста с 40 запросами. Для HTTP/1 накладные расходы на передачу данных составляют около 6Kb, для HTTP/2 — всего в 1440 байт. То есть благодаря HTTP/2 можно проектировать API любой степени детализации, не беспокоясь о проблемах неоптимальной передачи данных.

Мысли в статье интересные. Но мне не хватило сравнения описываемого подхода с GraphQL (плюсы, минусы, бенчмарки).

#http #performance #musings

https://www.mnot.net/blog/2019/10/13/h2_api_multiplexing

Прочитал статью Артура Басака — "Должен ли фронтенд разработчик уметь писать бэкенды?"

Артур пишет про то, что граница между фронтендом и бэкендом очень размыта. На западе под фронтендом понимается работа с CSS/HTML. У нас чаще всего по-другому — под фронтом понимается JavaScript, а владение CSS/HTML подразумевается как само собой разумеющееся.

С другой стороны фронтенд и бэкенд сильно переплетены друг с другом — для разработки сложных вещей требуется понимание и того, и другого. Например, в микросервисных архитектурах может использоваться Backend For Frontend (BFF) — сервис, который собирает и подготавливает данные для рендеринга или передачи на клиент. В компаниях BFF обычно разрабатывают фронтенд-разработчики.

В конце статьи есть хорошая мысль: любая технология — это всего лишь инструмент. Чем большим количеством инструментов владеет разработчик, тем больше он ценится на рынке.

#musings #backend #frontend

https://medium.com/front-end-in-regions-grodno/front-back-e1198c42d673

На этой неделе в сообществе web-разработчиков развернулся спор "HTTP/2 vs GraphQL". Марк-Андрэ Жиру встал на защиту GraphQL со статьёй "Is GraphQL Still Relevant in an HTTP2 World?"

В статье говорится о том, что HTTP/2 может помочь в снижении количества запросов к серверу и в более быстрой доставке ресурсов клиенту. Но тем не менее он не решает проблему поддержки большого количества эндпойнтов, с которым хорошо справляется GraphQL. Марк ещё пишет о том, что GraphQL очень удобен при разработке приложений, построенных на базе компонентов. GraphQL предоставляет много разных возможностей из коробки (интроспекция, типизированная схема и т.п.). Поддержка GraphQL существует во многих языках. В статье ещё есть раздел про сетевые ограничения, которые сказываются на дизайне API, построенных на базе HTTP/2, но мне он показался неубедительным.

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

#http #graphql

https://medium.com/@__xuorig__/is-graphql-still-relevant-in-an-http2-world-64964f207b8

Грег Уитворт — участник рабочей группы CSS и разработчик MS Edge — рассказал про результаты исследования среди разработчиков для выявления проблем при работе с <select> — "Can we please style the <select> control?!"

Исследование проводилось среди 1400 разработчиков при этом оценивался масштаб пользователей, который будет затронут потенциальными нововведениями. Самыми желаемыми функциями оказались встроенный поиск элементов и полноценная возможность стилизации у элемента <select>. Грег пишет, что пока не известно, каким образом будут реализованы все пожелания. Для этого в рамках WICG OpenUI будет создан прототип элемента управления, он послужит основой для создания нового предложения в стандарт.

Очень круто, что ребята из Microsoft взяли на себе ответственность по улучшению <select>. Скорее всего первые прототипы элемента будут реализованы в Edge.

#future #html

http://gwhitworth.com/blog/2019/10/can-we-please-style-select/

Сегодня столкнулся с новым атрибутом cookie SameSite. На web.dev есть хорошая статья про то, зачем о нужен и какую проблему решает — "SameSite cookies explained".

Cookie пользователей отправляются на сервер при любых запросах, даже если запрашивается статический ресурс с чужого сервера. Например если страница сайта site.com содержит изображение сайта site.net, при запросе изображения в запросе будут отправлены все куки пользователя для site.net. Чтобы ограничить отправку кук только тому сайту, которому они принадлежат (first-party) можно воспользоваться новым атрибутом SameSite.

Этот атрибут может содержать несколько параметров:
— Strict — ограничить отправку cookie только first-party;
— Lax — тоже что и Strict + отправлять куки при переходе на другой сайт;
— None — не ограничивать отправку cookie (будет работать только с Secure ).

Предположительно с версии Chrome 80 (февраль 2020) все куки без атрибута SameSite будут интерпретироваться как если бы для них был установлен SameSite=Lax. Поэтому если вы используете cookie, которые должны отправляться при любых запросах, для них необходимо явно установить SameSite=None.

#security #cookie

https://web.dev/samesite-cookies-explained/

Посмотрел доклад Эда Соудена — работает над государственными сайтами Великобритании — "What even is a table? A quick look at Accessibility APIs".

Эд рассказывает про работу с таблицами с точки зрения доступности. Скринридеры позволяют перемещаться по таблицам не только от колонки к колонке, но и к следующей строке в пределах одной колонки. Если применить к таблице свойство display: block, например, чтобы добавить overflow: scroll для небольших экранов, то скринридер больше ну будет воспринимать таблицу как таблицу и навигация будет сломана. Более того недостаточно использовать семантические теги, так как браузеры использует эвристику для определения табличной вёрстки. Если таблица состоит из одной ячейки, то она не будет считаться таблицей. Если таблица состоит из трёх-четырёх ячеек, которые занимают 95% ширины страницы, то она тоже не будет считаться таблицей (в Firefox). Но если таблица содержит двадцать строк, то она становится таблицей. Если в таблице в строках чередуется цвет, то она тоже будет считаться таблицей.

В конце доклада Эд советует всегда "слушать" вёрстку сайта с помощью скринридеров и не использовать атрибут role="table" для изменения семантики элемента, так это может вести к проблемам.

Доклад интересный. Очень рекомендую посмотреть, если интересуетесь темой a11y.

#a11y #internals

https://vimeo.com/139062429

Недавно Иван Немытченко сделал небольшой сайт, посвящённый make — makefile.site.

Есть распространённое заблуждение, что make используется только для сборок программ, написанных на C. На самом деле его можно использовать как раннер разных задач. Например, часто в больших проектах его используют для упрощения запуска проекта в режиме отладки, запуска тестов, сборки проекта и многого другого.

На сайте человеческим языком объясняются принципы работы make. Читать эту документацию гораздо проще чем официальную man страницу. На данный момент ещё не всё дописано, но самое важное уже есть. Рекомендую посмотреть.

#doc #tool

makefile.site

Сегодня двенадцатая версия Node.JS получила официальный статус LTS (12.13.0). LTS релиз поддерживается 30 месяцев, обычные версии — 6 месяцев. Я пропустил анонс прошлого релиза 12.12.0, который состоялся 10 октября, поэтому перечислю самые интересные нововведения нового релиза и 12.12.0.

В LTS релизе npm был обновлён до версии 6.12.0. Эта версия включает node-gyp, который поддерживает Python 3 для сборки нативных модулей.

Добавлен флаг --force-context-aware для предотвращения загрузки нативных модулей, которые не могу быть одновременно использованы в разных воркерах в рамках одного процесса ("Context Aware"). Новый флаг позволяет явно накладывать ограничения на используемые модули в Electron и других встраиваемых окружениях.

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

В модуле fs был добавлен opendir, с помощью которого можно асинхронно получить элементы директории. Этот метод очень полезен при чтении директорий с очень большим количеством элементов внутри.

Продолжается процесс внедрения поддержки source maps. Появился флаг --enable-source-maps для включения source maps в стектрейсах.

В модуле tls исправлен баг с опцией pauseOnConnect. Добавлена возможность использования HSM (Hardware Security Module) для получения доступа к приватным ключам.

Метод process._tickCallback объявлен deprecated.

#nodejs #release

https://github.com/nodejs/node/releases/tag/v12.13.0

Сегодня Firefox обновился до версии 70. В блоге Mozilla Hacks появился пост про новый релиз — "Firefox 70 — a bountiful release for all".

Самое интересная новая пользовательская фича — возможность генерирования паролей в <input type="password">. Сгенерировать пароль можно через контекстное меню. Или если у поля ввода есть атрибут autocomplete="new-password", то при фокусе на нём будет появляться диалог для генерации пароля.

Появилась поддержка CSS-свойств text-decoration-thickness, text-underline-offset и text-decoration-skip-ink, с помощью которых можно управлять внешним видом линии подчёркивания. В display появилась поддержка значений, состоящих из двух ключевых свойств, например, display: block flex;.

В движке JavaScript реализована поддержка числовых разделителей — 1_000_000. Добавлен Intl.RelativeTimeFormat.formatToParts, с помощью которого можно получить составные части относительных дат. Выполнение JS стало быстрее благодаря новому интерпретатору.

В инструментах разработчика теперь отображаются подсказки для неактивных CSS-свойств. Появилась возможность ставить точки останова на мутациях DOM-дерева. Улучшили поддержку средств анализа доступности: добавили информацию о контрастности в инструменте выбора цвета и добавили средство автоматического анализа доступности страницы с клавиатуры.

#firefox #release

https://hacks.mozilla.org/2019/10/firefox-70-a-bountiful-release-for-all/

Неделя релизов продолжается. Вчера вышел Chrome 78. Разработчики браузера опубликовали статью про новинки релиза — "New in Chrome 78".

В рамках имплементации спецификации Houdini CSS Properties and Values API Level 1 добавлен метод window.CSS.registerProperty, с помощью которого можно задать начальное значение, фоллбек, тип и другие параметры CSS-переменных.

Изменилась стратегия обновления сервис воркеров. Если сервис воркер подключался с помощью importScripts(), то браузер подгружал новую версию скрипта тогда, когда был изменён его путь. С версии 78 сервис воркеры будут обновляться и в том случае, когда содержимое скрипта будет изменено.

Добавлены новые экспериментальные возможности, которые можно включить для пользователей вашего сайта в рамках Orgin Trials. Например, с этой версии можно включить Native File System API для доступа к файлам из веб-приложения. Также можно включить SMS Receiver API, с помощью которого можно получить одноразовый пароль из SMS-сообщения.

В инструментах разработчика можно увидеть, какое количество времени сторонние скрипты блокировали главный поток. Также появилась возможность аудита приложения, если были использованы Request Blocking или Local Overrides. Теперь можно сообщить о проблеме в Chrome Dev Tools с помощью меню Main Menu > Help > Report a DevTools issue.

#release #chrome

https://developers.google.com/web/updates/2019/10/nic78

Случайно увидел ссылку на статью про TTFB от Гарри Робертса — "Time to First Byte: What It Is and Why It Matters".

TTFB (Time To First Byte) — время прошедшее от запроса ресурса до первого байта ответа — один из основных показателей производительности web-приложений. Максимальное сокращение этого времени лежит в основе всех оптимизаций. В статье есть список того, что может влиять на TTFB: роутинг в CDN, время чтения ресурсов с файловой системы, приоритизация в HTTP/2, время исполнения кода бэкенда, скорость работы запросов в базе данных и т.п. Для анализа того, что происходило на сервере во время обработки запроса, можно использовать Server Timing API.

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

#performance #metrics

https://csswizardry.com/2019/08/time-to-first-byte-what-it-is-and-why-it-matters/

Пару дней назад вышла минорная версия языка elm — 19.1. По этому поводу Эван Чаплицки — дизайнер языка — написал пост про то, над чем шла работа в последнее время — "The Syntax Cliff".

Elm часто подвергается критике. Она возникает из-за того, что большая часть фронтенд-сообщества и команда разработки языка ставят в приоритет разные вещи. Это очень хорошо видно на примере последнего релиза. Самое большое изменение в 19.1 — улучшенные сообщения компилятора при парсинге синтаксически некорректного кода. Эван решил приоритезировать эту фичу, чтобы снизить порог входа в язык. Теперь сообщения об ошибках фактически обучают синтаксису и особенностям языка. Казалось бы, изменение небольшое, но оно имеет очень важное значение для увеличения сообщества за счёт новых людей, которые начинают изучение языка и не бросают его из-за борьбы с компилятором.

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

#elm #release

https://elm-lang.org/news/the-syntax-cliff

Майкл Шарналь недавно написал статью про исправление отображения фотографий в браузере, если они были сняты в портретной ориентации — "Image orientation on the web".

Информация о том, как был повёрнут фотоаппарат во время съёмки, находится в EXIF-данных изображения. Для того, чтобы изображение отображалось корректно, надо чтобы браузер прочитал эту информацию и повернул изображение. В Firefox для этого используется CSS-свойство image-orientation: from-image , в Safari изображение поворачивается автоматически, если есть EXIF-данные. Рабочая группа CSS решила, что последний вариант лучший и объявила image-orientation: from-image deprecated.

Пока не все браузеры отображают изображения в правильной ориентации. Одно из решений этой проблемы — поворачивать изображения при их сохранении на сервер. В статье описывается, как это сделать с помощью Node.JS.

Статья хорошая. Читать стоит, если работаете с загружаемым контентом пользователей.

#image #nodejs

https://justmarkup.com/articles/2019-10-21-image-orientation/

В посте про релиз Firefox 70 был интересный пункт про то, что в display появилась поддержка значений, состоящих из двух ключевых слов. Рейчел Эндрю на Mozilla Hacks написала статью про это нововведение — "The two-value syntax of the CSS Display property".

Правила, которые определяют распределение элементов на странице, задаются с помощью контекста форматирования (Formatting Context), которое, в свою очередь, можно установить с помощью свойства display. Например, Flex Formatting Context устанавливается с помощью декларации display: flex. Но это ещё не всё. Спецификация CSS определяет поведение самого блока и его потомков. В примере выше <div>, у которого будет выставлен display: flex, будет иметь блочный тип относительно своих соседей в нормальном потоке документа, но у потомков будет задан Flex Formatting Context. То есть у блока существует внешний (для нормального потока документа) и внутренний (для потомков) типы отображения. Обновлённая спецификация для display теперь явно описывает эту особенность. Например, display: flex эквивалентно display: block flex, а display: inline-flex — display: inline flex.

На данный момент поддержка комбинированных значений есть только в Firefox 70. В любом случае, рекомендую почитать статью или хотя бы посмотреть на таблицу соответствий новых и старых значений display.

#css #specification

https://hacks.mozilla.org/2019/10/the-two-value-syntax-of-the-css-display-property/

Ребята из Microsoft в блоге на хабре опубликовали небольшой пост про модернизацию контролов нового Edge — "Улучшение элементов управления в Microsoft Edge на Chromium".

После перехода на кодовую базу Chromium разработчики Edge сфокусировали своё внимание на элементах управления, потому что Windows работает на разных устройствах с разными способами ввода. Например, очень сильно был изменён контрол ввода времени: вместо небольшого текстового поля с маленькими спиннером, теперь при клике/тапе на контрол будет появляться некоторое подобие календаря, но для работы со временем. В итоге совместной работы с командой Chrome были доработаны поля ввода, элемент выбора цвета, чекбокс, выпадающий список и другие элементы. Ещё были обновлены маппинги элементов управления, для улучшения работы скринридеров и других асисстивных технологий.

В комментариях разработчиков ругают за то, что они "перекрашивают кнопки". Я же считаю, что они занимаются хорошим делом. В итоге их труды по улучшению доступности элементов управления будут доступны во всех Chromium-based браузерах.

https://habr.com/ru/company/microsoft/blog/472268/

#edge #a11y

Аксель Раушмайер написал у себя в блоге статью про проблемы с разделяемым изменяемым состоянием и способы их решения — "The problems of shared mutable state and how to avoid them".

Если один и тот же объект, массив или другая структура изменяется в нескольких местах программы, то это может приводить к неприятным багам. Для предотвращения таких проблем часто используют защитное копирование (Defensive copying), недеструктивное изменение данных и иммутабельные данные. В статье описываются все эти подходы.

Забавно, что буквально перед тем как начать статью, я сидел и пробовал вспомнить все способы ограничения доступа к свойствам объекта. Вспомнил только про Object.freeze и Object.seal. В статье нашёл третий забытый метод — Object.preventExtensions.

Статья у Акселя получилась большой и подробной. Рекомендую почитать.

#js #immutability

https://2ality.com/2019/10/shared-mutable-state.html

Наткнулся в твиттере на отличный тред Криса Ачарда про DNS — "DNS Record crash course".

Если вам приходилось работать с доменными именами, то скорее всего вы знаете про существование DNS-записей A, AAAA, CNAME, MX и т.п. В треде Крис очень кратко рассказывает про назначение этих записей и их особенности. Например, если был определён CNAME для поддомена, тогда не получится определить другие запись для того же самого поддомена.

Очень рекомендую почитать тред — там всё написано без воды и по делу. Must read для тех, кто только начинает заниматься web-разработкой.

#dns #backend

https://twitter.com/chrisachard/status/1188870256971915265?s=20

Корри Хаус — известный спикер в React-сообществе — поделился своим пятилетним опытом работы с React — "Lessons learned from 5 years in React".

Документ содержит 63 пункта про работу с компонентами, JSX, про управление состоянием приложения, производительность, переиспользование компонентов и их тестирование. Есть пара пунктов, которые хочется выделить. Не используйте во всех компонентах без исключения useMemo, shouldComponentUpdate, PureComponent. Используйте их только там, где они нужны. Если бы их использование не несло дополнительные накладные расходы, они были бы включены по умолчанию. Если есть в этом смысл, используйте в своих компонентах имена, которые используются в Web-платформе (`onBlur`, onChange и т.п.). Используйте as как пропс для модификации типа верхнеуровневого элемента.

Есть в списке пара пунктов, которые у меня вызвали вопросы. Например, полный отказ от тестирования снепшотами. Вместо них Корри предлагает использовать Percy или Chromatic. Это очень жёсткая позиция. Проблема со снепшотами возникает только тогда, когда их очень много. Если для компонента создаётся один снепшот, то этого вполне достаточно для отлавливания непреднамеренного изменения кода.

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

#react #list #experience

https://www.dropbox.com/s/tsid5bnphznbvjv/