Представьте типичную ситуацию. У вас есть сервер на каком-то языке (сейчас какой именно для нас не важно, но допустим, это Rust). И в нём по каким-то причинам нужно исполнить JavaScript-код. Например, фронтенд написан на React, и вы хотите рендерить HTML на сервере (SSR). Или есть бизнес-логика, которая проще пишется на JS. Или библиотека, которая существует только в npm, и переписывать её на Rust нет ни сил, ни желания. Таких примеров можно привести множество: markdown, dompurify, highlight.js и т.д.

На официальном сайте Deno (раздел Built for the real world) красуется любопытная табличка. Согласно их замерам, Deno уходит в отрыв от Node.js по HTTP аж в 1.65 раза:

Независимые тесты (denosaurs/bench, pkgpulse 2026, jsmanifest 2026) показывают похожую картину: Deno стабильно быстрее на HTTP-нагрузке. Я решил копнуть глубже и понять, где Deno получает преимущество по сравнению с Node.js.

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

Как говорил классик: в 100 раз за Rust. Кажется, что название является кликбейтом. И такого быть в принципе не может. Но я запланировал цикл из трёх статей, в которых постараюсь рассказать, как достичь такого фантастического результата.

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

Мы столкнулись с этим во время миграции большого исторического проекта на Next.js 15. Вайбкодинг сначала выглядел как идеальное ускорение: модель за минуты переносила страницы, компоненты, хуки и server actions. Но затем на ревью начали прилетать огромные PR с тысячами строк сгенерированного кода.

На детальном ревью выяснилось, что AI часто переносит поведение неточно, пишет собственные велосипеды вместо использования готовых open source решений, не подтягивает дизайн-токены из Figma, не делает Storybook stories и не запускает тесты, если его явно об этом не попросить.

В статье рассказываю, почему проблема не в самом AI, а в отсутствии процесса вокруг него. И предлагаю prompt-first подход: сначала ревьюить короткий промт-план с контекстом, ограничениями, файлами и критериями приёмки, а уже потом генерировать код и открывать PR.

Хочу показать три приёма, как можно ускорить загрузку интерфейсов с Backend-Driven UI и улучшить UX. Решения показали хорошие результаты на демо-версии, но увы, пока ещё не внедрены в реальный проект. Было бы интересно обсудить с вами, как эти приёмы могут помочь в боевых задачах и что ещё можно улучшить.

Представьте ситуацию: ваша команда закончила интеграцию с API, все протестировала и подготовила релиз. А тут внезапно серверная команда меняет формат ответа. Фронтенд падает, QA злится, пользователи недовольны. Приходится вручную переписывать валидации, искать баги и терять дни, чтобы всё починить. 

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

В первую очередь статья будет полезна фронтенд-разработчикам и командам, работающим над сложными веб-приложениями, особенно тем, кто активно взаимодействует с API, описанными через OpenAPI.