Вайб-кодинг захватывает разработку везде, кроме одного места — 1С. Универсальные ассистенты здесь просто не работают: они не видят вашу конфигурацию. Показываю агента, который эту проблему закрыл — и что вайб-кодинг для 1С уже наступил, а не когда-нибудь потом.
Каждый день мы пишем JSX, используем хуки и стараемся не нарушать их строгие правила. Но как вся эта «магия» работает под капотом? Почему условный рендер ломает useState, а индексы массива в key приводят к багам? Зачем React перешел на архитектуру Fiber и как алгоритм обходит дерево элементов, не блокируя браузер?
Чтобы перестать воспринимать React как черный ящик, лучший способ — написать его с нуля.
В этой статье мы шаг за шагом воссоздадим собственный движок React. Мы реализуем функцию createElement, разберем Fiber-архитектуру с асинхронным рендерингом, напишем алгоритм Reconciliation и создадим систему хуков, разобравшись в логике их работы.
На официальном сайте Deno (раздел Built for the real world) красуется любопытная табличка. Согласно их замерам, Deno уходит в отрыв от Node.js по HTTP аж в 1.65 раза:
Независимые тесты (denosaurs/bench, pkgpulse 2026, jsmanifest 2026) показывают похожую картину: Deno стабильно быстрее на HTTP-нагрузке. Я решил копнуть глубже и понять, где Deno получает преимущество по сравнению с Node.js.
Есть готовый сайт, написанный на Laravel + Vue. Руководство попросило сделать его мультиязычным. Зная, что для Laravel “есть все”, я сходу без чтения документации назвал кратчайший срок. Но когда зашел на страничку Vue I18n то понял, что ошибся. Мультиязычность Vue происходит на клиенте, файлы переводов по формату отличаются от файлов Blade. Другими словами, если брать все «из коробки», то переводы придется дублировать и держать в разных местах, js приложение раздуется от подключения плагина I18n и к тому же на клиента придется загружать словари переводов... очевидно же, что надо делать переводы на сервере, то есть все хорошо, но без Vue I18n.
ТЗ формулировалось так:
У вас бывает такое чувство, когда вы при выполнении работы упёрлись в какую-то проблему и что-то внутри подсказывает, что не может такого быть, чтобы у неё не было решения? Когда кажется, что уже всё пропало и мы столкнулись с фундаментальным ограничением реальности, но отказ принять это продолжает вести вас в дебри спецификаций, беседы на Github 10 летней давности и изучение статей гигантов уже прошедших этот путь и поделившихся с нами своими результатами? И вот спустя многие часы напряжённого скрипа извилин вы дописали очередную строчку, обновили страницу и вот оно, то, что вы хотели получить смотрит на вас с экрана? Это ощущение успеха, наверное, в той или иной степени знакомо каждому инженеру. В такие моменты мне, обычно, очень хочется поделиться результатом с коллегами и, по возможности, написать статью если это может быть полезно кому-то ещё. В этой записи я собрал 3 подобных ситуации, где в рамках нашей работы возникли решения, которые, насколько мне известно, довольно уникальны и в полной мере не были описаны раньше. Приглашаю вас разделить со мной радость обнаружения решения, которое казалось невозможным!
Прошлый раз я рассказал, как написал свой калькулятор раскладки плитки, потому что замучился считать ванную в столбик. Тот пост был про версию 1.2 — база, прямая/диагональная раскладка, смета, PDF, нумерация плиток. Комменты были классные, фидбек пошёл сразу, и за месяц я выкатил ещё три версии. Самое заметное — ёлочка и общий план квартиры, где все комнаты лежат на одном полотне. Про это и пишу.
Каждый день мы натыкаемся на одни и те же грабли в связке фронта и бэка. Каждые такие грабли — это деньги и время. А если ещё и договариваться не умеем, процессов нет и решать никто не берётся, то дальше начинаются конфликты, атмосфера в команде проседает и проблемы копятся ещё быстрее.
Статья не про саму автогенерацию — с ней всё понятно, про неё и без меня написано достаточно. Мы внедрили генерацию типов из OpenAPI, и она вытащила наружу то, что с генерацией напрямую не связано: кто не хочет писать комментарии, почему у одной сущности два имени и почему у нас падал dev. По сути — про команду, эго и умение договариваться.
Сразу оговорюсь: это не единственно верный путь. Команды и компании разные, у всех свои нюансы, я рассказываю, как было у нас. Но если автогенерации у вас ещё нет и вы соберётесь её внедрять — будете хотя бы знать, что вас ждёт.
Владелец сайта по остеклению смотрит отчёт и злится. Позиции есть, страницы держатся в топе, SEO-работы идут не первый месяц: тексты переписывали, блоки добавляли, кейсы оформляли, фотографии меняли. А кликов всё равно меньше, чем он ожидал.
Вопрос к подрядчику в такой ситуации возникает простой и довольно неприятный: «Вы вообще что делаете? Если сайт уже в топе, почему люди не переходят?» На эмоциях это звучит как обвинение, но сама проблема реальная. Позиции в отчёте есть, а бизнес не видит того эффекта, который привык ждать от этих позиций.
И тут не всегда помогает ответ «надо ещё поработать над текстами». Иногда текстов уже достаточно. Блоков тоже достаточно. Страница видна, но плохо объясняет машине, что именно она предлагает: услугу, регион, исполнителя, условия, цену, замер, гарантию, филиал.
Вот здесь и стоит вспомнить про микроразметку. Не как про волшебную кнопку, которая вернёт клики. Не вернёт. А как про способ сделать страницу менее мутной для поисковиков, агрегаторов и других машинных потребителей.
С сайтом услуг это особенно заметно. Интернет-магазин размечать проще: товар, цена, наличие, доставка. У услуги всё грязнее.
Хайп-цикл фронтенда, кажется, наконец-то выдохся. Мы вышли из фазы бесконечного переизобретения колеса, где каждый месяц появлялся «убийца React», и вошли в эпоху убийцы Fable инженерной зрелости. Сегодня опытного инженера сложно впечатлить очередным фреймворком: ценность сместилась в сторону предсказуемости, скорости поставки (delivery) и снижения когнитивной нагрузки.
Привет, меня зовут Павел Востриков, и я — архитектор веб-направления в «Лаборатории Касперского». В этой статье хочу разобрать JS-экосистему как набор инженерных компромиссов.
На HolyJS Spring 2026 мы предложили 120+ инженерам оценить свой реальный стек. Получившийся радар мог быть просто списком библиотек, но в итоге вышел срезом того, как выглядит рациональный подход к коду в 2026 году. Мы видим, как разработчики массово идут в сторону предсказуемой скорости масштабирования решений и инженерной гигиены.
После сборки на Tauri голос начал трещать, автокалибровка почти минуту вмешивалась в разговор, а демонстрация экрана через минуту становилась чёрной. Разбираем запись и логи, находим усиление до ×4 без лимитера, резкие разрывы 20-мс аудиопакетов и зависший видеотрек при живом соединении LiveKit — и показываем, как исправили каждый сбой в версии 0.0.26.
Каждый раз, когда верстаешь новый проект, лендинг или дэшборд, Дизайнер просит поставить на плашки ссылки со свежими логотипами сервисов, соцсетей или технологического стека. Начинается отдельная каста разработки и дизайна: найди официальный брендбук, вытащи оттуда SVG (Не факт что он там будет) или иди на сторонние агрегаторы, где половина файлов кривые, а скачивание запрятано за скрытой рекламой "Скачать Яндекс". Когда мне это полностью надоело я создал свой сервис - ГдеИконка (GdeIkonka)
Я занимаюсь созданием сайтов с начала 00-х. Я просто интересовался этой темой. Веб‑дизайн и разработка сайтов никогда не были моей профессией. Я заканчивал институт, работал в ночных клубах танцором и сделал для себя сайт‑визитку: это было намного проще, чем раздавать агентам фотографии сценических образов в конвертике. Позже на этом сайте появились другие артисты, а самим сайтом начинали потихоньку пользоваться ивент‑агентства и клубные промоутеры. Позднее с годами я уже вёл несколько сайтов дружеских коллективов, а мой первый маленький сайт превратился в каталог артистов с самостоятельной регистрацией и возможностью за плату продвигать свою анкету.
Как и писал ранее — сайты — это моё хобби. Иногда я прибегал к помощи сторонних веб‑дизайнеров, что‑то делал сам. Такое поверхностное занятие сайтами с годами привело к тому, что сайты устарели на десятилетие в плане дизайна и UX. В этом году в бизнесе артистов для корпоративов наступило затишье и появилось много свободного времени. Было принято решение обновить сайты! И именно во время этого обновления появилась проблема, из которой в итоге вырос HeadInspect.
Встроенный граф Obsidian хорош ровно до момента, когда vault разрастается и превращается в клубок линий. Я решил сделать из базы знаний место, которое можно запомнить, — и собрал open-source плагин CosmoGraph 3D на Three.js и WebGL. В статье разбираю весь путь от metadataCache и wikilinks до сферической раскладки по золотому углу, процедурного рельефа, кратеров, bloom и нативного ItemView внутри Obsidian. Без облачной обработки заметок и без рассказов о «магии»: только код, архитектурные компромиссы и честный список того, что ещё предстоит ускорить.
После экспорта из Figma иконка 24×24 может оказаться в браузере крошечной, огромной или размытой. Обычно файл при этом исправен — просто разные части цепочки смотрят на разные параметры. Разбираем систему координат, viewBox, контракты и ловушки в React.
Два месяца назад мы взялись перенести в веб мою настольную игру. «Release любой ценой» — карточная игра про хаос IT‑разработки: собираешь релиз из Backend, Frontend и Database, соперники его валят, ты отбиваешься. Про саму настолку я здесь уже писал.
Нас в проекте трое: разработчик (ditayler), я (dimbo‑design, дизайнер) и Claude Code, через которого работаем оба. Ему досталась реализация логики игры и фундамент: монорепо, сеть, движок. Мне видимая часть: интерфейс, анимации, поведение карт, UX. Прочитать код я, в общем‑то, могу, а вот понять нет: моё ревью проходит на экране, как дизайн‑ревью.
Из этой конфигурации торчит неудобный вопрос. С моей стороны в проект постоянно едет код. Как убедиться, что туда не едет мусор, если прочитать его я не в состоянии? Ответ, на котором стоит проект: нестыковки должны всплывать сами — между договорённостью и кодом, между докой и реальностью. И сразу честно, чтобы не выглядело героическим строительством по ходу: большую часть этого фундамента разработчик задал ещё на старте, и именно фундамент работает. Что‑то доросло позже в моей зоне, за что‑то пришлось повоевать. Дальше эта система по частям, в порядке появления в проекте.
Современный JavaScript / TypeScript сегодня, предоставляет мощный инструмент для асинхронного программирования, который знаком каждому - async/await на основе Promise. Он позволяет писать последовательный код и легко обрабатывать ошибки. Однако за простотой скрываются серьёзные ограничения, которые становятся критичными в высоко-нагруженных системах, играх, сложных пользовательских интерфейсах и приложениях, требующих предсказуемой производительности.
Представьте себе сервер, обрабатывающий тысячи запросов одновременно. Все они конкурируют за процессорное время. Как гарантировать, что запрос от клиента выполнится раньше, чем фоновая синхронизация? Как отменить долгую операцию, если клиент разорвал соединение? Как избежать пауз сборщика мусора при создании миллионов временных объектов? Нативный async/await не даёт ответов на эти вопросы - он лишь оборачивает асинхронные операции в удобный синтаксис.
В этой статье мы разберём, как кооперативные корутины (Coroutines) решают эти задачи на примере моей библиотеки ts-adaptive-coroutines, изучив каждый аспект по кирпичикам, посмотрев на инструмент, который добавляет в TypeScript адаптивные приоритеты, арены памяти, каналы, семафоры и много-поточность.
Состояние во Vue обновилось, а интерфейс остался прежним — и начинается охота на watch, nextTick и принудительный ререндер. Разберём, где именно рвётся реактивная связь, почему это происходит и как находить такие проблемы до того, как вокруг них вырастут костыли.
После статьи о выборе Tauri нас спросили, сколько памяти будет занимать программа, которая живёт в трее рядом с игрой. Мы запустили старый БОЛТУН на Win32 и новый на Tauri в одинаковом пустом лобби. Получилось 2,2 МБ против 128 МБ. Разбираемся, откуда взялись девять процессов WebView2, что показал замер и почему это не стало автоматическим отказом от нового интерфейса.
Тот же Rust‑код, что рисует топологию на десктопе, собирается в wasm и рисует в <canvas> через WebGPU. Сайт при этом не знает про GPU: кликнул на нарушение в списке, камера уехала на место, маркер показал дефект. Ниже как это устроено, где «просто пересобрали» было бы враньём, и какие ловушки сидят не в Rust, а в вебе.
Задача
У нас десктопный инструмент для топологии интегральных схем, layout в формате GDSII (и OASIS). Файл описывает геометрию кристалла: иерархия ячеек, на листьях прямоугольники и полигоны по слоям (металл, поликремний, диффузия). Координаты целые, в DBU, единицах базы данных; в микрометры переводим уже при развороте сцены. Реальный проект: сотни мегабайт на диске, миллионы фигур после разворачивания иерархии.
Рядом выросла веб‑платформа с результатами анализа этих дизайнов. Захотелось показать сам layout в браузере, в том же UI: клик по нарушению в списке открывает его место на топологии. В десктопных пакетах это называют RVE, results viewing environment. Нам нужна была такая навигация без второго рендер‑движка.
Что отсекли сразу
Серверный рендер в тайлы. Каждый зум это запрос. Интерактивность мёртвая, плюс сервер рисует чужие данные.
Canvas2D или SVG на JS. На миллионах прямоугольников не работает. И это был бы второй движок.
Отдельный JS/TS‑парсер и рендер. Формат один, интерпретации через полгода две. Для GDS это особенно опасно: иерархия, зеркала, массивы ссылок.
Остался вариант, который мы и сделали: тот же Rust, цель wasm32-unknown-unknown, картинка в <canvas> через WebGPU.
Переписал с Perl/GTK3 на C++/GTK4 ds-measurer — утилиту для измерений поверх живого экрана, снятия скриншотов (в буфер обмена и/или на диск) и цветов в различных CSS-нотациях (в буфер обмена и/или c выводом на экран).
Есть поддержка цветовых схем с переключением по ним, направляющих с прилипанием к ним, выделение из центра и/или с фиксированным соотношением сторон, настраиваемые сетки и хоткеи.