VueJS *

Yandexbot заходит на ваш SPA сайт, получает пустой <div id="root"></div> и уходит. Именно так выглядит индексация большинства одностраничных приложений без SSR. Страницы не попадают в выдачу, органический трафик стоит на нуле, а команда недоумевает: сайт же работает.

Проблема не в качестве кода, а в архитектуре рендеринга. Поисковые роботы медленно или вообще не выполняют JavaScript, а значит, видят страницу до того, как ваш React или Vue успел что-то нарисовать. Настройка Server Side Rendering для индексации SPA приложений поисковиками решает эту проблему: HTML приходит уже готовым прямо с сервера.

Привет! Я Пётр Гришечкин, эксперт в области SEO для e-commerce. Последние 15 лет я проектирую системы кратного роста трафика для крупнейших сайтов. И последнее время пишу всякие околоSEO статьи – https://t.me/seo_and_sem

Это статья написано для начинающих frontend и backend разработчиков, которые хотят разобраться с технической SEO-оптимизацией. Здесь будут конкретные команды, примеры кода для React/Next.js, Vue/Nuxt.js и Angular, а также чек-лист внедрения.

Проблема не в том, что инструментов мало. Проблема в том, что большинство из них построены вокруг браузера прошлого поколения, тогда как frontend уже давно живёт внутри runtime. Именно из этой практической боли появился собственный runtime-инспектор — сначала как консольный скрипт для одной конкретной задачи, а затем как полноценный инструмент, который неожиданно нашел отклик у QA и разработчиков.

Недавно в Амстердаме прошла конференция Vue.js Amsterdam 2026 — ежегодное мероприятие, посвящённое экосистеме Vite и современным инструментам фронтенд-разработки.

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

В этой статье разберём основные анонсы конференции: Vite 8, Vite+, Void Cloud, а также обновления Vue и Nuxt.

Как вырваться из замкнутого круга навязываемых акулами BigTech сомнительных технологий на простор устойчивого развития? Как сделать так, чтобы код внедряемой сейчас Дизайн‑системы — через пару лет опять не превратился в очередную, никому не нужную и максимально не удобную, «тыкву‑легаси»? Как выйти из дурного холивара с модными фреймворками на фронтенде и сделать библиотеку переиспользуемых компонент подходящую сразу для всех технологий и «на века»?)))

Ваша команда работает с большим количеством различных недокументированных проектов, основанном на одном визуальном языке? У вашей корпорации есть строгий брендбук и огромное количество клиентских веб‑сервисов написанных на разных фреймворках, которые по факту выглядят немного по‑разному в «одних и тех же мелочах»? Ваши фронты «пишут каждый свой фреймворк для дизайна заново каждый раз на каждом проекте»? Знакомо? UUI спешит к вам на помощь!

Мода на технологии все стремительней меняется, а браузер и простой интерфейс в нем остается. Вышел новый модный фреймворк и заказчику хочется проект именно на нем? Да пожалуйста! Легко! Так мы становимся максимально независимы от капризной и накаченной лоббированием индустрии реализуя основную задачу. Поставляя единый гайдлайн повсюду.

Рассказываю, как я сделал простейший yaml сервис на Java и Vue для разовой загрузки данных, чтобы не писать тонны кода и не мучиться с JSON.

Предыдущая часть: Enovia умерла, да здравствует JMatrixPlatform: пересобираю легендарную платформу на Java и Vue

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

Рано или поздно почти любой бэкенд-проект приходит к задаче: нужна простая внутренняя страница. Посмотреть список чего-то, нажать пару кнопок, может быть что-то удалить.На «внутренней» странице пользователей не будет, а значит – «и так сойдёт». И вот тут начинается выбор: какие технологии взять или какой стек выбрать?
Привет! На связи Евгений Захаров — backend разработчик в компании ecom.tech. Моя команда занимается вопросами координации и планирования работы внештатных сотрудников. В этой статье мой опыт, накопившейся за многие года работы в разных компаниях, дальше мы разберём базовые сценарии, риски, сложности. Поехали!

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

Меня зовут Иван и я занимаюсь frontend-разработкой в компании SimbirSoft. В марте 2026 на официальном сайте Nuxt объявили о выходе новой версии Nuxt v4.4. В ней произведена миграция на Vue Router v5, добавлена возможность создания пользовательских фабрик useFetch/useAsyncData, типизация пропсов в Layout, новый композабл и компоненты для работы с доступностью, профилирование сборки, улучшение производительности и многое другое.

Также в январе вместе с выходом версии Nuxt v4.3 разработчики продлили поддержку Nuxt 3 до 31 июля 2026 года (ранее указывали срок до 31 января 2026 года). Решение было принято после открытия обсуждения, чтобы узнать у сообщества, как прошло обновление с версии 3 до версии 4. Многие отметили, что ждут новостей о сроках релиза Nuxt 5, который должен выйти вместе с Nitro 3, поэтому пока не спешат обновляться на четвертую версию. А пока мы ждем новостей, давайте посмотрим, какие интересные нововведения появились в последних релизах Nuxt. Данная статья — это краткий обзор на новые фичи и изменения, которые мне показались интересными.

Чувак, уже есть Pinia, Pinia Colada, TanStack Query для Vue, зачем ещё один способ управлять состоянием во Vue?

Меня просто задолбало писать везде флаги отслеживания состояния для действий и делать store через фабричную функцию, как это делали наши праотцы в начале 2000-х. Запоминать зоопарк из разных composable-функций и хуков. Изучать какую-то другую систему реактивности, типа MobX, тоже не хочу. Это какой-то зашквар.

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

И это возможно, покажу, как это работает на примере.

Я не OpenSource разработчик, но за пару десятков лет написал под сотню enterprise-level библиотек, которые остаются в рабочем контуре, дорабатываются под каждый проект и адаптируются к новым технологиям. Большого смысла выходить в OSS не было, кроме как для упрощения обучения коллег и единого места хранения документации.

Но и желание помогать другим и делиться выстраданными подходами, экспертизой и конкретным кодом мне не чуждо - сегодня поможешь ты, завтра - тебе. Через полгода подготовки и адаптации к OpenSource (сам использую и дорабатываю около 8 лет) в свет выходит одна из библиотек моего рабочего контура - Reactive Route.

Так как я работаю с проектами на разных стеках, стараюсь писать код максимально framework-agnostic - независимыми слоями, которые можно заменить или переписать, не трогая остальной код проекта. А к фреймворкам и библиотекам для работы с состоянием они подключаются с помощью легковесных адаптеров, сохраняя синтаксис работы. Конкретно для Reactive Route выложил набор готовых адаптеров в комбинациях, которые сейчас чаще всего использую:

• React + MobX / Observable

• Preact (no compat) + MobX / Observable

• Solid.js + нативная реактивность / MobX / Observable

• Vue + нативная реактивность

В одном npm-пакете - строгая TS-типизация, SSR / MPA / no-JS / Widget режимы и тщательно протестированная отказоустойчивость. В статье не буду пересказывать документацию на русском и английском, а поговорю скорее про общие принципы качества, использование ИИ в разработке и почему многие библиотеки раздуваются, не успев даже стабилизировать ядро.

Почти каждый фронтенд-разработчик однажды задаётся вопросом: что на самом деле происходит внутри современных фреймворков. Почему изменение переменной автоматически обновляет интерфейс? Как библиотека понимает, что именно нужно перерисовать?

13 марта 2026 года вышла новая мажорная версия инструмента для сборки фронтенд‑приложений — Vite 8. Главным изменением стал переход на новый бандлер Rolldown, написанный на Rust. Теперь Vite использует единый инструмент вместо связки esbuild и Rollup, что позволяет значительно ускорить сборку — по заявлениям разработчиков, в некоторых проектах прирост достигает 10–30 раз. Это самое значительное изменение архитектуры Vite со времени выхода Vite 2.

Кроме этого, в релизе появились встроенные devtools, улучшенная поддержка TypeScript, новые возможности для SSR и ряд изменений в экосистеме плагинов. На основе поста в официальном блоге Vite 8 разберём ключевые нововведения и как они повлияют на разработку. 

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

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

И один лишь рынок особой категории геоданных, именующих себя детьми лейтенанта Шмидта, находится в хаотическом состоянии. Анархия раздирала корпорации вроде Гугла… Ладно, я увлёкся. Но в самом деле…

Vue DnD Kit v2: headless drag-and-drop с composable API — делай что хочешь, как хочешь

Если вы когда-нибудь пробовали сделать drag-and-drop на Vue по-настоящему гибким — с кастомным overlay, вложенными зонами, multi-drag и анимацией при отпускании — вы знаете, что большинство библиотек держат вас в клетке. Vue DnD Kit v2 эту клетку сломал.

И вам это понравится!)

Привет, я Дима, senior frontend разработчик в компании Doubletapp. 

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

В тексте: 
- Почему стандартные тестовые задания не работают
- Как должен выглядеть адекватный технический этап
- Почему этот подход даёт лучший результат

Привет! На связи Дима — Senior Frontend разработчик в Doubletapp. В этой статье я расскажу, как эффективно собесить фронтендеров. Мой стек — Vue, Nuxt, поэтому примеры будут на основе моего опыта, но текст подойдет для всех разработчиков и нанимающих менеджеров.

В этой статье 

- Что я понял спустя 80+ собеседований? 
- Как собесят на рынке?
- Почему это все не работает
- Фактор ИИ и «подготовленных» кандидатов
- Как проводить инженерное интервью: 4 принципа

Синхронизация атрибутов элемента с DOM-свойствами

Очевидно, что нашему компоненту потребуются атрибуты, через которые пользователь сможет контролировать его поведение. Наш компонент должен вести себя как стандартный элемент ввода типа «input», поэтому обязательно должен поддерживать такие атрибуты как disabled и required – и это самый минимум. Поэтому важно разобраться (ну или вспомнить) что такое «content vs IDL attributes», и как с этим работать.

Документация по веб-компонентам мало говорит об атрибутах, разве что рекомендует использовать attributeChangedCallback() для наблюдения за ними, но этого недостаточно. Хотя это полезное API, нам оно не подходит, потому что оно уведомляет нас о уже совершенном действии (изменении атрибута), а нам нужно контролировать этот процесс, то есть – синхронизировать атрибуты и свойства с нормализацией значений.

Так как наш компонент наследует базовый класс HTMLElement, а в нем уже реализовано большое количество разных методов, то мы можем переопределить некоторые из них чтобы получить нужный нам результат. Для начала определим наши свойства в виде пар get/set и значения в приватном поле:

Пошаговое руководство по развёртыванию блога с нуля: Strapi CMS (админка и API) и Nuxt.js (фронтенд) на VPS Ubuntu. В итоге — работающий блог за Nginx с возможностью включить SSL по отдельной инструкции.

Всем привет! Кажется, настала пора поделиться изменениями в Азбуке, которые произошли с 2022 года, когда я выпускал прошлую статью. Наш текущий стэк: Vue 3, Nuxt 4, TS.

В процессе создания новых сервисов, столкнулись с проблемами роста, дублирования кода и модульностью в Nuxt - расскажу, как справились с этим.

За последние пару лет я провёл сотни технических собеседований — от junior до senior специалистов. И я обнаружил что есть одна тема, с пониманием которой есть проблемы почти у всех кандидатов с кем мне доводилось общаться. Это Virtual DOM.

Почти каждый кандидат объясняет его примерно так:

“Virtual DOM нужен, чтобы обновлять не всю страницу, а только её часть. Поэтому всё работает быстрее.”

Привет, Хабр! Меня зовут Василий Беляев. Я руководитель группы разработки по направлению фронтенда в ИТ-компании «Криптонит». В этой статье хочу поделиться опытом и рассказать об оптимизации библиотек: о том, с какими проблемами мы столкнулись, и как их пошагово решили.

Для начала кратко опишу фронтовый стек у нас в «Криптоните»: мы те ребята, которые не пишут на React. У нас все проекты и библиотеки написаны на Vue + Composition API. Из дополнительных инструментов мы используем следующие: