Гюёнг Ким в блоге 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