Ниже я приведу примеры, как пустить пыль в глаза юзерам можно улучшить ситуацию с ощущением чужеродности приложения среди других, написанных на честном Gtk, китами из XCode, Windows UWP и прочим с 0% вайбкодинга
Мне часто доводится вести странные споры с фанатами фреймворков о том, действительно ли <div> «столь же хорош», как и <button>.
Спойлер: нет. И давайте выясним, почему.
На основе наблюдений я выделил 5 самых проблемных случая, когда JavaScript блокирует загрузку сайта. В статье вы узнаете, как с ними бороться.
Недавно столкнулся с задачей: нужно было быстро перевести несколько сотен PNG-файлов в WebP для сайта, но делать это через онлайн-сервисы не хотелось — во-первых, передавать изображения куда-то сторонним серверам не очень удобно, а во-вторых, процесс обычно занимает заметное время.
В итоге я сделал небольшое браузерное приложение, которое решает задачу локально — без установки, без серверов и без лишних телодвижений. Делюсь инструкцией, вдруг кому-то пригодится.
Понадобилось мне как-то раз сделать из PWA мобильные приложения. Приключение на 20 минут, зашли и вышли - подумал я и пропал на пару месяцев. В статье будет гремучая смесь из Java, C#, NodeJS, Swift, bash, Dockerfile и github actions. Но в результате возможность непрерывно поставлять свежие сборки в магазины приложений.
Привет! Я — Павел, фронтенд-разработчик, и это мой первый пост на Хабре. На момент публикации мне 34 года, а за плечами — 5 лет опыта в профессии. Уже чуть больше года я работаю в бигтех-компании: делаю новый функционал на React, пишу тесты, провожу код-ревью и периодически тушу рабочие пожары. А в качестве разминки для мозгов разгребаю легаси на смежном проекте и постоянно что-нибудь изучаю. У меня классные коллеги, конкурентная зарплата, ДМС для всей семьи, приятные премии и ощущение каких-то перспектив. Но так было не всегда.
Взгляд на интеграцию ИИ в программирование от опытного программиста (миллион строк кода я, наверное, написал за всю жизнь). Текст писал я сам, это не мусор от GPT, ИИ здесь только исправил ошибки.
Если дать этот текст ИИ на фактчек, то он может как полностью подтвердить мою статью кучей проверенных фактов, так и полностью опровергнуть, и тоже с кучей фактов, т.е. по сути будет заниматься черри-пикингом - всё зависит от формулировки вопроса. И где же тогда правда? Правда, я думаю, у тех, кто в этой среде годами работает и получает много опыта как разработки с ИИ, так и без него. Т.е. имеет хоть какие-то экспертные знания. В этой статье мнение одного из таких людей. Мнения одного человека, конечно, мало, нужно обобщать опыт сотен людей из разных сфер программирования. Я вношу в это обобщение свой небольшой вклад.
Решение на Битрикс24: как мы помогли С‑Маркетингу узнать реальный вклад каждого из 1300+ сотрудников
Цели в блокнотах, Excel и «в голове» превращают стратегию компании в пазл без картинки. Особенно, если речь идет о бизнесе, где больше тысячи сотрудников. Для С-Маркетинга мы собрали этот пазл в единое решение на Битрикс24: сделали постановку и оценку целей прозрачными, а премии и повышения — аргументированными.
API URLPattern официально стал базовой возможностью и доступен во всех основных браузерах с сентября 2025 года. Однако он может не работать на старых устройствах или в старых браузерах. Узнать больше.
Когда требуется функциональность, реагирующая на изменения URL, часто приходится писать сложные регулярные выражения или подключать сторонние библиотеки для маршрутизации. Теперь, когда URL Pattern API вошел в Baseline, у нас появилось стандартное, мощное и универсальное решение для этой задачи.
Решил мигрировать с WebStorm на VS Code, но обнаружил, что нет поддержки автоимпорта Angular-компонентов. В WebStorm это работало из коробки — начинаешь писать <app-, IDE сразу подсказывает компоненты и автоматически добавляет импорт. В VS Code такого не было.
На первый взгляд задача выглядела несложной — пару регулярок накидать и можно сделать своё решение.
Но пока я разбирался с регулярками, Angular-разработчики выпустили официальную поддержку: добавили импорты на автокомплит и диагностику. Можно было опустить руки, но официальная реализация оказалась неидеальной, и у меня было несколько идей фич, которые позволяют сохранить актуальность проекта и приблизить опыт работы к WebStorm.
Однажды при работе с крупной кодовой базой одного фронтенд-приложения я заметил, что функционал постепенно группируется относительно команд (доменов). Каждая из таких групп функционала постепенно накладывает собственные ограничения на архитектуру. Как оказалось, обработка ошибок при сравнении кода двух разных команд неоднородна. В одном случае разработчики структурировали ошибки стандартным наследованием JS/TS, в другом были использованы перехваты возникающих ошибок и логирование.
Стало ясно, что нам требуется обобщить подход к тому, как мы структурируем (называем, наследуем) и выбрасываем ошибки. Как показала практика, соглашений о кодировании недостаточно.
Что мы хотели получить?
Музыканты - ребята творческие. И называют они себя и свои произведения тоже творчески. Иногда так заковыристо, что программистам стримингов и музыкальных сервисов остается только посочувствовать.
Вот, казалось бы, что может быть проще: создать базу треков и исполнителей. Пишем имя артиста/группы, название альбома, список треков и даем возможность по ним искать. Но потом натыкаемся на исполнителя Prince, который изменил своё имя на знак, который не существует и начинаем печалиться, потому что непонятно, как его искать после переименования. Фанаты вроде как нашли выход и предложили использовать 4 спец.символа юникода Ƭ̵̬̊, что тоже похоже на костыль, а задавать старое имя как псевдоним, вроде как концептуально неправильно. Ну или попадаются металлюги Brouillard, у которых каждый альбом называется так же - Brouillard. А каждый трек внутри альбома имеет такое же название.
Но это еще цветочки, потому дальше тесты целостности библиотеки начинают падать, так как в ней попадаются треки длиной либо одну секунду, либо 639 часов. Ну или встречаются треки с нулевым номером, потому что это так называе "секретные" композиции, которые можно было найти включением первого трека и переключением плеера назад. Как вы понимаете, сегодня мы поговорим о музыкальных edge-случаях. Заходите, будет интересно.
Привет, Хабр.
Красивый и интуитивно понятный интерфейс — это моя личная страсть. Я тратил дни, чтобы докрутить свои проекты до нужного мне уровня. В итоге я начал систематически собирать приёмы HTML и CSS, которые мгновенно улучшают восприятие пользователя.
Сегодня я решил показать вам несколько проверенных трюков. Выбрал самые лёгкие в освоении, чтобы вы смогли внедрить их уже сегодня, не отвлекаясь на сложности.
Давайте посмотрим, что я вам подготовил.
Понедельник, утро, открываешь проект, а авторизация на dev-стенде снова сломана. Или же надо поторопиться с релизом фичи, а бэк еще не готов, и разрабатывать нужно параллельно, и тут без моков не обойтись. Ну или классика: в командировке лежит интернет, и вся работа встала колом. Знакомо?
Что тут можно поделать? Можно подождать, пока починят стенд. Можно залезть в код и что-нибудь там нахардкодить, переполнив его ненужной логикой моков. Можно поставить Postman, Insomnia или другие популярные решения. Но у каждого подхода есть подводные камни: простои и сорванные дедлайны, забытые хардкоды в продакшене, необходимость согласований с инфобезом (особенно если вы работаете в банке) и зависимость от внешних серверов.
Мы попробовали существующие решения и поняли: ни одно из них не закрывает наши потребности полностью. Нужно было что-то свое: простое в установке, работающее офлайн, не требующее дополнительных приложений и аккаунтов. Что-то, что можно быстро настроить под себя и не зависеть от внешних решений вендора. Так появился наш велосипед — браузерное расширение Req-Saver.
Да, представимся. Мы — Александр Битько и Дмитрий Панфилов, фронтенд-разработчики в ПСБ. Сегодня расскажем, как превратили мокирование запросов из головной боли в простую и понятную работу.
Этот стартап превращал мух в еду — пока не погас свет
Еда из мух
Компания Inseco должна была стать успешным примером в производстве белка для насекомых в Африке. Вместо этого, спустя семь лет и после seed раунда в $5,3 млн. , компания закрылась и распродала свои активы.
Кэширование — скрытый двигатель, на котором держится веб. Именно оно делает сайты быстрыми, надежными и относительно недорогими в обслуживании. При правильной настройке кэширование снижает задержки, разгружает серверы и позволяет даже хрупкой инфраструктуре выдерживать резкие всплески трафика. При неправильной настройке или полном отсутствии кэширования сайты работают медленно, остаются уязвимыми для атак и обходятся очень дорого.
В основе кэширования лежит сокращение лишней работы. Каждый раз, когда браузер, CDN или прокси обращается к серверу за ресурсом, который не изменился, впустую тратятся время и трафик. Когда сервер заново формирует или повторно отдает идентичный контент, это лишь добавляет нагрузки и увеличивает затраты. А при пиковом трафике — например, в "черную пятницу", во время вирусной публикации или DDoS-атаки — такие ошибки стремительно накапливаются и приводят к сбоям всей системы.
В ИТ любят свободу. Проекты собираются за неделю, команды работают из разных часовых поясов, и мысль о том, что всех нужно оформить в штат, звучит как нечто из другой эпохи. Гибкость - это ведь суть всей индустрии: не держать, а подключать. Аутстафф стал естественным продолжением этой логики. Появился запрос - подключили двух разработчиков через партнёра, подписали договор, оплатили часы, и всё по-честному.
Но с точки зрения закона это далеко не всегда так просто. Аутстафф живёт где-то между аутсорсом, фрилансом и трудовым наймом, и от того, как именно выстроены отношения, зависит, на чьей стороне окажется инспектор. И вот здесь многие бизнесы начинают спотыкаться: формально всё чисто, а по сути нет.
Если убрать красивые слова, аутстафф - это ситуация, когда один работодатель «предоставляет» своих сотрудников другому. Формально они числятся в первой компании, а трудятся у второй. Для IT это удобно: не нужно расширять штат, платить взносы, вести кадровые документы, оформлять отпуска. Можно собрать проектную команду из десяти человек за два дня.
Но инспекции и суды такие конструкции воспринимают с настороженностью. Причина проста: слишком часто под аутстаффом прячут обычные трудовые отношения, чтобы сэкономить на налогах. ФНС и трудовая инспекция научились это видеть. Им не нужны слова «гибкая модель» и «оптимизация», они смотрят на то, кто управляет человеком, кто даёт задачи, кто несёт ответственность за результат и кто получает от этого прибыль.
Если разработчик сидит в офисе заказчика, имеет корпоративный e-mail, доступ к Jira и Confluence, участвует в стендапах, слушает руководителя проекта и работает по внутреннему графику, то все разговоры о том, что он «чужой сотрудник», бессмысленны. Он ваш.
Даже если у него в трудовой записано другое юрлицо, даже если все деньги проходят через подрядчика.
Что важно фронтенд-разработчику при создании веб-приложений? Поддержка текущей кодовой базы, удобство внедрения новых фич и возможность повторно использовать компоненты. Создать такие условия помогает популярный подход к проектированию — FSD (Feature Sliced Design). Разбиваем интерфейс на независимые, переиспользуемые модули (виджеты, фичи и т. д.), получаем чёткие правила, единую структуру проекта и ускорение разработки за счёт переиспользования кода и изоляции ответственности.
Подход FSD во многом прекрасен, но всё же нам в нём не хватало некоторых важных аспектов: внятного разделения слоёв бизнес-логики, удобства работы с кастомными хуками (они быстро разрастаются, обрастают связями и становятся сложными для тестирования). Также было неясно, куда выносить сложные общие компоненты из разных частей проекта. И, например, как легко отделять один бизнес-модуль от другого, не ломая всю систему…
Меня зовут Иван Соснович, я тимлид фронтенд-разработки в СберТехе, тружусь в команде Platform V Kintsugi — это графический инструмент для сопровождения, мониторинга и диагностики Postgres-like СУБД. В этой статье я покажу, как мы доработали FSD под себя, и дам ссылку на пример со структурой приложения. Надеюсь, будет полезно фронтенд-разработчикам.
Вы когда-нибудь видели в консоли сообщение вроде: «Access to fetch at '…' from origin '…' has been blocked by CORS policy»? Это как в том фильме: «Суслика видишь? — А он есть». CORS не бросается в глаза, пока все работает, но в нужный момент пресекает недопустимые действия. Например, чтение ответа на кросс-запрос без разрешения сервера.
Меня зовут Баир, я разработчик в команде fuse8. В этой статье я отвечу на вопросы о том, зачем была создана CORS политика, как она устроена под капотом, почему простого действия типа «поставить заголовок на бэке» может быть мало, и какие безопасные паттерны стоит выбирать во фронтенде.
Полистав различные ресурсы в Интернете и просмотрев множество видео по данной теме, я решил составить наиболее полную картину по данному, не побоюсь этого слова, революционному API, чтобы вы уже сегодня могли начать использовать его в своём проекте!