Джошуа Голдберг в своём блоге задокументировал процесс добавления новой фичи в TypeScript — "TypeScript Contribution Diary: // @ts-expect-error".
Джошуа добавил поддержку новой директивы
Хорошая статья. Рекомендую почитать статью всем, кому интересно узнать больше про внутренности TypeScript.
#internals #typescript
http://blog.joshuakgoldberg.com/ts-expect-error/
Джошуа добавил поддержку новой директивы
// @ts-expect-error в TypeScript 3.9. С её помощью можно подавить конкретные ошибки компилятора. В статье очень подробно рассказывается, как была добавлена эта фича, что было изменено, почему это было сделано именно так, с какими проблемами столкнулись пользователи после релиза RC-версии, какие были фиксы и т.п. Например, в начальной реализации для JSX не учитывался случай использования директивы игнорирования ошибок подобным образом:{/*
// @ts-ignore */}
<MissingRequiredProp />Хорошая статья. Рекомендую почитать статью всем, кому интересно узнать больше про внутренности TypeScript.
#internals #typescript
http://blog.joshuakgoldberg.com/ts-expect-error/
Joshuakgoldberg
TypeScript Contribution Diary: // @ts-expect-error | Goldblog
Adding a new comment directive to the TypeScript compiler.
Андрей Печкуров написал статью про внутреннее устройство 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
В 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
Medium
[V8 Deep Dives] Understanding Map Internals
ES6 introduced many built-in collections. We will try to understand Map implementation in V8 and make practical conclusions.
Крис Фоллин написал статью про новую архитектуру бэкенда 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/
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
Современные движки (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 наняли решить самые важные проблемы с флексами: исправить работу с
В статью стоит заглянуть, если хотите узнать подробнее о нюансах работы с flexbox.
#css #internals
https://blogs.igalia.com/svillar/2020/10/01/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 — написал статью про сложности имплементации свойства
Маниш разрабатывал Stylo — CSS-движок, написанный на Rust, который стал частью Firefox. Одной из его задач было добавление поддержки свойства
Проблема в том, что на размер шрифта влияют очень много факторов. Размер может быть задан разными юнитами и ключевыми словами. На него влияет выбранное семейство шрифтов, например,
Интересно, что в некоторых случаях разработчики не следуют полностью спецификации, а делают good enough приближение, потому что точно реализовать фичу по спеке бывает очень сложно.
В общем, хорошая статья. Рекомендую почитать всем, кто интересуется внутренней работой браузеров.
#css #internals #firefox #specification
https://manishearth.github.io/blog/2017/08/10/font-size-an-unexpectedly-complex-css-property/
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/
manishearth.github.io
font-size: An unexpectedly complex CSS property
font-size is the worst. It’s a CSS property probably everyone who writes CSS has used at some point. It’s pretty ubiquitous. And it’s super complicated. “But it’s just a number”, you say. “How can …
В 2016 году в набор команд ARM была добавлена операция, специально разработанная для работы с JS-движками, — "Armv8-A architecture: 2016 additions".
В JavaScript все числа представляются в формате чисел с плавающей запятой двойной точности, но при работе с битовыми операциями они преобразуются в 32-битные целые числа (в спецификации для этого используется
Можно сказать, что 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
В 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
Arm
Armv8-A: 2016 additions
The Arm v8-A architecture continues to evolve, with the additions developed through 2016 collectively known as Armv8.3-A. In this post we go through these in detail.
Буквально на днях выйдет новая версия 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/
В 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/
Mozilla Hacks – the Web developer blog
Warp: Improved JS performance in Firefox 83
We have enabled Warp, a significant update to SpiderMonkey, by default in Firefox 83. SpiderMonkey, the JavaScript engine used in the Firefox
Месяц назад проходила конференция для разработчиков виртуальных машин, на которой Вячеслав Егоров рассказал про историю развития языка программирования 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
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
YouTube
10 years of Dart
Slides (with speaker notes) https://mrale.ph/talks/vmil2020/
Dart (http://dart.dev) might be the only contemporary programming language that changed its core principles so radically between two major versions. 10 years ago, in 2010, it was born as a dynamically…
Dart (http://dart.dev) might be the only contemporary programming language that changed its core principles so radically between two major versions. 10 years ago, in 2010, it was born as a dynamically…
Матиас Байненс — разработчик 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
Результаты исследования 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
Chrome for Developers
Simulating color vision deficiencies in the Blink Renderer | Chromium | Chrome for Developers
Why and how we implemented color vision deficiency simulation in DevTools and the Blink Renderer.
В блоге 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
V8 по умолчанию использует регэксп-движок Irregexp, который в свою очередь использует алгоритм бэктрекинга для проверки паттернов регэкспов. Этот алгоритм может приводить к катастрофическим откатам (сatastrophic backtracking). Катастрофический откат — это ситуация, когда проверка регулярного выражения не может быть выполнена за разумное время из-за экспоненциального роста количества возможных вариантов, которые должны быть обработаны движком. Катастрофические откаты могут использоваться для совершения DOS-атак, когда web-сервис обрабатывает входные данные пользователей с помощью регулярных выражений.
В V8 версии v8.8 был добавлен новый экспериментальный движок, который не подвержен проблеме экспоненциального взрыва, но гораздо медленнее (на данный момент) Irregexp. Его можно включить с помощью экспериментальных флагов V8.
Довольно хардкорная статья. Рекомендую почитать всем, кто интересуется темой разработки браузеров и безопасностью.
#v8 #security #internals
https://v8.dev/blog/non-backtracking-regexp
v8.dev
An additional non-backtracking RegExp engine · V8
V8 now has an additional RegExp engine that serves as a fallback and prevents many instances of catastrophic backtracking.
Максим Садым из 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
При открытии 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
Chrome Developers
Improving DevTools startup time - Chrome Developers
Reduce DevTools performance overhead of message dispatch in the front-end.
Алекс Руденко из команды разработки Chrome DevTools написал статью про добавление поддержки редактирования стилей, создаваемых с помощью CSS-in-JS-библиотек — "CSS-in-JS support in DevTools".
Возможность редактирования CSS-in-JS стилей появилась в Chrome 85. Для поддержки редактирования стили должны быть представлены как статический текст. В случае с CSS-in-JS статического текста нет, так как такие стили размещаются в памяти во внутренней структуре данных CSSOM. Для добавления возможности редактирования их стали преобразовывать в текст. Для синхронизации мутируемых стилей был добавлен новый механизм, который оповещает бэкенд DevTools при изменении стилей с помощью CSSOM API.
Хорошая статья. Рекомендую почитать, если интересуетесь внутренней работой браузеров.
#internals #chrome #cssinjs
https://developers.google.com/web/updates/2021/02/css-in-js
Возможность редактирования CSS-in-JS стилей появилась в Chrome 85. Для поддержки редактирования стили должны быть представлены как статический текст. В случае с CSS-in-JS статического текста нет, так как такие стили размещаются в памяти во внутренней структуре данных CSSOM. Для добавления возможности редактирования их стали преобразовывать в текст. Для синхронизации мутируемых стилей был добавлен новый механизм, который оповещает бэкенд DevTools при изменении стилей с помощью CSSOM API.
Хорошая статья. Рекомендую почитать, если интересуетесь внутренней работой браузеров.
#internals #chrome #cssinjs
https://developers.google.com/web/updates/2021/02/css-in-js
Chrome for Developers
CSS-in-JS support in DevTools | Blog | Chrome for Developers
How we support CSS-in-JS in DevTools and how it is different from regular CSS.
Андрей Печкуров — участвует в разработке Node.js — написал статью про внутреннее устройство Math.random в V8 — "[V8 Deep Dives] Random Thoughts on Math.random()".
V8 использует генератор псевдослучайных чисел (PRNG), поставляемый окружением (Node.js, Chromium) или откатывается на системный источник случайности (например,
#js #v8 #internals #security
https://apechkurov.medium.com/v8-deep-dives-random-thoughts-on-math-random-fb155075e9e5
V8 использует генератор псевдослучайных чисел (PRNG), поставляемый окружением (Node.js, Chromium) или откатывается на системный источник случайности (например,
/dev/urandom в Linux), если он не был задан в окружении. После того как генератор был проинициализирован seed-значением, все последующие случайные числа генерируются детерминировано с помощью алгоритма xorshift128+ и сохраняются в пуле из 64 значений, который заполняется по мере необходимости. Использование пула заранее сгенерированных случайных чисел очень распространённый подход, который используется при реализации PRNG.Math.random не рекомендуется использовать для задач, связанных с безопасностью, потому что под капотом он не использует криптографически безопасный генератор псевдослучайных чисел (CSPRNG). Для таких задач вместо Math.random рекомендуется использовать генератор из Web Crypto API или модуля crypto в Node.js.#js #v8 #internals #security
https://apechkurov.medium.com/v8-deep-dives-random-thoughts-on-math-random-fb155075e9e5
Medium
[V8 Deep Dives] Random Thoughts on Math.random()
This blog post aims to go through V8’s internal implementation of Math.random() briefly, including security aspects of it.
Лин Кларк опубликовала статью, посвящённую оптимизации работы JavaScript-кода в WebAssembly-окружении — “Making JavaScript run fast on WebAssembly”.
Некоторые платформы ограничивают набор оптимизаций, которые могут быть применены к JavaScript-коду. Например, на iOS и игровых консолях нельзя использовать JIT-компилятор, поэтому JS-движки там могут работать только в режиме интерпретатора. Это ограничивает спектр задач, который может быть решён с помощью JS. Участники Bytecode Alliance (Fastly, Mozilla, Igalia) работают над решением на базе WebAssembly, которое позволит ускорить выполнение JS-кода на таких платформах и достичь уровня производительности JIT-компиляторов ранних версий JavaScript-движков.
В разрабатываемом решении в качестве первой оптимизации будет использоваться снапшот памяти, который позволит сократить время инициализации программы до нескольких микросекунд. В качестве второй оптимизации будет использоваться AOT-компиляция с генерацией стабов для внутренних кешей.
В статье говорится о том, что подобный подход может использоваться не только с JavaScript, но и с Python, Ruby, Lua.
#js #internals #webassembly
https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly
Некоторые платформы ограничивают набор оптимизаций, которые могут быть применены к JavaScript-коду. Например, на iOS и игровых консолях нельзя использовать JIT-компилятор, поэтому JS-движки там могут работать только в режиме интерпретатора. Это ограничивает спектр задач, который может быть решён с помощью JS. Участники Bytecode Alliance (Fastly, Mozilla, Igalia) работают над решением на базе WebAssembly, которое позволит ускорить выполнение JS-кода на таких платформах и достичь уровня производительности JIT-компиляторов ранних версий JavaScript-движков.
В разрабатываемом решении в качестве первой оптимизации будет использоваться снапшот памяти, который позволит сократить время инициализации программы до нескольких микросекунд. В качестве второй оптимизации будет использоваться AOT-компиляция с генерацией стабов для внутренних кешей.
В статье говорится о том, что подобный подход может использоваться не только с JavaScript, но и с Python, Ruby, Lua.
#js #internals #webassembly
https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly
Bytecode Alliance
Making JavaScript run fast on WebAssembly
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations.
Мэттью Гауде — разработчик SpiderMonkey — написал статью про опыт имплементации приватных полей класса в JavaScript-движке — "Implementing Private Fields for JavaScript".
Мэттью пишет о том, что при добавлении новой фичи в движок нужно учитывать три аспекта: ментальную модель, спецификацию и реализацию. Иногда они совпадают друг с другом, и имплементация сводится к пошаговой реализации алгоритма из спецификации. Иногда они расходятся, и имплементация начинает сильно отличаться от спецификации, сохраняя только семантику. Реализация приватных полей попала во вторую категорию.
Также в статье разбираются нюансы работы c приватными полями. Оказывается, приватные поля могут быть добавлены к любому объекту, даже если он был явно закрыт от изменений с помощью
Очень интересная статья. Рекомендую почитать.
#js #internals #spec #firefox
https://www.mgaudet.ca/technical/2021/5/4/implementing-private-fields-for-javascript
Мэттью пишет о том, что при добавлении новой фичи в движок нужно учитывать три аспекта: ментальную модель, спецификацию и реализацию. Иногда они совпадают друг с другом, и имплементация сводится к пошаговой реализации алгоритма из спецификации. Иногда они расходятся, и имплементация начинает сильно отличаться от спецификации, сохраняя только семантику. Реализация приватных полей попала во вторую категорию.
Также в статье разбираются нюансы работы c приватными полями. Оказывается, приватные поля могут быть добавлены к любому объекту, даже если он был явно закрыт от изменений с помощью
Oblect.seal(). Насколько я понимаю, это "побочный эффект" спецификации, и его не стоит использовать для решения своих задач.Очень интересная статья. Рекомендую почитать.
#js #internals #spec #firefox
https://www.mgaudet.ca/technical/2021/5/4/implementing-private-fields-for-javascript
Matthew Gaudet
Implementing Private Fields for JavaScript — Matthew Gaudet
Браузер. Рендеринг. Производительность
Второй год я помогаю с поиском спикеров на CodeFest — крупнейшая конференция за Уралом. В прошлом году у нас выступал Сергей Ufocoder — автор канала @ufostation — с докладом "Браузер. Рендеринг. Производительность".
В докладе рассказывается о производительности рендеринга в Chromium с точки зрения архитектуры браузера. Подробно объясняется работа пайплайна рендеринга на примере
Доклад немного хардкорный, но полезный. Рекомендую посмотреть.
#performance #chromium #internals #talks
https://www.youtube.com/watch?v=tbDxm1hiEI4
Второй год я помогаю с поиском спикеров на CodeFest — крупнейшая конференция за Уралом. В прошлом году у нас выступал Сергей Ufocoder — автор канала @ufostation — с докладом "Браузер. Рендеринг. Производительность".
В докладе рассказывается о производительности рендеринга в Chromium с точки зрения архитектуры браузера. Подробно объясняется работа пайплайна рендеринга на примере
about://tracing и профилировки страниц с помощью вкладки Performance в DevTools. Рассматриваются несколько случаев оптимизации производительности с объяснением, почему это работает именно так. При подготовке доклада Сергей консультировался с официальной документацией Chromium и с разработчиками браузера.Доклад немного хардкорный, но полезный. Рекомендую посмотреть.
#performance #chromium #internals #talks
https://www.youtube.com/watch?v=tbDxm1hiEI4
YouTube
Сергей Ufocoder Иванов. Браузер. Рендеринг. Производительность
При погружении в тему производительности разработчик может ступить на ложный путь, который, возможно, и позволит решить некоторые проблемы, связанные со скоростью отрисовки, но будет бесполезен при решении других проблем.
В данном докладе мы пройдём с вами…
В данном докладе мы пройдём с вами…
Возможно, вам не нужен Rust и WASM, если у вас есть JavaScript
Увидел в канале @ufostation ссылку на статью Вячеслава Егорова про анализ проблем производительности библиотеки source-map — "Maybe you don't need Rust and WASM to speed up your JS".
Авторы source-map переписали основную логику библиотеки на Rust и WebAssembly, чтобы улучшить производительность. Егор решил проверить оригинальный код на предмет возможных оптимизаций. Там были найдены и исправлены проблемы, связанные с неоптимальной сортировкой, была уменьшена нагрузка на сборщик мусора заменой большого числа объектов типизированным массивом с ссылками на нужные данные, была испралвена проблема с деоптимизацией кода, связанной с передачей двух аргументов в функцию, которая ожидает на вход три аргумента.
В результате всех оптимизаций JavaScript-код стал уступать по скорости Rust и WebAssembly всего лишь на 15%.
Крутая статья. Рекомендую почитать всем.
#performance #js #internals #webassembly #rust
https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html
https://habr.com/ru/post/350018/ (перевод на русский)
Увидел в канале @ufostation ссылку на статью Вячеслава Егорова про анализ проблем производительности библиотеки source-map — "Maybe you don't need Rust and WASM to speed up your JS".
Авторы source-map переписали основную логику библиотеки на Rust и WebAssembly, чтобы улучшить производительность. Егор решил проверить оригинальный код на предмет возможных оптимизаций. Там были найдены и исправлены проблемы, связанные с неоптимальной сортировкой, была уменьшена нагрузка на сборщик мусора заменой большого числа объектов типизированным массивом с ссылками на нужные данные, была испралвена проблема с деоптимизацией кода, связанной с передачей двух аргументов в функцию, которая ожидает на вход три аргумента.
В результате всех оптимизаций JavaScript-код стал уступать по скорости Rust и WebAssembly всего лишь на 15%.
Крутая статья. Рекомендую почитать всем.
#performance #js #internals #webassembly #rust
https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html
https://habr.com/ru/post/350018/ (перевод на русский)
Хабр
Возможно, вам не нужен Rust, чтобы ускорить ваш JS
Несколько недель назад я обнаружил пост "Окисляем Source Maps с Rust и WebAssembly" распространяющийся по Твиттеру и расказывающий о выигрыше в производительности от замены обычного JavaScript в...
👍41🔥9
Новое дерево доступности в Chrome DevTools
Йохан Бей из команды разработки Chrome DevTools рассказал про новое дерево доступности, которое появится в будущих версиях Chrome — "Full accessibility tree in Chrome DevTools".
С помощью дерева доступности скринридеры и другие технологии доступности предоставляют средства для работы со страницей. В Chrome 97 и ниже дерево доступности в один момент времени может отображать только выбранный элемент и его потомков. В новой версии Chrome дерево будет отображаться для всей страницы сразу, упрощая поиск элементов, которые недоступны скринридерам. Обновлённое дерево также позволит реализовать новые функции и инструменты для решения проблем доступности.
Новое дерево доступности пока доступно только в Chrome Canary.
#debug #a11y #internals #devtools
https://developer.chrome.com/blog/full-accessibility-tree/
Йохан Бей из команды разработки Chrome DevTools рассказал про новое дерево доступности, которое появится в будущих версиях Chrome — "Full accessibility tree in Chrome DevTools".
С помощью дерева доступности скринридеры и другие технологии доступности предоставляют средства для работы со страницей. В Chrome 97 и ниже дерево доступности в один момент времени может отображать только выбранный элемент и его потомков. В новой версии Chrome дерево будет отображаться для всей страницы сразу, упрощая поиск элементов, которые недоступны скринридерам. Обновлённое дерево также позволит реализовать новые функции и инструменты для решения проблем доступности.
Новое дерево доступности пока доступно только в Chrome Canary.
#debug #a11y #internals #devtools
https://developer.chrome.com/blog/full-accessibility-tree/
Chrome for Developers
Full accessibility tree in Chrome DevTools | Blog | Chrome for Developers
Review the new, full-page accessibility tree in DevTools, as well as the design and implementation of this tree.
👍7
React server components под капотом
Чан Ву рассказал про внутреннее устройство React server components (RSC) — "How React server components work: an in-depth guide".
Серверные компоненты — это экспериментальный тип React-компонентов, которые не попадают в клиентский бандл и позволяют бесшовно выносить на сервер часть логики приложения. Результатом выполнения серверных компонентов является представление дерева React-компонентов в формате, подходящем для стриминга. В статье подробно разбирается принцип работы RSC, их ограничения и внутреннее устройство.
Статья хорошая. Рекомендую почитать всем, кто хочет разобраться в устройстве серверных компонентов.
#react #internals
https://blog.plasmic.app/posts/how-react-server-components-work/
Чан Ву рассказал про внутреннее устройство React server components (RSC) — "How React server components work: an in-depth guide".
Серверные компоненты — это экспериментальный тип React-компонентов, которые не попадают в клиентский бандл и позволяют бесшовно выносить на сервер часть логики приложения. Результатом выполнения серверных компонентов является представление дерева React-компонентов в формате, подходящем для стриминга. В статье подробно разбирается принцип работы RSC, их ограничения и внутреннее устройство.
Статья хорошая. Рекомендую почитать всем, кто хочет разобраться в устройстве серверных компонентов.
#react #internals
https://blog.plasmic.app/posts/how-react-server-components-work/
Plasmic Blog
How React server components work: an in-depth guide
A deep dive exploration of React server components under the hood.
👍34👎1