Фронтенд

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

Поэтому некоторые популярные сервисы вообще запрещают звонки из мобильного браузера и просто отправляют пользователя устанавливать нативное приложение.

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

Сегодня мы сравним основные фреймворки: их плюсы и минусы, поделимся своим опытом работы с каждым и поможем понять, какой же лучше выбрать для своего проекта?  

Тестировать вручную увлекательно только в первый раз. Но потом это все больше превращается в рутину, ты устаешь от однообразия, а взгляд начинает замыливаться. Это естественно для человека. Что же с этим можно делать? Можно автоматизировать.

E2E — это тестирование сквозного бизнес-процесса глазами пользователя: от входа в систему до финального действия. В этой статье мы сравним три фреймворка — Selenium, Cypress и Playwright — на основе личного опыта и технических особенностей, чтобы помочь вам сделать осознанный выбор.
 
Зачем автоматизировать UI и почему не мобилку? 

Почему UI? Веб-интерфейсы — основной канал взаимодействия для большинства корпоративных и B2C-продуктов. Их стабильность критически важна.

А почему не мобильные приложения? Автоматизация мобильного тестирования — это дорого. Нужен «зоопарк» реальных устройств или сложные симуляторы, поддержка двух платформ (iOS/Android), а стоимость и сложность поддержки часто перевешивают выгоду. Для многих проектов ручное мобильное тестирование остаётся оптимальным. Поэтому сосредоточимся на вебе.

Selenium

Самый популярный фреймворк. Это как конструктор. То есть огромная система, которую ты сам строишь и сам делаешь как надо. Единственная ее проблема в том, что поддерживать и настраивать ее довольно непросто. И для того, чтобы она работала, нам нужны драйвера (Selenium WebDriver), которые нужно периодически обновлять. Конечно, это можно обойти с помощью драйв-менеджера, но это тоже требует определенных навыков.
 
Сейчас очень популярны два фреймворка: Cypress и Playwright

Привет!

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

JS/TS: Evan You — Vite, Rust, VoidZero; State of JS 2025 и новый интерфейс npm (npmx).

AI: Transformers.js v4 в NPM; тест «заменит ли ИИ опытного дебаггера».

Фреймворки: React — ViewTransition, SSG-сравнение, календарь DayFlow; Angular — обзор v22 и демо проект на Genkit.

CSS и браузеры: гистограммы и подсветка поиска без JS; предпочтения размера шрифта из системы в Chrome.

Доступность и интерфейсы: когнитивная доступность (W3C), combobox vs multiselect, якоря и UX.

Разное: ограничения и вдохновение, «искусство неправильного взаимодействия», репортаж с t-sync.

Сервис‑воркеры сегодня — не экзотика, а рабочий инструмент: offline‑режим, агрессивное кэширование, «живые» обновления и всё такое. Под это уже давно есть отличный, проверенный Workbox, и я сам с ним работал.

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

Поэтому я написал @budarin/pluggable-serviceworker — не вместо Workbox, а как более лёгкий, типизированный и прозрачный рантайм для тех случаев, когда хочется полной управляемости и минимально возможной когнитивной нагрузки.

Бьюсь об заклад вы привыкли к инструментам разработчика в Chrome. Ежедневная проверка вёрстки, просмотр логов или анализ загрузку страницы делается на автопилоте. Но что если есть альтернатива, которая в некоторых моментах работает иначе и часто даже лучше?

Инструменты разработчика в Firefox создавались отдельно и имеют свою историю. Их команда не ставила задачу сделать копию Chrome. Вместо этого они сфокусировались на своих идеях о том, как сделать отладку более наглядной. В результате некоторые вещи там реализованы более прямолинейно и понятно. Конечно, не всё идеально, и у Chrome есть свои преимущества. Об этом сегодня и поговорим.

В этой статье мы посмотрим на Firefox DevTools в деталях. Отойдем от банальных соревнований в стиле «у кого DevTools длиннее». Вместо этого разберем, в каких ситуациях панель Firefox может сэкономить вам время, а в каких всё же удобнее остаться в Chrome. Откроем для себя несколько приёмов, которые можно добавить в свою ежедневную работу, независимо от браузера.

Привет, Хабр! Меня зовут Сергей, я фронтенд-инженер в Банки.ру.

В этой статье расскажу, как Zod помог нам перестать писать валидацию на уровне полей, подружился с React Hook Form и стал единым источником правды о структуре данных.

К Zod мы пришли не сразу. Долгое время типы и валидация у нас жили в разных слоях приложения: TypeScript определял структуру данных во время разработки, а отдельные функции или библиотеки (вроде Yup) проверяли входящие значения в рантайме.

Это классическая проблема: дублирование логики и рассинхрон. Типы в interface поменялись, а валидация осталась прежней (или наоборот). Мы пробовали Yup, но он казался громоздким в связке с TS: типы приходилось выводить вручную или мириться с тем, что схемы выглядят непрозрачно. В какой-то момент стало непонятно: зачем тащить отдельную библиотеку, если проще написать if (typeof x === 'string')?

С переходом на Zod всё стало значительно проще: одна схема одновременно является и валидатором, и источником типа данных.

Как любой другой язык программирования, JavaScript позволяет создавать элементы доступные в любом месте приложения. И, как и с другими механизмами, JS тут имеет свои уникальные, но важные особенности, которые мы подробно сейчас рассмотрим.

Глобальная область видимости может принимать различные формы в зависимости от того как загружаются код JS...

Решил один мой коллега (не разработчик) заняться пет-проектом: создать платформу с элементами соцсети и встроенным картографическим плагином. И вот приходит этот коллега ко мне с вопросом по части фронтенда: «А как бы мне отрендерить страницы: на сервере или на клиенте?», описывая то решение, которое он уже сделал и которое в целом работает.

Что ж. Меня зовут Андрей, я фронтенд-разработчик в Selectel. В этой статье я расскажу и покажу, какие виды рендеринга веб-страниц существуют и в каком случае лучше использовать тот или иной подход. Разберем все это дело на примерах. Сперва пройдемся по теоретическим основам, а затем — по практике. Если так сложилось, что и вас жизнь привела к подобным фронтендерным запросам, но должного опыта еще нет, добро пожаловать под кат.

Как заставить летать список из 5000+ товаров на странице? Нативный рендер кладёт вкладку, а все базовые оптимизации уже сделаны.

Разбираем послойно: внедрение React Compiler (React 19), виртуализация через TanStack, гибридное кэширование (Redis + unstable_cache) и архитектура работы с анонимными пользователями без лишних запросов к БД. Работа над ошибками, которая ускорила проект в разы.

Этот cказ о том, как мне надоело приглядываться к раскладке клавиатуры, и я решил проблему попутно освоив нестолько фичей в программировании и не только

Есть одна маленькая, но изматывающая боль, знакомая почти каждому, кто много печатает. Ты смотришь на экран, пальцы уверенно бегут по клавиатуре, мысль сформулирована… и на выходе получается:

Всем привет, меня зовут Паша и я Head of QA. Ну… был им до недавнего времени. Мы оказались в банальной ситуации: проект пришлось приостановить по независящим от нас причинам — и я снова оказался «в поиске интересных возможностей».

И опять упёрся в саму парадигму найма. Бесконечная война соискателей и рекрутеров: одни не могут нормально рассказать, что умеют, вторые не знают, кого искать. В итоге ищут не человека, а функцию — и важно не то, как ты думаешь, а какие теги у тебя есть, чтобы пройти фильтры ATS. Эта парадигма ломает саму суть задачи найма.

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

Так появилась идея сделать собственный сайт. Не классическое резюме и не список технологий, а персональную визитку, более ориентированную на техлидов и C-level, чем на эйчаров и автоматические фильтры. Сам сайт я хотел сделать нескучным и изначально видел в голове в стилистике окна персонажа из Fallout 2 — с атрибутами, самооценкой скиллов, перками, и ироничным описанием.

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

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

Если хотите — вот сайт: pavel.rocks (для полного погружения лучше смотреть с десктопа, под мобилу я постарался адаптировать на современный лад).

А под катом — подробный рассказ о процессе: как я к этому подошёл, на какие грабли наступал, почему мобильный адаптив оказался сложнее, чем весь остальной сайт, и при чём здесь дихотомИИя. Ну или просто заходите, если вы любите Fallout 2 так же как я.

У нас случилась классика: бэкенд уже отдает данные, бизнес ждет экран «вчера», а фронтендера в команде нет и ближайшие фронты заняты.

Мы рискнули и собрали MVP‑интерфейс за неделю — без выделенного фронта, но на корпоративном стеке (Vue/TypeScript) и с дизайн‑системой.

Это не история «AI все сделал». Это история про то, как правила + дизайн‑система + ревью как для джуна могут делать из AI‑ассистента нормальный инструмент, а не генератор мусора.

Когда заходит разговор про WebAssembly, где-нибудь в начале дискуссии обычно появляется комментарий в духе «А что, собственно, произошло?»

Этот язык преподносили как нечто поворотное. Неужели это просто был яркий маркетинг? А может, очередной случай с обречённым на провал апплетом JVM?

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

Всем привет, на связи снова я — Дмитрий, React-разработчик. Сегодня хочу рассказать об интересном баге, который был замечен в большой и сложной таблице.

Проблема заключается в том, что в таблице на React с колонками, у которых есть свойство position: sticky, иногда пропадала граница между соседними ячейками по вертикали. Причём проявлялась она не всегда и носит случайный характер. Забавно, что изменение масштаба страницы (Ctrl + колесико мыши) мгновенно возвращает исчезнувший бордер. При этом в CSS все прописано и никуда не исчезает — это чисто визуальный баг рендера.

Пару лет назад в CSS произошла тихая революция, вызвавшая тектонический сдвиг в разработке интерфейсов. Вкратце — нам разрешили «сверлить» настоящие дырки в блоках.

Создание блоков с вырезами всегда было трудоёмким, даже для вырезов простейшей формы. Фронтендеры годами тренировались мысленно рассекать блоки на части: прямоугольничек для контента, прямоугольничек для выреза и ещё парочка рядом с ним. И вдруг парадигма поменялась...

Простые вырезы теперь делаются в десять раз быстрее. Одной строчкой кода. Да, надо менять мышление и забывать про нарезку блоков. И как же это приятно!

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

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

Но в процессе внедрения, произошло то, чего никто не мог предугадать. Я полюбил вашу технологию. И теперь я здесь, чтобы дать вам шанс исправиться, указав вам на ваши проблемы.

Моя главная претензия к современному реактивному сообществу проста: вы потеряли фундамент. Вы строите небоскребы на болоте, игнорируя три фундаментальных правила игры, которые заложили авторы библиотеки.

Обзор на браузерные API, которые стали Widely available в январе 2026. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде.

Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем. 2.5 года назад также каждый месяц выходили новые фичи в браузере, а вот их уже пора начинать применять.

У меня постоянно открыто несколько окон Хрома с множеством табов. В одном - десяток табов с медленными запросами в наш BI-сервис, которые я "вот-вот посмотрю". Во втором - исследование нюансов $lookup и $unwind в MongoDB. В третьем, где больше всего вкладок, - санкт-петербургские правила зачисления в школу, потому что жизнь.

Расширения для сохранения табов науке давно известны, но в отзывах регулярно жалуются на потерю данных - и почему же не сделать свой велосипед, заточенный под бэкап?

У каждого пользователя Chrome уже есть Google-аккаунт, и чаще всего с включённой синхронизацией. Использовал его - и получился Tab Saver с бэкапом вкладок без регистраций и смс!

Использовать синхронизацию в гуглоэккаунт просто и, опять-таки, - без регистраций и смс. Пробуйте!

Что должен делать разработчик, чтобы проект, над которым он работает, не имел проблем? Очевидно — нужно просто исправить все баги и больше не писать новых. 

Хорошая попытка, но в реальности и для существующего сервиса скорее всего потребуется ещё несколько шагов, чтобы радикально уменьшить количество открытых багов. В том числе нелюбимое многими разработчиками — начать писать тесты. Зачем этим должны заниматься сами программисты, почему нельзя всё переложить на AI, с чего начать и каким принципам следовать, расскажу в статье.   

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

В этой статье — история трансформации 2ГИС ПРО: от перегруженного картографического интерфейса для гиков до гибкой платформы, где любой может собрать себе рабочее пространство под конкретную задачу.

Расскажу, как мы:

• отказались от устаревших слоёв в пользу виджетов,
• пересобрали интерфейс вокруг единого дашборда,
• внедрили независимую логику для виджетов,
• переехали на сетку, виртуализацию и архитектуру, вдохновлённую микросервисами,
• сделали миграцию незаметной для пользователей.

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