Всем привет! Меня зовут Анатолий, я представляю команду Front-End разработки компании DD Planet.
В этой статье расскажу о том, как наш проект завершил этап разработки и трансформировался в стабильный рабочий продукт.
Хотя различия в скорости работы CSS-селекторов хорошо документированы, на практике разработчики часто недооценивают их влияние на производительность. В этой статье мы количественно оценим, как некорректный выбор селекторов замедляет работу приложения, и систематизируем ключевые принципы оптимизации CSS.
React — самый популярный фреймворк среди фронтенд‑разработчиков. Его подходы к разработке приложений часто воспринимаются как единственные правильные. Но что, если такие «стандарты» — это не необходимость, а вредная привычка, ломающая Developer Experience?
В статье разберем типичные проблемы Developer Experience в React: избыточный бойлерплейт, сложность управления состоянием и неочевидные оптимизации производительности. Покажем, как эти же задачи решаются в Svelte и обсудим, как смена фреймворка может упростить разработку.
Статья будет полезна разработчикам, которые хотят расширить свой кругозор и критически переосмыслить привычные подходы к фронтенд‑разработке.
Большинство людей не задумывается о случайном наборе букв и цифр, выдаваемых им Департаментом транспортных средств.
Но я не такой.
В Интернете я всегда стремлюсь получить понятный и запоминающийся цифровой идентификатор. Многие годы мне удавалось подбирать идентификаторы в виде моего имени + фамилии в Instagram* (@jlaf) и осмысленных слов на других платформах (@explain, @discontinue). Поэтому когда ДТС в третий раз прислал мне письмо с напоминанием о необходимости обновления номера, у меня сработал тот же инстинкт: почему я даже не задумался о том, чтобы получить номер с красивым сочетанием символов?
В Codex появилась экспериментальная фича — skills: декларативное описание локальных «навыков» агента с автоматическим discovery и строгими правилами применения. В статье разберём, как это работает под капотом, зачем нужно и как использовать это в своих проектах.
Принимая архитектурные решения, часто так или иначе приходится идти на компромисс: между качеством и скоростью разработки, сложностью реализации и удобством поддержки, быстротой решения бизнес-задачи и гибкостью. Со временем небольшие уступки накапливаются и проект покрывается легаси. Даже если исправно разгребать техдолг, то в любом случае на достаточно длинной дистанции решения и технологии устареют, и станет невозможно обойтись «генеральной уборкой» — потребуется смена архитектуры.
В статье расскажу, как мы столкнулись с неизбежной необходимостью переделки веб-плеера RUTUBE — сервиса, который существует с 2006 года, пережил несколько смен команд и парадигм разработки и при этом достаточно большой и высоконагруженный, чтобы нельзя было «просто так взять и всё переписать».
Сегодня я рассмотрю несколько специализированных сервисов для хостинга фронта, среди которых не будет однотипных VPS. Только узкоспециализированные решения для хостинга сайтов.
Мне хотелось ответить на вопрос, какой сервис будет лучшим для конкретного, узкого сценария и стека, а не просто перебрать очевидные сервисы, которые популярны, но не имеют своей специализации.
Это интервью — разбор реального опыта миграции фронтенда Compo B2B Platform с Angular 13 на актуальные версии фреймворка (в итоге — Angular 19). Команда Compo Soft прошла путь через несколько мажорных апдейтов, замену и переписывание зависимостей, рефакторинг архитектуры и внедрение новых возможностей Angular — от Standalone Components до Vite и non‑destructive hydration.
Представьте, что вы нажимаете кнопку «Отправить заказ» в интернет-магазине. Если страница зависла, вы нажмёте её ещё раз. Идемпотентная система обработает повторный запрос так, что вы не получите два одинаковых заказа и с вашей карты не спишутся деньги дважды. Неидемпотентная — создаст два заказа и спишет средства дважды.
Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Так как при использовании Feature-Sliced Design (FSD) возникает много вопросов и разные люди понимают её по-разному, я решил написать статью-справочник, раскрывающий некоторые подробности методологии. В этой статье я продолжаю использовать те же принципы и часть терминологии, что и в предыдущей.
Здесь я, в основном, описываю структурирование по правилам методологии. А в следующей статье, напротив, рассмотрю, как можно улучшить структуру проекта, намеренно нарушая правила FSD. Заранее предупрежу, что правила методологии носят рекомендательный, а не обязательный характер. Их назначение — задать направление структурирования, а дальше принимать решения нужно в зависимости от конкретного проекта и ситуации в нём. Строгое же следование правилам может привести к бо̒льшим проблем, чем их нарушение.
Если заметите ошибки — пишите в комментариях!
Привет, Хабр!
Выгорание операторов — распространенная проблема в кол-центрах. По разным оценкам, текучесть персонала здесь достигает 40–45%, а средний срок работы составляет 8–12 месяцев. Это приводит к дополнительным расходам на обучение, росту нагрузки на команду и снижению качества сервиса. При этом заметные изменения в поведении сотрудников обычно фиксируются слишком поздно — когда проблема уже стала системной.
Я Катя Саяпина, менеджер продукта МТС Exolve. В этом материале разберу способ раннего обнаружения таких изменений. Он опирается на статистические отклонения в поведении оператора и дополняет прямое общение с сотрудниками и сбор обратной связи в команде. Мы создадим на Python сервис, который объединит Telegram-бота, API МТС Exolve и LLM, развернутую на платформе MWS GPT.
Сегодня многие живут в формате «сидячей работы» — неважно, офис это или диван дома. Часы за ноутбуком проходят незаметно, а тело в это время терпеливо копит напряжение и усталость.
У меня с этим длинная история, но был один момент, который оказался переломным. Несколько лет назад я сменила режим работы, не оставив себе ни дня на нормальный отдых. Мой день выглядел просто: кровать — ноутбук — кровать. На любые «тренировки для сидячих сотрудников» не было ни сил, ни желания. И однажды всё закончилось так, как обычно и заканчивается — внезапно. Я наклонилась поднять пакет с продуктами и словила жёсткий зажим поясницы. Неделя обезболивающих, минимум движения и максимум тревоги заставили признать очевидное: так жить нельзя.
Опыт был болезненный, но показательный. И именно он научил меня тому, о чём я хочу рассказать в этой статье — как вернуть телу силы без часов в зале, без героизма и без «новой жизни с понедельника».
Каждая успешная рекламная кампания начинается с технологий, которые остаются за кадром. Но именно от них зависит, увидит ли целевой пользователь нужное объявление, сможет ли рекламодатель быстро настроить кампанию и получить точный отчет, и не сгорит ли его бюджет из-за мошенников или технических сбоев. Когда мы начинали проект AdWebs, нам нужно было создать платформу, которая справится с тремя ключевыми вызовами: высокая нагрузка, безопасность данных и безупречный пользовательский опыт. Вот как мы это сделали.
JWT, SSO, OAuth, OpenID Connect — названия знакомые каждому разработчику. Но стоит спросить: «Зачем в продакшене нужен JWKS?» или «Чем отличается OAuth2 от OpenID Connect?» — уверенность сразу исчезает.
В этой статье мы разберём как устроен JWT и его подпись, зачем нужны access и refresh токены, что такое JWKS и в чём отличие OAuth от OpenID Connect.
Вместо скучных стандартов и спецификаций протоколов в статье будет один наглядный образ на примере отелей и пропусков. Это позволит не только запомнить, но и прочувствовать на реальных примерах, избавиться от хаоса и путаницы в голове, когда речь заходит об аутентификации и авторизации. Цель статьи — не дать «рецепт внедрения», а дать возможность понять, как это работает внутри и «пощупать» эти темы на Go.
Залипающий hover на мобильных устройствах – частый баг. Раньше мы решали это просто плагином PostCSS Hover Media Feature, он оборачивает все псевдоклассы :hover в медиазапрос @media (hover: hover) {}. Так мы проверяли поддержку hover и отключали его на мобилках. Но во время тестирования одного проекта оказалось, что на некоторых устройствах hover продолжает залипать.
В 2013-м я получил свою первую вакансию джуна. Требования: PHP, MySQL, jQuery. Всё. Я открыл tutorial, за выходные накодил todo-лист, через месяц уже чинил баги в проде.
Вчера смотрел вакансию для джуна. Требования занимали два экрана. Node.js ИЛИ Python ИЛИ Go. React ИЛИ Vue ИЛИ Angular. PostgreSQL + Redis + MongoDB. Docker обязательно. Kubernetes — плюсом. GraphQL знание приветствуется. Плюс микросервисы, CI/CD, облака...
Я посчитал: чтобы формально соответствовать этой вакансии, нужно изучить минимум 15 технологий. На поверхностное изучение каждой — месяц. Итого больше года непрерывной учёбы. Для позиции джуна.
А что сейчас?
Сейчас — это Node.js, Deno, Bun для JavaScript-бэкенда. Go, Rust, Elixir для хайлоад. Python с FastAPI, Django, Flask. Kotlin, Java, Scala для enterprise. Плюс Ruby, PHP (еще жив), C#/.NET... И это только языки и рантаймы. А еще базы: PostgreSQL, MySQL, MongoDB, Redis, Cassandra, ElasticSearch. Очереди: RabbitMQ, Kafka, NATS. Контейнеризация: Docker, Kubernetes, Helm. CI/CD: GitLab, Jenkins, GitHub Actions, CircleCI. Облака: AWS, GCP, Azure.
Бедные джуны. Хотя нет — бедные мы все. Даже опытные разрабы теряются в этом океане, когда делают шаг в сторону. Зоопарк технологий растёт экспоненциально. И вопрос "с чего начать?" и "куда двигаться?" превращается в настоящий паралич выбора.
Привет, Хабр!
В мире фронтенда активно всё меняется. Появляются одни инструменты, но только их выучишь — они устаревают, и нужно уже учить новые. Новые методы и API в JavaScript. Даже в HTML появляется что-то новое. И, конечно, CSS не отстаёт.
В общем не удивительно, что люди забывают или не успевают услышать о возможностях в CSS. В этой статье я постараюсь показать несколько из их, которые считаю полезными.
Давайте посмотрим, что я вам подготовил.
Всем привет, я сооснователь мессенджера Пачка и отвечаю, в том числе, за маркетинговую инфраструктуру.
Нам нужно было оперативно увезти наш сайт с Webflow: 500+ страниц, блог и база знаний. При этом возвращать фронтенд-разработку в режим постоянной поддержки сайта мы не хотели. Поэтому рассматривали конструкторы и CMS, но быстро поняли, что это будет работа в минус. Все усилия на переезд лишь вернули бы сайт в рабочее состояние, не дав новых возможностей.
В итоге мы решили вести разработку и поддержку сайта в Cursor. То есть переписать его на NextJS с помощью AI агентов. Такая связка дала понятную модель страниц, быструю доставку статики и ISR для контента, а также возможность отказаться от отдельной CMS за счёт MDX.
В спокойном режиме за два месяца удалось полностью переписать сайт и запустить его в прод. Ниже делимся практическим опытом этого переезда.
В этом посте будут объяснены две стратегии оптимизации WebAssembly, которые не так давно были реализованы в движке V8 и вошли в версию браузера Google Chrome M137. Речь пойдёт о спекулятивном встраивании call_indirect inlining и о поддержке деоптимизации в WebAssembly. В сочетании два этих приёма помогают генерировать более качественный машинный код, так как основаны на допущениях, которые строятся, исходя из обратной связи, поступающей от среды исполнения. Благодаря этому, WebAssembly выполняется быстрее, особенно это касается программ WasmGC. Например, проверив эти приёмы на наборе микробенчмарков, написанных на Dart, видим, что комбинация двух оптимизаций даёт ускорение в среднем более чем на 50%. В более крупных и реалистичных приложениях и на тех бенчмарках, которые рассмотрены ниже, достигается ускорение между 1% и 8%. Деоптимизации — также очень важная составляющая для дальнейшей оптимизации в будущем.
Когда вы заходите на сайт, ему нередко нужно знать, какой у вас браузер и устройство. Это помогает показывать подходящую версию страницы, например мобильную или полную, а также включать только те функции, которые может поддерживать ваш браузер.
Раньше для этого можно было использовать только строку User‑Agent, которую браузер отправляет автоматически, но её избыточность и сложность парсинга стали сдерживать развитие веба. Client Hints предлагает другой подход: вместо того чтобы сразу раскрывать всю информацию, браузер передаёт только те данные, которые действительно нужны сайту.
На связи Степан из команды Яндекс Браузера. Сегодня поговорим о том, как мы переходим от устаревшего User‑Agent к современной технологии Client Hints. В статье разберём, почему User‑Agent стал проблемой, как работают хинты под капотом и какие перспективы у перехода на новую технологию.
