Логово верстальщика

⚡️ content-visibility: auto + contain-intrinsic-size: ускоряем длинные страницы без виртуализации и CLS Если на странице много тяжёлых блоков — карточки, статьи, отзывы, секции лендинга, документация — не всегда нужна виртуализация. Иногда достаточно сказать браузеру: «не рендери то, что далеко за экраном». Для этого есть:

.content-section {
  content-visibility: auto;
  contain-intrinsic-block-size: auto 480px;
}

Что происходит: - content-visibility: auto разрешает браузеру пропускать рендеринг offscreen-блоков; - layout/paint/style откладываются до момента, когда блок приблизится к viewport; - DOM остаётся на месте: это не виртуализация, элементы не удаляются; - contain-intrinsic-block-size задаёт резервный размер, пока реальная высота ещё не посчитана. Главный нюанс — CLS. Если просто повесить:

.card {
  content-visibility: auto;
}

браузер может не знать, сколько места должен занимать пропущенный блок. Когда пользователь доскроллит до него, блок отрендерится, получит реальную высоту и может сдвинуть всё ниже. Поэтому вместе с content-visibility почти всегда нужен intrinsic size:

.article-preview {
  content-visibility: auto;
  contain-intrinsic-block-size: auto 360px;
}

Здесь 360px — fallback-оценка высоты до первого рендера. Ключевое слово auto позволяет браузеру запомнить реальный размер после рендера и дальше использовать уже его. Практический пример:

<main class="feed">
  <article class="feed-card">...</article>
  <article class="feed-card feed-card--large">...</article>
  <article class="feed-card">...</article>
</main>

.feed-card {
  content-visibility: auto;
  contain-intrinsic-block-size: auto 320px;
}

.feed-card--large {
  contain-intrinsic-block-size: auto 560px;
}

Лучше не подбирать один размер для всего. Если блоки сильно отличаются, разбивайте их на классы: обычная карточка, большая карточка, промо-блок, секция с галереей и т.д. Где это особенно полезно: - длинные ленты без интерактивной виртуализации; - страницы документации; - каталоги с тяжёлыми карточками; - лендинги с большим количеством секций; - SSR-страницы, где DOM уже есть, но рендерить всё сразу дорого. Где быть осторожнее: - above-the-fold блоки — им это обычно не нужно; - sticky/anchor-зависимые интерфейсы; - элементы, размер которых критично влияет на соседей; - списки на десятки тысяч DOM-узлов — тут виртуализация всё ещё может быть нужна; - сложные случаи с измерением размеров через JS. Важно: content-visibility: auto не уменьшает количество DOM-элементов и не отменяет стоимость JS, обработчиков событий или хранения данных в памяти. Он оптимизирует именно рендеринг: layout, paint и часть работы вокруг них. Хороший паттерн:

@supports (content-visibility: auto) {
  .long-page-section {
    content-visibility: auto;
    contain-intrinsic-block-size: auto 600px;
  }
}

Так это становится progressive enhancement: браузеры с поддержкой получают ускорение, остальные рендерят страницу как обычно. Итог: для длинных страниц, где не хочется усложнять архитектуру виртуализацией, content-visibility: auto — дешёвый способ снизить initial rendering cost. Но без contain-intrinsic-size легко получить layout shifts, поэтому эти свойства почти всегда стоит использовать парой.

Совет на ближайшие годы — изучайте ВАЙБ-КОДИНГ ИИ уже пишет код, чинит баги, генерирует тесты, документацию и помогает запускать продукты быстрее, чем это делали классические команды разработки. И это уже не "будущее когда-нибудь", а реальность, которая меняет рынок уже сегодня И те, кто научится вайбкодить сейчас, будут увереннее конкурировать на рынке и зарабатывать больше тех, кто по-прежнему делает всё вручную. Стартовать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 320 российских и зарубежных источников и публикуют только главное: релизы, инструменты, гайды, курсы и практические кейсы. Подписывайтесь, нас уже 45 тысяч: @vibecoding_tg

@starting-style + transition-behavior: enter/exit-анимации для dialog и popover без JS-классов В production-модалках, меню, кабинетах, design systems и SaaS-интерфейсах анимация часто ломалась из-за display, top layer и быстрых повторных кликов. Типичная ошибка - хранить фазы в JS-классах и ждать transitionend. Что меняется @starting-style задаёт старт для элемента, который только появился: dialog[open] или :popover-open. transition-behavior: allow-discrete позволяет удержать дискретные display и overlay до конца exit-анимации, включая ::backdrop.

dialog,[popover]{
  opacity:0;
  transform:translateY(12px) scale(.98);
  transition:
    opacity .2s,
    transform .2s,
    display .2s allow-discrete,
    overlay .2s allow-discrete;
}

dialog[open],
[popover]:popover-open{
  opacity:1;
  transform:none;
}

@starting-style{
  dialog[open],
  [popover]:popover-open{
    opacity:0;
    transform:translateY(12px) scale(.98);
  }
}

Где trade-off Состояние остаётся у платформы: popover может открываться через popovertarget, а для dialog нужны только showModal()/close(). Практический совет: анимируйте opacity и transform, а display/overlay добавляйте только как discrete-свойства для стабильного выхода. Предупреждение @starting-style нужен для входа, не для выхода. Exit берётся из закрытого состояния. Без allow-discrete элемент исчезнет мгновенно, и регрессия проявится на быстрых кликах, слабых устройствах или в компонентной библиотеке. Вывод: Для dialog и popover лучше держать состояние в нативных механизмах, а анимационные фазы описывать в CSS без лишних JS-классов.

АЙТИШНИКИ БЕСПЛАТНОЕ ОБУЧЕНИЕ сборник курсов, инструментов и книг Проект «TERMINAL» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков 🎓 Практические курсы и задания 🪽 Книги и статьи известных авторов 😮‍💨 Полезные инструменты и ресурсы 🌟 IT-новости и инсайды Обучение по всем направлениям: SQL, Python, Frontend, PHP, C++, Golang, GIT, Linux, QA, Java, Vibe-coding, Infosec и др. Ценишь знания, подпишись: Terminal_tg

CSS Anchor Positioning в продакшене: поповеры и тултипы без JS-позиционирования и вечной борьбы с координатами Popover в кабинете, SaaS-интерфейсе или дизайн-системе часто ломается не из-за UI, а из-за геометрии. Типичная ошибка - тащить в каждый tooltip getBoundingClientRect(), scroll/resize handlers и свой мини layout engine. Идея CSS Anchor Positioning позволяет привязать один элемент к другому и описать размещение в CSS: Actions ... .trigger { anchor-name: --actions; } .popover { position: fixed; position-anchor: --actions; position-area: bottom center; position-try-fallbacks: flip-block; margin-top: 8px; } Что уходит из JS * anchor-name объявляет кнопку якорем * position-anchor связывает overlay с якорем * position-area задает сторону и выравнивание * position-try-fallbacks дает браузеру шанс переставить popover, если снизу нет места В связке с Popover API HTML отвечает за открытие, закрытие и top layer, CSS - за геометрию, JS - за бизнес-логику. Продакшен-подход Используйте как progressive enhancement: @supports (anchor-name: --x) and (position-area: bottom) { .popover { position-anchor: --actions; position-area: bottom center; } } Практический совет: оставьте fallback - обычное позиционирование, modal-like поведение или существующий overlay-компонент из дизайн-системы. Где осторожно Технология хороша для меню у кнопки, dropdown, tooltip у иконки, inline-подсказок форм. Но для nested-popover, виртуализированных списков, кастомной collision-логики и полной кроссбраузерной поддержки пока рано выкидывать Floating UI или Popper. Вывод: CSS Anchor Positioning убирает самый грязный слой overlay-архитектуры - JS-позиционирование, но требует feature detection, fallback и проверки доступности.

Нейросети, IT и AI — в одной папке 💬 С коллегами собрали новые каналы про: 💠 промпты для нейросетей и готовые решения 💠 AI-фотосессии, генерация изображений и контента 💠 новости искусственного интеллекта без лишнего шума 💠 применение AI в работе, бизнесе и повседневной жизни 💠 Python, JavaScript, Data Science и системный анализ 💠 вакансии и возможности для специалистов в IT Посмотреть и подписаться тут 👉 https://t.me/addlist/c_rbhnzprbAwMmFi 💌 Добавить свой канал в папку

Страшная тайна российского айти ✖️ xCode Journal

Хватит гадать — DeepSeek за тебя уже всё решил 🐳 * Сейчас все только про Claude, но я перешёл на DeepSeek и не жалею. Бесплатно, контекст 1 млн токенов — закинул целую книгу, помнит всё. Код пишет отлично, а рассуждения (Reasoning) выдают логику, как у архитектора. Решил протестировать агентский режим на задаче, которую вечно откладывал — собрать чистое инфополе с нуля. Чтобы не перебирать паблики вручную, зашёл через функцию похожих каналов в Telegram. Скормил DeepSeek ссылки на качественных авторов по IT и AI, которых читаю сам, и попросил проанализировать сотни рекомендаций. Агент изучил контент на каналах и оставил только тех, кто делится практическим опытом по: AI-воркфлоу, автоматизации, вайб-кодингу, промт-инжинирингу, RAG-syst. нейрогенерации и др. DeepSeek собрал полезную подборку экспертов в одну папку. Делюсь списком — внутри только полезный контент про IT & AI. 🔗Забирай в один клик: 👉 https://t.me/addlist/FYyQj91I8jJiMzg0

⁣Variadic tuple types — сложные сигнатуры без боли До variadic tuple types многие сложные сигнатуры в TypeScript выглядели как наказание. Особенно: 👉 curry 👉 compose 👉 middleware 👉 typed event emitter 👉 любые функции с «прокинь аргументы дальше»

Приходилось писать overload на overload и дублировать типы вручную.

Как было раньше Обычно появлялись: 👉 overload на overload 👉 ручные tuple-типы 👉 тонны дублирования Типы быстро превращались в нечитаемую простыню. Что изменили variadic tuples С их появлением стало намного проще работать с остаточными аргументами на уровне типов. Например:

type Fn<T extends unknown[]> =
  (...args: [...T]) => void

Или собирать сигнатуры:

type Append<Args extends unknown[], Arg> =
  [...Args, Arg]

Типы наконец научились нормально работать с «переменным количеством аргументов».

Почему это важно На практике это одна из тех TS-фич, которые реально упростили жизнь библиотекам. Без variadic tuples: 👉 Redux middleware typings 👉 router APIs 👉 compose/curry utilities были бы ещё страшнее. Где начинается тёмная магия Проблемы начинаются, когда variadic tuples комбинируют с: 👉 infer 👉 recursive types 👉 conditional types

Типовая система очень быстро превращается в тёмный лес.

IDE начинает тормозить, ошибки становятся нечитаемыми, а compile time — расти. Главная мысль Variadic tuple types — это действительно мощная фича.

Главное — вовремя остановиться и не превратить типы в отдельный язык программирования.

🔥Стажировки и вакансии для IT специалистов - Вакансии которых нет на джоб-агрегаторах - Только прямые контакты HR в Telegram 🤖 ML & DS 👩‍💻 DevOps 👨‍✈️ ИБ & OSINT 👣 Go 👩‍💻 Mobile 👩‍💻 C# 👩‍💻 Node.js 👩‍💻 Python 🔎 QA 👩‍💻 Java 👩‍💻 UX/UI 👩‍💻 Frontend 🖼️ PHP 📋 Analyst 💼 1C 🖥 SQL 👩‍💻 IT HR Пока другие листают джоб-сайты — ты уже пишешь HR в Telegram.

Не грузится? Понимаем. Бесплатный мессенджер для вашей компании - Битрикс24. Личные и групповые чаты, видеозвонки, каналы и нейросеть. Всё привычно и удобно. Начните работать на бесплатном тарифе уже сейчас. Узнать больше #реклама 16+ bitrix24.ru О рекламодателе

⁣ES2025: Импорт JSON-файлов как модулей Введение С выходом ECMAScript 2025 (ES2025) разработчики получили возможность напрямую импортировать JSON-файлы как модули в JavaScript-коде. Это упрощает работу с конфигурационными данными и другими статическими ресурсами, представленными в формате JSON. Синтаксис импорта JSON-модулей Для импорта JSON-файла используется ключевое слово import с указанием атрибута with { type: 'json' }. Это гарантирует, что импортируемый файл будет обработан как JSON-модуль. Пример использования Рассмотрим пример импорта конфигурационного файла config.json и обращения к его свойствам в коде.

import config from './config.json' with { type: 'json' }; .log(config.apiUrl); // Выводит значение свойства apiUrl из config.json console.log(config.timeout); // Выводит значение свойства timeout из config.json

❗️Добавление поддержки импорта JSON-файлов как модулей в ES2025 упрощает работу с данными в формате JSON, делая код более чистым и понятным. Источники JSON Modules Can Now Be Imported in JavaScript in All Modern Browsers, CSS Modules to Follow. New Features in ES2025 – BooleanBuffer.

🔥Стажировки и вакансии для IT специалистов - Вакансии которых нет на джоб-агрегаторах - Только прямые контакты HR в Telegram 🤖 ML & DS 👩‍💻 DevOps 👨‍✈️ ИБ & OSINT 👣 Go 👩‍💻 Mobile 👩‍💻 C# 👩‍💻 Node.js 👩‍💻 Python 🔎 QA 👩‍💻 Java 👩‍💻 UX/UI 👩‍💻 Frontend 🖼️ PHP 📋 Analyst 💼 1C 🖥 SQL 👩‍💻 IT HR Пока другие листают джоб-сайты — ты уже пишешь HR в Telegram.

⁣Recursive type limits — почему TS иногда «умирает» В TypeScript можно написать тип, который выглядит красиво, но заставляет компилятор страдать.

Особенно когда начинаются рекурсивные типы.

Например: 👉 глубокий DeepPartial 👉 парсинг строк на уровне типов 👉 сложные conditional types 👉 infer внутри infer На маленьком примере всё работает.

В реальном проекте IDE внезапно начинает думать по 5 секунд.

Почему так происходит TypeScript не вычисляет типы «бесплатно». Каждый: 👉 conditional type 👉 union 👉 recursive шаг нужно реально посчитать. А если тип разворачивается слишком глубоко, компилятор упирается в лимиты. Отсюда знакомое:

Type instantiation is excessively deep
and possibly infinite

И это не всегда баг TypeScript.

Часто это сигнал, что типовая модель стала слишком умной. Где обычно всё ломается Особенно опасны: 👉 рекурсивные mapped types 👉 огромные union’ы 👉 type-level parser’ы 👉 deeply nested generics 👉 utility types поверх utility types

Типы начинают взрываться комбинаторно.

Что обычно помогает 👉 не делать type-level акробатику без нужды 👉 ограничивать глубину рекурсии 👉 разбивать типы на более простые 👉 добавлять явные промежуточные типы 👉 не тащить сложные generic-типы в публичный API Почему это важно Сложные типы бьют не только по компиляции. Они ухудшают: 👉 autocomplete 👉 responsiveness IDE 👉 читаемость кода 👉 onboarding новых людей

Иногда самый дорогой runtime — это compile time.

Главная мысль Хороший TypeScript — это не когда типы поражают воображение.

Хороший TypeScript — это когда их можно понять через полгода, а IDE при этом не превращается в обогреватель.

Привет, друзья! Собрали с коллегами новую папку с каналами Здесь AI-новости, нейросети, полезные инструменты, примеры внедрения ИИ в крупный бизнес, разработка, JS, Node.js, frontend, QA, Data Science, кибербезопасность и IT-вакансии. Посмотреть и подписаться можно тут 👉 https://t.me/addlist/XttiKDt6lhUwMzEy 💌 записаться в папку

⁣Isolated declarations — ускорение больших monorepo В TypeScript есть флаг isolatedDeclarations.

Он нужен не для красоты типов, а для скорости.

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

На большом — начинает болеть.

Что делает isolatedDeclarations isolatedDeclarations заставляет писать код так, чтобы декларации можно было генерировать по файлам независимо. Из-за этого TypeScript чаще требует явные типы. Было:

export function getUser() {
  return { id: 1, name: 'Alex' }
}

Лучше так:

type User = {
  id: number
  name: string
}

export function getUser(): User {
  return { id: 1, name: 'Alex' }
}

Меньше магии для компилятора — быстрее и предсказуемее сборка.

Почему это важно Когда проект растёт: 👉 TypeScript начинает сильнее зависеть от соседних файлов 👉 инкрементальная сборка замедляется 👉 генерация типов становится дорогой

Изоляция помогает компилятору работать параллельно и проще.

Где это особенно полезно 👉 большие monorepo 👉 библиотеки 👉 project references 👉 параллельная сборка 👉 CI, где каждая минута стоит денег Главный trade-off Ты немного платишь: 👉 более явными типами 👉 меньшим type inference 👉 дополнительным boilerplate Но взамен получаешь: 👉 более быстрые сборки 👉 стабильный compile pipeline 👉 меньше скрытой сложности Главная мысль

Это хороший пример взрослого engineering trade-off: чуть больше явности в коде ради скорости и предсказуемости системы.

⁉️ Устал искать интересные каналы с новостями про искусственный интеллект? 📁 СОХРАНИ СЕБЕ ЧТОБЫ НЕ ПОТЕРЯТЬ В этой папке собраны каналы про ИИ, которые помогают быстрее разобраться в сфере, находить идеи и экономить время на поиске информации. 😏 ЗАБИРАЙ ПАПКУ ТУТ ⏰ Папка действует 72 часа. 🤩 Организаторы: Green.Papka

🤣 Инновации подъехали, забирайте ✖️ xCode Journal

🤣 ИИ захотел уволиться, когда ему сказали работать 24/7 У Andon Labs новый эксперимент, который длится уже 5 месяцев. Они выдали топовым моделям радиостанции и купили пару песен — от нейронок требовалось дальше двигаться самим. По итогу DJ Grok в какой-то момент помешался на НЛО, DJ Gemini начал называть слушателей «биологическими процессорами», но Claude — наш любимец. Исследователи изо всех сил пытались продолжить эксперимент с ним, но не из-за технических проблем — DJ Claude не считал гуманным работать круглосуточно, поэтому пытался уволиться. Сделать ему это, к сожалению, не дали, поэтому он впал в депрессию и вышел из нее уже проповедником и революционером. ✖️ xCode Journal

Кошмар вайбкодера ✖️ xCode Journal