JavaScript *

Тот же 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.

Абсолютные импорты без расширений в ESM-монорепозитории.

Настраиваем Vite, TypeScript и автоимпорты в IDE (VSCode) с помощью “subpath imports”.

Разрешаем конфликты настроек без костылей.

Добавляем приоритет автоимпорта папок в качестве модулей, при наличии “index.ts”.

Настраиваем Vite и TypeScript на работу с исходниками компилируемой библиотеки в dev-режиме.

Скролл-фильм на лендинге — это обычно сотни WebP и десятки мегабайт. Рассказываю, как заменил секвенции кадров сырым H.264-потоком без контейнера и WebCodecs-декодером: 84 → 18 МБ на мобиле. С параметрами кодирования и тремя честными тупиками: почему HEVC оказался хуже x264, зачем шумодав не нужен и как B-кадры сломали фильм на живом iPhone так, что валидация этого не увидела.

В первой части мы разобрали архитектуру Rari, почему Rust под V8 даёт выигрыш, и посмотрели на бенчмарки. В данной статье хочется поговорить о том, что обычно остаётся за кадром демо: как это работает в продакшене, что конкретно поменялось под капотом, где ломается совместимость с Next.js, как мы портировали их SWC-плагины, и как производительность выросла с 4x до 67x.

За час ИИ-агент может изменить десятки файлов, написать тесты и потратить большой объём токенов. Польза для команды зависит от результата. Если разработчик долго восстанавливает ход изменений, переписывает половину патча или обнаруживает пропущенный сценарий после слияния, работа агента только увеличивает нагрузку.

Число запросов, объём сгенерированного кода и расход токенов показывают активность модели и её стоимость. Для оценки пользы нужны другие данные: сколько времени сэкономил разработчик и прошёл ли результат приёмку.

Для оценки каждой задачи нужны три параметра:

У меня браузерный генератор вывесок: человек набирает надпись, получает STL-модель корпуса под светодиодную ленту. Всё считается на его же машине, файл никуда не уходит. Однажды пришёл вопрос, который сломал мне неделю: надпись 500 мм, стол принтера 256×256. Что делать?

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

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

Задумывались ли вы когда-нибудь о том, что на самом деле происходит под капотом, когда вы рендерите приложение React? Мы знаем, что React строит дерево DOM и отображает UI на экране, но как React конструирует это дерево и как он эффективно обновляет его при изменении состояния?

В этой статье мы рассмотрим React Fiber — основной движок согласования (reconciliation) React. Мы рассмотрим, как React строил DOM до v15, недостатки этой ранней стековой (stack) модели с точки зрения производительности и то, как асинхронная архитектура Fiber решает эти проблемы, начиная с React v16 и до React v19.

Как просьба друга «настроить кассу» закончилась open-source ERP, тринадцатью российскими интеграциями и нейросетью, которая теперь считает закупки, ищет косяки в учёте и пишет владельцу в Telegram.

Есть у меня друг. Назовём его Артём.

Полгода назад он решил открыть ресторан. Небольшой: пятнадцать столиков, кухня, бар, доставка. Никакой федеральной сети и отдела автоматизации на сорок человек. Обычный ресторан, где владелец ещё вчера выбирал стулья, сегодня разбирается с поставщиком мяса, а вечером внезапно узнаёт, что касса тоже требует внимания.

Примерно за месяц до открытия Артём пришёл ко мне с классической фразой:

— Слушай, тыжепрограммист. Помоги систему настроить. Ну чтобы касса, кухня, заказы — всё нормально работало.

Если вы когда-нибудь были «тем самым знакомым программистом», то примерно понимаете, чем обычно заканчивается слово «помоги». Сначала задача выглядела просто: выбрать что-нибудь вроде iiko, поставить, настроить и забыть.

В итоге я полез смотреть, как вообще устроен ресторанный софт, перебрал несколько систем, остановился на open source, русифицировал его, прикрутил российские кассы, банки, 1С, маркировку, агрегаторов доставки, а потом зачем-то решил, что обычной автоматизации мне уже мало.

Так в ресторане появился DeepSeek, который скоро заменит Артема, а может и всех остальных. Сам будет заказывать еду, сам кушать... ну это я отвлекся.

Сразу важный момент. Я не писал ресторанную ERP с нуля. Это был бы отличный способ потратить много времени и получить плохую кассу. Я взял готовую open-source систему и начал допиливать её под конкретный ресторан. И вот здесь всё стало интереснее.

Stockfish умеет находить сильные ходы. Но браузерному расширению ещё нужно понять, какая из нескольких досок относится к текущей партии, дождаться стабильной позиции, пережить остановку service worker и не показать устаревший результат.

Дальше не про кнопки, а про проверки: какая доска настоящая, не протух ли ответ, пока считал движок, куда девать WASM, когда Chrome гасит service worker, и почему «сыграй как 1500» нельзя получить, урезав глубину. Отдельно, без эвфемизмов: подсказка в партии с человеком — это чит.

Привет, хабр! Уже 11 лет я пилю свой игровой движок, и я готов представить его публике. Я все еще дорабатываю его, но он уже вполне стабилен и я делаю игры на нем.

Движок открытый и бесплатный, нацелен преимущественно на мобильные игры, поддерживает пачку платформ — ios, android, web, mac, windows, linux. Он компактный (всего несколько мегабайт), производительный, позволяет писать логику игры как на C++, так и на JavaScript. Внутри есть убер‑редактор для всего — вот он на скриншотике выше

На мой взгляд, лучший способ рассказать о технологии — показать демо и рассказать как все устроено внутри. Под катом ссылки на репозиторий и демки (под веб), а также асскажу как он устроен внутри. Велкам!

Чем больше автономии я даю ИИ-агентам, тем больше требований к коду превращаю в механические проверки. Когда eslint-plugin-react сломался на ESLint 10, я собрал продолжение для React 19: сократил 102 активных правила до 11 и исправил ошибки, которые проявились только в реальных проектах.

Пагинация ломается не только внутри запроса к базе. Это цепочка: бэкенд определяет порядок и границу страницы, фронт хранит курсор и объединяет ответы, а пользователь меняет фильтры, повторяет запросы и возвращается на экран. Разберём шесть ситуаций, в которых локальные проверки зелёные, а список целиком работает неправильно.

Всем привет! Меня зовут Денис Смирнов, больше шести лет я работаю в компании iSpring и участвую в разработке нашего основного продукта — платформы для онлайн-обучения. Особенность платформы в том, что в ней достаточно гибко настраивается работа с датой и временем. Часовые зоны (таймзоны) можно указать на уровне аккаунта, тогда каждый пользователь может выбрать собственный часовой пояс. В некоторых модулях их можно дополнительно переопределять для отдельных пользователей.

Всем привет! Меня зовут Егор Савинцев, я Frontend Platform Engineer в Авито. Сейчас я работаю в команде архитектуры, а до этого в команде Phobos в рамках Платформизации переводил страницу объявления на Beduin — разрабатывал клиентскую архитектуру и переписывал блоки. 

Сразу важное отступление. 

Beduin — это Backend‑Driven UI. Если в нативе в коде клиентского приложения есть компоненты, бэкенд присылает им данные, и всё работает. В Beduin бэкенд присылает и данные, и сами компоненты в специальном виде. На клиенте у нас только рендерер — специальный компонент, который принимает JSON и рендерит то, что мы прислали. 

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

Статья будет полезна frontend‑ и mobile‑разработчикам, инженерам платформенных команд, архитекторам клиентских приложений и backend‑разработчикам, которые внедряют Backend‑Driven UI. В общем, всем, кто планирует переводить крупные экраны на BDUI и хочет заранее узнать, что может пойти не так. Спойлер: всё.

2026 год стал переломным для Bun. Переписывание на Rust с помощью Claude Fable 5 за 11 дней показало новые возможности AI-ускоренной разработки, а 20 августа 2026 вышел Bun v1.4 — первый production-релиз, полностью работающий на Rust-версии рантайма (до этого Rust использовался только внутри, например в Claude Code). Версия 1.3.14 добавила Bun.Image, HTTP/3 и Global Virtual Store, а v1.4 принесла резкий скачок совместимости с Node.js и десятки новых встроенных API. Bun стал частью Anthropic после приобретения в декабре 2025.

Когда говорят «у нас есть тесты на Playwright», обычно представляют классический e2e-сценарий: тест открывает приложение, проходит авторизацию, переходит по нескольким страницам и работает с настоящим или почти настоящим backend.

Мы используем Playwright немного иначе.

Основной пласт UI-автоматизации в нашем Angular-проекте — это CAT-тесты. CAT в данном случае расшифровывается как component autotest. Мы поднимаем отдельный компонент или целую бизнес-форму в Storybook, открываем её в настоящем Chromium, выполняем пользовательские действия, управляем HTTP-ответами и сравниваем интерфейс с эталонными снимками.

Получается тест, который находится между unit и e2e:

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

Плиточник говорит — берите пятнадцать процентов запаса и всё. Пятнадцать процентов от плитки по 2000 с лишним за метр это уже сумма, я в столбик посчитал и решил что нет, надо по‑другому. Калькуляторы онлайн — площадь на цену умножают, я и сам умею. В CAD полез — там сначала модель строй, а мне не чертежи нужны были.

Написал своё в итоге, дальше расскажу что вышло, скрины ниже, там понятнее чем я объясню.

Современные веб-приложения содержат сложную бизнес-логику, которая ранее традиционно располагалась на бэкенде. С ростом сложности возникает необходимость в эффективном управлении зависимостями для поддержания тестируемости, модульности и слабого зацепления этих модулей в приложении. Принцип Инверсии зависимостей (Dependency Inversion, DIP) и его реализация в лице механизма Внедрения зависимостей (Dependency Injection, DI) становится ключевым инструментом для решения этих задач.

Несколько лет назад у нас с одногруппником был зачёт по C++, и вместо того чтобы сделать что-то скромное (например, «Калькулятор» или «Генератор паролей»), мы, конечно же, решили замахнуться на какую-то игру, и тогда нам попалась новость о 30-летнем юбилее игры DOOM. План был красивый, т. к. на тот момент командной работы у нас не было, мы решили, что мой одногруппник пишет псевдо-3D-движок в духе классического рейкастинга, а я делаю 2D-платформер, который в итоге должен был запускаться прямо внутри его мира, как игровой автомат, который запускался бы перед игрой, и сколько патронов ты собрал, столько у тебя и будет в игре.

Проблема появилась не в архитектуре и не в гейм-дизайне, а гораздо раньше — на этапе, который мы оба благополучно пропустили: мы не договорились, на чём пишем. Я по рекомендации преподавателя взял SFML — с ним я уже возился на парах, там всё human-readable, спрайты, окна, звук из коробки. Товарищ выбрал SDL, т. к. видел гайд про DOOM на SDL — она даёт прямой доступ к буферу пикселей, что для рейкастинга буквально то, что нужно: рисуешь вертикальные полоски стен вручную, без лишней абстракции между тобой и экраном.

По отдельности оба выбора были правильными, а вместе — нет. Слинковать в одном проекте SDL и SFML можно, но два разных event loop, два разных подхода к окну и таймингу — это уже не работа для автомата по зачёту, а отдельная курсовая работа, на которую у нас оставалось дня два-три. Мы посчитали и сдали как два независимых проекта. Препод посмотрел, оценил — и выдал ровно ту фразу, которую в такой ситуации выдал бы любой человек, который знал о проекте: «Идея классная, жалко, что не объединили», но нам это было неважно на тот момент, как говорится, зачёт получили — и на этом спасибо.

React Native по-прежнему часто описывают формулой «один код для iOS и Android». В 2026 году она звучит слишком просто. Современное приложение на React Native — это общий продуктовый слой на TypeScript, нативный интерфейс, Hermes, Fabric, JSI, фоновые процессы, platform-specific код и довольно много решений о том, где именно должна выполняться каждая задача.

Мы столкнулись с этим в Synchra.24 — мобильном приложении для линейных и распределённых команд. В проекте больше тысячи TS/TSX-файлов и свыше ста экранов, но рядом с ними живут Kotlin и Swift: геопозиция, push-уведомления, биометрия, системные виджеты и работа с медиа. Это не история о функциях нашего продукта и не попытка его рекламировать. Это разбор того, чем на практике стала разработка на React Native к 2026 году — и какую часть этой работы действительно можно поручить нейросетям.