https://ispring-tech-event.timepad.ru/event/3332560/

Буду сегодня выступать! Трансляция есть, запись потом тоже будет.

Это случилось, реакт добавил новое апи Activity, которое в проде может ремаунтить ваши компоненты сохраняя их состояния. Это значит, что поведение StrictMode, которое многих бесило и его отключали, теперь из дева пришло в прод.

Что могу сказать. Концепция - отличная! Это очень хорошая оптимизация перфа SPA - вместо того что бы полностью ремаунтить страницы при навигации, просто скрывать не актуальные. Это значительно(!) улучшает UX и из-за уменьшения лага, и из-за сохранения состояния, т.е. в некоторых случаях избежания избыточных (повторных) лоадеров.

Но есть у этого подхода чисто реактовская проблема. Для нормального управления лайфсайклом состояния (в общем смысле) нам необходимы методы его синхронного создания при первом рендере и уничтожения при настоящем анмаунте, а не временном. А этих апи нет. Описывал пример проблемы тут: https://t.me/artalog/1291

Встречаются два спикера на конференции
- Как использовать FSD?
- Могу рассказать.
- Рассказать я и сам могу, а как использовать??

Простите...

True vibe coding

Стек: Roo, openrouter, Sonet для Architect и Boomerang, Flash для Code.

AMA vibe coding

Пробуйте, оставляйте фидбек!

Уточню, ссылка на ютуб: https://www.youtube.com/watch?v=WYHC4bT2E-4

База с 02:50 до 06:40.

А если хочется чего-то поинтересней, вот как делается простое расширение для персиста, которое можно потом использовать на любом атоме:

const withLocalStorage =
(key?: string): GenericExt =>
(target) =>
target.extend(
withInit((state) => {
let snapshot = localStorage.getItem(key ?? target.name)
return snapshot ? JSON.parse(snapshot) : state
}),
withChangeHook((state) => {
localStorage.setItem(key ?? target.name, JSON.stringify(state))
}),
)

const search = atom('', 'search').extend(withLocalStorage())
const page = atom(0, 'page').extend(withLocalStorage())

Reatom@1000

Друзья, вариантов больше нет, вопрос стейт менеджмента закрыт раз и навсегда, я серьезно!

Приглашаю всех к тестированию новой альфа версии реатома ❤️

npm i @reatom/core@alpha @reatom/react@alpha

Это стейт менеджер для всех! Просто начать! Надежно и безопасно развивать код до небывалых масштабов. Все быстро, продумано, типобезопасно, LLM френдли и так далее и так далее🤠

https://www.youtube.com/watch?v=WYHC4bT2E-4

02:50 смотрим новое апи
06:40 реалистичный пример
09:50 wrap из tc39/proposal-async-context и проблема SSR
18:28 проблемы императивного кода
23:44 экосистема и .extend

- попробовать пример в репле
- код примера
- документаия (сайт в разработке)
- быстрый старт для LLM
- дока для react пакета
- почему ТЫСЯЧА

Лайк, шер, репост!

Вот уже пару дней как я работаю на новом Apple MacBook Air 15' M4 24GB Sky Blue и как же это хорошо...

Все эти виндусы и линуксы намного менее предсказуемые. Железо и софт могут работать на 95% хорошо, но только мак дает "99% хорошо", и эта небольшая разница в фактических цифрах, которая включает общее качество подгонки всего и возможный оверхед на ручное обсуживание каких-то недоработок, в эмоциональном плане ощущается не как пятипроцентная разница, а 2-3 кратная разница.

Причем, если у вас нет задач постоянно что-то комплилить или держать локально мощные ЛЛМ, я очень рекомендую именно air. У него и цена безальтернативная, и мощность на грани возможного, и опыт использования более мягкий, как бы, потому что тротлинг тут, в крайнем случае, не скачкообразный а более плавный. Напомню, у air вовсе нет кулера, что делает его абсолютно тихим всегда, и лично я другими лептопами без этой фичи (т.е. всеми) пользуюсь с неприязнью.

Я понимаю людей которым больше подходит вин или линь, но если вы сомневаетесь - эир безальтернативный компьютер.

Вот уже пару дней как я работаю на новом Apple MacBook Air 15' M4 24GB Sky Blue и как же это хорошо...

Все эти виндусы и линуксы намного менее предсказуемые. Железо и софт могут работать на 95% хорошо, но только мак дает "99% хорошо", и эта небольшая разница в фактических цифрах, которая включает общее качество подгонки всего и возможный оверхед на ручное обсуживание каких-то недоработок, в эмоциональном плане ощущается не как пятипроцентная разница, а 2-3 кратная разница.

Причем, если у вас нет задач постоянно что-то комплилить или держать локально мощные ЛЛМ, я очень рекомендую именно air. У него и цена безальтернативная, и мощность на грани возможного, и опыт использования более мягкий, как бы, потому что тротлинг тут, в крайнем случае, не скачкообразный а более плавный. Напомню, у air вовсе нет кулера, что делает его абсолютно тихим всегда, и лично я другими лептопами без этой фичи (т.е. всеми) пользуюсь с неприязнью.

Я понимаю людей которым больше подходит вин или линь, но если вы сомневаетесь - эир безальтернативный компьютер.

Составил список открытых пропоузалов TC39 и соответствующих подходов в Effect — как по мне впечатляет. Особенно первый пункт:

• Async Context — R-channel & Context.Reference
• TS throws annotation — E-channel & expected errors
• Record & Tuple — Data module
• Composite — Equal trait
• Async Iterator helpers — Stream
• Explicit Resource Management — Scope
• pipeline operator — pipe function
• do-notation — Effect.Do | Effect.gen

Но более того — имплементация в Effect гораздо более композабельная и типобезопасная.

Я тут постарался запилить реально сложный, а точнее разнообразный бенч динамических переподписок. Он проверяет 6 разных паттернов изменения порядка зависимостей реактивного компьютеда. Результаты (больше - лучше, т.е. 100% - эталон):

MEDIAN for 128,64,64,32,32,32,16,16,16,16,8,8,8,8,8,8,4,4,4,4,4,4,4,4,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 subscribers

25% Reatom
40% mobx
42% $mol_wire
66% act
98% alien

https://github.com/reatom/reatom/blob/v1000/packages/core/bench_dynamic.ts#L749

Что, зачем я написал бенч, в котором моя либа на самом дне?)) Потому что объективность и совместная работа намного дороже личных побед ❤️

alien-signals - действительно сделали прорыв в перфе и это круто! Такие библиотеки и их авторы двигают всю нашу экосистему.

Хотя, свое решение я все же позащищаю. Что тормозит в реатоме? Строго говоря все. Он весь пропитан дополнительными фичами, которые его замедляют:

- система расширений
- виртуализация (контекст для тестов и ssr)
- иммутабельность для асинхронного контекста (отменить нельзя продолжить)

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

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

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

P.S. любой бенч можно повернуть в нужную сторону, если захотеть :D
MEDIAN for 1024 subscribers
40% alien
51% mobx
57% Reatom
58% act
90% $mol_wire

В react-router-typed-object добавлена поддержка типизированных хуков для отдельных роутов!

Напомню, в отличии от тенстак роутера и рр7, эта библиотека намного легче и не заставляет вас запускать сервис кодогенерации или придумывать особенное АПИ для типизированных роутов. Эта либа выводит все нужные типы сама из обычного конфига рр!

У меня на проекте файл с конфигом роутов в 2к строк, ниче не лагает :)

Качественные библиотеки делать очень сложно. Но и очень интересно 😊

UPD: получить поддержку вывода типов через // ^? можно в vscode через https://marketplace.visualstudio.com/items?itemName=Orta.vscode-twoslash-queries

Забыл объявить победителя. Им, конечно, стал @lekzd с https://t.me/korotaev_to_hard/105 спасибо!

Еще из новостей, Reatom переехал в свою организацию на гитхабе https://github.com/reatom/reatom !

Скоро будет очень большой анонс 😉

Однако для JS движка создать новый массив нередко быстрее, чем поменять существующий, так как в существующем уже накоплена информация о типах элементов и это может приводить к дополнительным проверкам и действиям, спаливать выполнение в медленные пути.

Но проблема не только в этом, а в том что меняется свойство length. Даже если массив будет изначально пустой (если задать size = 0 в тесте), разница все равно будет существенной (на моей машине Length в 10 раз медленее для size = 0). Это говорит о том, что скорей всего установка значения свойству length не оптимизируется, так как считается редким кейсом (в действительности это редко применяется). Если поиграться с опцией --max-opt для Nodejs, то можно заметить, что при отключении оптимизирующих компиляторов (--max-opt=1) время для Immutable вырастает в разы, а вот для Length на несколько десятков процентов – что поддерживает гипотезу.

Что интересно, если поменять другое свойство у массива, то есть не length, а скажем array[j].foo = 1 – то время тратится существо меньше.

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

Вот так и рождаются мифы о том как работают JS движки 🙂

> array.length = 0 не просто удаляет элементы, а изменяет capacity массива, т.е. дефрагментирует выделенный под него кусок памяти. Важно, что происходит это синхронно, т.к. ссылка на массив меняться не должна и сразу для всего пользовательского кода должна выдавать новый вариант массива.

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

Дефрагментация про другое – это процесс переукладки используемых фрагментов памяти более компактно, обычно в начало спейса, так чтобы свободная часть была представлена одним фрагментом. Процесс не применяет к объектам точечно, но применяется к области памяти (спейсу). В V8 этот процесс называется compat и является частью Major GC, одним из финальных его этапов. Так как процесс недешевый (нужно не только перенести много памяти с одного места в другое, но и обновить все ссылки, то есть прописать новые адреса), то он выполняется не на каждый Major GC, а только когда в этом действительно есть необходимость. При этом, "дефрагментация" осуществляется не для всех спейсов, в основном для старого поколения, и для некоторых других (например, large object space). Для молодого поколения необходимости в дефрагментации нет, так как когда заканчивается память в этом спейсе, то срабатывает Minor GC – из него эвакуируются выжившие объекты (переносятся во вторую молодую или в старую), а сам спейс зачищается и начинает наполняться заново, объектами которые создаются.

Массив это не монолит - он представляет из себя несколько объектов. "Входной точкой" является объект JS Array (типичный JS объект), под капотом опционально elements (массив значений фиксированной длины - fixed array) и другие объекты (например, для хранения собственных свойств, когда делается array.foo = 1). У массива действительно есть capacity, а именно свойство хранящее число используемых слотов в elements, так как elements может быть больше чем используется (обычно выделяется с запасом, чтобы не пересоздавать elements на каждый добавляемый элемент). Если размера не хватает, то создается новый fixed array большей длины, поле elements меняется на него - со старого ссылка снимается и он может быть собран GC. Таким образом, при изменении длины массива (в том числе через length), движку не нужно обновлять ссылки на массив, так как другие объекты ссылаются на JS Array, а его адрес сохраняется (адрес меняется только при миграции между спейсами и при "дефрагментации"). Свойство elements является внутренним, и к нему нет доступа из JS.

В V8 случай array.length = 0 обычно обрабатывается отдельно, в этом случае создается пустой elements (https://github.com/v8/v8/blob/2ff8d15b64f4840a1987b005fddaadb7b6fb87ae/src/objects/elements.cc#L1578). Почему "обычно", потому что в V8 (и других движках) есть множество внутренних типов для elements (по сути самого массива), в зависимости от того какие в нем хранятся значения и есть ли "дырки" (типы: https://github.com/v8/v8/blob/2ff8d15b64f4840a1987b005fddaadb7b6fb87ae/src/objects/elements-kind.h#L105). От типа elements зависит внутреняя логика и, в частности, применяемые оптимизации. Так массив чисел и массив объектов могут иметь совсем разные профили.

> А при array = [] старый массив может быть обработан сборщиком мусора асинхронно, а может даже и параллельно.

С точки зрения механики управления памятью (в плане сборки мусора, ее синхронности и т.д.), в обоих случаях разницы не будет. Разве что при создании нового массива будет создавать больше объектов (новые JS Array), которые позже могут эвакуироваться из молодой памяти – поэтому GC будет немного медленней, но в данном случае незначительно так как сами объекты крохотные.

Прожарили https://t.me/artalog/1604 :)
Спасибо @gorshochekvarit!

Вангую "скин" для переносного ЛЛМ в виде волейбольного мяча.

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

Пять самых явных описаны в 8.1.7.4 Generic task sources. Хотя, скорее всего, их больше.

Самое главное в этом то что приоритет обработки разных task source в спецификации не описан, а остается на усмотрение UA (User Agent, т.е. среда выполнения, т.е. браузер).

Накидал простенькие тесты для наглядности: https://stackblitz.com/edit/task-sources-test?file=index.html

Следующая версия реатома практически готова и это будет самая простая и самая эффективная (фичастая) библиотека для работы с сотсояниями и эффектами.

И это НЕ шутка на первое апреля 🙂

Как быстрее очистить массив, обнулив его или пересоздав? Например, queue.length = 0 или queue = []?

Спасибо @cevek, он предоставил тесты и их объяснение:

array.length = 0 не просто удаляет элементы, а изменяет capacity массива, т.е. дефрагментирует выделенный под него кусок памяти. Важно, что происходит это синхронно, т.к. ссылка на массив меняться не должна и сразу для всего пользовательского кода должна выдавать новый вариант массива. А при array = [] старый массив может быть обработан сборщиком мусора асинхронно, а может даже и параллельно.

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

Иначе говоря, пересоздание массива быстрее сразу по паре причин, да и в своем коде с этим удобнее и безопаснее работать.

setTimeout(() => main(true))
setTimeout(() => main(false))

function main(immutable) {
const size = 1e5;
const arr = Array.from({ length: size }, () => ({}));
const time = [];
const gctime = [];
global.gc();
for (let i = 0; i < 20; i++) {
const arrs = [];
for (let j = 0; j < 1000; j++) {
arrs.push(arr.slice());
}
const start = process.hrtime.bigint();
for (let j = 0; j < arrs.length; j++) {
if (immutable) arrs[j] = [];
else arrs[j].length = 0;

}
const end = process.hrtime.bigint();
time.push(Number(end - start) / arrs.length);
global.gc();
gctime.push(Number(process.hrtime.bigint() - end) / arrs.length);
}
console.log(immutable ? 'Immutable' : 'Length');
console.log('script:',Math.min(...time));
console.log('gc:', Math.min(...gctime));
}

> node --expose-gc test.js
Immutable
script: 20.2
gc: 28870.873
Length
script: 522.224
gc: 28798.743

Опчк, опубликовали 🤩
https://youtu.be/evt4KVG8BbQ