Пару дней назад Джейсон Миллер из Google написал статью про несколько стратегий загрузки js-бандлов с современным синтаксисом — "Modern Script Loading".

Отдача скриптов с современным синтаксисом для актуальных браузеров может очень положительно отразиться на производительности. При этом нельзя забывать о старых браузерах, которые могут не поддерживать новый синтаксис. Для условной загрузки скриптов в стандарте предусмотрен специальный аттрибут nomodule у тега noscript. Если вставить на страницу два тега скрипт один с современным синтаксисом, а другой со старым и с атрибутом nomodule, тогда последний не будет загружаться в современных браузерах. Но есть проблема — этот трюк будет вызывать лишний фетчинг файлов в Edge и Safari.

Джейсон предлагает четыре решения возникшей проблемы:
1. Определение поддержки браузером современных модулей и вставка на страницу нужного бандла в рантайме
2. При формировании страницы на сервере определять User-Agent и вставлять в код страницы нужный скрипт
3. Использовать описанный выше паттерн nomodule/module, понимая, что у какой-то части пользователей будет происходить лишняя загрузка кода
4. Использование полифиллов в теге с аттрибутом nomodule

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

#js #esm #modules #performance

https://jasonformat.com/modern-noscript-loading/

Сегодня прочитал небольшой туториал Мартина Сплитта — "Reading local files with JavaScript". В туториале разбирается, как работать с локальными файлами пользователя в браузере.

Современные браузеры не предоставляют сайтам доступ к локальной файловой системе в целях безопасности. Но пользователь может явно выбрать интересующие файлы для обработки с помощью элемента <input type="file">; после выбора файла можно прочитать его содержимое с помощью FileReader.

Вот простой пример получения содержимого файла:

document
  .getElementById('fileInput')
  .addEventListener('change', function () {
    if (this.files.length === 0) {
      console.log('No file selected.');
      return;
    }

    const reader = new FileReader();
    reader.onload = function () {
      console.log(reader.result);
    };
    reader.readAsText(this.files[0]);
  });

Можно прочитать файл как строку (как в примере выше), как data URL (например, для отображения выбранного изображения) или как бинарные данные.

Туториал Мартина гораздо меньше, чем похожий туториал на MDN "Using files from web applications", но он может быть полезен, если вам надо быстро разобраться с FileReader API.

#js #filereader #tutorial

https://50linesofco.de/post/2019-07-05-reading-local-files-with-javanoscript

Хочу продолжить тему локальной работы с файлами из браузера. Мой коллега — Паша Смирнов — выступал на JS Party NSK и Я.Субботнике с докладом "Приключения в отдельном потоке". В докладе он рассказал про то, как сохранить отзывчивость приложения при работе с большими файлами в браузере.

Паша делал UI для поиска по картинке в мобильной версии Яндекс.Маркета. Перед загрузкой изображения на сервер, надо было сжать изображение в браузере. Для сжатия был использован Canvas. Но во время сжатия изображения были заметны лаги в интерфейсе, поэтому он решил вынести обработку в воркер (Worker API), чтобы не блокировать основной поток браузера. Так как в воркере DOM API, а следовательно и Canvas, не доступны, было использовано решение с OffscreenCanvas (это тот же самый Canvas, но для работы из воркеров). Но с OffscreenCanvas тоже есть проблема: на данный момент он поддерживается только в тех браузерах, которые построены на базе Chromium. Было принято решение использовать прогрессивное улучшение:
if (window.OffscreenCanvas) {
// используем решение с OffscreenCanvas и воркером
} else {
// старый вариант с Canvas
}

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

Доклад хороший, рекомендую посмотреть или почитать расшифровку доклада на хабре, если интересует тема работы с Worker API в браузере.

#js #filereader #worker #yandex

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

Крис Койер на CSS-Tricks написал небольшую статью про работу с псевдоэлементами — «A Little Reminder That Pseudo Elements are Children, Kinda».

Вот основная мысль статьи. Псевдоэлементы ведут себя в родительских элементах точно так же как и обычные потомки. Например, если сделать грид на контейнере с пседоэлементом, то псевдоэлемент станет ячейкой этого грида. Это же справедливо и для флекс-контейнеров — внутри них псевдоэлемент становится флекс-элементом.

Взял на заметку, как получить стили псевдоэлемента из JavaScript. Для этого нужно использовать getConputedStyle с двумя аргументами:

const styles = window.getComputedStyle(
document.querySelector('.container'),
'::before'
);


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

#css #layout

https://css-tricks.com/a-little-reminder-that-pseudo-elements-are-children-kinda/

Сэм Сакконе из 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/