На дворе 2026-й, и за это время как React, так и Vue сделали гигантский скачок в развитии и создании экосистемы вокруг себя. Но статистика до сих пор беспощадна к Vue. На React в два раза больше вакансий, чем на Vue. Сколько я ни спрашивал React-инженеров, ответ был всегда один и тот же: «React для серьезных проектов, а Vue так уж».. Серьезно? Почему вы до сих пор так думаете?? Ну хоть один пример приведите, что нельзя сделать во Vue. Хотя бы потратьте 1 день на изучение экосистемы Vue 3 Composition API, Vue Router, Pinia - да вы после этого забудете про свой React. А про различные useState я вообще молчу, Vue тут вообще вас всех обошел с обычными ref. Это вы еще не слышали про keep-alive.
Я считаю, что такое мнение построилось из-за простой причины: люди просто поставили свою карьеру на React, вот почему они его защищают, а компании продолжают его использовать.
Но давайте копнем глубже, почему эта боль такая острая
Проблема не в том, что React плохой. Он был революционным в 2013 году. Безусловно. Но мы-то сейчас живем в другом времени. Реакт застрял в прошлом, пытаясь латать дыры, которые сам же и создал. Вспомните, сколько раз менялся подход к управлению состоянием... Каждый раз сообщество говорит: «Вот теперь-то мы всё сделали правильно». А по факту вы просто заставляете джуниора учить не язык программирования, а «путь воина React-разработчика».
Во Vue подход проще и, как ни странно, взрослее. Ты берешь ref, и всё. Магия? Нет, это просто продуманная реактивность. В React ты борешься с ререндерами. Ты знаешь это чувство, когда меняешь одну цифру в хедере, а перерисовывается вся таблица на пол-экрана, потому что кто-то забыл обернуть компонент в memo? А потом начинаешь отлаживать, почему useEffect срабатывает дважды, а потом просто сходишь с ума. Во Vue 3 ты об этом даже не думаешь. Система отслеживает зависимости на уровне компилятора. Это не «фича», это база.
Миф про «Enterprise»
Самый смешной аргумент, который я слышу: «Во Vue нет поддержки больших команд». Господа, вы когда-нибудь открывали код крупных проектов на Нуксте? Проблема масштабируемости решается не фреймворком, а архитектурой. Но если уж говорить о стандартах, то у Vue они есть. Официальный роутер, официальный стейт-менеджер (Pinia теперь - это стандарт).
В мире React ты приходишь на проект и первую неделю гадаешь: «Так, а стейт мы тут храним тут или тут? А роутинг какой? А почему тут два разных способа?». Это не гибкость, это хаос. Это «выбери свое приключение», которое превращается в поддержку легаси через год. Во Vue ты приходишь и видишь структуру. Она предсказуемая. Для бизнеса, кстати, предсказуемость стоит дороже, чем хайп вокруг библиотеки.
Keep-Alive и работа с памятью
Ладно, давайте про keep-alive. Это киллер-фича, о которой реактчики часто даже не знают, потому что им не приходилось решать задачу кеширования состояния вкладок. Представь: у тебя есть список товаров с фильтрами. Пользователь кликнул на товар, зашел внутрь, потом нажал «назад». В идеальном мире он должен вернуться на тот же скролл, с теми же фильтрами. В React ты будешь писать костыли через глобальный стейт, сериализацию в URL или танцы с бубном вокруг React Router. Во Vue ты просто оборачиваешь компонент в <KeepAlive>. Всё. Встроенная возможность движка. Почему это игнорируется? Потому что «так не принято»?
Экосистема и боль выбора
Еще один момент, который убивает продуктивность - экосистема. Казалось бы, у React её больше. Да, пакетов в нпм больше. Но сколько из них брошено авторами через полгода? Сколько из них не совместимы друг с другом? Vue-экосистема меньше, но она плотнее. Библиотеки компонентов (Quasar) часто делают вещи, которые в мире React требуют подключения трех разных библиотек и написания адаптеров.
Я не говорю, что у Vue нет проблем. Есть. Документация иногда скачет между версиями, комьюнити меньше, значит, готовых ответов на StackOverflow меньше. Придется думать головой. Но разве это не работа инженера? Читать доки и понимать, как работает инструмент, а не копипастить первый ответ из гугла?
Почему все молчат?
Возвращаясь к началу. Почему так много хейта? Скрытая причина - страх. Если ты признаешь, что Vue проще, мощнее и удобнее в поддержке, то что тогда делать с твоими пятью годами опыта на React? Придется переучиваться. Придется признавать, что время было потрачено не на тот инструмент. Это психологически сложно. Проще сказать: «Vue для игрушечных проектов», чем сесть и написать пет-проект на Composition API.
Я не призываю сжигать ноутбуки и удалять React. Нет. Инструмент должен подходить под задачу. Но когда говорят, что на Vue нельзя сделать сложный проект - это ложь. Это просто незнание.
Что в итоге?
Если вы читаете это и вы реакт-разработчик - не верьте мне на слово. Просто выделите выходные. Не «посмотреть видосик на ютубе», а реально попробовать собрать что-то сложное. Дашборд с графиками, авторизацией, сложной формой и кешированием вкладок. Попробуйте сделать это на Vue 3. И честно ответьте себе: где вы потратили больше времени на борьбу с фреймворком, а где на бизнес-логику?
Скорее всего, вы удивитесь, насколько меньше кода вы написали. И насколько тише стало в голове, когда не нужно думать о массивах зависимостей в useEffect.
Мир не делится на черное и белое. Но перестаньте уже говорить, что серый цвет - это плохо. Vue вырос. Он стал острым, быстрым и взрослым. Пора это признать, даже если это бьет по вашему резюме. Вакансий меньше? Да. Но качественных проектов на нем - полно. И работать на них, поверьте, приятнее.
Комментарии (42)
gsaw
04.04.2026 16:47Да не плачьте :) Дело не в Vue. Просто так сложилось, что react был раньше, c 2011, поддерживался крупной компанией со старта, было больше написано инструментов, фреймворков. Вот и получается, что в крупных проектах, чаще используются либо angular либо react. Проще найти специалистов, проще найти библиотеки с лучшей поддержкой, больше комьюнити, больше нейронов в ИИ моделях натренированных на react.
Крутость уже не играет роли, можно на любом языке написать с ошибками. И смысл тогда?
React.js vs. Vue.js
Linux vs Minix
Rust vs. C++
...
andreyr82
04.04.2026 16:47В React ты будешь писать костыли через глобальный стейт, сериализацию в URL или танцы с бубном вокруг React Router.
Почему это? Я возьму <Outlet />
danilovmy
04.04.2026 16:47Я говорил это с 2021, времен vuejs2/nuxt2. А потом, с середины 2025, мне стало все равно. Хотя стоит отметить, что предпоследней мажор nuxt4 хорош, а 5 будет ещё лучше.
Apolleon
04.04.2026 16:47Я тоже устал от реакта и его костылей. И я тоже высказался - записал видео на Ютуб: реакт vs vue. Набежали макаки реактовские и начали мне писать про правильную декомпозицию
Pnym Автор
04.04.2026 16:47Понимаю))
Я тоже в свободное время глубоко копаю и React, и Vue, и последние наблюдения заставляют задуматься. В экосистеме React, например, до сих пор нет прямого аналога Quasar «всё в одном». С React Compiler тоже были шероховатости в пет-проектах: в связке сreact-hook-formиногда ломался ререндер :(
aweebit
04.04.2026 16:47В React начиная с версии 19.2 доступен компонент <Activity>, функция которого насколько я понимаю такая же, как у <KeepAlive> из Vue.
А что предлагает Vue в качестве альтернативы реактовским useTransition / useDeferredValue?
TAZAQ
04.04.2026 16:47useTransition is a React Hook that lets you render a part of the UI in the background.
useDeferredValue is a React Hook that lets you defer updating a part of the UI.
Насколько я понял из документации, это специфичные для react хуки. Реактивность vue из коробки позволяет обновлять “part of the UI”, обновляя только компоненты которые реально изменились
aweebit
04.04.2026 16:47В основе Vue так же как и в основе React лежит концепция Virtual DOM, и, насколько я могу судить, так же как и в React компоненты обновляются целыми деревьями начиная от того компонента, где произошло изменение состояния. Поэтому проблемы, которые решают useTransition и useDeferredValue в React, ровно в той же степени актуальны и для Vue.
В моей карьере случаев, когда приходилось пользоваться этими хуками, было не так уж и много, но каждый раз я радовался тому, что работаю с React, а не другим фреймворком, потому что иначе пришлось бы пользоваться костылями вроде предложенного здесь варианта с useDebounceFn: https://dev.to/jacobandrewsky/handling-large-lists-efficiently-in-vue-3-4im1
Если надо, могу объяснить, почему это даже близко не то же самое.
Насколько мне известно, похожих на useTransition / useDeferredValue механизмов нет ни в одном другом фреймворке кроме React, и одного лишь этого факта мне уже достаточно для того, чтобы считать React более пригодным для по-настоящему сложных приложений, чем какое бы то ни было иное решение.
TAZAQ
04.04.2026 16:47Если надо, могу объяснить, почему это даже близко не то же самое.
Да, будьте добры, потому что из того что я вижу (не работал с реактом) это прям что-то узконаправленное под рендер реакта. Вообще, useTransition очень похож на nextTick, а useDeferredValue очень похож на дебаунсер с тем отличием, что он срабатывает не через “фикс” время, а когда откроется окошко для обновлений. Оба очень похожи на requestIdleCallback.
aweebit
04.04.2026 16:47Ни
nextTick, ниrequestIdleCallback, ниsetTimeout, ни что-либо ещё в от природы своей однопоточном джаваскрипте не способно прервать выполнение синхронного кода. Вот пример, который позволяет в этом убедиться:setTimeout(() => console.log('a second passed'), 1000); for (let i = 0; i < 1e10; i++); console.log('for loop done');Хоть мы и запросили вывод строки “a second passed” через секунду, на деле выводится она лишь после того, как завершается выполнение цикла for, а это происходит намного позже. Связано это с тем, что цикл выполняется синхронно, то есть не уступая дорогу никакому другому коду, пока цикл не будет выполнен полностью.
По той же самой причине строка “for loop done” появляется в консоли перед “a second passed”, хотя на момент её вывода прошло уже сильно больше одной секунды. Никакой код не может влезть ни между итерациями цикла, ни между циклом и выводом “a second passed”. Всё это синхронный код — последовательность выполняемых друг за другом инструкций, и возможности прервать его просто не существует. Чтобы такая возможность была, код надо сделать асинхронным, например вот так:
function tick() { return new Promise((resolve) => setTimeout(resolve, 0)); } setTimeout(() => console.log('a second passed'), 1000); let i = 0; for (let j = 0; j < 1e3; j++) { const end = i + 1e7; for (; i < end; i++); await tick(); } console.log('for loop done');Вычисление здесь мы разделили на 1000 равных по продолжительности частей, в конце каждой из которых с помощью
await tick()контроль передаётся циклу событий (event loop), который продолжает выполнение цикла for лишь после того, как будут выполнены все остальные ждущие в очереди задачи. Примером такой задачи может быть выполнение переданнойsetTimeoutфункции по истечении указанного срока (в нашем случае это вывод строки “a second passed” по прошествии одной секунды). Другой пример — считывание взаимодействий пользователя со страницей, которые прежде были полностью заблокированы на время вычисления цикла for. Если запустите сначала первый, а потом второй пример в консоли браузера и во время вычисления попробуете нажать куда-нибудь или ввести текст на странице, к которой эта консоль привязана, разница будет очевидна.Теперь наконец можем вернуться к
useTransitionиuseDeferredValue. Весь смысл этих хуков в том, что они превращают изначально синхронную операцию рендеринга дерева компонентов в асинхронную так же, как это было проделано мной с циклом for в примере выше. Оба хука позволяют выполнять тяжеловесные обновления UI на фоне таким образом, чтобы это никак не мешало более срочным синхронным обновлениям и взаимодействию пользователя со страницей, аuseDeferredValueещё и позволяет отменять обновления, которые становятся неактуальны из-за изменившихся вводных данных — например когда пользователь быстро вбивает слово в строку поиска, чтобы отфильтровать по нему данные в таблице. Это как раз тот самый пример, где Vue разработчикам предлагается использоватьuseDebounceFn. ПреимуществоuseDeferredValueпо-моему довольно очевидно:В случае
useDebounceFnфильтрация происходит лишь после того, как ввод слова в строку поиска был завершён (например по прошествии 300 мс с момента ввода последнего символа). Из-за этого фильтрация всегда ощущается заторможенной вне зависимости от размера таблицы.useDeferredValueже фильтрует сразу по мере ввода запроса. Если скорость рендеринга больше скорости ввода (например потому что данных в таблице пока что немного), то скорость отображения результатов этого рендеринга практически идентична тому, какой она была бы, будь этот рендеринг синхронным. Если же скорость рендеринга меньше скорости ввода, то React с каждым новым нажатием клавиши начинает новую попытку отрендерить таблицу на фоне, а предыдущую попытку при этом просто завершает, потому что она больше неактуальна. Так продолжается до тех пор, пока не выходит завершить рендеринг быстрее, чем пользователь нажимает следующую клавишу. Ресурсы расходуются максимально эффективно, при этом пользователь не чувствует никакой заторможенности.Насчёт узконаправленности хуков под рендер реакта: я не думаю, что это соответствует действительности. Возможность прервать рендеринг имхо должна быть во всех фронтенд-фреймворках, поскольку в каждом из них возможна ситуация, когда рендеринг занимает дольше 1000/60 = 16,67 мс, и таким образом в случае его синхронности страница начинает ощущаться заторможенной, как если бы показатель FPS упал ниже 60 кадров в секунду. Но по какой-то причине в то время как разработчики React задумались над решением этой проблемы ещё 10 лет назад (о чём подробнее рассказано в этом отличном видео: https://youtu.be/edN42P_vfCI), другие фреймворки по сей день не считают её приоритетной.
Zori4
04.04.2026 16:47Чтобы такая возможность была, код надо сделать асинхронным, например вот так:
Я бы сделал так:
setTimeout(() => console.log(a second passed'), 1000);function* heavyProcessGenerator(totalIterations) {const chunkSize = 1e10;for (let i = 0; i < totalIterations; i += chunkSize) {const end = Math.min(i + chunkSize, totalIterations);for (let j = i; j < end; j++) {}yield i;}}function runGenerator(iterator) {function step() {const result = iterator.next();if (!result.done) {setTimeout(step, 0);} else {console.log('for loop done');}}step();}runGenerator(heavyProcessGenerator(1e10));
При желании можно и на vue написать кастомный хук с соответствующим функционалом "магических" хуков реакта (наверное), чтобы не только React считатьболее пригодным для по-настоящему сложных приложений
aweebit
04.04.2026 16:47В том-то и прикол, что нельзя на Vue ничего такого написать, потому что рендеринг там заведомо синхронная операция. Эта идея обречена на провал, так же как и попытки найти способ вмешаться в цикл for из моего первого примера. Чтобы его можно было прервать, он изначально должен быть реализован таким образом, который позволил бы это сделать, но это, увы, не так. Та же ситуация и с рендерингом во Vue.
Zori4
04.04.2026 16:47Это да. Но во vue ты можешь управлять сам моментом начала рендера чего-то тяжёлого. Смысл тот же, но просто ты сам выносишь планировщик рендера наружу из системы реактивности:
import { ref, watch, nextTick } from ‘vue’;function useDeferredValue(value, delay = 100) {const deferredValue = ref(value.value);watch(value, (newVal) => {setTimeout(() => { deferredValue.value = newVal; }, delay); });return deferredValue;}Но в реальной разработке на vue это требуется редко. В отличие от React, где при изменении стейта пересчитывается весь Virtual DOM компонента, система реактивности Vue (Dependency Tracking) обновляет только конкретные DOM-узлы, затронутые изменением. Поэтому там, где в React нужно либо прерывать рендер (Concurrent Mode), либо вручную оборачивать всё в
useMemo/React.memo, во Vue обновления просто происходят быстрее и точечнее, не блокируя интерфейс.
kit_oz
04.04.2026 16:47компоненты обновляются целыми деревьями начиная от того компонента, где произошло изменение состояния
Сам по себе ререндер компонента никак не триггерит ререндеры дочерних компонентов. Наоборот - каждый компонент самостоятельно отслеживает свои зависимости, от куда бы они не пришли: пропсы, сторы, прямой импорт реактивной переменной. При этом, даже с большими объектами, ререндер будет происходить не на любое его изменение , а только при изменение тех полей, к которым в компоненте обращались.
dlartagnan
04.04.2026 16:47Activity работает через display: none, это даже не близко KeepAlive. Это не масштабируется на десятки экранов.
Забавно, что они 3 года пилили этот Activity, а получилось такое Г.
aweebit
04.04.2026 16:47Преимущество подхода с display: none в том, что помимо состояния, контролируемого React, сохраняется также и неконтролируемое состояние вроде значений <input>'ов и времени, на котором было остановлено проигрывание видео. Оба этих примера приведены в документации:
https://react.dev/reference/react/Activity#restoring-the-dom-of-hidden-components
https://react.dev/reference/react/Activity#my-hidden-components-have-unwanted-side-effects
Логики в этом по-моему больше, чем в сохранении лишь той части состояния, которая контролируется фреймворком.
dlartagnan
04.04.2026 16:47То есть вы считаете, что другого способа сохранить DOM состояние, кроме как через display:none, нет? Посмотрите этот момент из доклада про Lit:
aweebit
04.04.2026 16:47В ролике не объясняется, каким образом удалось достичь сохранения DOM состояния. Предположу, что это было сделано за счёт сохранения DOM узла в памяти после его удаления из дерева документа с помощью removeChild() / remove(), чтобы потом этот же узел можно было добавить обратно. Других способов полностью сохранить DOM состояние я не знаю.
Так или иначе, узел со всеми его подузлами должен оставаться в памяти, и поэтому мне совсем непонятно, с какой это стати такой подход лучше масштабируется. По-моему вся разница между ним и подходом команды React с display: none сводится к тому, видно ли скрытые узлы в инструментах разработчика. Сказать, что эта разница сильно влияет на масштабируемость, было бы нехилым таким преувеличением.
dlartagnan
04.04.2026 16:47Разница в том, что вам не нужно создавать по компоненту Activity на каждую страницу которую вы хотите закэшировать, вы просто оборачиваете текущий роут в директиву/компонент. И это масштабируется на бесконечное количество страниц, а так конечно узлы хранятся в памяти, потому и есть размер кэша.
Когда я говорю про масштабирование я в первую очередь имею в виду простоту и удобство использования.
zizop
04.04.2026 16:47Когда мы переводили проект с Twig на современный frontend, то как у многих встал выбор между React и Vue. И на тот момент для меня killer feature стало то, что переход на Vue можно было делать постепенно. И на надо было сразу писать ВСЁ на Vue/React, параллельно поддерживая еще и новые изменения в ветке с Twig. У нас банально не было столько ресурсов на это. Мы обернули весь проект во Vue, внутри всё так же работал Twig. А потом начали рефакторинг Twig -> Vue шаг за шагом, компонент за компонентом. И это был рабочий план. Потом я познакомился с Composition API, ref-сами, Pinia. И да, сейчас Vue на голову превосходит React, и все новые проекты я делают только на Vue, потому что для себя я определил, что это правильныы путь.
Albert_Developer
04.04.2026 16:47Тоже был подобный переход. Vue очень удобен для подобных задач, постепенно переписывали страницы с Twig на Vue, подключали Webpack. И проект с кучей легаси-кода засиял новыми красками и в нём стало гораздо приятнее работать.
FireLynx
04.04.2026 16:47Пишу на vue, react не трогала уже лет двенадцать точно, поэтому не знаю даже уже, что там.
Но во vue не всё так безоблачно, как описываете. Проблема с зоопарком непонятных пакетов тоже есть. Хвалёный Quasar обладает такими недостатками, что использовать его на практике не получается.
KeepAlive? Странная штука. Не очень надёжная и с кучей побочных эффектов. В итоге для своих проектов так и не вижу, где её можно использовать.
Но вы говорите, что в реакте всё ещё хуже. Тогда действительно непонятно, почему за него держатся.
Когда-то очень давно меня впечатлило, что во vue есть v-model, когда в реакте для двусторонней связи нужно было серьёзные пляски исполнить. Но это было давно. Версия реакта была что-то вроде 0.15. Как сейчас — не знаю
DeadPull
04.04.2026 16:47Поделитесь что это за недостатки у quasar? Честно сказать такого уровня проекта даже и не знаю. Очень крутая штука и любом моем проекте на фронденде почти всегда используется quasar: pwa, spa, ssr- все это работает без проблем! А если есть проблемы, то в наличии отличная документация.
Krealt
04.04.2026 16:47React и Vue - тут выбор скорее зависит не от фреймворка, а от команды и рынка. Оба хороши и удобны, огромное количество отличный библиотек для каждого из них.
onemantooo
04.04.2026 16:47Порог вхождения и количество "курсов" (в основном количество курсов) которые генерят "опытных" фронтенд разработчиков на мой взгляд здесь играют основную роль.
Для создания сложных приложений IMO Angular - React я всегда рассматривал наоборот для каких-то мелких приложений где не нужна серьезная архитектура/структурированность. Но даже для легких приложений я как Angular based разработчик всегда выбирал Vue. Он в разы чище, структурнее и с ним проще работать.
keireira
04.04.2026 16:47Такой тред, а поклонников моли до сих пор нет... Не дорабатывают
А вообще во вью забивают на jsx и пушат шаблоны уровня пуга или как он там сейчас называется. Одно это отваживает меня от вуя (да, у меня птср от хамл, пуга и подобного мусора). Ну и по мелочи там, опуская малый процент рынка и слава б.гу — мне и реактов со свифтами и некстами хватает, fine-grained reactivity влечёт держание в уме работу с рефами\reactive, toRefs добавляет масла; composition api переусложнён; реакт без пробелм на тс ложится, в вуе пляску с бубном помню с его definedProps<T>() или как там; вместо единой линии партии зопарк какой-то из options api, composition api, script setup, миксинов и ещё чёрт знает чего; про RSC вообще молчу. Впрочем, это больше вкусовщина и сейчас действительно можно писать на нём.
А про "серьёзное и несерьёзное" это наверное больше говорят в контексте что в вуе очень низкий порог входа?
Алсо, про кипалайв. Можно набросить что он для quick&dirty решений, когда же реакт толкает к арзитектуре с разделением на состояние и юи + не жрёт ресурсы пока поддерево заморожено (у вуя вроде тоже можно так сделать, но надо ручками всё чистить). Люди и так воют на ужасного веб-пожирателя ресурсов, а вуй,получается, ещё больше усугубляет эту проблему хд. Ну и не спорю что я вуй весьма поверхностно знаю, но вроде как кипалайв не даёт возможность пререндерить контент, например, когда в реакте можно сделать что-то типа
<Activity mode={activeTab === 'home' ? 'visible' : 'hidden'}>и радоватьсяkeireira
04.04.2026 16:47А, и самое главное. На вуе нельзя писать под мобилки без головной боли. Шах и мат. С реактом ты можешь очень быстро расширить своё сознание до свифта с котлином и начать писать на рн, а с вуем... кхм, оказываешься запертым в психотронной веб-тюрьме (кто-то скажет про квазар, но забудет упомянуть что в мобилки он тащит вебвью, а для десктопа вообще хромога бггг)
Zori4
04.04.2026 16:47keep-aliveво Vue — это инструмент для кеширования состояния и экземпляров, он удаляет компоненты из DOM, освобождая ресурсы рендеринга.
То, что ты описываешь в React (Activity/ hidden rendering) — это про пререндеринг. Во Vue это делается просто черезv-showи это было под капотом с первых версий.
Что касается ресурсов:keep-aliveхранит только JS-объект в памяти, а не живой DOM. Да, надо ручками чистить таймеры, подписки и тд, но это ответственность и дисциплина разраба писать чисто и убирать за собой)) Так что претензии к инструментуkeep-aliveтут беспочвенны)
ilemusic
04.04.2026 16:47Относительнл недавно остро встал вопрос на чём писать frontend не имея какого-либо опыта в современных фреймворках.
Советчиков рядом не оказалось, выбирать пришлось самому.
Выбирал очень долго. Angular я отмёл из-за typescript only (как я понял), а react из-за JSX (очень сильно напомнило JSP и сразу оттолкнуло, с меня хватит уже этого "дерьма").
Дошёл до Vue, сразу понравилась концепция где можно в одном файле компонента хранить разметку, код и стили. Для моих целей этот подход более удобен. Плюс поддержка как javascript, так и typescript. Я себе выбрал js, потом может перейду на ts, но это не точно. Ещё я познакомился с h() - моё почтение! JSX тут как мне кажется курит в сторонке.
Вместо вывода: я как бэкендер - кайфую от Vue! Реально удобный фреймворк. Оказалось, что создавать UI на современном стеке - это невероятно классно. С удовольствием погружаюсь с ним в создание нового компонента. И нисколько не жалею о выборе именно Vue. Для моих целей - он идеален.
greemq
04.04.2026 16:47Ооо да, сам так столкнулся. 5 лет на vue и последние полтора года на nuxt.
Такая история появилась где то пол года назад со второй работой, успешно весь фронт на nuxt с нуля поднимал, все отлично. Но тут в силу вступили требования, типа react это завод а nuxt/vue это так, экскаватор на радиоуправлении, и причем больше ссылаются что реакт это прям какое то божество которое можно крутить вертеть как хочешь. Покопался я в реакт коде и это такое усложнение как по мне, но людей не переубедить т.к. типа всякие lovable figma и другие на реакте выдают все.
Но те кто так говорят не могут мне ответить почему vue/nuxt хуже если все строится с нуля? Вот просто отказываются как либо комментировать данную вещь, но почему то команда которая сидит на vue/nuxt ничего плохого не говорила ни разу, разве что "неудобно как то".
Просто сейчас после простой архитектуры vue script/template реакт вообще не поддается какому либо пониманию)
Googlonator
04.04.2026 16:47Не знаю технических особенностей vue, я делал на нем лишь не большое приложение и мне не понравилось. Но я реакт разаб
Oeaoo
Это крик души? Тогда максимум сострадания)
Pnym Автор
Крик, но уже переходящий в хрип)