JavaScript *

Каждый, кто пишет на TypeScript хотя бы пару лет, отлично знаком со стандартным DI-сценарием: класс, декоратор @Injectable(), флаг emitDecoratorMetadata в конфиге и рантайм-магия фреймворка. Этот подход казался прорывным в 2015 году, но современный TypeScript ушел далеко вперед. У нас появились мощнейший статический анализ и продвинутый вывод типов, в то время как популярные DI-контейнеры вроде NestJS, InversifyJS или TSyringe будто законсервировались в прошлом.

Слепая приверженность старым паттернам начинает откровенно тормозить индустрию. Из-за legacy-декораторов мы оказываемся заперты в рамках медленного tsc без возможности безболезненно уйти на сверхбыстрые сборщики вроде esbuild или SWC. Наша бизнес-логика намертво заражается инфраструктурными импортами сторонних библиотек, а ошибки в графе зависимостей и скрытые утечки памяти обнаруживаются не на этапе компиляции, а уже в рантайме под нагрузкой на проде.

Но что, если заставить компилятор TypeScript проверять валидность всего графа зависимостей еще до запуска кода? Без декораторов, reflect-metadata, кастомных трансформеров и тяжелой кодогенерации.

В этой статье мы разберем концепцию «экстремальной типизации» на примере InferDI — первого DI-контейнера, где сам граф зависимостей вместе с lifetime-правилами перенесен напрямую в систему типов. Мы поговорим о фундаментальных вещах: почему полный отказ от «удобной» магии аннотаций в пользу 100% ванильного TypeScript — это лучшая инвестиция в архитектуру, безопасность, скорость сборки и долговечность вашего проекта на годы вперед.

Можно ли запустить казуальную HTML5-игру на чистом JS в Яндекс Играх, не зная геймдева и верстки? Спойлер: можно, но придется пройти через 2-3 месяца модерации.

Под катом — честный постмортем инди-проекта, созданного по вечерам на коленке. Рассказываю про костыли SPA-архитектуры на тегах <div>, продвижение и реальные графики трафика и доходов за первые недели.

Когда маркетологи хотят всё: сырые данные в GA4, запись сессий в Метрике, хитмапы в Clarity и при этом «Lighthouse 100» в PageSpeed Insights — приходится изобретать. Расскажу, как мы это сделали на небольшом проекте и во что это обошлось по времени и нервам.

Проект — нишевый агрегатор российских хостинг-провайдеров. Более 120 страниц в sitemap, 31 статья, десятки категорий услуг, живые цены, сравнения. Стек: Astro 6 + Strapi 5 + Tailwind 4, плюс Partytown, PostgreSQL, Nginx и обычный VPS на Ubuntu. Сайт собирается в статику во время билда, никакого SSR в рантайме нет.

На desktop — Lighthouse 100 / 100 / 100 / 100. На mobile с жёстким throttling (4x slow CPU) — 99 / 100 / 100 / 100. В реальных условиях и по Chrome UX Report — 100 везде. LCP на desktop — 0,5 секунды, на mobile throttled — 1,7 секунды. CLS — ноль. TBT — 10 ms на мобильном и 0 ms на десктопе.

В этой статье расскажу о свежем баге, который ронял один тип транзакций, пока остальные работали штатно. Если используете @formatjs/intl-durationformat для форматирования времени - этот кейс может сэкономить пару часов отладки.

Миграция большого legacy-проекта с Vue 2 на Vue 3 — это не только про код. Основная сложность начинается ещё до первого коммита: оценка объёма работ, поиск несовместимых API, планирование и организация процесса разработки.

Почему вообще это важно, и как донести эту мысль до бизнеса я уже описывала в другой своей статье «Ты всё ещё думаешь или уже мигрируешь на Vue 3». Рекомендую почитать.

А тут я поделюсь своим опытом, где мне пришлось лидировать миграцию: самостоятельно составлять план миграции, оценку времени, рисков и проводить саму миграцию.

Когда проект на Next.js только начинается, прямой fetch во внешний API кажется самым коротким путём. Есть страница списка, есть поиск, есть внешний источник данных, значит можно сходить туда напрямую и сразу показать результат.

На маленьком экране это работает. Но дальше почти всегда начинаются одинаковые проблемы. Интерфейс начинает зависеть от чужой структуры ответа. Ошибки приходят в форме, которую неудобно показывать пользователю. Параметры запроса приходится валидировать в UI. Потом появляется базовый URL, который не хочется держать строкой в коде. Затем появляется ключ или другой секрет, который уже нельзя светить в браузере. В этот момент становится видно, что между UI и внешним API не хватает серверной границы.

В App Router такую роль часто закрывает Route Handlers. В официальной документации Next.js они описаны как пользовательские обработчики запросов внутри app directory на основе стандартных Web Request и Response API. Они доступны только в app, по смыслу заменяют старые API Routes из pages и поддерживают GET, POST, PUT, PATCH, DELETE, HEAD и OPTIONS. (Next.js)

Смысл Route Handlers в том, что они позволяют собрать внутренний серверный контур прямо внутри приложения. Через него можно проксировать внешний API, нормализовать ответ под нужды UI, спрятать env-переменные и секреты, а также вернуть в интерфейс уже свой контракт, а не чужой.

У вас один SSG-лендинг, а платный трафик льётся из 12 кампаний под разные боли ЦА. Все ведут на дефолтный hero — конверсия в заявку проседает на 30–50%. Делать 12 лендингов дорого и убивает SEO, подменять hero на клиенте — FOUC и дефолт для поисковых ботов.

Рабочая схема, поставленная в продакшен за день: edge-функция Cloudflare Pages переписывает HTML на лету через HTMLRewriter, SSG остаётся источником истины, client-side React дублирует логику при гидратации. 200 строк кода, латенси без изменений (HTMLRewriter работает потоком), Lighthouse не страдает. Разбираю код, нюансы интеграции с vite-react-ssg и грабли из прода.

Разбираем очень неприятный баг в React Native + iOS: почему push-уведомления сохраняются на Android, но теряются на iOS в background/killed state. В статье обсудим как на самом деле устроены APNS, Notification Service Extension, App Groups и почему проблема вообще не в React Native. Будет интересно…

🧮 Математика больших чисел: из игры с нулевой суммой в игру с растущей суммой

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

В статье разобран пример автоматизации, как искать тикер с притоком капитала

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

Теперь — следующий шаг.

Я хочу поделиться идеей, как с помощью уже работающего инструмента автоматически строить эпюры Q и M для всей балки целиком. На данный момент это концепция и алгоритм, который я планирую реализовать. Буду рад услышать мнение сообщества.

Каждый раз, когда я хотел поправить отступ или цвет в процессе разработки, я делал одно и то же:

открыл DevTools → нашёл элемент → поменял значение → понравилось → скопировал → переключился в редактор → нашёл файл → вставил.

Это семь шагов ради однострочного изменения. Я сделал LiveStyleSync, чтобы это был один шаг.

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

Когда «снисходительность к входным данным» становится ловушкой? Когда имя хука начинает диктовать потребителю модель мышления? Когда подстановка снимка состояния — это не приём, а сигнал, что фазы жизненного цикла стоят не на том такте? Три мажорных релиза одной библиотеки — про эти три вопроса.

Год назад я почти перестал писать код руками - теперь чаще диктую задачу агенту прямо в терминале. И однажды понял, что мой здоровенный IDE превратился в дорогую рамку вокруг одного окна. Так появился лёгкий редактор, где терминал главный, а код с git - сбоку.

Внутри - про инженерию, а не про “качайте продукт”: как агент-независимо ловить “агент работает / ждёт ответа / закончил” через /proc, как собрать Windows-сборку Electron прямо с Linux без Wine, темы на контракте CSS-токенов и пара граблей, на которых я знатно подгорел (привет, Ctrl+V в русской раскладке).

GitHub постепенно превращается в кладбище старого кода. Мы сравнили тысячи репозиториев и посмотрели, какие языки быстрее теряют активность, а где экосистема всё ещё растёт.

Онлайн доска DGRM.net кеширует файлы в постоянном кеше. Постоянный кеш не удаляется при закрытии вкладки. Рассказываю как хранить большие файлы в браузере.

Статья о том, как получить наблюдаемость (observability) в приложении с минимальным кодом, а бонусом получить структурированные логи с типизированными шаблонами, автоматическую корреляцию со спанами OpenTelemetry, всё это с помощью набора библиотек, которые я называю CleverBrush Framework.

Если вы пишете на Angular, то наверняка часто используете хуки жизненного цикла вроде ngOnChanges, ngOnInit и ngOnDestroy. С появлением сигналов и концепции Zoneless (когда Zone.js уже не обязателен) у нас появились более элегантные и читаемые альтернативы.

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

Всем привет. Я занимаюсь фронтендом в небольшой команде сервиса бронирования отелей. Хочу как я 8 дней ловил утечку памяти на проде, несколько раз думал, что починил, и каждый раз ошибался. А последний фикс был не в нашем коде, а в патче самого Vue, который через неделю апстрим откатил как регрессионный. У нас в результате осталась одна патч-версия, в которой утечки нет; обычный minor/patch update сейчас для нас не безопасен без повторной проверки heap-снапшотами.

Наш стек Nuxt 3.18 + Vue 3.5.x + TypeScript, SSR, Pinia, PM2 cluster, nginx перед Node. Обычный каталог отелей с тысячами SEO-страниц вида /oteli-v-{город}/{подборка}

Я занимаюсь разработкой ПО для строительной механики. В процессе работы над одним из проектов возникла потребность в простом инструменте для построения линий влияния в многопролётных шарнирных балках. Готового решения под рукой не оказалось, и я написал свой веб-модуль.

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