Соскучились по рождественским календарям для программистов?

У CodeRun тут получился Advent of Code посреди лета, только с более олимпиадной составляющей: 15 задач, которые выкатываются пачками по 5 штук каждые 5 дней до 17 июля, общий зачёт и отдельные лидерборды по 11 языкам.

Главная механика — не просто «решил / не решил». Быстрый и экономный код даёт больше баллов, так что после первого accepted всё только начинается: можно переписывать решение, смотреть на время, память, крайние случаи и пытаться выжать из него ещё немного.

Я знаю людей, которые реально встают на час раньше, чтобы перед работой прорешать очередной LeetCode. Я не уверен, что сам готов к такой дисциплине, но понимаю, зачем они это делают: алгоритмы быстро ржавеют, если их не трогать. А здесь примерно тот же формат тренировки, только не в одиночном режиме и с таблицей, где сразу видно, насколько твоё «и так нормально» на самом деле нормально.

Призы тоже есть: топ-1 по каждому из 11 языков получает мерч-пак CodeRun, топ-3 общего зачёта — коллекционный лего-набор, а топ-200 общего зачёта — скип контеста и пробное интервью в Яндекс.

Последний пункт, кстати, довольно практичный. Даже если не относиться к этому как к спорту, такой челлендж можно использовать как понятный способ размяться перед алгоритмическими интервью: задачи, ограничения, дедлайн, сравнение решений и болезненное напоминание, что O(n²) иногда всё ещё O(n²).

#фишка дня

Когда я наткнулся на этот твит в обсуждении утилиты работы с цветами Андрея Ситника, я не сразу примерил его на себя. Но, как оказалось, стоило бы.

Итак, давайте поясню для тех, кто по ссылкам не ходит.

В азиатских иероглифических языках почти весь ввод с клавиатуры происходит в аккордном режиме или же в режиме т. н. композитинга, общее название — Input Method Editor.

TL;DR: На экране всплывает окошко с символами или их группами и пользователь может что-то выбрать.

На каких-то ОС оно вызывается долгим зажатием клавиши, где-то — по хоткею, а где-то — автоматически и сразу.

Так вот, одно дело азиатские языки (я очень рекомендую посмотреть сам твит), а другое — разные европейские. И речь о диакритических знаках: умляуты, акуты, ударения, птички и шапочки.

Так вот, я не имею финской раскладки, потому буквы ä, å и ö ввожу как раз в режиме композитинга, долгим зажатием «материнской» клавиши.

Собственно, так база для азиатских языков проникла и в мою жизнь.

Кстати, выбор Emoji из всплывающего окошка — туда же.

В JavaScript-событиях для этого режима имеется флаг isComposing. Поэтому если вы, как и я в примере на видео, решили реализовать ввод групп символов подобным образом — циклически перебирая поля ввода — стоит об этом подумать :)

Собственно, давайте и пример: https://codepen.io/alinaki/pen/MWMpdvO?editors=1010

И напишите в комментариях, как вы решаете проблему редкого ввода букв с диакритикой у себя в системе. Например, я не помню, как это происходит в Windows, а в Linux я использую клавишу Compose, она работает чуть иначе.

#javascript #composing #event #бородач

#инструмент дня

Появился Nub — новый «всё-в-одном» тулкит для JavaScript. Название, конечно, опасное: любой пост про него автоматически звучит как обращение к аудитории.

GitHub: https://github.com/nubjs/nub
Site: https://nubjs.com/

Кто уже догадался, откуда у названия ноги растут?

Да, оттуда.

Но есть нюанс: Nub не пытается заменить Node.js.

Смысл такой: дать разработчику всё приятное, что люди обычно хвалят в Bun — быстрый запуск, TypeScript из коробки, меньше зоопарка CLI, — но оставить выполнение кода на старом добром Node.js.

Nub — это один Rust-бинарник поверх обычного Node.js. Он умеет:

— запускать TypeScript/TSX/JSX без отдельного build step
— автоматически подхватывать tsconfig paths
— грузить .env
— импортировать YAML/TOML/JSONC/JSON5
— работать как быстрый runner для package.json scripts
— заменять npx/pnpm exec
— ставить зависимости
— управлять версиями Node
— делать watch mode

То есть вместо набора из tsx, ts-node, dotenv, tsconfig-paths, nvm, pnpm run, npx и пары заклинаний из README вашего монорепо — один nub.

Главный selling point не «мы быстрее всех, потому что переписали мир на Zig, потом по-ковбойски переписали его на Rust с помощью ИИ, а теперь давайте все сделаем вид, что это нормальный жизненный цикл инфраструктурного рантайма».

Код в итоге выполняет обычный Node.js. Nub просто добавляет слой удобства: транспиляцию через oxc, хуки резолвинга, полифиллы и быстрые команды вокруг проекта.

На сайте, конечно, бенчмарки красивые:

nub run — сильно быстрее npm run / pnpm run
nubx — сильно быстрее npx
nub install — быстрее pnpm и, по их тестам, даже чуть быстрее bun install
nub index.ts — примерно как обычный node по старту и быстрее tsx

Плюс отдельно упирают в supply-chain безопасность: build scripts по умолчанию не запускаются, свежие подозрительные релизы можно придерживать, вредоносные пакеты проверяются через OSV.

Выглядит как очень понятная реакция на последние годы JS tooling: всем понравилось, что Bun быстрый и удобный, но не всем хочется тащить в прод ещё один почти-Node, который иногда внезапно оказывается «почти», а потом ещё и внезапно оказывается почти переписанным.

Nub говорит: а давайте оставим Node, но перестанем страдать от того, что вокруг него исторически вырос целый огород одноразовых CLI.

Пока штука свежая, я бы не тащил её сразу в критичный CI без проверки, но для внутренних тулов, dev-скриптов и монореп — очень интересно.

#node #bun #typescript #oxc #rust

#уязвимость дня

У браузеров новый жанр: сайт может косвенно смотреть, что вы делаете на компьютере, по задержкам SSD.

Исследователи из Graz University of Technology показали атаку FROST. Схема примерно такая: сайт заводит себе большой файл в локальном хранилище браузера через Origin Private File System и постоянно читает его маленькими кусками. Пока SSD занят только этим — задержки одни. Открыли другой сайт или приложение — нагрузка на диск изменилась, задержки тоже. По этим микросдвигам можно попытаться понять, что ещё запущено на компьютере.

В эксперименте сайты угадывались примерно с точностью 89%, приложения — около 96%.

Отдельно хороша реакция браузеров. По пересказу Ars Technica и Tom’s Hardware, Google не считает fingerprinting уязвимостью безопасности. Apple, судя по статье, отправила в сторону будущих privacy-защит. Mozilla проблему признала, но фикса пока нет.

Получилось как обычно: API добавляли для нормальных вещей — локального хранения, офлайн-работы, быстрых приложений. А потом выяснилось, что из этого же API можно собрать ещё один датчик состояния машины.

Закрывать лишние вкладки теперь можно не из-за RAM, а для своей же приватности.

#ssd #vulnerability

#игра дня

Среда — это маленькая пятница! Время сыграть в... Carmageddon!

Его как Никита Аксёнов портировал в браузер :) Точнее, не оригинальную игру, а движок Deathrace, целью которого является реверс-инжиниринг оригинального движка.

Естественно, чтобы играть локально нужны ассеты игры, но по ссылке — всё работает прекрасно: https://retrogamescenter.ru/ports/carmaweb/index.html

В отличие от нативного Carmageddon, управление тут перенесено на стрелки, а не работает на Numpad. Я всё ещё помню, насколько это было ублюдочно.

Я стар. Я суперстар.

Жаль, мультиплеер не пашет пока :)

#game #old

#инструмент дня

После Scratch в обучении программированию часто начинается пробел.

Сначала ребёнок собирает игру из блоков: персонаж ходит, говорит, что-то собирает. Всё живое и понятное. А потом ему внезапно дают VS Code, JavaScript, Canvas, npm и объясняют, что теперь надо быть взрослым.

Roblox Studio и Minecraft MakeCode этот пробел частично закрывают, но по-своему. Они хорошо отвечают на вопрос «зачем мне вообще кодить»: чтобы сделать свой мир, карту, режим, предмет или механику. Но как следующий шаг после Scratch они не всегда мягкие. Roblox Studio быстро превращается в отдельную IDE с Luau, сценой, объектами и клиент-серверной моделью. Minecraft — в редстоун, команды, datapacks, моды и свою специфическую экосистему.

Odyc.js интересен тем, что он меньше.

Это маленький JavaScript-движок для пиксельных narrative games: карта, персонаж, диалоги, звуки, взаимодействия. Игру можно собрать буквально в одном файле, без большого геймдев-цирка и обряда посвящения через инфраструктуру. У него есть песочница, где можно сразу ковырять игру в браузере.

Для обучения это хороший масштаб: уже не блоки, но ещё не Unity. Ребёнок пишет настоящий код, видит объекты, строки, координаты, условия и события — и всё это сразу превращается не в абстрактный прямоугольник, а в комнату, дверь, ключ, NPC и диалог.

Scratch учит: программирование — это поведение.

Minecraft и Roblox показывают: кодом можно менять миры.

Odyc аккуратно вставляется между ними: теперь то же самое, но буквами — и пока в масштабе, который можно удержать в голове.

#game #js

Проект от подписчика!

Напоминаю, что я выкачу любую статью или проект от вас, не стесняйтесь писать.

Презентация? Выступили на митапе? Хотите поделиться интересной статьёй — добро пожаловать!


Всем привет! Меня зовут Влад. Хочу поделиться историей создания своего iOS-приложения «Мои зубы: дневник».

В конце 2025 года, работая HTML-верстальщиком, я остался без работы и решил перейти в разработку, начав изучать React. Вместо учебных задач придумал собственный pet-проект - стоматологический дневник.

Идея появилась из собственного опыта. Из-за частых переездов информация о лечении зубов постоянно терялась и со временем забывалась. Тогда решил совместить обучение с решением собственной проблемы. Так появилась первая веб-версия с минимальным интерфейсом и базовым функционалом заметок. По сути, это был полигон для экспериментов, на котором я закреплял полученные знания о новой технологии.

Но постепенно проект начал увлекать меня все больше. Я придумывал новые функции, улучшал интерфейс и в какой-то момент поймал себя на мысли, что хочу довести его до состояния настоящего продукта, причем в формате мобильного приложения.

Разработка мобильной версии потребовала разобраться не только с React Native, но и глубже погрузиться в UI/UX, адаптацию интерфейса и пользовательский опыт. Для ускорения миграции и разработки активно использовал Codex.

Больше всего переживал за публикацию в App Store, но модерация прошла с первой попытки менее чем за сутки.

Немного о технической стороне проекта. Приложение построено по принципу Local First: все основные данные хранятся на устройстве пользователя, поэтому регистрация не требуется. Для резервного копирования используется iCloud.

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

Сейчас продолжаю развивать проект в свободное время. Теперь, когда публикация первой версии позади, начинается не менее интересный этап - продвижение и поиск первых пользователей.

Буду очень благодарен за установку, отзыв в App Store или обратную связь. Спасибо всем, кто решит поддержать проект !🫶🏻
App Store:
https://apps.apple.com/app/id6777985791

#релиз дня

TypeScript 7.0 доехал до stable: тот самый компилятор на Go теперь ставится обычным npm install -D typescript.

Пресс-релиз: https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

Языковых изменений по сравнению с TypeScript 6 почти нет: главный смысл релиза — новый нативный компилятор.

Microsoft обещает примерно 8–12x ускорение именно для TypeScript-компилятора на больших проектах. В их бенчмарках VS Code проверяется за 10.6 секунды вместо 125.7, Sentry — за 15.7 вместо 139.8, Playwright — за 1.47 вместо 12.8. Памяти тоже обычно уходит меньше.

Но это не значит, что весь ваш build внезапно стал в десять раз быстрее. Ускорили tsc, type-checking и language server. А рядом всё ещё живут бандлер, тесты, линтеры, генераторы, typedoc, typescript-eslint и всякая обвязка, которая как раз может сломаться первой.

Но есть скучная часть, из-за которой лучше не обновлять это пятничным вечером.

Зелёный tsc --noEmit ещё не значит, что миграция зелёная. Сам код может типизироваться нормально, а вот вокруг него внезапно начнёт трещать обвязка: старые опции в tsconfig, тулзы, которые лезут в Compiler API, генераторы схем, typedoc, ts-morph, typescript-eslint с type-aware правилами, кастомные трансформеры и прочая инженерная живность.

Microsoft прямо пишет: в TypeScript 7.0 нового API ещё нет, он ожидается в 7.1, причём будет другим. Для переходного периода предлагается держать рядом TypeScript 6 через @typescript/typescript6, чтобы tsc уже был быстрым, а инструменты, которым нужен старый API, пока жили на старой версии.

Так что новость хорошая, но миграция не уровня «npm update и пошли пить кофе». Сначала grep по tsconfig на старые флаги, потом проверка всего, что импортирует typescript, потом уже tsc --noEmit, build и тесты. Особенно если у вас монорепа, decorators/metadata, Nest/TypeORM/MikroORM или самописный codegen.

TypeScript стал сильно быстрее, а твоя миграция — нет.

#typescript

#заметка дня

Одно из моих любимых применений ИИ-агентов и ИИ вообще, это разработка под закрытые, ограниченные и легаси-платформы. Например, NES/Dendy, PalmOS, Rockbox для iPod или... телевизор.

Да-да, стоит себе в комнате телевизор на Tizen, вроде и можно на него приложения ставить — а нечего. Стриминги да и только. Ну да, может и есть в магазине пара игр, но там какое-то невозможное количество рекламы.

А иногда хочется просто позалипать в условный тетрис, 2048, сокобан, арканоид — на большом экране и без возни с эмуляторами. Да даже приставку запускать в лом.

Штош, приступаем к работе!

Одна из самых сложных задач — это тулинг. В случае Tizen OS он давно не обновлялся, эмулятор вообще не работает под современными маками, половина бинарников — под Intel-машины. Установка и настройка всего этого, выбор подходящих версий SDK и закрепление документации жрут какое-то невероятное количество контекста.

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

Да и я тоже не особо в курсе, как пишутся игровые движки, потому пришлось повозиться. Но мы дошли от стабильных 3 кадров в секунду при перерисовке всего экрана разом до стабильных ограниченных сверху 50! C эффектами шейдеров и звуком :)

Врубаешь звук, и всё падает с 50 кадров до 25. Кто ж знал, что надо держать аудиоконтекст прогретым и запускать звуки только по событию, а не всегда держать в процессе :)

В общем, подробности последуют. Пишется это всё на C++ c таргетом в NaCl (говорю же, старый ТВ), WebAssembly и Cocoa (macOS, на илюстрации). Очень хотелось выжать максимум из платформы.

Оставайтесь на связи, дальше будет больше :) Исходники и релиз тоже попозже.

#tizen #nacl #webassembly

#фишка и #статья дня

Надоело проигрывать битву z-index? Используй BFG от CSS: infinity.

Ладно, кроме шуток (хотя я и не шутил). С помощью infinity можно гарантировать верно скруглённые углы на прямоугольниках, мы с вами уже рассматривали алгоритм для веба и Flutter: https://t.me/htmlshit/1565

Вместо

  border-radius: 9999px;

...пишем:

  border-radius: calc(infinity * 1px);

А ещё в CSS общепринятое «если что-то поделить на ноль, получится бесконечность» вполне себе закреплено на практике:

calc(infinity) = calc(1 / 0)
calc(1px / 0) = calc(infinity * 1px)

Учителя вторых классов будут нами явно недовольны.

В общем, читаем статью и погружаемся в бесконечность и далее:
https://codersblock.com/blog/playing-with-infinity-in-css/

#css #infinity #math #бородач

#статья дня

У Джоша Комо вышел разбор squash and stretch — старого анимационного приёма, который нормально работает и в интерфейсах.

Суть простая: объект во время движения немного растягивается, а при остановке или ударе — сжимается. Из-за этого движение выглядит не таким механическим.

В интерфейсах это можно использовать совсем незаметно. Например, при наведении стрелка не только удлиняется, но ещё чуть меняет форму:

.arrow {
transition: transform 200ms;
}

.button:hover .arrow {
transform: scaleX(1.15) scaleY(0.9);
}

Особенно хорошо это работает с пружинной анимацией вместо обычного easing. Но выкручивать эффект сильно не стоит: тогда кнопка уже начинает вести себя как желе.

Ну а сама статья тут: Squash and Stretch

#animation #tutorial

#инструмент дня

Очень жаль, что у меня не было под рукой этого сайта в бытность студентом.

А ещё, поскольку иных способов отбирать джунов, кроме как третировать их алгоритмами на собесе, толком и нет, важно самому их понимать как никогда.

Итак, встречайте: https://algorithm-visualizer.org/

Прекрасный проект по визуализации алгоритмов. От брутфорса и сортировки до динамического, будь оно неладно, программирования.

Приглашаю накидать в комментариях подобных проектов.

#algorithms #cs #visualizations #бородач

#библиотека дня

Crashcat — новый физический движок для JavaScript. Его можно использовать с Three.js, Babylon.js, PlayCanvas или собственным рендерером.

Внутри есть столкновения, трение, шарниры, пружины, моторы, ragdoll, character controller и continuous collision detection.

Исходники лежат на GitHub.

Но лучше всего возможности движка показывают примеры на сайте. Там можно покатать машину, побегать персонажем, собрать ragdoll, запустить конвейер, подвесить объекты на шарнирах или навалить сотни тел в одну кучу.

Каждый пример небольшой и показывает одну конкретную механику без лишней обвязки.

Сейчас такой набор уже не выглядит чем-то экзотическим: берёшь рендерер, подключаешь физику, добавляешь готовые модели — и через несколько часов у тебя что-то ездит, падает и сталкивается.

Но примеры заодно хорошо показывают разницу между «движок умеет» и «игра работает». Готовый character controller ещё нужно нормально связать с камерой и управлением, машину — настроить под нужное поведение, а физические объекты — встроить в правила игры.

Пришло время пилить все те дурацкие игры, в которые любит позалипать дочка. Но хотя бы без рекламы и попапов.

#game #engine

#молния дня

Не планировал выпускать ещё один пост сегодня, но тут прям надо.

Есть автор такой, Дэн Холлик. Вы можете его знать по веб-сайту makingsoftware.com, где он буквально дотошно расписывает как работают современные (и не очень) компьютерные технологии.

Прям буквально про все: как работает экран, сеть, ИИ, GPU, шейдеры, сеть. Это потрясающая серия статей, которые он объединяет в книгу.

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

Так вот, он сегодня на пару дней выкатил статью «Как сделать шрифт». И это, как всегда, просто пушка. Дотошно и красиво, именно про основы: формирование координат и кривых.

Рекомендую: https://www.makingsoftware.com/chapters/how-to-make-a-font

#font #book

#инструмент дня

Скриншоты для App Store добавляются заметно сложнее, чем должны.

Сначала нужно запустить приложение в симуляторе с подходящим устройством. Потом разобраться, какие размеры Apple принимает для iPhone и iPad и какие изображения можно получить масштабированием из одного набора. Порядок неочевидный: если снять не в том разрешении, часть скриншотов придётся делать заново.

Дальше — App Store Connect. Интерфейс медленный, требования к изображениям разбросаны по разным экранам, порядок скриншотов легко перепутать, а загрузка нескольких локализаций быстро превращается в монотонную ручную работу.

Заметка на будущее для разработчиков: проще делать на айфонах/симуляторах Pro Max. Кстати, весь сыр-бор случился просто потому что на тот момент (февраль 2026) AppStore для экрана 6.9“ нужен был скриншот только с iPhone 14 Pro Max и никак иначе. А ещё, если ты забыл снять совместимость с iPad — конечно же модератор будет на iPad и не дай бог твоему интерфейсу расползтись.

AppScreen позволяет собрать оформление прямо в браузере: загрузить кадры, выбрать устройство, добавить фон, текст и рамку, настроить каждый экран отдельно и выгрузить готовые изображения архивом.

Готовая версия работает на GitHub Pages, а исходники лежат на GitHub. При желании проект можно запустить локально. А для полноценного промышленного инструмента ему, конечно же, не хватает загрузки CSV с локализацией.

Надо кстати поискать плагины для Figma, решающие ту же проблему…

#apple #ios #appstore

#статья дня

Леа Веру написала большой текст в защиту полифиллов. Поводом стало мнение одного из ключевых редакторов WHATWG: полифиллы якобы вредят веб-платформе, потому что слишком рано занимают имена и форму будущих API.

Проблема действительно существует. Кто-то реализует ещё не утверждённый API, библиотека становится популярной, сайты начинают от неё зависеть. После этого изменить название или поведение уже сложно: старые страницы сломаются. Браузерам приходится либо повторять чужую реализацию вместе с её ошибками, либо искать для стандарта менее удачную форму.

В качестве более безопасной альтернативы часто предлагают ponyfills.
Полифилл добавляет отсутствующий API туда, где он должен находиться:
if (!RegExp.escape) {
RegExp.escape = value => /* реализация */;
}

После этого приложение всегда вызывает RegExp.escape(). В новом браузере работает нативная версия, в старом — подставленная.

Ponyfill глобальные объекты не меняет. Это обычная импортируемая функция:
import { regexpEscape } from "./regexp-escape.js";

На первый взгляд подход аккуратнее: ponyfill не занимает имя будущего API и не вмешивается в платформу. Но Веру считает, что полноценной заменой полифиллам он быть не может.

Главное преимущество полифилла — код сразу пишется под стандартный API. Когда браузер добавляет нативную реализацию, приложение автоматически начинает использовать её, а полифилл постепенно превращается в пустышку.

Ponyfill остаётся в коде. Даже когда браузеры давно поддерживают нужный API, проект продолжает использовать импортированную функцию. Для перехода на нативную реализацию придётся менять импорты и вызовы.
Можно заставить ponyfill внутри проверять наличие нативного API, но тогда получается, по выражению Веру, «разобранный полифилл»: стандартная реализация уже используется, однако нестандартный интерфейс и отдельная зависимость всё равно остаются.

Ponyfills полезны, пока API только проектируется: на них можно проверить идею, не занимая заранее имя в платформе. Но для уже сформировавшегося API полифилл даёт более естественный путь — стандартный интерфейс сегодня и автоматический переход на браузерную реализацию завтра.

Веру также считает, что полифиллы несправедливо делают виноватыми в проблемах совместимости. Даже без них останутся проверки возможностей, @supports, условные импорты и самописные обёртки, которые точно так же могут закрепить раннюю форму API.

Зато полифиллы позволяют использовать новую возможность после появления первой браузерной реализации, не дожидаясь всех остальных. Разработчики получают работающий API, а другие браузеры — реальный спрос и причину быстрее добавить поддержку.

Поэтому популярный полифилл — не только риск, но и сигнал: функция разработчикам уже нужна, а стандартизация и браузеры за ней не успевают. Ponyfills хороши для экспериментов, но не заменяют главного свойства полифилла — способности со временем стать ненужным.

#javascript

#заметка дня

Вчера сайт 35mmc уронил Chrome на моём iPhone. Я просто читал статью про Olympus XA.

Подключил телефон к Web Inspector, записал таймлайн. За двенадцать секунд страница разогналась до 627 МБ памяти. Процессор жрал до 160%. Safari несколько раз запускал полный сборщик мусора, память немного проседала — и тут же начинала расти снова. Потом вкладка умерла. Буквально Web Page Crashed.

Вы же в курсе, что все браузеры на iPhone — это Safari? Но вот отработка нештатных ситуаций ведёт себя по разному. Chrome просто падает, а Safari — перезагрузит страницу несколько раз, на что-то надеясь.

Кстати, такая тактика даже лучше.

Самое смешное, что перед этим сайт предлагает купить ad-free experience.

Я не против рекламы и не против подписок. Маленькому изданию надо как-то зарабатывать. Но в данном случае выглядит издевательски: «заплатите, чтобы убрать рекламу, пока браузер не упал».

Погонял страницу ещё через Chrome с сетевыми трейсами и heap snapshots. Там не один неудачный баннер, а вполне себе рекламный комбайн: Flashtalking с креативами Adobe, Google SafeFrames, куча bidder’ов и измерителей, плюс Primis video player. А у видео внутри HLS, Google IMA, OMID, video Prebid и ещё свой трекинг.

В прогонах, где включался этот видеостек, память за короткую загрузку и прокрутку прибавляла 8–12 МБ. В других прогонах почти не росла. То есть один читатель получит просто перегруженную страницу, а другому случайно выпадет набор рекламы, который положит вкладку.

Не буду делать вид, что по одному таймлайну можно назвать виновника каждого байта. Но когда GC работает, память всё равно растёт, а Safari убивает процесс — пользователю всё равно, как это правильно назвать: memory leak, allocation pressure или «interplay независимых рекламных систем».

Он просто не дочитает статью.

#performance

#заметка дня

В конце прошлого года в Chrome появилась небольшая, но полезная оптимизация CSS-анимаций. Браузер перестал считать любое упоминание width или height безусловной причиной выполнять анимацию на в основном потоке.

Раньше даже такой код лишал opacity возможности анимироваться на compositor:

@keyframes fade {
from {
width: 200px;
opacity: 0;
}

to {
width: 200px;
opacity: 1;
}
}

Ширина здесь вообще не меняется, но одного присутствия width в keyframes было достаточно, чтобы Chrome счёл всю анимацию non-composited.

В Chrome 144 это исправили. Blink теперь проверяет, действительно ли layout-зависимое свойство меняется между кадрами. Если значения одинаковые, width или height больше не мешают opacity и transform работать на compositor.

Особенно заметна эта оптимизация во View Transitions. Chrome сам генерирует для них анимации с width и height, даже когда геометрия элемента остаётся прежней. До исправления такие переходы могли без необходимости фоллбека в основной поток.

В первой реализации, правда, нашлась проблема с округлением:

97.984px
97.9844px

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

Но чудес не произошло. Если размер действительно меняется:

@keyframes expand {
from {
width: 100px;
}

to {
width: 300px;
}
}

браузеру всё ещё приходится пересчитывать layout на каждом кадре. Такая анимация остаётся в основном потоке. Chrome не превращает её автоматически в transform: scale().

Для подобных случаев в CSSWG обсуждают отдельный механизм, условный size-animation, но к июлю 2026 года это всё ещё только предложение без готовой спецификации и реализации.

Так что старое правило остаётся в силе: реально меняющиеся width и height лучше без необходимости не анимировать. Chrome лишь убрал случай, когда неизменяющийся размер мешал нормальной compositor-анимации.

#performance