Сэм Сакконе из Google написал статью про профилирование webpack-сборки — "Why is my webpack build slow?"

В статье описывается три подхода к профилированию сборки:
1. Использование webpack-плагина ProfilingPlugin
2. Использование встроенных в node.js средств профилировки
3. Использование профилировщика Chrome Dev Tools

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

Статью точно стоит почитать, если вы используете webpack и хотите выяснить, что негативнее всего влияет на сборку проекта.

#webpack #performance #build

https://samsaccone.com/posts/why-is-my-webpack-build-slow.html

Мой коллега — Александр Воронянский — сегодня на хабре опубликовал статью про то, как наша команда Яндекс.Маркета доставляет фичи до пользователей — "От идеи до релиза. Детальный опыт фронтенда Маркета".

У нас работает более 40 фронтенд-разработчиков. В нашей ответственности находятся клиентская часть и Node.js BFF (Backend For Frontend). Мы работаем в контурах-командах, состоящих из разных специалистов: фронтендеры, бэкендеры, дизайнеры и продакт менеджеры. Любой человек из команды может предложить свою идею для улучшения сервиса, которая проходит оценку по системе GIST. Если идея хорошая, то команда начинает над ней работать. После того как написан код, пройдено ревью, тесты и другие проверки, фича попадает в релиз. Релизят у нас ребята из QA. Во время релиза проходит большое количество проверок: E2E-тесты, нагрузочные тесты, скриншот-тесты и т.п. Если всё ок, релиз попадает в престейбл (стейджинг). Там тоже проводятся проверки. После этого этапа свежий код релиза раскатывается по датацентрам.

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

#ci #process #yandex

https://habr.com/ru/company/yandex/blog/459960/

Увидел твит, в котором человек жаловался на то, что форма для ввода данных ругалась на его имя и фамилию (Zi Ye). В ответах к твиту была ссылка на хорошую статью про валидацию имён от Карли Хо — "What's in a name (validation)?"

Основная мысль статьи — не валидируйте имена. Причин очень много: у пользователя может быть несколько имён и фамилий, имя может содержать любое количество букв, содержать не только буквы и т.п. Имя — это всего лишь способ, которым можно определить конкретного человека.

Для формирования хорошего пользовательского опыта при добавлении в форму поля для ввода имени надо отталкиваться от причин, зачем оно вам необходимо. Если для отправки персонализированных сообщений, то добавьте метку "Как к вам обращаться?", если для отправки товара — "Ваше имя (для получения товара)". Если нельзя отказаться от валидации имени (такое бывает), то в сообщении с текстом ошибки не стоит говорить о том, что имя неправильное, так как это звучит абсурдно, лучше честно сообщить о том, что в системе есть ограничения и перечислить их.

Статья очень полезная. Советую почитать.

#ui #ux #validation

https://dev.to/carlymho/whats-in-a-name-validation-4b41

Недавно инженеры Slack в статье "When a rewrite isn’t: rebuilding Slack on the desktop" поделились опытом обновления своего приложения.

Старая архитектура Slack содержала три основных проблемы: ручное управление DOM, жадную загрузку данных и отдельные процессы для каждого workspace. С первыми двумя проблемами можно было справиться постепенно: для работы с DOM был выбран React, для работы с данными — Redux. Но последняя проблема требовала фундаментального изменения дизайна приложения. Был выработан план: продолжать работать со старой кодовой базой, постепенно её обновляя и используя строгий интерфейс взаимодействия современной и старой части приложения. При этом весь новый код постепенно переносился в современное приложение из старого. Таким образом получилось добиться баланса между доставкой новых фич пользователям и переписыванием приложения. В результате обновлённое приложение стало работать быстрее и потреблять меньше памяти.

Статья очень интересная. Определённо, стоит почитать.

#electron #performance #architecture

https://slack.engineering/rebuilding-slack-on-the-desktop-308d6fe94ae4

Попалась на глаза статья, в которой ребята из Quizlet рассказывают про опыт перевода кодовой базы c Flow на TypeScript — "Now or Never: Migrating 300k LOC from Flow to TypeScript at Quizlet".

Было несколько причин, которые заставили задуматься о миграции на TypeScript: медленная работа тайп-чекера, проблемы в определениях типов используемых библиотек, не такая качественная поддержка в редакторах кода как с TypeScript и т.п.

Общая кодовая база на момент переноса состояла из 300 тысяч строк. Рассматривался вариант с инкрементальным переносом проекта на TypeScript, но это усложнило бы поддержку кода, поэтому было решено мигрировать весь код сразу. Для автоматической конвертации использовался babel-плагин babel-plugin-flow-to-typenoscript. После переноса появилось 6000 ошибок в типах. Как написано в статье это не было проблемой, так как Flow всё равно их не отлавливал, поэтому они были заигнорированы. После внедрения TypeScript покрытие кода типами увеличилось на 20%. Также стали отслеживаются те ошибки, которые были проблемой для Flow.

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

#flow #typenoscript

https://medium.com/tech-quizlet/now-or-never-migrating-300k-loc-from-flow-to-typenoscript-at-quizlet-d3bae5830a1

Александр Хованский опубликовал на хабре неплохую статью "Введение в Screen Capture API — Сканируем QR коды в браузере".

Автор статьи захотел написать приложение, с помощью которого можно распознавать qr-коды прямо на компьютере. Для этого он воспользовался Screen Capture API. Это API позволяет захватывать изображения с экрана монитора целиком, окна какого-то определённого приложения или определённой вкладки браузера (эта возможность доступна только в Chrome).

В статье есть пример кода захвата; он состоит из следующих частей:
1. Отправка потока в <video>
2. Периодическая отрисовка <video> в <canvas>
3. Захват изображения с помощью getImageData()

Ещё в статье есть ссылка на демо готового приложения. Проверил — всё работает замечательно. Но стоит иметь в виду, что Screen Capture API поддерживают только Firefox, Chrome и Edge.

#web #api #tutorial

https://habr.com/ru/post/460825/

Хочу поделиться с вами каналом @we_use_js. В канале публикуются интересные посты про js и смежные технологии, там есть про всё: React, Angular, Vue.js, rx.js, redux etc. Переодически проскакивают ссылки на интересные инструменты, которые могут пригодится в разработке. Иногда таскаю оттуда ссылки в Defront. https://news.1rj.ru/str/we_use_js

Джек Эллис и Пол Джарвис, работающие над анонимной системой аналитики Fathom, рассказали о том, как они собирают данные, не нарушая GDPR и не надоедая пользователям всплывающими сообщениями о необходимости принять соглашение на их трекинг (всем знакомые окошки "We use cookies").

Для трекинга они используют захешированные анонимизированные данные. Разные типы хешей используются для разных типов аналитики: уникальных просмотров страниц, подсчёта уников, отслеживания связанных запросов (например, чтобы показать, сколько времени пользователи находились на сайте). Для первого типа используется хеш от соли SHA256, идентификатора сайта, ip адреса, User Agent, имени хоста и пути документа. Для второго — всё то же самое без хоста и пути. Третий тип использует предыдущее состояние о просмотре страницы для уникального пользователя, удаляя это состояние после подсчёта необходимой метрики.

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

Статью можно почитать ради интереса или если вам надо поддержать GDPR в вашем проекте. Кстати, новую систему аналитики ребята обещают заопенсорсить в этом году.

https://usefathom.com/anonymization/

#web #gdpr #analytics

Попалась на глаза подборка туториалов Робина Вирух про настройку React-проекта с нуля от создания package.json до настройки enzyme и hot module replacement.

Туториалы очень хорошие. В них всё написано по делу, понятно и аккуратно. Автор поддерживает их в актуальном состоянии; несмотря на то что некоторые статьи были опубликованы более двух лет назад, в них рассматриваются последние версии библиотек. Я немного запутался с перекрёстными ссылками, поэтому вот список ссылок на статьи в корректном порядке:

1. How to set up a modern JavaScript project
2. How to set up a Webpack project
3. How to set up Webpack with Babel
4. How to set up an advanced Webpack application
5. How to set up React with Webpack and Babel
6. How to test React components with Jest
7. How to test React components with Jest & Enzyme

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

#tutorial #webpack #react #jest

Хидде Де Врис недавно опубликовал статью про новую модель для работы с деревом доступности из JavaScript — "Meaning without markup: Accessibility Object Model".

На сегодняшний день есть много проблем при работе с деревом доступности. Cамая большая проблема заключается в том, что оно недоступно для разработчиков. Mozilla, Google и Apple работают над новой спецификацией Accessibility Object Model (AOM), которая позволит извлечь дерево доступности для манипуляции из JavaScript.

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

Поддержка AOM на данный момент есть в экспериментальном режиме в Chrome и Safari. Очень круто, что над улучшением доступности веба идёт такая большая работа.

https://hiddedevries.nl/en/blog/2019-07-22-meaning-without-markup-accessibility-object-model

#a11y #aom #experimental

Сегодня пришлось переустанавливать macOS. Переустановка сама по себе не очень долгий процесс, но установка всех необходимых программ и конфигурирование настроек в системе может занять много времени. Для ускорения этого процесса хорошие люди делятся своими скриптами для конфигурирования системы, так называемыми dotfiles.

Ларс Капперт написал хорошую статью, в которой он рассказывает, как настроить dotfiles под себя — "Getting Started With Dotfiles". По этой статье я делал свой набор конфигов лет пять назад, и они до сих пор помогают. Очень рекомендую ввязаться в эту авантюру, так как она потенциально может потом сэкономить ваше время при настройке системы, ну и просто это интересно.

You’re The King Of Your Castle!

#tool #config

https://medium.com/@webprolific/getting-started-with-dotfiles-43c3602fd789

Прочитал статью Майкла Шварца et al, посвященную способу идентификации окружения, в котором работает браузер, — "JavaScript Template Attacks: Automatically Inferring Host Information for Targeted Exploits".

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

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

Мне очень понравился изобретательный способ определения разрядности процессора, который использовался исследователями для дополнительного сбора информации о системе перед этапом сбора метрик. Этот способ использует JavaScript-код, который компилируется в машинный код, использующий разное число SSE XMM регистров на 32- и 64-разрядных x86-процессорах.

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

#security #paper

https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_01B-4_Schwarz_paper.pdf

Денис Колесников (мой бывший коллега) написал хорошее расширение для просмотра JSON в браузере. Про это расширение недавно написал статью Роман Дворнов — "JsonDiscovery: Меняем опыт просмотра JSON в браузере".

Подобных инструментов есть много. Что отличает JsonDiscovery от других — возможность написания запросов к JSON и его верхнеуровневого анализа. Это очень удобно при работе с сервисами, с которыми ещё не приходилось работать или если сервис генерирует большие JSON-ответы, в которых надо копаться. Для написания запросов используется язык Jora, при написании запроса работает автодополнение. Если навести курсор на иконку "s", то можно увидеть сигнатуру структуры с небольшой статистикой. Конечно, есть традиционное представление JSON'а в виде дерева, но можно настроить кастомное отображение данных. Есть возможность быстрого копирования частей дерева в буфер обмена.

Тулза получилась очень прикольной. Советую поставить и поиграться (поддерживается Firefox и Chrome).

#tool #json #analytics

https://habr.com/ru/post/461185/

В JavaSript коммьюнити Мартин Клеппе считается одним из самых известных исследователей в области обфускации JS-кода. Несколько лет назад он представил проект JSFuck — подмножество JavaScript, использующее шесть символов []()!+, с помощью которых можно представить и выполнить любой JavaScript-код. В 2016-ом году была совершена атака на пользователей eBay, в ней был использован этот метод обфускации.

Недавно Мартин представил свой новый проект — Five. Five — это развитие идей JSFuck, использующее пять символов для представления кода — $+=[]. Это подмножество работает только в браузерах и на тех страницах, где есть jQuery UI.

Довольно сложно в нескольких словах объяснить как работает Five, но его суть заключается в следующем. С помощью символов $+=[] можно получить доступ к исходному коду функции $.find(). Полученный исходный код работает как алфавит, из которого по кусочкам можно сформировать любой JavaScript-код. Для выполнения кода используется ссылка на document.body, которая достаётся из $.datepicker.dpDiv[0].ownerDocument.body. То есть если сайт использует jQuery UI (таких сайтов много) и если он не экранирует $+=[] в пользовательских данных, это может открыть возможность для XSS-атак.

#js #fun #security #obfuscation

http://aem1k.com/five/

Ричард Кроули из Slack рассказал про то, как они тестируют устойчивость сервисов к ошибкам — "Disasterpiece Theater: Slack’s process for approachable Chaos Engineering".

Для тестирования fault-tolerance команда Slack следует процессу, который они назвали "театром маленьких разрушений". В самом начале этого "представления" определяется, какая часть системы будет тестироваться, составляется план отключения и восстановления. Документируются гипотезы того, как будет себя вести поломанная система. Вот пример из статьи: "Отключение мастера MySQL приведёт к повышению времени ответа на 20 секунд для запросов, которые зависят от этой базы, для других запросов повышения таймингов не будет, ожидается менее 1000 неудачных запросов, которые будут заретраены клиентами”. Затем провоцируется поломка в тестинге. Гипотезы сверяются с тем, что произошло в реальности и делаются выводы. Если в тестинге, всё прошло хорошо, поломка провоцируется в проде. В статье есть пара примеров того, какие проблемы были обнаружены благодаря такому подходу.

В Яндексе тоже проводятся подобные проверки, у нас они называются учениями. В общем, это нормальная практика, которую не надо бояться, она помогает вскрывать и устранять проблемы, связанные с инфраструктурой, мониторингами и кодом.

https://slack.engineering/disasterpiece-theater-slacks-process-for-approachable-chaos-engineering-3434422afb54

#devops #backend #testing

Недавно вышел Chrome 76. Разработчики по традиции написали несколько статей, посвящённых новому релизу браузера — "New in Chrome 76".

Cамая интересная фича с точки зрения пользователей — упрощённый процесс установки PWA приложений в настольной версии Chrome. Если сайт отвечает критериям PWA, то в адресной строке появляется специальная кнопка, которая запускает процесс установки. Ранее установку можно было инициировать только из меню браузера, что было не очень очевидно. Была добавлена поддержка медиа-выражения prefers-color-scheme, для того, чтобы сайты могли адаптировать свою тему в зависимости от настроек операционной системы. Частота проверки новых версий установленных PWA-приложений (Android) изменилась с трёх дней до одного.

В инструментах разработчика была добавлена вкладка Memory, которая в реальном времени показывает потребление памяти сайтом. Добавили удобное автодополнение CSS-свойств по их значениям. Например, если при добавлении нового свойства у элемента написать "italic", то появится подсказка, которая предложит "font-style: italic". Упростилась работа с Blob — const text = await blob.text(); — теперь необязательно использовать враппер над FileReader. Новый Chrome поставляется с V8 v7.6, в котором был добавлен Promise.allSettled(), был ускорен JSON.parse() и ускорена работа с sealed/frozen массивами.

#release #chrome #announcement

https://developers.google.com/web/updates/2019/07/nic76

Увидел в канале Веб-стандартов ссылку на статью Джереми Вагнера — "Responsible JavaScript: Part I".

В первой части статьи автор пишет о том, что JavaScript оказывает большое влияние на производительность современных сайтов. Тренд говорит о том, что средний объём передаваемого JavaScript скоро увеличится до 400Кб (около 2Мб в распакованном виде). Поэтому стоит немного остановиться и начать использовать инструменты по своему назначению. Например, прежде чем делать полноценное SPA-приложение для отображения статей имеет смысл задуматься, а не подойдут ли для этой задачи старые добрые HTML и CSS. Даже без JavaScript хорошо спроектированный блог будет доступен и будет быстро загружаться.

Джереми не призывает к отказу от JavaScript, но если какая-то задача решается хорошо без него, то лучше JS не использовать, например, для раскладки документа.

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

#js #performance #musings

https://alistapart.com/article/responsible-javanoscript-part-1/

Вчера я написал про первую часть цикла статей Джереми Вагнера про производительность. Сегодня прочитал вторую — "Responsible JavaScript: Part II".

В этой статье Джереми приводит конкретные практические примеры, которые могут помочь в снижении объёма JavaScript-бандлов. Начинается она с обсуждения tree-shaking. Надо помнить, что он работает только благодаря статической природе модульной системы из ES2015. Поэтому, если вы используете babel, надо убедиться, что в настройках @babel/preset-env стоит modules: false, чтобы экспорты и импорты не преобразовывались в CommonJS. Для определения мест, где можно добавить code splitting, можно проанализировать те точки приложения, где происходит обработка пользовательского взаимодействия. Если приложение использует загружаемые скрипты со сторонних сайтов, следует убедиться, что они помечены в конфиге webpack как externals, для того чтобы исключить их из бандла.

Ещё можно настроить сборку так, чтобы собиралось два бандла (один для старых браузеров, второй для современных), и с помощью такого трюка загружать только необходимый код:

<!-- Modern browsers load this file: -->
<noscript type="module" src="/js/app.mjs"></noscript>
<!-- Legacy browsers load this file: -->
<noscript defer nomodule src="/js/app.js"></noscript>

Если первая часть была из категории "интересно почитать", то вторая попадает в категорию "must read".

#js #performance #webpack

https://alistapart.com/article/responsible-javanoscript-part-2/

Илья Стрельцын (один из редакторов css-live) опубликовал хорошую статью — "Фантастические веб-спецификации и где они обитают".

Статья рассказывает про спецификации и всё, что надо знать для того, чтобы начать с ними эффективно работать. В начале статьи рассказывается про логику формирования адресов на страницы документов. Самые последние версии спецификаций находятся по таким адресам: https://www.w3.org/TR/<название_технологии>/. При этом все ранее опубликованные спецификации (технические отчёты — technical reports) хранятся вечно, их адреса выглядят так: https://www.w3.org/TR/2008/WD-html5-20080610. Хранить документы вечно по зафиксированным адресам необходимо для защиты от патентных троллей. На страницах всех спецификаций есть ссылка на Editor's Draft (ED), именно там находится самая свежая версия документа с исправлениями неточностей, опечаток и т.п.

В статье ещё рассказывается про разные статусы документов, и что они обозначают. Немного затрагивается история непростых взаимоотношений W3C и WHATWG.

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

#specification #web #css #html

https://css-live.ru/css/fantasticheskie-veb-specifikacii-i-gde-oni-obitayut.html

Валерий Шибанов написал статью про то, как он участвовал в конкурсе телеграма — "Как я не занял первое место в конкурсе для JavaScript-разработчиков от Telegram".

По условиям конкурса надо было написать быструю и компактную библиотеку отрисовки графиков. Существующие библиотеки использовать не разрешалось.

Для решения задачи автор выбирал между canvas и SVG. В итоге остановился на canvas, так как он даёт больше возможностей для оптимизаций. На первом этапе конкурса Валерий не занял призового места из-за проблем с производительностью. На втором этапе, где предлагалось добавить к существующему решению дополнительные виды графиков, автор поработал над оптимизацией. В предыдущем решении были использованы html-элементы, для управления областью просмотра графиков. Они располагались над canvas, и это снижало производительность прорисовки. В итоге он их убрал. Ещё была закеширована миникарта и исправлена не очень плавная анимация. После всех улучшений удалось занять 4-ое место.

Респектую автору и поздравляю с призовым местом.

#contest #rendering #noscript #canvas

https://habr.com/ru/company/lanit/blog/460625/

Вчера на сайте web.dev Фил Волтон из Google опубликовал статью, посвящённую Largest Contentful Paint, — новому API, с помощью которого можно получить наиболее точное время появления основного содержимого сайта.

Необходимость в новом API возникла из-за того, что существующее событие DOMContentLoaded не всегда соответствует появлению содержимому, которое можно считать полезным. First Paint и First Contentful Paint тоже не очень хорошие кандидаты для получения времени, так как они отражают начало рендеринга. Метрики First Meaningful Paint и Speed Index, которые рекомендовались ранее, часто некорректно говорят про время отображения основного контента.

В результате дискуссий рабочей группы W3C и исследований, проведённых командой Google, было обнаружено, что наиболее аккуратный способ определения времени отображения основного содержимого страницы, это отслеживание времени рендеринга самого большого элемента.

Для определения этого события предназначено API Largest Contentful Paint (LCP). Так как при загрузке страницы контент может меняться, браузер отправляет PerformanceEntry c типом largest-contentful-paint при каждом появлении нового большого элемента. Отправка метрики прекращается, после того как пользователь начинает взаимодействовать со страницей. Время самого последнего отправленного события является нужным значением.

Largest Contentful Paint доступен в Chrome 77. В этой версии также стал доступен Element Timing API, на базе которого построен LCP. С помощью него можно узнать время появления конкретных элементов на странице.

#web #performance #rendering #chrome

https://web.dev/largest-contentful-paint