Попалась на глаза статья, в которой ребята из 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-typescript. После переноса появилось 6000 ошибок в типах. Как написано в статье это не было проблемой, так как Flow всё равно их не отлавливал, поэтому они были заигнорированы. После внедрения TypeScript покрытие кода типами увеличилось на 20%. Также стали отслеживаются те ошибки, которые были проблемой для Flow.

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

#flow #typescript

https://medium.com/tech-quizlet/now-or-never-migrating-300k-loc-from-flow-to-typescript-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://t.me/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-javascript-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: -->
<script type="module" src="/js/app.mjs"></script>
<!-- Legacy browsers load this file: -->
<script defer nomodule src="/js/app.js"></script>

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

#js #performance #webpack

https://alistapart.com/article/responsible-javascript-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 #svg #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

Аксель Раушмайер в прошлом месяце написал неплохую статью о том, как работают глобальные переменные в JS — "How do JavaScript’s global variables really work?"

Перед объяснением нюансов работы с глобальными переменными в статье рассказывается, что такое область видимости (scope) и как она определяется на уровне спецификации. В спеке области видимости "реализуются" с помощью lexical environments, которые состоят из environment record (нечто похожее на словарь с ключами и значениями) и ссылки на внешний scope. Таким образом дерево вложенных друг в друга областей видимости представляется деревом связанных между собой lexical environments.

На самом верхнем уровне этого дерева находится "global environment", состоящий из двух компонент: "object environment record", который поддерживает связь с свойствами глобального объекта ( window / self в браузере и global в node.js), и "declarative environment record", который создаётся с помощью const, let, class. Эти части существуют независимо, что даёт возможность создавать биндинги с одинаковыми ключами в разных записях. При обращении к таким биндингам из кода будет побеждать declarative environment record. Если очень упростить, то можно сказать, что начиная со спецификации ES2015 в JavaScript появились два разных вида глобальных переменных.

Рекомендую почитать статью и посмотреть на примеры того, как это всё работает.

#specification #js #es2015

https://2ality.com/2019/07/global-scope.html

Хочу ещё разок написать про блог Акселя. Совсем недавно он опубликовал там статью про globalThis — "ES proposal: globalThis".

В прошлом посте рассказывалось о том, что в JS сейчас есть два вида глобальных переменных, один из которых определяется с помощью global object. В браузерах исторически для доступа к глобальному объекту использовался window. В веб воркерах для доступа к global object используют self, потому что window там недоступен. В node.js в свою очередь вместо window используется global. Для того чтобы унифицировать доступ к глобальному объекту в разных окружениях, в стандарт языка планируется добавить globalThis.

Предполагается, что новый идентификатор будет полезен при написании полифиллов и для определения наличия фич в JS-окружении. С помощью него также можно создавать "классические" глобальные переменные, но это не приветствуется, так как само по себе наличие global object считается ошибкой дизайна языка, от которого нельзя избавиться из-за обратной совместимости.

На данный момент globalThis находится на третьей стадии добавления в стандарт. Его поддержка уже есть в Firefox, Chrome и Safari.

#js #proposal

https://2ality.com/2019/08/global-this.html

Нашёл интересную статью Омара Шехата про работу с бинарными данными в браузере — "Binary data in the browser: Untangling an encoding mess with JavaScript Typed Arrays".

Омар кодил приложение для визуального создания полиритмов с возможностью загрузки полученной мелодии в виде midi-файла без использования бэкенда. Для генерации midi он использовал библиотеку jsmidgen, которая без проблем работала в node.js, но в браузере результат получался битым.

Сначала было предположение, что по каким-то причинам некорректно работал jsmidgen, но дебаг это не подтвердил. Потом автор предположил, что проблема возникает при передаче строки в Blob. Он принудительно перевёл каждый символ результата в uint8 с помощью типизированного массива, и это решило проблему. Далее в статье идёт детальный разбор того, почему первый подход к решению задачи был неудачным. Если говорить кратко, то проблема заключалась в том, что при передаче в Blob строка кодируется в UTF-8. В UTF-8 один символ может быть закодирован с помощью одного или двух байт.

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

#js #encoding #binary #midi

https://blog.logrocket.com/binary-data-in-the-browser-untangling-an-encoding-mess-with-javascript-typed-arrays-119673c0f1fe/