Ингвар Степанян из Cloudflare написал статью про объяснение принципа работы Binary AST — "Faster noscript loading with BinaryAST?"

Binary AST — это предложение в TC39, цель которого ускорить парсинг JavaScript. Парсинг может быть основной причиной медленного старта приложений на слабых устройствах. Например, на флагманских смартфонах парсинг 1Мб JavaScrpt занимает 100ms, в то время как на слабых устройствах (Moto G4) — более секунды. С помощью Binary AST на этапе сборки можно представить AST JavaScript в бинарном виде с дополнительными хинтами, которое позволяет ускорить парсинг до 90% в синтетических тестах.

Ингвар в статье также рассказывает про то, каким образом Cloudflare внедрил поддержку Binary AST. Они используют кодировщик Binary AST, который написан на Rust. Исходный JavaScript при этом парсится с помощью Shift в инстансе v8. На данный момент их следующая цель — сбор данных с реальных проектов, чтобы улучшить формат представления AST.

Binary AST находится на первом этапе рассмотрения в TC39. Прототип реализации уже добавлен в Nightly-версию Firefox. Над развитием стандарта работает Mozilla, Cloudflare, Facebook и Bloomberg.

#js #proposal #tc39

https://blog.cloudflare.com/binary-ast/

Пару дней назад Дас Сурма из Google опубликовал у себя в блоге статью про работу с WebAssembly — "Raw WebAssembly".

В статье объясняются базовые принципы работы виртуальной машины wasm. Разбирается структура WebAssembly-модулей в текстовом формате "wat". Есть пара интересных примеров. Например, показывается как из WebAssembly вызывать JavaScript-функцию. Подобный подход используется в wasm-bindgen, для того чтобы из Rust-кода манипулировать DOM-узлами в браузере. Есть пример работы с памятью.

Сурма в статье пишет про то, что для эффективной работы c WebAssembly необязательно знать внутреннюю структуру wasm-модулей и особенности работы виртуальной машины. Но это знание может помочь в тех ситуациях, когда что-то идёт не так.

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

#webassembly #vm

https://dassur.ma/things/raw-wasm/

Евгений Вецель написал отличную статью о том, как сохранить здоровье программисту — "Стимуляторы работы программиста. Здоровье".

Евгений советует делать физические нагрузки на протяжении дня. Например, если любите слушать подкасты, то лучше слушать их находу. В принципе ходить очень полезно для здоровья. Для пополнения энергии советует хорошо питаться и спать. В статье есть такой совет, что если днём вам хочется поспать, то можно задремать на 15-20 минут. Но лично мне было бы некомфортно спать прямо на рабочем месте, поэтому я стараюсь спать минимум 8 часов каждый день. Есть несколько советов про еду: кушайте полезную еду, старайтесь делать это регулярно, пейте много воды и уменьшайте количество употребляемого кофе.

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

#productivity #life #health

http://blog.csssr.ru/2019/05/07/work-stronger

Несколько дней назад в Firefox Nightly (версия 68) появилась поддержка Resize Observer. В принципе, я про него уже знал, но захотелось более подробно поразбираться в его особенностях. На сайте Web Fundamentals есть очень хорошая статья с описанием того, какие проблемы он решает и как с ним работать — "ResizeObserver: It’s Like document.onresize for Elements".

До появления этой спецификации отслеживание изменения размеров можно было реализовать с помощью getBoundingClientRect или getComputerStyle. Это очень непроизводительный подход, который приводит к лагам при взаимодействии со страницей. Resize Observer позволяет очень эффективно отслеживать и реагировать на изменение геометрии элементов на странице. Обработка событий изменения размеров в Resize Observer происходит сразу после этапа раскладки (layout) до стадии отрисовки (paint), таким образом это самое подходящее место для размещения логики изменения положения элементов или их размеров.

Resize Observer немного напоминает Media Queries и Element Queries из CSS, но они предназначены для разных целей. Media Queries и Element Queries задаются декларативно в CSS и определяют представление при изменении размеров. С помощью Resize Observer описывается необходимое поведение при изменении размеров. В статье есть очень показательный пример с окном чата, когда при изменении размера окна, список сообщений всегда должен быть "приклеен" к самому низу, но только в том случае, если пользователь не прокрутил список к другому сообщению.

На данный момент экспериментальная поддержка Resize Observer есть уже во всех актуальных браузерах. Для более старых версий браузеров можно использовать полифил.

#web #performance #future

https://developers.google.com/web/updates/2016/10/resizeobserver

Вчера вышла новая версия Firefox 67. В блоге Mozilla Hacks по традиции опубликовали пост с самыми интересными нововведениями — "Firefox 67: Dark Mode CSS, WebRender, and more".

В Windows 10 начался процесс постепенной выкатки на всех пользователей с видеокартами NVidia нового WebRender. Это новый движок рендеринга, написанный на Rust и активно использующий GPU для отрисовки элементов страницы.

Появилась поддержка медиа-функции prefers-color-scheme с помощью, которой можно определить, включена ли у пользователя светлая или тёмная тема ОС, и соответствующим образом изменить внешний вид страницы. В JavaScript были добавлены динамические импорты import() и String.prototype.matchAll. Улучшили инструменты разработчика. Теперь можно ставить брекпойнты на частях одного большого выражения, записанного в одну строку (column breakpoint). Добавлена фича "log point", с помощью которой можно добавлять логирование в ходе процесса отладки, не используя console.log().

Добавили поддержку кодека AV1. Улучшили менеджер паролей. Расширили настройки приватности — теперь браузер может определять криптомайнеры и скрипты, пытающиеся идентифицировать пользователя по цифровому отпечатку.

С каждым релизом Firefox становится лучше, это не может не радовать. Здорово то, что много внимания уделяется инструментам разработчика. WebRender тоже очень крутая фича, очень жду когда она появится под macOS.

#firefox #announcement

https://hacks.mozilla.org/2019/05/firefox-67-dark-mode-css-webrender/

Алекс Реадрон в конце апреля написал статью "What does react-beautiful-dnd cost to maintain?", в которой он делится своим опытом поддержки популярной библиотеки для drag'n'drop в react.

Поддержка занимает очень много времени — примерно один полный день в неделю. Чтобы снизить нагрузку, Алекс оптимизировал процессы, с помощью которых пользователи библиотеки могут самостоятельно решать возникающие проблемы. Он написал подробную документацию и поддерживает её в актуальном состоянии. Записал бесплатные видео-уроки на egghead. Добавил вывод warning-сообщений в консоль при неправильной настройке библиотеки. Он не добавляет новые фичи в библиотеку, когда есть открытые баги. В итоге такой подход тоже позволяет снизить время на поддержку.

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

Статья хорошо рассказывает про то, что у популярных Open Source-проектов ненулевая стоимость владения. Очень много времени уходит не только на написание кода, но и на попытки воспроизвести описанные ошибки и многое другое.

#programming #musings #opensource

https://dev.to/alexandereardon/what-does-react-beautiful-dnd-cost-to-maintain-52e8

Посмотрел доклад Джефа Ши из Netflix про то, как развивалась их часть React-приложения, отвечающая за регистрацию нового пользователя — "Redux For Transactional Apps".

Из доклада мне запомнилось то, как они боролись с разобщённостью флоу процесса регистрации на разных платформах: Web, Mobile, TV. На каждой платформе транзакции описывались в самом приложении (в докладе под транзакцией подразумевается пошаговое изменение состояния приложения). Логика транзакций в итоге была перемещена в API, что позволило решить проблему.

Ещё в докладе Джеф рассказал про то, какой профит они получили при использовании Redux. Благодаря тому, что view отделено от стейта, они могут использовать одну и ту же логику изменения состояния на разных платформах, просто подменяя компоненты, отвечающие за представление.

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

#react #statemanagement #talk

https://youtu.be/V8oTJ8OZ5S0?t=1134

Попалась на глаза очень прикольная статья Сид Балы про объяснение принципа работы кодека H.264 — "H.264 is Magic". Перевод статьи на русский язык есть на хабре.

H.264 используется при передачи видеопотока, в формате Blu-ray, в телефонах и т.п. При кодировании фрейма производится сжатие с потерями с использованием частотного пространства. Потом производится цветовая субдискертизация, которая обрабатывает закодированные цвета таким образом, чтобы изображение использовало меньшее количество цветов.

После обработки фреймов наступает этап кодирования компенсации движения, когда выделяется базовый фрейм I-frame и последующие фреймы, которые кодируют смещение блоков 16x16 пикселей базового фрейма. Это позволяет эффективно сжимать движущиеся изображения на статичном фоне. После кодирования компенсации движения применяется энтропийное кодирование.

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

#algorithm #video

https://sidbala.com/h-264-is-magic/

Пару месяцев в закладках лежала статья Дага Силларса про объяснение того, почему инлайн изображений в CSS с помощью Base64 является анти-паттерном — "Performance Anti-Patterns: Base64 Encoding".

Добавление закодированных в base64 изображений блокирует critical rendering path. Если изображение очень большое, то это повлияет на размер CSS. После загрузки большой CSS-файл должен будет распариться. Комбинация этих двух факторов увеличивает задержку перед отображением документа. Также может возникнуть такая ситуация когда один и тот же файл может быть заинлайнен несколько раз. Даг нашёл пример, в котором одно и тоже фоновое изображение было заинлайнено 115 раз. Ещё в статье был пример большого CSS, в который было заинлайнено 6 разных шрифтов.

Совет в статье простой — использовать инлайн изображений с умом. Также не стоит инлайнить шрифты. И по возможности надо переходить на HTTP/2.

P.S. Завтра буду рассказывать обновлённый доклад про кодмоды на FrontendConf в Москве. Если среди вас кто-нибудь там будет, подходите сказать привет, буду рад вашему фидбеку.

#performance #base64 #css

https://calendar.perfplanet.com/2018/performance-anti-patterns-base64-encoding/

Прочитал серию из двух хороших статей "Disguise-Driven Testing: Jest Mocks in Depth" Джо Моргана про использование моков в Jest.

Jest — это фреймворк для тестирования, разработанный Facebook, который развивался в самом начале как форк Jasmine. В первой части рассказывается про основы использования моков, зачем они нужны и как их использовать. Очень подробно разбирается пример их использования для подмены результатов вызова Rest API сервиса. Первая часть написана очень доступно, поэтому особенно рекомендую почитать её новичкам и тем, у кого небольшой опыт работы с инструментами для тестирования.

Во второй части статьи рассматриваются, на мой взгляд, более интересные примеры. Пример мока генератора уникального id, с возможностью его тонкой настройки. И пример мока библиотеки, которая работает с DOM API. В последнем примере тестируется React-компонент, использующий хуки. Для того чтобы useEffects заработал корректно, использовался небольшой трюк с задержкой с помощью async/await. Вторую часть статьи рекомендую тем, у кого уже есть опыт использования Jest. Скорее всего из неё вы узнаете что-нибудь новое.

#jest #mocks #testing

https://ponyfoo.com/articles/disguise-driven-testing-jest-mocks-in-depth
https://ponyfoo.com/articles/disguise-driven-testing-jest-mocks-in-depth-part-2

Вчера увидел ссылку на статью Марка Миллера (участник TC39) "The Tragedy of the Common Lisp: Why Large Languages Explode".

Несмотря на название статьи речь в ней идёт про JavaScript. Марк работает над стандартизацией языка с 2007 года. Он очень заботится о том, чтобы язык оставался минимальным и элегантным. В статье он объясняет, почему избирательно подходит к выбору того, что будет добавлено в ECMAScript. По его мнению, минимализм языка является тем качеством, который ценят большинство разработчиков. Осознание того, что мы полностью понимаем принципы работы инструмента, ведёт к чувству удовлетворения.

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

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

#js #tc39 #musings

https://medium.com/@erights/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9

Инженеры eBay неделю назад написали пост про то, как они используют WebAssembly у себя в проекте — "WebAssembly at eBay: A Real-World Use Case". На хабре есть перевод.

В мобильном приложении eBay есть функция чтения штрих-кодов. С помощью отсканированного штрих-кода продавец товара может сэкономить время на заполнении объявления о продаже. Разработчики захотели сделать нечто подобное для мобильной версии сайта.

Сначала для чтения штрих-кодов они использовали JavaScript библиотеку BarcodeReader. Но она работала хорошо только в 20 процентах случаев. Потом они воспользовались скомпилированной в WebAssembly C++ библиотекой, которую они используют в нативных приложениях. И опять возникла проблема — библиотека даёт отличный результат только на сфокусированном изображении. Так как есть ограничения Web-платформы связанные с камерой, они не смогли добиться хорошего результата. Потом они попробовали другую Open Source C++ библиотеку, там тоже было не очень всё ок, но она работала в тех случаях, когда не работала предыдущая библиотека. Поэтому у них появилась идея распознавать штрих-код, используя сразу три разных подхода одновременно: с помощью двух скомпилированных в WebAssembly библиотек и с помощью JavaScript-библиотеки.

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

#webassembly #usecase

https://www.ebayinc.com/stories/blogs/tech/webassembly-at-ebay-a-real-world-use-case/

Давайте вернёмся к теме отладки приложений. Нашёл в дебрях интернета статью 2014-го года "The Debugging Toolbox".

В статье Бэн МакКормик пишет про свою стратегию решения проблем в коде. В этом ему помогает выстроенный с годами процесс, который можно поделить на несколько шагов:

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

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

#debug #programming

https://benmccormick.org/2014/08/19/the-debugging-toolbox

Ссылку на вчерашнюю статью я нашёл у Марка Эриксона в статье "Blogged Answers: Debugging Tips".

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

В статье Марк ещё рассказывает про три случая из его реальной работы, которые потребовали долгого дебага. В первой истории проблема заключалась в неправильном регистре файла, во второй и третьей — в проблемном коде, который забивал главный поток Twisted, из-за чего зависала вся система.

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

#debug #programming

https://blog.isquaredsoftware.com/2019/01/blogged-answers-debugging-tips/

Аксель Раушмайер у себя в блоге два дня назад опубликовал статью про то, как работают декларации в JavaScript — "Unpacking hoisting".

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

Традиционные функции и var'ы всплывают и работа с ними не вызывает особых проблем. Особенности есть при работе с const, let и class. Если обратиться к сущности в объявлении функции, то всё будет ок, но если попытаться выполнить эту функцию, когда сущность ещё не объявлена, то возникнет исключение ReferenceError. Промежуток времени между входом в область видимости сущности и исполнением инструкции с её объявлением называется Temporal Dead Zone (TDZ). Если в это время обратиться к объявляемым переменной/классу/функции, то возникнет исключение. Именно поэтому первый вызов функции из примера ниже выкинет исключение, а второй выполнится без ошибок:

function a() {
  return b;
}

a(); // throws ReferenceError
const b = 1;
a(); // 1

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

#js #es2015

http://2ality.com/2019/05/unpacking-hoisting.html

Вей Гао опубликовала статью про то, как она добавила поддержку тёмной темы у себя в блоге — "Night Mode with Mix Blend Mode: Difference".

При подготовке своего доклада "This World Mixed and Blended" к Вей пришла идея сделать тёмную тему с помощью CSS-свойства mix-blend-mode: difference. Difference — режим смешивания, который доступен почти во всех современных браузерах кроме IE11. Этот режим можно выразить формулой: difference(A, B ) = |A - B|. То есть абсолютное значение разницы двух цветов.

Для реализации тёмной темы Вей сделала дополнительный div, который перекрывает контент. У этого элемента установлены background: white и mix-blend-mode: difference;. Благодаря этому светлый фон становится тёмным, а тёмный текст — светлым. Для исключения изображений из режима смешивания используется свойство isolation: isolate.

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

#css #colors

https://dev.wgao19.cc/2019-05-04__sun-moon-blending-mode/

Прочитал интересную статью Алексея Круглова "Continuous integration в Яндексе".

В статье рассказывается о том, как происходит работа над проектами в Яндексе. Есть единый монорепозиторий. В нём содержится очень много кода (25Гб), над которым работают более 2000 разработчиков. Использование монорепозитория позволяет снизить издержки на систему CI/CD, предотвращает вероятность появления библиотек с похожей функциональностью (так как всё на виду) и снижает порог для внесения исправлений в смежные проекты (используется общий стек для работы с кодом).

На каждый коммит запускается прогон тестов. Запускаются только те тесты, которые необходимы. Чтобы обнаружить нестабильно работающие тесты, они прогоняются два раза. Если какие-то тесты начинают "моргать", то владельцы этих тестов начинают получать уведомления с проблемой. Также используются diff-тесты, которые могут однозначно определить проблемный коммит, который вызвал поломку тестов.

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

#ci #testing #yandex

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

Эдди Османи опубликовал в марте статью про работу с большими списками в React — "Rendering large lists with react-window".

Рендеринг десятков и сотен тысяч элементов в списке приводит к лагам в интерфейсе. Для решения этой проблемы используются виртуализированные списки, в которых рендерится не весь контент сразу, а только та его часть, которая видна в данный момент плюс некоторое смещение выше и ниже. Самая известная библиотека для создания таких списков react-virtualized Брайана Воуна (Brian Vaughn). Но существует более компактный аналог от того же автора — react-window. Про него и рассказывает в статье Эдди.

React-window — очень компактная и быстрая библиотека. В статье есть примеры того, как сделать с помощью неё виртуальный список и таблицу на гридах. У react-window есть несколько ограничений в отличие от react-virtualized, но для большинства случаев она подходит хорошо.

#performance #react #library

https://addyosmani.com/blog/react-window/

Пару месяцев назад в канале был обзор статьи "Код ревью" Дмитрия Мананникова. Тогда я написал, что к ней добавить особо нечего. Но недавно нашёл пост бывшего инженера Facebook — "On Code Reviews", который отлично дополняет предыдущую статью.

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

Если вы работаете в команде с ревью кода (и даже если нет), очень рекомендую прочитать статью.

#musings #codereview #programming

https://medium.com/@schrockn/on-code-reviews-b1c7c94d868c

Дас Сурма недавно написал ещё один пост про работу с WebAssembly — "Compiling C to WebAssembly without Emnoscripten".

В этой статье он показывает как работать с WebAssembly без Emnoscripten. Есть пример того, как скомпилировать простой C-код в wasm с помощью llvm. Немного разбирается архитектура llvm (бэкенд/фронтенд-компиляторы). Показывается, как работать с динамической памятью, на примере суммирования массива целых чисел. Для выделения памяти в Emnoscripten используется malloc, но так как в статье рассказывается про более низкий уровень, там используется простой самописный bump-аллокатор памяти.

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

#webassembly #llvm #internals

https://dassur.ma/things/c-to-webassembly/

Хочу порекомендовать хороший небольшой телеграм-канал Олега Ковалёва, в котором он собирает cheat-sheets для самых разных технологий. У него можно найти подборки по алгоритмам, машинному обчению, базам данных, go, rust, инструментам разработки, гиту и т.п. Активно собирает подборки от подписчиков. В общем, рекомендую.

P.S. Это не реклама, Олег даже не в курсе, что я решил немного попиарить его канал.

#telegram #tools

https://news.1rj.ru/str/techchsh