Привет, Хабр! Пилю потихоньку пет‑проект и решил поделиться тем, что вылезло при первом же деплое.

Откуда взялась эта штука 

Основная занятость у меня связана с ИИ, но есть ещё подработки по 1С — в основном администрирование: обновления, настройка оборудования, выгрузки и прочее. Всё взаимодействие идёт в Telegram: множество чатов, в каждом свои задачи, у каждой свой дедлайн и своё техническое окно, когда её вообще можно делать. Базу не обновишь в разгар рабочего дня — значит, задача не просто «к пятнице», а «в пятницу после семи».

Пока задач несколько, они держатся в голове. Дальше начинается путаница: помнишь, что на этой неделе у кого‑то обновление, а у кого именно — уже нет. Я начал забывать про клиентов. Писал на бумажке. Бумажка не работает по простой причине: про неё тоже надо вспомнить. Она лежит рядом и молчит. А напоминание должно приходить само и туда, где я и так сижу целый день. Так и родилась мысль сделать свой блэкджек.

Если вы пишете на JavaScript или TypeScript, выбор инструмента обычно начинается с двух знакомых вариантов: VSCode или WebStorm.

Сегодня расскажу вам про третий вариант: OpenIDE. Это готовая IDE на базе той же платформы, которую использует WebStorm.

Философия также схожа: вам не нужно собирать рабочий инструмент из десятка расширений. В одном дистрибутиве комфортно и легко настроить и менять версии Node.js, npm, yarn и pnpm, TypeScript, React и Angular, линтеров, Git и HTTP-клиенты. Можно открыть проект и сразу заниматься делом.

Прочтя недавний перевод про запаковку БД в exe, решил рассказать об идеи, которую реализовал лет 6 назад в своем домашнем проекте. Сам проект недоделал, но речь в статье об архитектуре файлов и их запаковке.

Банальный пример — когда печатаешь в input, а интерфейс начинает лагать на большом списке: классическая боль старого React. Я решил разобраться, как и почему React переписал свою архитектуру: отказался от рекурсивного обхода дерева, изобрел новую структуру данных и научился прерывать рендер ради нашего ввода.

В статье рассмотрю проблемы синхронной отрисовки и переход к новой архитектуре,  почему пришлось отказаться от методов жизненного цикла с приставкой *will, что такое Fiber, почему первый вариант приоритизации с ExpirationTime не сработал и как пришли к React Lanes.

Один и тот же JavaScript-код в браузере, Node.js, Deno и Bun должен показывать примерно одинаковую скорость – по крайней мере, так кажется до первых замеров. Я взял четыре прикладные задачи, добавил к сравнению Python и измерил не только время выполнения, но и потребление памяти, причём отдельно посмотрел, как результат меняется вместе с границами замера. Оказалось, что у каждой среды своё представление о быстродействии, а лидер зависит не только от алгоритма, но и от того, входят ли в задачу чтение файлов, парсинг или обработка изображений. Все примеры и исходные данные можно запустить локально и сравнить результаты со своей машиной.

Привет, Хабр! (И тебе, случайный читатель, который открыл эту статью в перерыве между двадцатой правкой того, что ты ещё месяц назад гордо назвал финальной версией).

Сегодня давайте без кода и без нытья пофилософствуем на тему:

Когда же продукт готов? И будет ли готов когда-нибудь...?

Всем привет!) Напомню: в первой статье я показал дебаунс на Redis, который склеивает дробные сообщения клиента. Во второй — модуль привязки «чат = сделка» и то, почему вебхуки стоит держать в изолированных ключах. Обе части заканчиваются примерно одинаково: «...и текст уходит ИИ‑агенту». Это, пожалуй, тот финал, на котором обычно ставят точку и заливают демо на GitHub... Но не в данном случае!)

Каждый день мы пишем JSX, используем хуки и стараемся не нарушать их строгие правила. Но как вся эта «магия» работает под капотом? Почему условный рендер ломает useState, а индексы массива в key приводят к багам? Зачем React перешел на архитектуру Fiber и как алгоритм обходит дерево элементов, не блокируя браузер?

Чтобы перестать воспринимать React как черный ящик, лучший способ — написать его с нуля.

В этой статье мы шаг за шагом воссоздадим собственный движок React. Мы реализуем функцию createElement, разберем Fiber-архитектуру с асинхронным рендерингом, напишем алгоритм Reconciliation и создадим систему хуков, разобравшись в логике их работы.

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

Логика выглядит убедительно ровно до того момента, пока не посмотришь, что именно считает принимающая сторона. Антифрод почти никогда не спрашивает «встречался ли нам раньше такой набор параметров». Он спрашивает другое: «бывают ли вообще такие устройства». Это два разных вопроса, и ответы на них расходятся в противоположные стороны.

Разберу, откуда берётся расхождение, покажу, как оно считается, и почему рандомизация параметров чаще ухудшает результат, чем улучшает.

Хайп-цикл фронтенда, кажется, наконец-то выдохся. Мы вышли из фазы бесконечного переизобретения колеса, где каждый месяц появлялся «убийца React», и вошли в эпоху убийцы Fable инженерной зрелости. Сегодня опытного инженера сложно впечатлить очередным фреймворком: ценность сместилась в сторону предсказуемости, скорости поставки (delivery) и снижения когнитивной нагрузки.

Привет, меня зовут Павел Востриков, и я — архитектор веб-направления в «Лаборатории Касперского». В этой статье хочу разобрать JS-экосистему как набор инженерных компромиссов.

На HolyJS Spring 2026 мы предложили 120+ инженерам оценить свой реальный стек. Получившийся радар мог быть просто списком библиотек, но в итоге вышел срезом того, как выглядит рациональный подход к коду в 2026 году. Мы видим, как разработчики массово идут в сторону предсказуемой скорости масштабирования решений и инженерной гигиены.

Какое-то время назад я выкладывал статью на Хабр про свое obsidian хранилище.

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

Кроме простой структуризации и удаления лишнего, я также провел некоторые махинации над кодом dataviewjs своей библиотеки книг и доделал свою домашнюю страницу, добавив интеграцию со своей основной библиотекой и поработав на css составляющей. В общем-то были еще некоторые изменения, но об этом всем будет далее.