Фронтенд

Angular v21 подъехал — и это один из самых насыщенных релизов за последние годы.

Главные нововведения:

🔥 Signal Forms — реактивные формы на сигналах с полной типизацией и упрощёнными кастомными компонентами.
🎨 Angular Aria (Developer Preview) — headless-компоненты с приоритетом на доступность и вашей собственной стилизацией.
🤖 Angular MCP Server стал стабильным — теперь ИИ-агенты могут понимать ваш код, искать примеры, обновлять проект и даже обучать Angular.
🧪 Vitest — новый стабильный test runner по умолчанию.
⚡ Zone.js больше нет в новых приложениях — Zoneless теперь стандарт, что даёт меньше магии, больше производительности.
📚 Обновлённая документация: новый Signals tutorial, переработанный Routing, улучшенное DI, Material-темизация и полноценный гайд по Tailwind.
➕ Плюс десятки мелких улучшений: CLDR v47, RegExp в шаблонах, новый formatter сигналов, улучшения CDK, анимаций и DevTools.

Angular продолжает разворачиваться в сторону реактивности, AI-first разработки и отказа от лишней магии.

Если ещё не пробовали — самое время запустить ng update и посмотреть, что может v21.

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

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

Поэтому я написал простой браузерный скрипт, который автоматически скрывает истории почти от всех, кроме тех, кого я явно добавил в список исключений по имени или ID.

Скрипт запускается из консоли, продолжает работать даже в неактивной вкладке и доступен в открытом репозитории.

GitHub

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

История стартует в 1982, когда Университет Карнеги (Carnegie Mellon University, CMU) и корпорация IBM запустили Andrew Project, проект который должен был упростить коммуникацию и совместную работу внутри университетского кампуса.

Tilda раздражала, JS пугал, а Rust манил… В итоге я переписал лендинг на Rust + Leptos - просто потому что «а почему бы и нет?». Под катом: немного боли, пара побед, сравнение с конструктором и вывод о том, что заниматься фигнёй иногда очень полезно.

Бывало, открываешь код-ревью — и чувствуешь себя археологом. Каждый кусок кода — как артефакт из разных времен: тут блестит бронзовая монетка, там торчит бивень мамонта, а чуть дальше — отпечатки времен .NET 4, пережившие три рефакторинга. Все это чудом взаимодействует, но порой страшно тронуть — вдруг вся конструкция рассыплется.

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

Мы в команде разработки пользовательского интерфейса поняли это, когда наш общий код перестал быть общим: его было слишком много, он жил своей жизнью, и никто уже не знал, что в нем есть и как оно работает. С этого начался Kaspirin — наш внутренний фреймворк, который мы создали не для расширения возможностей, а чтобы навести порядок и убрать лишнюю вариативность. Название придумалось само собой: смесь Kaspersky и aspirin — лекарство от головной боли, вызванной избыточной гибкостью.

Пять лет назад мы запустили интернет-магазин на Nuxt 2. За это время он превратился в классический монолит: вносить правки стало дорого, а сайт начал «задыхаться» под нагрузкой. Когда вышел Nuxt 3, перед нами встал выбор: пытаться оживить проект через Nuxt Bridge или переписать всё с нуля.

Мы проанализировали код и поняли: плавная миграция для нас — это путь к созданию «зомби-проекта». Слишком много фундаментальных отличий: Options API против Composition API, Vuex против Pinia, смена логики роутинга и несовместимость ключевых библиотек.

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

Внутри кейса:
• 4 технических «фаталити», которые делают миграцию легаси-монолита невозможной.
• Архитектура FSD + Nuxt 3: как мы подружили фронтенд с бэкендом на Symfony и навели порядок в зависимостях.
• Паттерн «Фабрика»: как упростить сложную логику доставки в Composition API.
• Бонус: почему благодаря правильному старту недавнее обновление с Nuxt 3 до Nuxt 4 заняло у нас минимум времени, в отличие от мучений с Nuxt 2.

Если вы всё еще поддерживаете проекты на второй версии и боитесь подступиться к обновлению — этот опыт для вас.

После работы с React/Vue/Angular захотелось вернуться к основам, но с современными возможностями. Сделал RWC — библиотеку реактивных веб-компонентов.

Ключевые преимущества:
• Совместимость — компоненты работают в любом проекте
• Производительность (сигналы для реактивности) — точечные обновления DOM
• Простота — минимальный API, легко обучать команду
• TypeScript-first — типизация из коробки без костылей

Компоненты, написанные на RWC, можно встроить в React, Vue, Angular или даже legacy jQuery-проект. Никакого vendor lock-in.

Библиотека весит <10KB, компоненты работают в любом проекте.

Это перевод классической статьи 1995 года одного из титанов теории разработки программного обеспечения - профессора Никлауса Вирта (если найдется некто, кто не знает его, то можно ознакомится, не выходя с habr, со статьями о нем здесь и здесь а небольшая ретроспектива итогов предсказаний Вирта из этой статьи доступна здесь). Текст имеет больше историческое значение, но написан ясным и доступным языком, и, возможно, побудит кого-нибудь пересмотреть подходы к созданию программного обеспечения.

Когда-то я просто хотел писать мобильные приложения. Никаких планов «стать техлидом», «управлять командами» или «строить архитектуру» у меня не было. Я просто любил разбираться в технологиях и доводить фичи до ума.

Но как это обычно бывает, если долго и упорно копать в одном направлении — горизонт начинает расширяться.

Расскажу коротко, как это произошло у меня.

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

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

Сегодня я покажу Вам примеры кризиса IT у маститых компаний. Казалось бы, там всё должно быть отлично с функционалом у приложений, но нет — все они заложники кризиса в отрасли. В конце объясню, почему, пока смотрим примеры.

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

В современных веб-приложениях для потокового видео всё чаще требуется не просто воспроизводить контент, но и анализировать аудиодорожку в реальном времени. Например, строить индикаторы уровня громкости (VU/PPM метры), визуализировать спектрограммы или детектировать тишину. В этой статье разберём, как корректно объединить hls.js и Web Audio API для анализа аудио из HLS-потока в браузере, избежав типичных подводных камней.

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

Во многих проектах на Next.js возможности для SEO остаются неиспользованными: страницы индексируются не полностью, структурированные элементы отсутствуют, а ссылки в соцсетях отображаются неправильно. Чтобы этого избежать, существуют проверенные инструменты и подходы, которые помогают сделать SEO понятным, полным и эффективным.

В данной статье рассмотрены ключевые аспекты настройки SEO в проектах на Next.js: работа с метаданными, генерация sitemap и robots.txt, оптимизация изображений и внедрение структурированных данных. 

Всем привет, с вами Артем Леванов, Front Lead в компании WebRise.

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

Следующая проблема, с которой сталкивается любая форма — валидация.

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

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

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

В последние годы CSS стабильно развивается. По себе знаю, что уследить непросто. По этой причине многие продолжают использовать лишь часть его возможностей, ограничиваясь проверенными годами решениями.

Ничего против них не имею. Просто хочу рассказать о нескольких приёмах, которые вы могли упустить. Они помогут вам в разных ситуациях.

Давайте посмотрим, что я вам подготовил.

Что такое кастомные медиавыражения и почему обычные CSS-переменные не работают внутри @media. Простое объяснение, понятные примеры и разбор того, как браузер вычисляет стили под капотом.

Команда JavaScript for Devs подготовила перевод статьи Пола Кинлана о том, почему новые веб-фреймворки сегодня оказываются «мёртвыми при рождении». Автор утверждает: сочетание сетевых эффектов, экосистемы React и обучения LLM формирует замкнутый цикл, в котором альтернативы просто не успевают набрать критическую массу.