Веб-разработка *

Intl API широко доступен (за исключением Intl.DurationFormat, который работает во всех современных браузерах, но существует недостаточно долго, чтобы считаться «широко доступным») и может удовлетворить почти все требования к форматированию непосредственно в браузере, без загрузки кода и без необходимости его парсинга. Он также учитывает языковые предпочтения пользователей, поэтому даты и числа можно форматировать так, как им удобно, без дополнительных усилий.

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

Меня зовут Михаил Рыбочкин, я бэкенд-разработчик в компании GRI. Участвую в разработке и поддержке платформы для крупного ювелирного ритейлера. Я расскажу, как реализован Server-Driven UI для интернет-торговли с более чем 1000 розничных магазинов; как устроено управление конфигурацией интерфейса через Django Admin и как это позволяет менять интерфейс без релизов приложения; какие у этого подхода есть ограничения и какой инцидент произошёл в эксплуатации. Особенность нашего подхода в том, что SDUI одновременно обслуживает и нативные мобильные приложения, и веб на Vue. Один конфиг, один API, две целевых платформы

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

Разработчики сталкиваются с выбором: использовать CSS Modules или CSS-in-JS решения. Эти подходы дают изоляцию стилей и интеграцию с компонентами, но различаются по реализации и ограничениям.

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

Данная статья не ставит цель назвать одного победителя. Вместо этого мы сравним основные подходы - CSS Modules и CSS-in-JS. 

Я устал каждый раз гуглить одно и то же в nginx — и сделал инструмент, который объясняет конфиги на русском

Очередной генератор nginx-конфигов? Нет. Ну, почти нет.

Использование ИИ в разработке давно вышло за рамки генерации простых функций. Для крупного финтеха это вопрос системной интеграции и безопасности. В ИТ-кластере «СВОЙ Тех» мы постоянно ищем способы оптимизации Time-to-Market. В этом материале мы делимся опытом того, как заставить нейросети работать с легаси-кодом, зачем им доступ к Figma через MCP-протокол и почему будущее за Spec Driven Development.

Coolify это бесплатный инструмент, который позволяет легко запускать приложения на ваших серверах и управлять ими через визуальный интерфейс.

В прошлых статьях мы уже разобрались, как подготовить сервер, затем установить на нём Coolify и запустить простые приложения из GitHub.

А сегодня посмотрим, как с помощью Coolify создать базу данных на своем сервере и какие преимущества это даёт.

Всем привет! Меня зовут Евгений Оселедец, я ведущий разработчик в компании Axenix. В этой статье расскажу, как мы упаковали React и Java в единое автономное desktop-приложение с помощью Electron для Windows, Linux и macOS — без Docker, без предустановленной Java у пользователя и без необходимости интернет-соединения. Расскажу, с какими техническими вызовами мы столкнулись и какие решения сработали на практике.

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

С 30 мая 2025 вступил в силу Федеральный закон от 30.11.2024 № 420-ФЗ «О внесении изменений в КоАП РФ», пунктом 10 которого установлена ответственность за невыполнение или несвоевременное выполнение оператором персональных данных обязанности по уведомлению уполномоченного органа по защите прав субъектов персональных данных о намерении осуществлять обработку персональных данных.

А теперь перевожу с юридического на человеческий все важные нюансы указанного нововведения ↓

Всю свою карьеру разработчика я пользовался Postman. Помню его ещё простым расширением Chrome, слегка облегчавшим тестирование API. Жизнь в времена была гораздо проще. Сегодня я присоединяюсь к растущей толпе разработчиков, отказывающихся от этих инструментов, потому что они продались.

Великое предательство: как наши любимые инструменты обернулись против нас

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

Postman, когда-то бывший любимцем всех разработчиков, стал наглядным примером такой трансформации. Переломным для многих моментом стало удаление Scratchpad (офлайн-режим). После этого — снижение производительности и привязка к облачному сервису. Внезапно мы оказались вынуждены синхронизировать свою работу с облаком Postman для доступа к базовому функционалу (привет, Microsoft?). Во-первых, это вставляет палки в колёса разработчиков, работающих над конфиденциальными проектами в сфере банкинга и здравоохранения, а также в государственном секторе. В этом и есть смысл — заставить их платить за инструмент, максимизировать прибыль руководства, поэтому наносимый отрасли сопутствующий ущерб не учитывается.

Недавно я внедрил blue‑green деплой в проде. Реализация довольно простая и кастомная, но справляется со своей задачей на ура! Также сообщу, что используется обычный докер композ на виртуалке — возможно, кому‑то такой подход будет полезен.

Для фоновых процессов (воркеров)

В приложение добавляется специальный инфрастуктурный singleton класс с флагом is_accepting, и обертка на consumers. В каждом консьюмере перед обработкой проверяем этот флаг: если True — обрабатываем задачу, если False — переносим задачу на повторную обработку (например, в rabbitmq делаем сразу nack(requeue=true))

Привет! Меня зовут Максим Иванков, я развиваю школы программирования и робототехники для детей уже 9 лет. Сегодня расскажу про то, над чем работал последние 9 месяцев с перерывами — про свой собственный скрейч. Назвал я его Кубоша. Это визуальный редактор блочного программирования в стиле майнкрафта, в который я встроил задачи с автоматической проверкой и интегрировал в свою онлайн школу.

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

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

С формами в Next.js проблема обычно начинается не на уровне кнопки submit. Кнопка как раз почти всегда работает. Настоящая путаница начинается позже, когда форма уже живёт в проекте какое-то время. В одном месте ошибка показывается под полем, в другом только общей строкой сверху. Где-то кнопка блокируется на pending, а где-то можно отправить запрос несколько раз подряд. Клиент считает данные валидными, а сервер отвечает, что правило нарушено. Поле уже зелёное, а сохранение всё равно не прошло. В этот момент становится видно, что форма была собрана как кусок UI, а не как контракт.

Используем как примеры паттерны из проекта Workbench. Полезно смотреть на форму не как на набор input и submit, а как на договор между UI, валидацией и местом записи данных. У такого договора есть простая форма - какие данные считаются допустимыми, где и как они проверяются, в каком виде ошибка возвращается в интерфейс, что происходит на pending, когда форма блокируется, что считается успехом, а что общей ошибкой, не привязанной к конкретному полю.

Как только форма описывается так, код перестаёт расползаться. И здесь Zod в Next.js даёт не просто удобную схему, а способ удерживать client и server в одном наборе правил.

Привет. Я фронтенд-разработчик. По мнению тех, кто, по мнению некоторых, перекладывает джейсончики туда-сюда, я крашу кнопочки. Но сам я себя идентифицирую иначе: я тоже перекладываю джейсончики, и у меня всё точно так же, как у них. Даже архитектура. У меня тоже есть контроллеры, сервисы и хранилища, и я также обрабатываю запросы пользователей. Даже больше, я делаю HATEOAS, «тру» RESTful, если хотите. Давайте расскажу, как я к этому пришел.

Когда-то давно я только верстал. Накидывал разметку, добавлял классы, идентификаторы и стилизовал ЦСС-ом. И было хорошо. Потом от меня потребовали динамичности — пришлось добавить JavaScript. И было очень хорошо.

Технологии развивались, и мне хотелось пробовать новое. Я попробовал AJAX. Это было так волнительно... Я сказал бэкендерам: основную разметку жду от вас, а опции для выпадающего списка, например, отдавайте джейсоном по запросу. Они были не в восторге. «Одному HTML подавай, другому CSV, третьему ещё что-то — безобразие!» Но мы нашли компромис. Бэкэндеры сказали: «Вот вам, мол, джейсон, дальше сами как-нибудь». И назвали это REST API.

Сначала было очень круто! Мы, верстальщики, организовались. Мы стали фронтендерами! Конечно же, мы сразу побежали решать ещё нерешённые сто раз решённые задачи. Мы писали библиотеки и фреймворки — четыре миллиона штук! Да у нас даже есть библиотека с функцией для умножения чисел — lodash.multiply. Мы придумывали свои паттерны и архитектуры, например FSD. Короче, мы стали очень крутые.

Но то уже были «мы», а не я. Мне было сложно. Шутка ли, изучать по одному новому фреймворку в неделю? А ведь еще переписывать всё надо, стек-то устарел... В общем, в какой-то момент я перестал поспевать за модой и справляться со сложностью. Переходишь из одного проекта (на React) в другой (на Vue), а там всё иначе. Берешь нового разработчика в команду с опытом в React, например, а ему нужно время, чтобы вникнуть, потому что в его старой команде был другой «стейт-менеджер». Вавилон, никто друг друга не понимает.

Около года назад моё желание кастомизировать десктопный клиент популярного музыкального сервиса привело меня в некое сообщество. Всё началось с попытки восстановить заброшенную тему «Blurity» после очередного обновления Electron-хоста, которое сломало все селекторы. Но проект быстро перерос рамки обычных правок CSS.

В этой статье я расскажу, как ChromaSync эволюционировал из простого визуального патча в полноценную инженерную систему — runtime-аддон со сложной архитектурой. Мы разберем «анатомию» плеера, создание декларативной системы из 70+ настроек и перенос тяжелой математики аудиореактивных эффектов в изолированное ядро на WASM. Это история о том, как 700 строк JavaScript превратились в 10 000, а обычная «разукрашка» — в оптимизированную экосистему, умеющую балансировать между визуальной насыщенностью и производительностью системы.

Рефакторинг должен быть скучный и надежный. Надо держаться от искушения обновить библиотеку, починить баг, улучшить стиль. Под катом разбор почему именно такой путь сможет вытянуть тяжелый legacy рефакторинг, а шаг вправо и влево ведет к откату релиза.

Мы сделали интерактивный дом-таймлайн про телевидение 90-х и 00-х. Под катом: как команда без разработчиков дошла от JSON-файла на VPS за до корпоративного Kubernetes

У меня был один телефон, на котором я создавал проект, редактируя файлы в nano.

9 месяцев свободного времени (которого у работающего электрика не так уж много) ушло на то, чтобы из полного нуля сделать работающий P2P-видеосервис.

Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит.

По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025)

При этом исследование Carnegie Mellon выяснило, что наибольшим источником технического долга являются именно архитектурные проблемы — а не баги и не плохой код на уровне функций.

Теперь о Go. По данным Go Developer Survey 2024, главной проблемой команд, работающих с Go, названо поддержание единых стандартов кода — в том числе из-за разного уровня опыта участников и привнесения не-идиоматических паттернов из других языков. (Источник: go.dev/blog/survey2024-h2-results)

Это напрямую про нашу тему: люди приходят из Java, Python, C# и приносят с собой архитектурные привычки, которые в Go не работают. Clean Architecture и DDD — не исключение. Их часто реализуют "как в Java", а потом жалуются, что Go — многословный и неудобный язык.

Давайте разберёмся, как делать это правильно.

Как мы сюда попали?

Представьте: вы начинаете новый Go‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру:

Привет!

Это 13-й выпуск Frontend Status — дайджеста по фронтенд-разработке.

В этом выпуске:

📺 Для тех, кто хочет делать игровые интерфейсы быстрее: видео про 2D-игры с AI и Phaser, где генеративные инструменты работают как напарник, а не как «чёрный ящик».

🤖 В AI-разделе — разбор того, что уже можно брать в прод: micro-ml на Rust/WASM, кейс крупной техкомпании с роем из 50+ агентов, Flint Alpha и практическая интеграция Claude с видео.

🛡️ По безопасности фокус на снижении рисков: прикладной XSS, бесплатная оценка уязвимостей кода от GitHub и дорожная карта крупной техкомпании по постквантовой криптографии.

🎨 CSS-блок про баланс визуала и доступности: почему box-shadow не заменяет outline в forced-colors и как сохранить корректный фокус.

⚛️ React-секция для тех, у кого интерфейсный слой растёт в сложности: управление модалками без хаоса, UI без брейкпоинтов и состояние компонентов через radio state machine.

⚡ В JS/TS — практичный набор без перегруза: Pretext для текста, k-means для палитр, модульная архитектура, Intl API и Web Audio API в Node/Bun.

🅰️ Angular-раздел посвящён Signal Forms в v21 и тому, как перейти к типизированным формам без ручных подписок.

🌐 В стандартах и дизайне — что уже можно внедрять сейчас: CSS Image Animation, Baseline за март, Liquid UI и UX-подходы для legacy-систем.

…и многое другое.