Frontender's notes [ru]

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

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

Диктовка для Mac вместо клавиатуры Кодишь с Claude/Cursor и устал печатать промпты и сообщения? Зажал горячую клавишу, сказал - текст сам встал туда, где курсор. В любом приложении: редактор, браузер, мессенджер. - отдельная русская модель: распознаёт русский с пунктуацией, тянет смесь рус/англ-терминов - распознавание локально, на твоём маке - голос не уходит в облако, в отличие от облачных сервисов - от 290 ₽/мес - дешевле зарубежных аналогов - оплата картой РФ, без VPN и зарубежных карт macOS, Apple Silicon 🎁 Промокод FNOTES - месяц Pro бесплатно! → www.taptalk.team/

⁣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 — это действительно мощная фича.

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

Стажировки и вакансии для JavaScript разработчиков - Вакансии которых нет на джоб-агрегаторах - Только прямые контакты HR в Telegram @jobs_js_fronted для фронтов @jobs_js_back для бека Пока другие листают джоб-сайты — ты уже пишешь HR в Telegram.

🤣 Не баг, а фича ✖️ xCode Journal

⁣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.

Стажировки и вакансии для JavaScript разработчиков - Вакансии которых нет на джоб-агрегаторах - Только прямые контакты HR в Telegram @jobs_js_fronted для фронтов @jobs_js_back для бека Пока другие листают джоб-сайты — ты уже пишешь 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

⁣starting-style — правильные enter animations без JS В CSS появился @starting-style.

Он решает старую проблему: анимацию появления элемента, который только что добавили в DOM.

Раньше для этого обычно: 👉 делали setTimeout 👉 дёргали классы через JS 👉 ловили reflow-хаки Теперь можно нативно:

.modal {
  opacity: 1;
  transition: opacity .2s;
}

@starting-style {
  .modal {
    opacity: 0;
  }
}

Элемент появляется сразу с анимацией. Без двойного рендера и JS-костылей.

Почему это важно Раньше браузер не успевал увидеть начальное состояние элемента. Из-за этого приходилось: 👉 форсить reflow 👉 откладывать изменение класса 👉 городить лишнюю логику Теперь CSS сам понимает: 👉 с какого состояния начинать transition Где особенно полезно 👉 dialog 👉 popover 👉 conditional rendering 👉 enter animations в UI Почему это ощущается приятно Анимации становятся: 👉 чище 👉 предсказуемее 👉 без лишнего JS

CSS постепенно забирает себе всё, что раньше приходилось городить через JavaScript.

Приглашаем на Frontend Mix — бесплатный митап ЮMoney для всех, кто интересуется фронтенд-разработкой 🤩 🔔 28 мая, четверг, 19:00 (мск) — приходите на митап в Санкт-Петербурге или подключайтесь онлайн. Спикеры из ЮMoney поделятся, как работают над задачами и улучшают процессы в команде. Вот о чём будут рассказывать: 🟣 Как спят вкладки в браузере. На живом примере разберём, как браузер усыпляет вкладки, почему из-за этого ломается real-time и какие приёмы дебага и resync помогают находить и чинить их в продакшене. 🟣 Как построить Spec-Driven платформу для генерации писем. Используя OpenAPI как единый источник правды, покажем, как описывать контракты электронных писем через спецификацию и автоматически генерировать консистентный HTML. 🟣 Подключение модуля шумоподавления в рабочее место оператора. Рассмотрим инструменты React, WebSockets, WebRTC, а также архитектуру и логику работы модуля шумоподавления. 🟣 Круглый стол — AI во фронтенде: вызовы и реальность. Обсудим влияние нейросетей на фронтенд с трёх позиций: рынка, разработки и образования. Чтобы попасть на митап, нужна регистрация. Все подробности — на сайте Frontend Mix 👈

⁣Promise.withResolvers() — новый способ работы с Promise В JavaScript появился Promise.withResolvers().

Штука маленькая, но код с Promise реально становится чище.

Раньше обычно писали так:

let resolve
let reject

const promise = new Promise((res, rej) => {
  resolve = res
  reject = rej
})

Работает, но выглядит странно. Особенно это:

«вынесем resolve наружу»

Теперь можно нормально:

const { promise, resolve, reject } =
  Promise.withResolvers()

👉 без лишнего конструктора 👉 без мутаций переменных 👉 без промежуточного boilerplate Где это особенно полезно 👉 очереди 👉 event-based логика 👉 deferred pattern 👉 кастомные async abstractions Почему это приятно Раньше приходилось: 👉 создавать Promise вручную 👉 тащить resolve/reject наружу 👉 писать шаблонный код снова и снова Теперь API делает это нативно.

Мелочь, а ощущается как функция, которая давно должна была появиться.

Как сегодня оплачивают зарубежные сервисы, которые нельзя оплатить из РФ? Через мутных ботов, ребят с досок объявлений или сайты-прокладки. Если в двух словах — через посредника. Который каждый раз откусывает неплохую такую комиссию просто за то, что вбивает данные своей карты. В итоге вы: — Переплачиваете 20–30% сверху при каждой оплате. — Отдаете свои логины и пароли незнакомым людям. — Рискуете получить бан аккаунта за оплату с карты, которой еще оплатили неизвестно сколько аккаунтов. PintoPay убирает посредников из вашей жизни. Теперь вы сами контролируете свои оплаты: • Выпускаете свою виртуальную карту прямо в Telegram за 3 минуты. • Пополняете криптой (USDT) или рублями через СБП. • Привязываете к Apple Pay / Google Pay для оплаты чего угодно в путешествиях. Всё. Вы сами оплачиваете нейросети, хостинги, отели и любые зарубежные подписки. Без левых комиссий и чужих карт. Apple Pay работает везде, где доступна безконтактная оплата. Цена вопроса — $35 за выпуск. Но после первой же покупки $10 возвращаются вам обратно на баланс. По факту, безлимитный доступ к мировым платежам обходится в $25. Хватит кормить «помогаторов» и переплачивать за каждую подписку. Забирайте свою карту здесь: 👉 PintoPay 👉 PintoPay 👉 PintoPay Чтобы выпустить карту, надо запустить бота и открыть в нем мини-апп.

⁣React state machines против “простого state” Принято считать, что state machine — это что-то из мира enterprise и слишком сложных приложений. Мол: 👉 обычного useState достаточно 👉 зачем усложнять 👉 у нас же «просто форма»

Проблема в том, что «простой state» очень быстро перестаёт быть простым.

Почему обычный state начинает ломаться Пока состояний мало — всё выглядит нормально:

const [loading, setLoading] = useState(false)
const [error, setError] = useState(null)
const [success, setSuccess] = useState(false)

Но потом появляются вопросы: 👉 может ли быть одновременно loading и success? 👉 что делать при retry? 👉 можно ли отправить форму повторно? 👉 что если запрос отменился?

Количество комбинаций начинает расти взрывным образом.

В чём идея state machine State machine заставляет явно описывать: 👉 какие состояния существуют 👉 какие переходы между ними разрешены Например:

idle → loading → success
idle → loading → error
error → loading

Невалидные состояния просто невозможно получить.

Почему это мощно Логика становится предсказуемой Вместо набора флагов — у тебя конечный автомат. Не: 👉 loading = false 👉 success = true 👉 error = ??? А: 👉 приложение находится в состоянии success Меньше impossible states Обычный state легко приводит к странным комбинациям: 👉 loading + error 👉 success + loading 👉 success без данных

State machine убирает целый класс багов.

Проще масштабировать Когда сценариев становится больше: 👉 retries 👉 optimistic updates 👉 multi-step flows 👉 async transitions обычный state начинает разваливаться. FSM переносит сложность из хаоса в структуру. Но есть trade-off State machine — это дополнительная абстракция. Для: 👉 modal с двумя состояниями 👉 простого toggle 👉 маленького local state это может быть overengineering. Где state machine особенно полезна 👉 формы с несколькими шагами 👉 async flows 👉 onboarding 👉 complex UI states 👉 websocket / realtime UI 👉 payment flows Там, где логика переходов важнее самих данных. Главная мысль Проблема обычного state не в том, что он плохой.

А в том, что набор boolean-флагов не масштабируется вместе со сложностью UI.

State machine — это способ сделать сложные состояния явными и контролируемыми.

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