JavaScript *

Недавно я увидел видео, где маленький мальчик собирает кубик Рубика за 2,76 секунды (вот оно), и мне тоже захотелось научиться его собирать. Конечно, не за такое время, но главное — суметь сложить хотя бы за 10 минут. Главная проблема в том, что кубика у меня нет; можно купить, но это как-то скучно, на троечку. Поэтому я подумал: а почему бы не написать за выходные простой код, чтобы побыстрее посмотреть и покрутить кубик, а потом уже можно и купить. Заодно и разберусь, где что находится у кубика.

Navigation API предоставляет возможность инициировать (программно запускать), перехватывать и управлять навигацией в браузере. Он также позволяет исследовать (traverse) сущности истории (history entries) приложения. Это улучшенный вариант предыдущих возможностей веб-платформы, связанных с навигацией, таких как History API и window.location, который решает их проблемы и специально предназначен для одностраничных приложений (single-page applications, SPA).

Заключительная часть серии статей про Laravel + Centrifugo и как его готовить.

Сравниваем альтернативы Centrifugo для Laravel: Reverb, Pusher, Ably, Socket.IO, SSE и polling. Разбираем плюсы, минусы и сценарии выбора real-time решения.

Начинаете писать E2E-тесты? Думаете, нужно просто открыть страницу, нажать кнопку и написать expect?

Разберем на примере Playwright, почему отчёт может быть зелёным, но бесполезным.

Меня зовут Иван Некипелов, я технический руководитель команды фронтенд инфраструктуры в Wildberries & Russ. Последнии несколько лет мы с командой развиваем архитектуру и инфраструктуру большого frontend-продукта.

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

В статье разберём, как именно раннер решает, что тест прошёл, почему .then без return выполняется уже после теста, почему try/catch в async‑тесте — частый источник ложного зелёного, что не так с forEach и setTimeout внутри тестов и какие инструменты не дают тесту соврать. Примеры на Jest, но контракт у Mocha, vitest и прочих тот же.

Разбираем frontend и эксплуатацию real-time системы на Laravel и Centrifugo: JS client, reconnect, token refresh, HTTP recovery, Nginx, логи и мониторинг.

В этой статье разберём, как правильно организовать публикацию real-time событий в Laravel: почему не стоит отправлять сообщения напрямую из контроллеров, как использовать Laravel Events и listeners, зачем нужны queue jobs, почему afterCommit() критичен для корректности данных и каким должен быть безопасный payload без полной Eloquent-модели.

Каждый, кто пишет Telegram‑ботов на Node.js / TypeScript, знает про библиотеку Telegraf.js. Это был стандарт индустрии. Ключевое слово — «был». Оригинальный репозиторий фактически заброшен майнтейнерами, пулл‑реквесты годами висят без ответа, а сам фреймворк застрял в прошлом.

Пока Telegram один за другим выкатывает масштабные апдейты (Звёзды, Подарки, Бизнес‑аккаунты, Улучшенные медиа), официальный Telegraf не поддерживает ничего из этого.

Мне надоело смотреть на падающие в продакшене боты и городить костыли, поэтому я создал форк — telegraf‑hardened. На прошлой неделе мы выпустили мажорный релиз v6.0.0. Рассказываю, как под капотом устроена обновленная либа.

Это девятая статья про инженерные решения в ONEMIX. Тема узкая, push-уведомления. Но я её давно хотел разобрать, потому что туториалов в интернете много, а production-граблей в них почти нет.

Если коротко, туториал по push выглядит так. Регистрируешь токен через Notifications.getExpoPushTokenAsync(). Отправляешь на бэкенд. Когда приходит пуш — addNotificationResponseReceivedListener ловит тап, навигируешь в нужный экран. Всё.

В реальном мессенджере таких туториалов недостаточно. Появляется десяток узких проблем. Пуш приходит когда юзер уже в этом чате. Пуш приходит когда приложение убито системой. Navigation после открытия из пуша добавляет дублирующийся экран в стек. На iOS звонки идут через отдельный канал VoIP который требует совершенно другой инфраструктуры. Эти грабли я и разберу.

Всем привет! Хочу поделиться, возможно, не новым, но, на мой взгляд, довольно изощренным видом фишинга. Кто-то уже наверняка сталкивался с таким методом, а для кого-то он окажется в новинку.

Real-time без авторизации опасен. Если пользователь может подписаться на чужой канал, он может получать чужие уведомления, статусы заказов, сообщения, события админки или финансовые обновления. В обычном HTTP API такая ошибка выглядела бы как доступ к чужому endpoint. В WebSocket-архитектуре ошибка такая же, просто выглядит менее очевидно.

Разбираем в Centrifugo: публичные и приватные подписки, connection token, subscription token, права доступа и безопасное подключение

Когда локальный стейт в React-модуле начинает расти - разработчик инстинктивно тянется к useReducer+Context. Это работает, пока не перестаёт: ререндеры везде, провайдеры в елочку, логика размазана. В статье разбираю как этот путь выглядит в реальном продакшне на примере редактора субтитров, и почему паттерн Scoped Store на базе Context+Zustand+useRef решает эту проблему чище и проще.

Современная корпоративная разработка — это всегда про компромиссы. Нужно быстро прототипировать, но при этом не потерять в качестве кода. Хочется держать в голове всю архитектуру — и фронтенд, и бэкенд, и контейнеризацию, и тесты. А по факту время уходит на переключение между десятками вкладок, согласование REST-контрактов и разбор ошибок по логам.

В этой статье мы расскажем, как в проекте нейропрототипа модуля Планирования (PlanningProto) мы использовали Cursor — редактор с ИИ, который встроен прямо в репозиторий.

В первой части мы разобрались, что Real-time на Laravel-сайте нужен там, где интерфейс должен получать изменения без перезагрузки страницы: новые уведомления, смену статуса заказа, сообщения в чате, обновления виджетов, события в административной панели. Для таких задач классическая модель HTTP-запроса уже недостаточна, а polling создаёт лишнюю нагрузку на backend. Один из практичных вариантов решения — использовать Centrifugo как отдельный WebSocket-сервер рядом с Laravel-приложением.

В этой статье разберём архитектуру Laravel + Centrifugo: за что отвечает Laravel, какую роль выполняет Centrifugo, как frontend подключается к real-time каналу и как выглядит типовой сценарий публикации события, например при изменении статуса заказа.

Исторически создание карусели в веб-разработке означало использование какой-либо JS-библиотеки. Slick, Swiper, Flickity, Embla Carousel и другие заполняли пробел платформы. Каждая из них увеличивала размер сборки, имела свои особенности обеспечения доступности и накладные расходы на обработку событий. Полный минифицированный пакет Swiper v11 весит приблизительно 140 КБ; даже модульные импорты составляют 40-60 КБ для ядра и навигации. Умножьте это на бесчисленные маркетинговые страницы, галереи товаров в электронной коммерции и макеты с большим количеством медиаконтента, которые зависят от каруселей, и расходы сильно возрастут: долгое время до интерактивности, блокировка основного потока во время инициализации и большой размер передаваемых данных на каждой странице, где используется слайдер.

Разбираем, зачем нужен real-time на сайте, почему polling создаёт лишнюю нагрузку и как Centrifugo помогает добавить WebSocket в Laravel-приложение без разрушения backend-архитектуры.

Привет, меня зовут Александр Богданов, я ведущий фронтенд-разработчик стрима «Программы лояльности» в MWS. Наша команда отвечает за развитие и поддержку продуктов МТС Premium и МТС Cashback. 

На 2025 год у нас было три активных пользовательских витрины, которые использовали разный стек, разные дизайн-системы, по-разному взаимодействовали с бэкенд-сервисами и имели еще целый набор мелких отличий. Из-за этого разработке приходилось поддерживать зоопарк решений и технологий, а также многократно повторять одни и те же действия на разных стеках. Высокие time-to-market и стоимость разработки одной фичи закономерно не устраивали бизнес, поэтому перед нами поставили задачу — перейти на архитектуру микрофронтендов.

В посте расскажу, как мы это сделали с помощью npm-пакетов и какие результаты получили.

Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов.

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

В Telegram он увидит свой видео‑бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения, потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает.

Это боль которая лечится не «правильным useState», а отдельным архитектурным слоем. Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.

 Архитектура «оркестратор + сабагенты» на одном экране: ведущий агент держит план и раздаёт подзадачи изолированным сабагентам.

Один AI-агент в чате – это удобно, пока задача помещается в контекст. Как только она начинает разъезжаться по 30 файлам, четырём ролям и циклу «исследуй – реализуй – отревьюй – поправь», единый чат превращается в свалку: модель путает, какой шаг где, тащит решения из первой задачи в третью и стабильно проседает по качеству начиная с заполнения окна примерно наполовину. Схема «оркестратор + сабагенты» – это инженерный ответ на проблему: один ведущий агент держит план и раздаёт подзадачи изолированным сабагентам с пустым контекстом.

Мы у себя в Veai полгода живём с этой архитектурой в IDE-плагине под JetBrains. За это время накопилось достаточно граблей, чтобы написать честный текст: как это устроено, на каких задачах команда из агентов реально лучше одного, и где она проигрывает с разгромом.