Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 31
Это крик души? Тогда максимум сострадания)
Да не плачьте :) Дело не в Vue. Просто так сложилось, что react был раньше, c 2011, поддерживался крупной компанией со старта, было больше написано инструментов, фреймворков. Вот и получается, что в крупных проектах, чаще используются либо angular либо react. Проще найти специалистов, проще найти библиотеки с лучшей поддержкой, больше комьюнити, больше нейронов в ИИ моделях натренированных на react.
Крутость уже не играет роли, можно на любом языке написать с ошибками. И смысл тогда?
React.js vs. Vue.js
Linux vs Minix
Rust vs. C++
...
В React ты будешь писать костыли через глобальный стейт, сериализацию в URL или танцы с бубном вокруг React Router.
Почему это? Я возьму <Outlet />
Наконец кто-то это сказал)))
Я говорил это с 2021, времен vuejs2/nuxt2. А потом, с середины 2025, мне стало все равно. Хотя стоит отметить, что предпоследней мажор nuxt4 хорош, а 5 будет ещё лучше.
Я тоже устал от реакта и его костылей. И я тоже высказался - записал видео на Ютуб: реакт vs vue. Набежали макаки реактовские и начали мне писать про правильную декомпозицию
Понимаю))
Я тоже в свободное время глубоко копаю и React, и Vue, и последние наблюдения заставляют задуматься. В экосистеме React, например, до сих пор нет прямого аналога Quasar «всё в одном». С React Compiler тоже были шероховатости в пет-проектах: в связке с react-hook-form иногда ломался ререндер :(
В React начиная с версии 19.2 доступен компонент <Activity>, функция которого насколько я понимаю такая же, как у <KeepAlive> из Vue.
А что предлагает Vue в качестве альтернативы реактовским useTransition / useDeferredValue?
useTransition 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”, обновляя только компоненты которые реально изменились
В основе 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 более пригодным для по-настоящему сложных приложений, чем какое бы то ни было иное решение.
Если надо, могу объяснить, почему это даже близко не то же самое.
Да, будьте добры, потому что из того что я вижу (не работал с реактом) это прям что-то узконаправленное под рендер реакта. Вообще, useTransition очень похож на nextTick, а useDeferredValue очень похож на дебаунсер с тем отличием, что он срабатывает не через “фикс” время, а когда откроется окошко для обновлений. Оба очень похожи на requestIdleCallback.
Activity работает через display: none, это даже не близко KeepAlive. Это не масштабируется на десятки экранов.
Забавно, что они 3 года пилили этот Activity, а получилось такое Г.
Преимущество подхода с 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
Логики в этом по-моему больше, чем в сохранении лишь той части состояния, которая контролируется фреймворком.
То есть вы считаете, что другого способа сохранить DOM состояние, кроме как через display:none, нет? Посмотрите этот момент из доклада про Lit:
В ролике не объясняется, каким образом удалось достичь сохранения DOM состояния. Предположу, что это было сделано за счёт сохранения DOM узла в памяти после его удаления из дерева документа с помощью removeChild() / remove(), чтобы потом этот же узел можно было добавить обратно. Других способов полностью сохранить DOM состояние я не знаю.
Так или иначе, узел со всеми его подузлами должен оставаться в памяти, и поэтому мне совсем непонятно, с какой это стати такой подход лучше масштабируется. По-моему вся разница между ним и подходом команды React с display: none сводится к тому, видно ли скрытые узлы в инструментах разработчика. Сказать, что эта разница сильно влияет на масштабируемость, было бы нехилым таким преувеличением.
Разница в том, что вам не нужно создавать по компоненту Activity на каждую страницу которую вы хотите закэшировать, вы просто оборачиваете текущий роут в директиву/компонент. И это масштабируется на бесконечное количество страниц, а так конечно узлы хранятся в памяти, потому и есть размер кэша.
Когда я говорю про масштабирование я в первую очередь имею в виду простоту и удобство использования.
Когда мы переводили проект с Twig на современный frontend, то как у многих встал выбор между React и Vue. И на тот момент для меня killer feature стало то, что переход на Vue можно было делать постепенно. И на надо было сразу писать ВСЁ на Vue/React, параллельно поддерживая еще и новые изменения в ветке с Twig. У нас банально не было столько ресурсов на это. Мы обернули весь проект во Vue, внутри всё так же работал Twig. А потом начали рефакторинг Twig -> Vue шаг за шагом, компонент за компонентом. И это был рабочий план. Потом я познакомился с Composition API, ref-сами, Pinia. И да, сейчас Vue на голову превосходит React, и все новые проекты я делают только на Vue, потому что для себя я определил, что это правильныы путь.
Пишу на vue, react не трогала уже лет двенадцать точно, поэтому не знаю даже уже, что там.
Но во vue не всё так безоблачно, как описываете. Проблема с зоопарком непонятных пакетов тоже есть. Хвалёный Quasar обладает такими недостатками, что использовать его на практике не получается.
KeepAlive? Странная штука. Не очень надёжная и с кучей побочных эффектов. В итоге для своих проектов так и не вижу, где её можно использовать.
Но вы говорите, что в реакте всё ещё хуже. Тогда действительно непонятно, почему за него держатся.
Когда-то очень давно меня впечатлило, что во vue есть v-model, когда в реакте для двусторонней связи нужно было серьёзные пляски исполнить. Но это было давно. Версия реакта была что-то вроде 0.15. Как сейчас — не знаю
React и Vue - тут выбор скорее зависит не от фреймворка, а от команды и рынка. Оба хороши и удобны, огромное количество отличный библиотек для каждого из них.
Порог вхождения и количество "курсов" (в основном количество курсов) которые генерят "опытных" фронтенд разработчиков на мой взгляд здесь играют основную роль.
Для создания сложных приложений IMO Angular - React я всегда рассматривал наоборот для каких-то мелких приложений где не нужна серьезная архитектура/структурированность. Но даже для легких приложений я как Angular based разработчик всегда выбирал Vue. Он в разы чище, структурнее и с ним проще работать.
Боже как я тебя понимаю)
тоже самое говорят и про $mol
Такой тред, а поклонников моли до сих пор нет... Не дорабатывают
А вообще во вью забивают на 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'}> и радоваться
А, и самое главное. На вуе нельзя писать под мобилки без головной боли. Шах и мат. С реактом ты можешь очень быстро расширить своё сознание до свифта с котлином и начать писать на рн, а с вуем... кхм, оказываешься запертым в психотронной веб-тюрьме (кто-то скажет про квазар, но забудет упомянуть что в мобилки он тащит вебвью, а для десктопа вообще хромога бггг)
Было бы желание :D
https://nativescript-vue.org
https://vue.lynxjs.org
Уже можно. vue-lynx
Поддерживаю
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как же устал это слышать: «React для создания сложных приложений, а Vue так уж…»