Фронтенд

Angular Signals 101 Это не поверхностный обзор, а полное погружение в мир сигналов. Мы разберем всё: от публичного API до внутреннего устройства планировщика в Zoneless.

Эта книга не столько о коде, сколько о целостном подходе к взаимодействию с продуктологами и подотчетными разработчиками. 

Она о том, как должно меняться мышление у middle-разработчика в сторону senior-разработчика. Автор в частности поясняет, что «цель этой книги — дать вам справочник для работы с новыми и legacy-проектами во фронтенде и бэкенде, а также для работы по их развертыванию». 

Автор приводит приемы senior-разработчиков, чтобы «работать скорее на уровне системы, чем отдельных строк кода» и находить оптимальные/компромиссные решения.

База знаний помогает пользователям быстро понять, какие возможности есть у облачных сервисов — так же, как качественный README объясняет назначение open source‑проекта. 

В этом материале мы собрали несколько интересных бесплатных инструментов для подготовки README.

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

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

React больше не побеждает за счёт своих технических достоинств. Сегодня его выбирают по умолчанию. И именно это «по умолчанию» теперь тормозит инновации во всей фронтенд-экосистеме.

Когда командам нужен новый фронтенд, разговор редко начинается с вопроса: «Каковы ограничения и какой инструмент лучше всего под них подходит?» Чаще всё звучит так: «Давайте возьмём React — его все знают». Такой рефлекс запускает самоподдерживающийся цикл, в котором архитектуру определяют сетевые эффекты, а не техническая уместность.

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

Привет, Хабр! Меня зовут Роман Изотов. Последние 5 лет я провел по ту сторону баррикад – в роли IT-рекрутера, где отсмотрел более миллиона резюме и провел тысячи собеседований. Сегодня я помогаю IT-специалистам взламывать систему найма, и вот что я вижу: многие по-настоящему сильные Senior-инженеры, тимлиды, архитекторы сталкиваются с одной и той же проблемой – их резюме просто не работает.

«Мой опыт говорит сам за себя!» – Главное заблуждение.

Кажется логичным: если у тебя 7-10 лет опыта, куча проектов, сложные технологии, то резюме должно привлекать. Но в 2025 году это больше не так. Рынок перегрет, конкуренция бешеная. На одну Senior-вакансию приходят десятки, а то и сотни откликов. И вот тут в игру вступают фильтры, о которых вы могли даже не догадываться.

Фильтр №1: Автоматизированные системы отбора (ATS) – ваш первый и самый беспощадный враг.

Забудьте про креативный дизайн и инфографику. Для ATS ваше резюме – это набор ключевых слов. Если вы не используете точную лексику из описания вакансии, не указываете конкретные технологии и метрики – ваша заявка просто не дойдёт до HR. Система не поймёт, что "оптимизировал производительность" означает "сократил время отклика сервиса на 30% на пять миллионов пользователей". А если она не поймёт, то вы в корзине.

Осенью 2025 года заканчивается официальная поддержка Windows 10. Для миллионов пользователей и компаний окончание поддержки ставит вопрос о выборе дальнейшей стратегии. Наиболее очевидный путь — переход на Windows 11, однако его могут ограничивать более строгие аппаратные требования. Конечно, найдутся пользователи и организации, которые предпочтут продолжить эксплуатацию Windows 10 и после окончания официальной поддержки. У такого подхода есть свои плюсы, в первую очередь — отсутствие немедленных затрат на обновление железа или переобучение персонала. Однако минусы этого решения крайне серьезны: растущие уязвимости из-за отсутствия обновлений безопасности, потенциальная несовместимость с новым программным обеспечением и риски несоблюдения требований регуляторов, особенно для бизнеса. Таким образом, каждая стратегия требует тщательной оценки рисков и затрат.

На мой взгляд, стратегически верным шагом в данной ситуации  является миграция на Linux. Но что делать армии программистов, годами создававших приложения под экосистему Microsoft? Приложения на .NET Framework, WPF и WinForms — это кровь тысяч корпоративных и бизнес-систем. Полное переписывание их на другие технологии — это колоссальные затраты времени и денег. Однако существует элегантный и экономически выгодный путь, который не только решает проблему совместимости с Linux, но и открывает новые горизонты для разработки. Этот путь — кроссплатформенный фреймворк Avalonia UI и современная платформа .NET.

Плавный переход вместо болезненного переучивания

Привет, Хабр!

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

Но мощный и гибкий бэкенд - только половина уравнения. Без современного, умного и производительного фронтенда вся эта свобода рискует остаться просто красивой теорией. Где же тот самый «идеальный фронтенд», который раскроет потенциал Headless на все 100%?

Многие мои собеседники "стопроцентно" уверяли меня, что сама суть функционального программирования заключается в повсеместном использовании map, filter и reduce; что эти функции превосходят циклы for во всём, настолько, что их нужно запихнуть в каждый возможный язык безо всякого анализа затрат и выгод, потому что выгоды настолько несравненно потрясающие, что затраты просто не могут иметь значения. А само сомнение в этих затратах уже доказывает, что я ничего не понял. Поэтому пора задать главный вопрос: действительно ли именно они (map, filter и reduce) и есть ядро функционального программирования?

К чёрту теорию; давайте посмотрим на практику. Давайте взглянем на реальный проект на Haskell. Я знаю два крупных проекта на Haskell, которые вышли за пределы хаскель-экосистемы и стали полезными программами, которые люди скачивают: xmonad и pandoc. Но xmonad - странная программа: она делает массу привязок к библиотекам C и взаимодействует со всевозможными системными сервисами…Что, конечно, неплохо, как говорится, но из-за этого она не очень типична. А вот pandoc - это чистейший Haskell: парсинг, работа с абстрактным синтаксическим деревом, его трансформация и генерация; т.е., по сути, огромный компилятор для документов. Более «хаскельским» код быть не может. Давайте посмотрим на него.

Практический опыт MANGO OFFICE в оценке архитекторов и старших разработчиков

Привет, Хабр!

Наш спикер — Константин Густов, руководитель отдела развития архитектуры и IT бизнес-партнёр MANGO OFFICE. И он недавно принял участие в подкасте Деплой. В компании он выстраивает производственные процессы разработки и руководит командой из 13 архитекторов на 400 IT-специалистов.

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

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

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

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

Собственно, выглядит компонент загрузки файла вот так:

Интернационализация (или i18n) — это одна из тех функций, которые кажутся необязательными, пока они действительно не понадобятся. Как только вы захотите выйти за пределы одного языка или региона, внезапно вашему коду приходится поддерживать несколько локалей, текст с направлением справа налево и культурно-специфичные форматы.

Если вы искали решения, то, скорее всего, уже встречали i18next или react-intl. Оба инструмента мощные, но у них есть свои недостатки: высокий порог входа, множество шаблонных JSON-файлов или сложная интеграция с TypeScript.

В этой статье мы разберём:

И чтобы всё было безопасно.

Поговорим про CDN, SRI, кэш-отравления, подмены и rsbuild-плагины.

Браузеры — это очень странный мир. Хотя WebAssembly добился успеха, в том числе и на серверах, клиент по-прежнему ощущается примерно таким же, как и десять лет назад.

Энтузиасты будут говорить вам, что доступ к нативным веб-API через WASM — это решённая задача, достаточно лишь минимального клея JS.

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

Не буду притворяться, что знаю о браузерах всё. Сегодня уже никто не знает всего, в этом-то и проблема.

В перспективе отключения глобального интернета в РФ актуальным становятся разные способы сохранять информацию в офлайне для последующего потребления: архивы кинофильмов, музыки, книг, копии сайтов — своя мини-версия Архива интернета.

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

Один из вариантов — генерация локальных мини-сайтов с перекрёстными гиперссылками. В таком виде информация воспринимается очень комфортно.

Доброго дня, читатель! Меня зовут Александр Роут, я фронтенд‑разработчик в Домклик. 

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

Эта атака — не первый и не последний случай в истории. Она вновь подняла важный вопрос «Насколько мы можем доверять сотням зависимостей, которые добавляем в свои проекты?» Часто мы устанавливаем пакеты, практически не задумываясь о том, что именно скачиваем и запускаем. Особую опасность представляют postinstall‑скрипты, которые могут выполнять произвольные действия на вашем компьютере сразу после установки.

Всем привет! Меня зовут Артем, я фронтенд разработчик в Банки.ру. Недавно перед нашей командой встала задача внедрить SSO-аутентификацию через Keycloak для клиентских сервисов. Помимо базовой настройки важно было полностью переработать стандартные формы входа, чтобы они соответствовали корпоративному стилю и UX-требованиям.

Эта статья будет полезна фронтенд-разработчикам, которые хотят кастомизировать интерфейс Keycloak, не жертвуя современным стэком, скоростью разработки и здравым рассудком. А также командам, которые находятся на этапе выбора решения для авторизации из имеющихся на рынке. Мы разберём практические шаги внедрения, покажем код и честно расскажем о подводных камнях, с которыми столкнулись сами.

Представь, что ты строишь крутой интерактивный сайт из деталек LEGO. React — это как раз такой продвинутый набор «умных» деталек для постройки сайтов. А эта книга — инструкция к нему.

Белый экран при загрузке SPA — типичная боль. Пользователь открывает приложение, ждёт пока загрузится приложение, а экран пуст. А если качество связи оставляет желать лучшего а размер чанков не может похвастаться оптимизацией(да это отдельная тема для обсуждений, но все же)? Я часто сталкиваюсь с этим в реальных проектах и вот наконец то появилось время и силы сделать так, чтобы у пользователя никогда не было пустоты на экране.

В проектах на Qt рано или поздно встаёт вопрос: делать интерфейс на Widgets или на Quick. Первый вариант даёт зрелый набор контролов и привычное поведение окон, второй — гибкость, анимации и GPU-рендеринг. Иногда нужно объединить эти подходы: например, когда в приложении на Qt Quick требуется окно, способное выходить за границы основного, как это делают всплывающие подсказки или выпадающие списки в классических десктопных программах.

В этой статье я разберу рабочий способ показывать окна Qt Widgets из приложений Qt Quick — без хака с QQuickPaintedItem и без потери преимуществ Scene Graph.