Наткнулся на статью Стейси Тей "How we made Carousell’s mobile web experience 3x faster". В статье Стейси делится опытом оптимизации web-приложения Carousell.

Их стартап из Сингапура. Это довольно богатая страна, пользователи которой пользуются мощными смартфонами с хорошим интернет-соединением. С выходом на рынок Филиппин и Индонезии у них появилась проблема — у средне-статистического пользователя их сайт грузился 15 секунд.

Они ввели бюджет на производительность: 120KB для ресурсов критического пути рендеринга, 2 секунды для First Contentful Paint и 5 секунд Time-to-Interactive. Частично реализовали паттерн PRPL, заинлайнили критический CSS, стали лениво грузить изображения, стали использовать сервис воркеры для кеширования запросов, включили сжатие изображений у своего CDN-провайдера. В итоге их сайт стал грузиться в 3 раза быстрее, в 3 раза увеличился CTR и на 63% увеличился органический траффик из Индонезии.

Статья очень ярко показывает, как оптимизация производительности может влиять на бизнес-метрики приложения.

#web #performance #pwa

https://medium.com/carousell-insider/how-we-made-carousells-mobile-web-experience-3x-faster-bbb3be93e006

Недавно был выпущен Firefox 68. По традиции на Mozilla Hacks разработчики опубликовали статью про новые фичи браузера — "Firefox 68: BigInts, Contrast Checks, and the QuantumBar".

В новой версии появилась поддержка пропозала BigInt, который позволяет работать с большими целыми числами в JavaScript, не теряя в точности. Была добавлена поддержка последнего синтаксиса для scroll snapping. В рамках работ над web-совместимостью были добавлены проприетарные методы из IE для работы с CSS-правилами: addRule() и removeRule(), и была добавлена поддержка -webkit-line-clamp (ура!). Доступ к медиаустройствам теперь разрешён только тем сайтам, которые работают по HTTPS. Теперь можно передавать опцию noreferrer в методе window.open().

В инструментах разработчика на панели доступности можно включить предупреждения для неконтрастного текста. Информацию по web-совместимости можно получить через about:compat. Новый многопоточный WebRender, написанный на Rust, теперь включён у пользователей на Windows 10 с видеокартами AMD. Продолжается работа над удалением легаси-кода, использующего XUL/XBL — адресная строка браузера была переписана с использованием стандартных web-технологий: HTML, CSS, JS.

#release #firefox

https://hacks.mozilla.org/2019/07/firefox-68-bigints-contrast-checks-and-the-quantumbar/

Хочу продолжить тему про Firefox. В посте выше было написано, что в новой версии браузера была добавлена поддержка последнего синтаксиса для scroll snapping. Рейчел Эндрю месяц назад написала пост про эту фичу — "CSS Scroll Snap Updated in Firefox 68".

Scroll Snap — это эффект прилипания контента при прокрутке содержимого контейнера. Он очень полезен при реализации каруселей, слайдеров и подобных элементов. Прилипание можно реализовать, используя JavaScript, но это может привести к плохому пользовательскому опыту, именно поэтому CSS Working Group разработала спецификацию "CSS Scroll Snap".

Работает Sroll Snap так: у контейнера задаётся свойство scroll-snap-type, а у вложенных элементов, которые должны прилипать, — scroll-snap-align. До Firefox 68 был реализован черновой стандарт Scroll Snap, в новой версии его поддержка была прекращена.

На данный момент поддержка актуальной спецификации Scroll Snap есть во всех основных браузерах: Firefox, Chrome, Safari.

#firefox #css

https://hacks.mozilla.org/2019/06/css-scroll-snap-updated-in-firefox-68/

Facebook открыл исходный код JavaScript-движка Hermes, который был разработан для оптимизации работы React Native приложений на Android.

Hermes в отличие от V8 использует ahead-of-time компиляцию (парсинг и компиляция JS-кода в байткод происходит не на устройстве пользователя, а на этапе сборки программы). Приложения, использующие Hermes, запускаются гораздо быстрее (примерно в 2 раза быстрее в демо с Mattermost) и потребляют меньше памяти. При сборке приложений с новым движком apk-пакеты занимают меньше места. Для режима разработки предусмотрена ленивая компиляция кода на устройстве, чтобы фидбек при разработке оставался быстрым.

Движок поддерживает большую часть синтаксиса ES2015. В процессе разработки добавление const, let, ES-модулей, классов, вычисляемых свойств объектов. Исключены из поддержки Proxy, Reflect, with и другие редко-используемые части языка.

Hermes уже используется в production-приложениях Facebook. На данный момент разработчики не планируют адаптировать Hermes для работы на сервере или в web'е.

https://www.youtube.com/watch?v=zEjqDWqeDdg

#talk #reactnative #engine #announcement #facebook

Эту неделю можно запомнить как неделю релизов JavaScript-движков. 9 июля Фабрис Беллар (автор QEMU, FFmpeg) представил свой новый проект — QuickJS.

QuickJS — это маленький встраиваемый JavaScript-движок, который поддерживает спецификацию ES2019. Его особенности: быстрая интерпретация, быстрое время старта, проходит 100% ECMAScript Test Suite, может компилировать исходники с JS-кодом в исполняемые файлы без зависимостей, содержит математические расширения BigInt, BigFloat, директивы 'use bigint'; и 'use math'; и т.п., содержит небольшую стандартную библиотеку, которая разбита на два модуля: std и os.

По результатам бенчмарка v8, QuickJS опережает другие встраиваемые движки — DukTape, XS, MuJS и JerryScript. Удивительно, что это творение рук одного человека. Очень рекомендую прочитать про него статью на хабре (https://habr.com/ru/post/119455/).

#js #engine #embedded

https://bellard.org/quickjs/

Анкита Масанд написала статью про использование API для интернационализации приложений в JS — "New Intl APIs in JavaScript".

API интернационализации живёт в глобальном объекте Intl. В статье рассматривается несколько кейсов, где оно может быть полезно. Например, можно использовать Intl.RelativeTimeFormat для форматирования относительных дат ("минуту назад", "день назад", "через 10 дней" и т.п.). Intl.ListFormat для форматирования списков (можно использовать списки с конъюнкцией, дизъюнкцией или с обычным перечислением через запятую). Intl.NumberFormat используется для форматирования больших целых чисел (между разрядами числа в русскоязычном формате добавляются пробелы, в англоязычном — запятые). Для форматирования времени и дат используется Intl.DateTimeFormat.

Intl доступен во всех актуальных браузерах, но полнота имплементации от браузера к браузеру отличается. Например, Intl.RelativeTimeFormat не поддерживается в IE11 и Edge.

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

#js #i18n

https://blog.bitsrc.io/new-intl-apis-in-javanoscript-c50dc89d2cf3

Евгений Бондаренко в статье "9 лет в монолите на Node.JS" поделился опытом перевода Node.js монолита OneTwoTrip на микросервисы.

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

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

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

#nodejs #architecture

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

Недавно в блоге V8 появилась статья, посвящённая новому пропозалу WeakRef (Stage 3) — "Weak references and finalizers".

Попробую объяснить своими словами его суть на примере. Представьте, что у вас в браузере происходит какая-то обработка изображений, например, на них накладывается водяной знак (согласен, пример не очень реалистичный), а затем эти изображения как-то используются. Водяной знак накладывается функцией, которая интенсивно потребляет CPU. Изображения могут повторяться, поэтому, чтобы лишний раз не загружать процессор, мы создаём кеш изображений с водяным знаком в Map, ключом пусть выступает название файла изображения. Но тут возникает проблема, если какое-то изображение не будет нами использоваться, оно всё равно будет находиться в памяти, так как Map по ключу будет на него ссылаться (strong reference). Поэтому, чтобы наш Map не отжирал лишнюю память, необходимо как-то определять такие ситуации и руками чистить кеш. Это не очень удобно.

Именно здесь на помощь приходит WeakRef. С помощью WeakRef можно создать слабую ссылку на изображение и записывать её по ключу вместо самого изображения:

const wr = new WeakRef(image);
cache.set(name, wr);
// для получения изображения
const ref = cache.get(name);
const image = ref.deref();

В этом случае сборщик мусора сможет самостоятельно определять ситуации, когда изображение в кеше уже не нужно и очищать память. Для очистки ключей из Map в пропозале предлагается использовать дополнительное API FinalizationGroup.

Интересный факт. В самом начале статьи даётся небольшой обзор уже входящих в стандарт WeakMap и WeakSet. Оказывается, что наиболее формальное название для отношения, которое используется в WeakMap — Ephemeron.

#js #proposal #gc

https://v8.dev/features/weak-references

Пару дней назад Джейсон Миллер из 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