Оптимизация next.js monorepo приложения

Как я ускорил работу с тулингом на своем проекте в среднем более чем в 10 раз, заменив JS-инструменты на нативные.

Прототипно-ориентированный язык программирования

Как я ускорил работу с тулингом на своем проекте в среднем более чем в 10 раз, заменив JS-инструменты на нативные.

Поиск работы в 2026 году — это инженерная задача, которую все решают вручную. hh.ru перемешивает релевантные роли с шумом: на запрос «Senior PHP» прилетают джуны, фронтендеры и «PHP со знанием 1С». Одна и та же вакансия репостится под разными URL — и отследить, что ты уже откликался на неё месяц назад, практически невозможно. Зарплатные вилки скрыты или указаны в разных форматах. Значительная часть рынка вообще живёт вне hh — в ATS западных компаний (Greenhouse, Ashby, Lever, Workday), на Habr Career, в GetMatch и GeekJob, и у каждого источника свой API и своя схема данных. А поверх всего этого — ИИ по обе стороны воронки: резюме первым читает ATS-скринер, а не человек, рынок захлёстывают массовые AI-отклики, и рекрутёры в ответ закручивают фильтры.
Если декомпозировать задачу честно, получается типовой ETL-конвейер: агрегация из неоднородных источников, нормализация и дедупликация в единую модель, скоринг против резюме, трекинг откликов во времени. Ровно то, что бэкендеры строят на работе, — только над данными о собственном трудоустройстве. Я так и поступил: написал локальный клиент, который агрегирует 41 источник, оценивает каждую вакансию под резюме, ловит репосты, ведёт воронку откликов и разворачивается одной командой. Сервер слушает только loopback — резюме и история откликов не покидают машину.
В статье — разбор архитектуры и решений: фронтенд без сборки и без virtual DOM, два реестра адаптеров с тестами на согласованность, SSRF-защита на DNS-pinning, двухфазный SSE с детерминированным завершением, 13 локалей с RTL, тестовая пирамида из 1543 кейсов и Spec-Driven Development как замена командного ревью для solo-проекта.

В одной из предыдущих статей я поднимал вопрос о том, что интерфейс системы целиком и полностью работает на Английском языке. Я пообещал, что в будущем реализую поддержку нескольких языков, и вот этот момент настал. Но, как это часто бывает, пока я копался в коде ради мультиязычности, попутно переписал пару системных модулей, чтобы они наконец-то работали стабильно ну и не ручками же вводить переменные в файл пакета. Поэтому релиз 3.6.6 получился тройным: Системные исправления, исправления интерфейса ну и новый плагин.
┼┼┼┼┼┼┼┼┼▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄┼┼┼┼┼┼┼┼
┼┼┼┼┼┼┼┼┼█▒▒░░░░░░░░░▒▒█┼┼┼┼┼┼┼┼
┼┼┼┼┼┼┼┼┼┼█░░█░░░░░█░░█┼┼┼┼┼┼┼┼┼
┼┼┼┼┼┼─▄▄──█░░░▀█▀░░░█──▄▄─┼┼┼┼┼
┼┼┼┼┼┼█░░█─▀▄░░░░░░░▄▀─█░░█┼┼┼┼┼
┼┼┼██░██░████░██░░░██░░░█████┼┼┼
┼┼┼██▄██░██▄▄░██░░░██░░░██░██┼┼┼
┼┼┼██▀██░██▀▀░██░░░██░░░██░██┼┼┼
┼┼┼██░██░████░████░████░█████┼┼┼
Для строительства компиляторов, нам нужны начала математики. Из них, как мы убедимся, проистекает добрая половина понимания и всех наших работ.
В частности, без начал не понять лямбда-исчисление Чёрча, которое мы применим на этапе работы с AST. Рассмотрим элементы дискретной математики с примерами на С, JavaScript, SQL.

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

Хочу анонсировать свой фреймворк Point0. Это первый Bun FullStack фреймворк сопоставимый по функционалу с Next.js и TanStack Start. Однако, имеет кардинально другой DX, ради которого и был создан.
Мне всегда не нравились существующие фреймворки, особенно Next.js и Remix (React Router). Но я думал, что, видимо, по-другому фреймворки просто не получаются, поэтому и не делают. А громоздкость, чужие строгие соглашения, неповоротливость архитектуры, это просто необходимое зло, с которым я должен смириться.
В какой-то момент во мне накопилось критическое ощущение, что всё же должно быть совершенно по-другому. И я подумал, а напишу-ка я псевдокод на воображаемом фреймворке, который бы меня устраивал, вообще не взирая на возможность реализации. Просто буду писать проект, будто бы идеальный фреймворк существует.
И получилось так здорово, что я просто забыл обо всём на свете и 10 месяцев пилил реализацию этого фреймворка, а 3 месяца назад даже уволился с работы, чтобы уже скорее его добить. И вот добил, и хочу поделиться с вами.

Начнём с предыстории. Когда я опубликовал первую статью про клон Flappy Bird, я хотел получить результат, который был бы мне приятен, но вместо этого получил всего понемногу. Можно сказать, сработал эффект Зейгарник, когда незавершённая задача создаёт когнитивное напряжение, которое буквально «заставляет» нас возвращаться к мыслям о ней. Вроде поучил физику, посмотрел, как лучше работать с рендерингом, узнал, почему птица стала такой популярной игрой, но один комментарий заставил задуматься, что на этом нельзя останавливаться и стоит сделать ещё что-то, пока эффект не пропал.

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

Расскажу, как и почему я в какой-то момент решил написать собственный pivot grid — без сторонних библиотек, на чистом JavaScript и DOM. И что из этого получилось: от первой версии с обычным GROUP BY до кэширования больших выборок и цепочки связанных гридов.

Ну что же…, на дворе 2026 год, первый DogPlanner живёт своей жизнью, доступен на многих площадках мобильных приложений, мы о нём много писали в соцсетях и различных блогах. С тех пор как мы сделали его, а опубликовали мы его аж в июне 2020 года, вы прислали нам много различных идей по его доработке, написали множество отзывов, а также мы узнали о приличном количестве проблемных мест по его функциональности и содержанию, и всё это было абсолютно заслуженно! Хотим сказать вам огромное спасибо за всю обратную связь, которую мы получили, и получаем до сих пор от вас! Но давайте снова вернёмся к критике…

Предисловие
Возможно то, про что я хочу рассказать в своей первой статье тут, покажется не новым, уже знакомым велосипедом. Речь пойдет о контроллерах на базе ESP32 и программном обеспечении. Да, современных решений, открытых и бесплатных – много. А сейчас зарождается еще одно (а опенсорса мало не бывает, я считаю).
В статье я упущу и не буду рассказывать ни про свое знакомство с ардуиной, esp, php, python, js ни про то, что пришел сюда давным-давно гуманитарием. И да простят мой, вероятно не корректный, «жаргон» истинные профессионалы в микроэлектронике и программировании - итак, приступим.
Совсем недавно я отключил RPI4 с HA и наконец «воткнул» в котельную очередную, но «готовую к деплою» версию контроллера (разрешите его далее называть «УМНЫЙ К1», спасибо).

Привет, Хабр! Меня зовут Александр, я руковожу веб-разработкой в InfoWatch. Мы занимаемся проектированием решений, которые обеспечивают информационную безопасность для разных компаний.
В этой статье я расскажу, как мы обеспечиваем интеграцию SPA-приложений. Главная цель этого процесса — сохранить стабильность и совместимость приложений, при этом не потеряв по пути скорость поставки функционала. Под катом — о подходах и решениях, которые мы используем, а также пара примеров из практики и немного рекомендаций, если вы по работе занимаетесь подобными вещами.

Уже почти июнь подходит к концу, а я так и не выпустил эту статью. Исправляюсь.
Обзор на браузерные API, которые стали Widely available в мае 2026. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде.
Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем. 2.5 года назад также каждый месяц выходили новые фичи в браузере, а вот их уже пора начинать применять.

У меня в Obsidian накопилось под две тысячи заметок. Ежедневники, конспекты, обрывки идей, недописанные черновики. Граф‑вью честно показывает мне облако точек: красиво, но бесполезно. Какие заметки висят сиротами без единой связи, какие дублируют друг друга под разными тегами, какие кластеры тем так и не соединились, из графа не вытащить.
Очевидная мысль: «отдам всё LLM, пусть разберётся». Но 2000 заметок это миллионы токенов. Ни в один контекст это не влезает, а если бы и влезло, стоило бы как крыло самолёта и утонуло бы в шуме.
Так появился идея по созданию Vault Audit AI, плагин для Obsidian, который проводит аудит хранилища через LLM: находит сироты, кластеризует темы, предлагает теги и связи. Я его опубликовал в официальном каталоге и выложил на GitHub. В этой статье разберу инженерную начинку: как обойти лимит контекста через MapReduce, как не платить за повторный анализ, как абстрагировать четырёх LLM‑провайдеров под одним интерфейсом, и что пришлось переделать, чтобы пройти автоматическое ревью каталога.
Код на TypeScript, фрагменты настоящие (слегка почищены от обёрток локализации ради читаемости).

Спойлер: коды готовы — вставьте и пользуйтесь.
Знаете, что меня расстраивало больше всего в чатах с нейросетями? Сидишь, читаешь длинный ответ в момент генерации. Дошёл до середины, понял, что упустил какую-то деталь в начале, крутишь скролл вверх. А бот в этот момент дописывает новый абзац, и весь текст уезжает обратно вниз.
Штатная стрелочка «наверх» тут не спасает. Она кидает к шапке сайта, а не к началу конкретного сообщения ассистента. Приходится ловить текст вручную. Сейчас стали выкатывать что-то вроде истории запросов справа от чата, похожее на закладки, но мне они не нравятся по той же причине: надо приглядываться и целиться в анимированный интерфейс.
Чтобы не дергать страницу туда-сюда, я набросал около 10 юзерскриптов для всех популярных чатов. Они вешают в углу экрана кнопку, которая телепортирует прямо к первой строчке именно последнего ответа. Заодно вычищают визуальный мусор, который разработчики добавляют в интерфейс без возможности отключения штатными методами.

Если к вам придут с задачей внедрения интерактивной карты офиса, какой рендер вы выберете? Canvas или SVG? Верхнеуровневый обзор скажет, что Canvas хорош для частых перерисовок (географические карты, игры), а SVG — когда важна работа с отдельными элементами, которые естественным образом присутствуют в DOM.
Мы выбрали SVG.
В этой статье не будет глубокого анализа, это живая история о том, почему мы отказались от идеи использовать Canvas, как строили карту с нуля, какие инструменты использовали, как организовали связь между SVG-элементами и данными в БД, и как сделали админку, где карту могут менять дизайнеры без участия разработчиков.

npm install — такая привычная многим из читателей команда, но за последние пару месяцев она обернулась сущим кошмаром для инженеров по безопасности. И ладно бы всё сводилось к проверке 5 пакетов из package.json, но у каждой зависимости по 10 своих зависимостей, а у тех ещё по 10. В итоге мы тянем 2000, а не 5 пакетов, и тут, кажется, уже руками не проверишь. И именно на этой боли всех безопасников, поддерживающих JS-проекты, сыграла команда TeamPCP. В этой статье я хочу подробно, от А до Я, разобраться, в чём опасность, почему так произошло и как от этого защититься.

Пока фронтенд-инженеры продолжают пересобирать свои проекты на новых сборщиках, JavaScript как язык становится всё более зрелым, быстрым и безопасным. Мы собрали самые интересные новости из мира JS и TS за последние месяцы, мимо которых нельзя пройти.

В этой статье разберу пять направлений, в которых мы получили измеримый эффект:
1. Type checking — TSCheck vs TSGO
2. Linting — ESLint vs Biome vs Oxlint
3. Bundling — Webpack → Vite → Rsbuild
4. API-контракты — Кодогенерация без AI
5. React-оптимизации — React Compiler в production

DatePicker казался нам небольшой задачей в разработке UI, пока мы не попробовали создать компонент, который будет корректно работать с keyboard navigation, screen reader’ом, управляемым состоянием и реальными проверками доступности.
Нам потребовался DatePicker производственного уровня на React и TypeScript, и сначала очевидный путь казался очень заманчивым: дать AI четкий запрос, получить 80% готового кода, а остальное доработать руками. Подробный разбор этого кейса есть в моей предыдущей статье «Попросили Claude создать WCAG-доступный DatePicker на React и потратили 3 дня на доработки».
Так вот.
Модель может сгенерировать структуру календаря, атрибуты ARIA, базовую keyboard navigation и логику работы с датами.
Затем начинается интеграция: поведение фокуса становится нестабильным; возникают конфликты между обработчиками событий; озвучивание screen reader’ами требует тщательного тестирования; небольшое изменение в логике работы с датами может неожиданно нарушить работу календаря; код выглядит нормально, но компонент пока не является надежным.
В этой статье я сравниваю два способа создания доступного DatePicker'а с помощью AI:
Первый — 80% кода с помощью AI, остальные 20% руками. Второй — системное проектирование с AI-агентом: PRD, декомпозиция задач, правила агента, внешняя верификация, Vitest, Playwright, сборка Vite, проверки типов и строгий цикл, в котором агент не может двигаться дальше, пока не будет пройден текущий шаг.
Дальше все по делу: в чем AI действительно нам помог; где он начал сбиваться с курса; почему одного большого promt'а оказалось недостаточно; как The Verifier изменил процесс и почему основная задача инженера в разработке с использованием AI больше не сводится только к написанию кода, а заключается в контроле над замыслом, архитектурой, контрактами и стоимостью изменений.