Гюёнг Ким в блоге Igalia рассказал про новую систему межпроцессорного взаимодействия Chromium — "How Chromium Got its Mojo?".

Chromium использует мультипроцессорную архитектуру для безопасности и устойчивости к сбоям. Внутри него работают разные процессы: renderer process, browser process, GPU process, utility process и т.п. Для общения между процессами используется IPC (Inter-process Communication). Команда Chromium решила отказаться от IPC и разбить браузер на большое количество маленьких сервисов. Для этого был разработан Mojo.

Mojo — это фреймворк для взаимодействия между процессами внутри браузера. Он отвечает за доставку сообщений между процессами и позволяет интегрировать большое количество компонентов без необходимости их линковки, сокращая время сборки и упрощая работу с частями кода, написанными на C++, Java, JavaScript. На данный момент идёт активная работа над миграцией кода, использующего Chromium IPC, на Mojo.

Если интересуетесь техническими деталями работы браузеров, то очень рекомендую заглянуть в статью.

#internals #chromium

https://blogs.igalia.com/gyuyoung/2020/05/11/how-chromium-got-its-mojo/

Increment — журнал про разработку — в этом месяце был полностью посвящён фронтенду. Там много постов от разработчиков из мира фронтенда. Среди них есть статья Эвана Ю "The process: Making Vue 3", где он рассказывает про разработку Vue 3 и особенности его работы.

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

Из статьи узнал, что первые прототипы были написаны с использованием Flow, но команде приходилось поддерживать тайпинги для TS, которые были востребованы гораздо больше чем Flow-тайпинги. В итоге от Flow отказались в пользу TypeScript. Ещё в статье есть интересные технические детали работы Vue 3. В новой версии компилятор шаблонов был полностью переписан. В его основу лёг пайплайн на базе AST-трансформаций, который позволил компоновать оптимизации времени компиляции в виде плагинов трансформаций. Статический анализ шаблонов и новая архитектура позволили ускорить работу с Virtual DOM до 10 раз в бенчмарках рендеринга.

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

#vue #internals #history #jsframeworks

https://increment.com/frontend/making-vue-3/

Мэттью Виплайз написал статью про генерацию UUID на клиенте — "Generating UUIDs at scale on the Web".

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

Для генерации UUID рассматривались два варианта: Web Crypto API и URL.createObjectURL(). Остановились на последнем, так как для надёжного использования Web Crypto API требовалась инициализация кода в веб-воркере, из-за этого просаживалась скорость. Перед тем как внедрить новое решение был проведён A/B-тест, чтобы удостовериться, что нет коллизий при генерации UUID. Данные показали примерно пять коллизий на один миллион запросов. Это было гораздо больше чем в теории. Исследования показали, что основная проблема была в гугл-боте, меньшая часть проблем была связана с браузером в PS Vita и .Net-конверторами html в pdf.

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

#cryptography #internals

https://medium.com/teads-engineering/generating-uuids-at-scale-on-the-web-2877f529d2a2

Джошуа Голдберг в своём блоге задокументировал процесс добавления новой фичи в TypeScript — "TypeScript Contribution Diary: // @ts-expect-error".

Джошуа добавил поддержку новой директивы // @ts-expect-error в TypeScript 3.9. С её помощью можно подавить конкретные ошибки компилятора. В статье очень подробно рассказывается, как была добавлена эта фича, что было изменено, почему это было сделано именно так, с какими проблемами столкнулись пользователи после релиза RC-версии, какие были фиксы и т.п. Например, в начальной реализации для JSX не учитывался случай использования директивы игнорирования ошибок подобным образом:

{/*
// @ts-ignore */}
<MissingRequiredProp />

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

#internals #typescript

http://blog.joshuakgoldberg.com/ts-expect-error/

Андрей Печкуров написал статью про внутреннее устройство Map в V8 — "[V8 Deep Dives] Understanding Map Internals".

В V8 для Map используется детерминированная хэш-таблица (deterministic hash table) — структура данных, которая гарантирует порядок обхода хранящихся в ней значений (в порядке их добавления в Map). Все данные для организации структуры данных находятся в одном большом массиве, который поделён на три логические части: заголовок, хэш-таблицу и данные. При добавлении и удалении значений из Map алгоритм периодически создаёт новую таблицу, поэтому операции вставки и удаления могут иметь временную сложность O(N). Операция извлечения данных из Map работает за O(1).

Интересная статья. Рекомендую почитать, если интересуетесь тем, как работает V8 изнутри.

#internals #v8 #algorithm

https://itnext.io/v8-deep-dives-understanding-map-internals-45eb94a183df

Крис Фоллин написал статью про новую архитектуру бэкенда Cranelift — "A New Backend for Cranelift, Part 1: Instruction Selection".

Cranelift — это фреймворк для компиляторов, написанный на Rust. По своему дизайну он похож на llvm: фронтенд часть отвечает за преобразование кода в промежуточное представление (IR), бэкенд часть — за компиляцию IR в исполняемый код целевой платформы. Cranelift используется в Firefox для компиляции wasm. Также он используется в качестве компилятора в wasmtime — обособленном рантайме для WebAssembly.

Старая архитектура бэкенда Cranelift была сложна для добавления новых фич. Также нельзя было скомпилировать последовательность из нескольких команд IR в одну команду (отношение "многие к одному"). Новая архитектура решает эти проблемы.

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

#firefox #internals #wasm

https://cfallin.org/blog/2020/09/18/cranelift-isel-1/

Вчера, когда писал пост про Indicium, в ссылках увидел очень интересную статью Матиаса Байненса и Бенедикта Мюрера про концепции, которые используются при создании всех современных JS-движков — "JavaScript engine fundamentals: Shapes and Inline Caches".

Современные движки (V8, SpiderMonkey, JavaScriptCore, Chakra) преобразуют абстрактное синтаксическое дерево программы в байткод, который исполняется интерпретатором. Во время исполнения программы собирается дополнительная информация, на основе которой оптимизирующий компилятор преобразует байткод в машинный код. В разных движках этот пайплайн компиляции/интерпретации уникален. В V8 есть один оптимизирующий компилятор (TurboFan), в SpiderMonkey два (Baseline, Ion Monkey), в JavaScriptCore три (Baseline, DFG, FTL).

При работе с объектами движки тоже похожи друг на друга. При создании объекта в памяти, они сохраняют структуру объекта в скрытый класс, который в разных движках называется по-разному (Map, Shape, Type, Structure). Благодаря использованию скрытых классов происходит экономия оперативной памяти и становится возможна оптимизация "Inline Cache" для быстрого доступа к свойствам объекта.

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

Интересная статья. Очень рекомендую почитать всем, кто интересуется внутренним устройством JS-движков.

#js #internals

https://mathiasbynens.be/notes/shapes-ics

Серджио Виллар в блоге Igalia написал пост о том, как они исправляли в WebKit проблемы с flexbox — “Closing the gap (in flexbox)”.

В WebKit накопилось большое количество проблем, связанных с flexbox. Много тестов из Web Platform Test не проходило. Ребят из Igalia наняли решить самые важные проблемы с флексами: исправить работу с min-width:auto и min-height:auto, исправить поведение flexbox-элементов внутри таблиц и наоборот, исправить проблемы с обработкой высоты, заданной в процентах, для контейнеров с неограниченными размерами. Среди самых важных изменений было добавление поддержки свойства gap. В статье разбираются наиболее интересные примеры неправильного поведения flexbox’ов в WebKit.

В статью стоит заглянуть, если хотите узнать подробнее о нюансах работы с flexbox.

#css #internals

https://blogs.igalia.com/svillar/2020/10/01/closing-the-gap-in-flexbox/

Маниш Горегаокар — разработчик Servo — написал статью про сложности имплементации свойства font-size — "Font-size: An Unexpectedly Complex CSS Property".

Маниш разрабатывал Stylo — CSS-движок, написанный на Rust, который стал частью Firefox. Одной из его задач было добавление поддержки свойства font-size.

Проблема в том, что на размер шрифта влияют очень много факторов. Размер может быть задан разными юнитами и ключевыми словами. На него влияет выбранное семейство шрифтов, например, font-size: medium в рубленных шрифтах это 16 пикселей, а в моноширинных шрифтах — 13 пикселей. Также Firefox (из коробки) и Chrome (с помощью расширения) позволяют задавать размер шрифта в зависимости от текущего языка текста. Есть свои нюансы для задания размеров шрифта в MathML и при его использовании c аннотациями ruby.

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

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

#css #internals #firefox #specification

https://manishearth.github.io/blog/2017/08/10/font-size-an-unexpectedly-complex-css-property/

В 2016 году в набор команд ARM была добавлена операция, специально разработанная для работы с JS-движками, — "Armv8-A architecture: 2016 additions".

В JavaScript все числа представляются в формате чисел с плавающей запятой двойной точности, но при работе с битовыми операциями они преобразуются в 32-битные целые числа (в спецификации для этого используется ToInt32 ). Битовые операции относительно часто используется в JS-коде, поэтому для ускорения таких преобразований в набор команд архитектуры Armv8 была добавлена новая команда FJCVTZS.

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

#js #internals

https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/armv8-a-architecture-2016-additions
https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs

Буквально на днях выйдет новая версия Firefox. В неё попадут изменения с улучшением работы JS-движка SpiderMonkey. Обо всех подробностях рассказал Ян дер Моой в статье "Warp: Improved JS performance in Firefox 83".

В SpiderMonkey используется два уровня компиляции кода: Baseline JIT для быстрой генерации байткода с минимальным количеством оптимизаций и Ion для генерации оптимизированного байткода. Ion в Firefox 83 будет заменён на новый оптимизирующий JIT-компилятор Warp. Warp в отличие от Ion не использует глобально собираемую информацию о типах и использует формат представления байткода CacheIR, которое используется в Baseline JIT.

Благодаря этим изменениям удалось ускорить выполнение JS-кода и уменьшить потребление памяти. Google Docs с Warp работает на 20% быстрее, бенчмарк Speedometer — на 10-12% быстрее. Firefox с Warp потребляет примерно на 8% меньше памяти по сравнению с Ion.

Новая архитектура упростила кодовую базу. Теперь разработчикам SpiderMonkey гораздо проще добавлять новые оптимизации и фичи.

#performance #firefox #internals

https://hacks.mozilla.org/2020/11/warp-improved-js-performance-in-firefox-83/

Месяц назад проходила конференция для разработчиков виртуальных машин, на которой Вячеслав Егоров рассказал про историю развития языка программирования Dart — "10 Years of Dart".

Dart начал разрабатываться инженерами Google в 2011 году. Первая версия не была статически типизируемой в обычном смысле, в ней была поддержка опциональных типов, и все оптимизации выполнялись на уровне JIT-компилятора (то есть во время выполнения кода). В 2015 году с появлением Flutter текущая имплементация языка не могла обеспечить хорошую производительность на iOS, потому что Apple запрещает использовать JIT-компиляцию в обычных программах. Команда Dart попыталась реализовать AOT-компиляцию (то есть до этапа выполнения кода) на базе существующего JIT-компилятора, но столкнулась с проблемами. Для решения этих проблем Dart должен был стать полноценным статически типизируемым языком. Над второй мажорной версией разработчики работали три года — Dart 2.0 зарелизился в 2018 году.

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

#dart #history #internals #talk

https://www.youtube.com/watch?v=e-58C8aGBM4

Матиас Байненс — разработчик V8 и Chrome — написал статью о том, как была реализована симуляция недостатков зрения в Chrome DevTools — "Simulating color vision deficiencies in the Blink Renderer".

Результаты исследования WebAIM говорят о том, что контраст текста — самая распространённая проблема доступности сайтов. Вы скорее всего встречали его упоминание в DevTools или Lighthouse и с большой вероятностью удивлялись тому, что эти инструменты жаловались на плохой контраст, в то время как вы могли легко всё прочитать. Дело в том, что анализ контраста включает в себя разные особенности восприятия цвета: кто-то не видит красный цвет, кто-то зелёный и т.п.

Для реализации симуляции недостатков зрения разработчики сделали прототип на обычных web-технологиях. Для этого они воспользовались SVG-фильтром на root-элементе. В этом фильтре описывается преобразование цветов на основе научной работы "A Physiologically-based Model for Simulation of Color Vision Deficiency". Чтобы не внедрять на страницу лишние элементы, решение с SVG было перенесено в движок браузера.

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

#a11y #internals #chrome

https://developers.google.com/web/updates/2020/11/cvd

В блоге V8 Мартин Бидлингмайер опубликовал статью про новый вспомогательный движок регэкспов, который позволяет избежать катастрофических откатов — "An additional non-backtracking RegExp engine".

V8 по умолчанию использует регэксп-движок Irregexp, который в свою очередь использует алгоритм бэктрекинга для проверки паттернов регэкспов. Этот алгоритм может приводить к катастрофическим откатам (сatastrophic backtracking). Катастрофический откат — это ситуация, когда проверка регулярного выражения не может быть выполнена за разумное время из-за экспоненциального роста количества возможных вариантов, которые должны быть обработаны движком. Катастрофические откаты могут использоваться для совершения DOS-атак, когда web-сервис обрабатывает входные данные пользователей с помощью регулярных выражений.

В V8 версии v8.8 был добавлен новый экспериментальный движок, который не подвержен проблеме экспоненциального взрыва, но гораздо медленнее (на данный момент) Irregexp. Его можно включить с помощью экспериментальных флагов V8.

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

#v8 #security #internals

https://v8.dev/blog/non-backtracking-regexp

Максим Садым из Google написал небольшой пост о том, как было ускорено открытие DevTools в Chrome 85 — "Improving DevTools startup time".

При открытии DevTools, браузеру нужно выполнить код с помощью V8. Этот код сериализовывался в строку, которая на стороне V8 выполнялась с помощью eval. Оказалось, что от сериализации можно было избавиться. Для этого был добавлен новый метод в API mojo (механизм, который используется Chromium для передачи команд из DevTools в V8). Благодаря этой оптимизации время старта DevTools сократилось на 13% (с 11,2 до 10 секунд).

Рекомендую заглянуть в статью, если интересуетесь темой разработки браузеров.

#chromium #internals

https://developers.google.com/web/updates/2021/02/faster-devtools-startup