Как стать автором
Обновить

Комментарии 62

А есть не тормозные фреймворки вообще?

А тормозные это какие?

Наверное все, которые сейчас в ходу.

Обоснуйте пожалуйста

Главное ляпнуть?

да тот же SolidJS: сильно меньше, чем React и шустрее за счёт более правильной модели реактивности

Ооо, это единственный стоящий комментарий.

P.S. почему их кличут фреймворками? Всё-таки это библиотеки больше напоминают

Angular — вполне себе фреймворк

Svelte. И гораздо удобнее, кайфовее в плане разработки и использования,чем эти 3. А еще и понятнее и проще для входа новых разработчиков. Разработка фронтенда реально становится удовольствием.

Vue CLI — это очень сильный инструмент, который упрощает создание и настройку проектов на Vue

Больше не поддерживается и не рекомендуется. Предлагается использовать create-vue.

Vuex: для управления состоянием приложения

Аналогично, давно уже предлагается использовать Pinia.

Не соглашусь про pinia. Она не рекомендовалась а просто была единственным storage для vue3, но потом вышел Vuex4 для vue3 и опять стало опять все хорошо и его можно снова использовать в проектах.

Хорошо для тех, кто не может избавиться от старых привычек или legacy кода?

Pinia is now the new default. The official state management library for Vue has changed to Pinia. Pinia has almost the exact same or enhanced API as Vuex 5, described in Vuex 5 RFC. You could simply consider Pinia as Vuex 5 with a different name.

Большое спасибо за вашу информацию! Действительно, Vue CLI и Vuex постепенно уступают место новым инструментам, и для новых проектов теперь рекомендуется использовать create-vue для создания каркасов проектов на базе Vite. Однако, я бы не была так категорична насчёт "не поддерживаются". Я видела проекты, которые до сих пор используют Vuex и Vue CLI. Пару месяцев назад, кстати, здесь же читала статью о миграции с Vue CLI и Webpack на Vite.

создатель Vue, однажды сказал: «Pinia — это фактически Vuex 5! На данный момент это действительно вопрос названия/брендинга».

Двустороннее связывание данных не только в angular, еще и во vue.
Хуки есть не только в react, а еще и во vue ака composables (примеры)
Очень сильный инструмент Vue CLI is now in maintenance mode, про vuex тоже уже сказали.
Вы делитесь мнением про времена vue v2)

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

Во-первых, хуки появились раньше в react, во-вторых, хуки во vue вообще не то же самое, что в react, потому что во vue это не хуки, а просто реактивный API, который буквально нужен для создания state и который можно использовать даже вне компонента. А в react хуки подвязываются к контексту для связки с нодой в VDOM, что и создаёт "магию" для того же state, и по сути являются костылями из-за отказа от классовых компонентов

Вы правы, хуки в React и Composition API в Vue 3 появились с разницей в полтора года или даже больше. Я, вероятно, перепутала их с другими концепциями, возможно, с миксинами. Благодарю за уточнение, это помогло лучше разобраться в различиях!

Typescript же все три поддерживают, реактивность тоже у всех есть. И компонентность. Так в чем обзор плюсов и минусов? Я не увидел выделенных отличий

Во Vue и Angular тайпскрипт не может проверять типы внутри шаблонов.

А если использовать JSDoc, то тоже нет возможности проверять?

Я не уверен, что есть такой чекер для шаблонов

Если ангуляр собирать под AOT, то вроде как проверяет

Вы про это?
https://angular.dev/tools/cli/template-typecheck

Отлично, этого раньше не хватало. Жаль, что по режимам и собственно чекам много нюансов. И во Vue такого очень не хватает.

А чего именно не хватает?
https://vuejs.org/guide/typescript/overview#typescript-in-templates

Передача параметров в компоненты в шаблонах не отслеживается.

Может я что-то не так понял, но типы для параметров, указанные в дочернем компоненте, вполне себе отслеживаются

Я ошибаюсь, или проверка во время разработки зависит от сторонних расширений к редактору?

Да, это плагин от разработчиков Vue, но под капотом используется универсальный Language Server Protocol, который есть во многих редакторах, от VSCode до vim.
В репозитории vuejs/language-tools собраны все тулзы, которые могут помочь при работе с *.vue файлами (например, cli утилита для тайпчека). Там же ссылки на плагины для редакторов/IDE.

Если использовать JSX, то проверка параметров работает из коробки.

Но смысла в использовании JSX немного, потому что выйдет компилятор шаблонов (Vapor), который выкинет VDOM и позволит обновлять DOM максимально точечно, на основе используемых реактивных объектов в шаблоне.
Не уверен, что он будет работать с JSX, хотя мейнтейнер Vue вроде бы упоминал о поддержке, могу ошибаться.

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

Но нет, всегда обламываюсь.

На рабочих проектах так делать никто не будет (потому что половина времени уйдет впустую). На студенческих... ну попробуйте сами :)

Зато вы непременно прямо, либо косвенно, узнаете об очередном факте устаревания какого-либо инструмента или библиотеки ;)

https://youtube.com/playlist?list=PLLnpHn493BHGeUSbg-tjxVyMKQnIB0kVL&si=dCDpetTEyQ9j4rJW

React vs Vue 3. Общее впечатление составить можно

из троих Vue единственный адекватный. а так, как упомянули выше, SolidJS сейчас является самым лучшим и по удобству и по производительности. скоро должен Svelte v5 выйти – тоже круто, но больше для тех, кому Vue нравится

Либо сгенерировано, либо копипаста какая-то старая. По факту: самый лучший фреймворк - VUE, это даже не обсуждается. Но использовать его в разработке не стоит, потому что с переходом на 3 версию половина экосистемы погибло, а ещё половина от половины - китайское. Angular - самый худший. Из за rxjs, observables и модулей (а также сервисов и ещё много чего). Он пытается превратится во VUE с каждой новой версией (раз в полгода), но пока что получается так себе. Поэтому нравится/не нравится (мне не нравится) кроме React ничего не остается. Всякие Solid, Svelte и т.д. серьезно рассматривать смысла нет, если только не мазохисты, любите костыли и велосипеды и не любите ии-помощников.

Вы меня раскусили, это сгенерированная старая копипаста. Что вы имеете в виду под «погибло» половина экосистемы Vue? И почему вы всё еще считаете его лучшим? Судя по вашему комментарию, лучший React?

Ну вот вы сейчас это и доказали. Как можно писать статью про фреймворки без понимания того, что в них происходит? У 2ой и 3ей версии VUE совершенно разные API, и когда вышла трёшка - все создатели библиотек, плагинов и пр (в том числе самых популярных) не кинулись скопом переписывать все это дело, ибо изменения радикальные, работы много. Соотв все это дело и кануло в лету. Найти что то готовое/актуальное за пределами vuetify не так просто, а чаще невозможно. Писать на нем можно, но зачем? Если есть реакт где все тоже самое, но нет таких проблем

Не совершенно разный, но устаревшие места нужно переписывать. Тем более никто не заставляет переписывать компоненты в объектном стиле на композаблы. Что же касается компонентов, так в больших проектах и так почти всё с нуля пишут, ибо стили под дизайн свои. Сложные же компоненты вроде датапикеров или мультиселектов есть. Ну а реакт — далеко не то же самое.

Да и датапикер с мультиселектом так же прекрасно пишутся

Особенно с композишн апи

А что такого нужно от экосистемы Vue, чтобы, по-вашему, можно было начинать его использовать в разработке?

Кстати, "ии-помощники" нормально понимают SolidJS, не надо на них наговаривать.

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

Разве аутентификация и авторизация в целом не зависят от UI-слоя, который предоставляют React или Vue?

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

Angular крут тем, что позволяет писать декларативный и реально реактивный код, его разработчики очень стараются работать в этом направлении. Особенно это видно по последним двум версиям (17-18), где они ввели сигналы (signals) и пытаются отвязаться от zone.js в своем механизме change detection. Теперь со связкой signals + rxJs (observables, subjects) можно писать минимум императивного кода. Кому не нравятся модули - делайте standalone компоненты, разработчики ввели и такую фичу, всё для народа.

Основной проблемой фреймворка раньше всегда слышал его возможную медленность при написании громоздких страниц. Такое случается у менее опытных разработчиков, которые ещё не вникали в принципы работы механизма, который обеспечивает фреймворку его реактивность - change detection'а. Если достаточно хорошо понять как это работает, использовать разные его стратегии в компонентах, пользоваться пайпами вместо обычных вызовов методов из шаблона страницы - всё будет ок даже при огромных страницах с множествами сложных форм. Да и разработчики, как было сказано ранее, стараются улучшать эту часть нашей жизни.

Angular крут тем, что позволяет писать декларативный и реально реактивный код

Но ведь и Vue позволяет писать декларативный и реально реактивный код. Притом изначально не требовал для этого костылей в виде RxJS, ZoneJS и прочего.

Да, Vue тоже крут, пусть я и не разбирался во всех его аспектах в то время как писал немного на нём, а после не особо следил за прогрессом языка. Мне кажется для любого человека достаточным для выбора фреймворка будет написать одно и то же приложение по типу прокаченной тудухи с каким-то минимальным стейт менеджментом. Человек почувствует разницу между ними и свою личную приязнь/удобство к какому-либо из них. А если вообще ничего не нравится, то зачем таким заниматься :)

Очень долго писал на Ангуляре, к rxjs так и не привык, каждый раз смотришь на какую-то магию в коде и не можешь вспомнить, как она работает. Это главное из-за чего не хочется больше Ангуляром пользоваться. Вью в первый раз увидел когда был переход с angular.js на Angular2, последний казался крайне перспективным, а Вью, хоть и хорошеньким, но не впечатлил. В прошлом году взялся за Вью снова - делал свой проект месяца полтора, а там Composition API просто сказка после ангулярных сервисов. Кроме тормозного Nuxt (в итоге его бросил и делал все на Vite) у меня нет никаких претензий к экосистеме, документации и т.п., все просто отлично, следующий коммерческий проект спокойно бы делал на нем. Что касается реакта, мне всегда был отвратителен его линукс вэй подход (собирай тысячу пакетов как знаешь) и его организация кода из-за jsx, и мне очень жаль, что он "победил"

С ангуляром и rxJs да, тут нужно реально вникнуть в суть этого, чтобы писать без боли и это даже нравилось. Насчёт остального поддерживаю, вот как раз на прошлой неделе надо было делать по работе демо апликуху на реакте. Я не реактивщик, но за несколько дней вышла нормальная демка с использованием FluentUI и прочих либ. Но как же это надоедает на каждый чих писать кучу лишнего кода используя встроенные и кастомные хуки.

С каких пор Vue и React стали фреймворками? Тогда в кучу им jQuery приписали бы.

Статья о девочке, как она познала Vue и React, на Angular сил не хватило? Ибо в Vue и React порог входа проще, так и надо было написать, входить во фронт нужно с этих двух библиотек.

Хотя бы примеры какие накидали к статье. На вид статья наляпаная на GPT.

Статья о девочке, как она познала Vue и React, на Angular сил не хватило — прекрасное название для моей следующей статьи! 😊

входить во фронт нужно с этих двух библиотек

ну это же совсем необязательно

С каких пор Vue и React стали фоеймворками?

Их часто называют фреймворками поскольку их функциональность и экосистемы выходят далеко за рамки обычных библиотек или вопрос был риторическим?О_о
За совет с примерами, спасибо, я приму его к сведению, важный момент))

это кстати с сайта vue
это кстати с сайта vue

А с каких пор vue не является фреймворком.

Основное отличие фреймворка от библиотеки это наличие инверсии контроля. Разве во vue нет инверсии контроля ?

Судя по комментариям, разработчики frontend на хабре более молодые и резкие :)

А по делу - не важно, framework ли или набор скриптов выбран как инструмент, но его НАДО использовать если он упрощает и/или организует мою работу и позволяет выполнить мои задачи быстрее и легче.

Я попробовал много предлагаемых пакетов. Основными были Jquery, React, Vue но не потому, что я не знаю остальные, а потому, что на тех проектах, где я работал, это уже было.

Два года назад на Vue конгрессе я познакомился с Deno.Fresh и это удивительно, как быстро он мне зашел сам по себе. Например до этого я пробовал $mol, прости господи. И это была $боль. А тут pReact, реактовый или vue подход при создании "островов" на выбор, и плюс простой интерфейс для backend части. Пару найденных мною isuue поправили за несколько недель.

В общем, для экспериментов я сейчас играю в deno.fresh. А для работы использую тот фреймворк/js-пакет, что уже выбран в проекте.

Сейчас к вам прибежит господин Карловский и скажет, что вы ничего не поняли, что у вас, простите, руки не из того места растут, и вообще, как можно сравнивать великий и божественный $mol с какими-то там ползающими по земле фреймворками...

Начинающему выбора не дают вообще - Реакт. Под VUE не так уж и много проектов. Ангуляр де фаркто мертв.

Создание SPA, где и нужны все эти модные мощные штуки - плохая практика и просто способ выстрелить себе в ногу. https://www.thoughtworks.com/de-de/radar/techniques/spa-by-default

И тут до сих пор не упомянули htmx, который решает 90% проблем фронта гораздо проще и убирает нужду в больших фреймворках.

Под Vue в целом достаточно проектов, а стартапы на нём делать быстрее, чем на Реакте.

Может быть 80% проблем HTMX и решает, но 20% задач сделают больно. И хорошо, если не более 80% времени они потребуют.

Разумных доводов от Thoughtworks, что SPA — это плохая практика, я не увидел. Browser history management решается обычным фронтендным роутером уже почти 10 лет; веб-аналитика тупо работает как есть — ей достаточно урла в браузере; там где нужны SEO (а это далеко не все админки) и TTFB — используются Next / Nuxt / whatever.

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

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

Можете привести практически пример? Потому что сейчас это ни о чём. В браузере API работы с историей есть из коробки, роутеры работают поверх него. И да, если он в приложении не нужен, роутер можно не подключать.

Скажу за Vue: мне проще всего его встраивать в "обычные" страницы. Angular требует "компиляции", React без jsx мало осмыслен. У меня есть корпоративный инструмент, где можно делать диалоги в дизайнере. И когда надо добавить интерактивность, то выбор между чистым JS/JQuery или Vue.

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

React

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

Виртуальный DOM - так же не является особенностью среди трех приведенных фреймворков, поскольку Vue так же его использует (https://vuejs.org/guide/extras/rendering-mechanism.html#virtual-dom). В добавок, что очень важно, VDOM не дает преимущества в производительности, эта байка, которую не стоит распространять среди начинающих разработчиков. VDOM - это ничто иной, как прослойка между DOM API и API фреймворка. И в любом случае -- это оверхэд.

JSX - безусловно является фишкой React. Однако, стоит понимать, что эта технология не привязана к React и на Vue так же можно писать, используя JSX, если очень захочется.

React Hooks - действительно особенность React. Плюс или минус, вопрос уже спорный, но действительно подход в свое время был уникальным, хотя тот же Vue с третьей версии предложил свой похожий синтаксис.

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

Отличная документация и обучение - с недавних пор согласен :D

Vue

Прогрессивный фреймворк - зачем нужен этот пункт, категорически непонятно. Это просто слоган с сайта Vue и все. Он не несет в себе смысла и особенности. Например, в тексте вы говорите, что Vue можно встраивать в другие фреймворки, видимо это делает его прогрессивным. Но ведь React тоже можно встроить в любое приложение "посередине" и все будет работать. Наверняка, и Angular можно, но я не пробовал, так что не уверен.

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

Декларативные шаблоны - согласен, что являются преимуществом, но не являются особенностью, так как Angular так же использует шаблоны, которые вроде как даже нормально типизируемы с недавних пор.

Реактивность - все три фреймворка реактивны в той или иной степени. React получил свое название не с проста. Особенностью можно было бы назвать, что Vue предлагает свою отдельную standalone систему реактивности, в то время как в React она жестко вплетена в фреймворк, а Angular использует стороннюю библиотеку.

Компонентный подход - вроде бы был у React...

Экосистема - снова повторение...

Отличная документация и сообщество - ...

Поддержка TypeScript - все три фреймворка написаны и поддерживают TS. Это не является особенностью Vue.

Angular

TypeScript - ну как так?

Модульность - согласен с этой особенностью. Хороший пример.

Двухстороннее связывание данных - у всех трех фреймворков есть реализация двустороннего связывания (React Controlled Component, v-model у Vue), так что это не является особенностью."

RxJS и реактивное программирование - согласен!

Шаблоны и директивы - есть у Vue.

Встроенное тестирование - согласен!

Большое сообщество и поддержка - как же упоминалось, есть у всех трех.

В итоге, большое спасибо за статью, несмотря на все, что я выделил выше, статья написана хорошо! Просто хотелось бы видеть в подобных статьях больше реальных различий, которые могут повлиять на выбор новичка. Например, что там по проектам на React. Курсам, книгам, статьям, видосам. Насколько сильно мы уходим с фреймворком от DOM API, насколько хорошо нужно знать как работает браузер и т.д и т.п.

P.S.: прошу прощения если передушнил, обижать никого не хотел!

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

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

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

Мне нравится Astro, хоть он не чисто UI-фреймворк, а больше full-stack и SSG. "Островная" архитектура, JSX-подобный синтаксис с некоторыми отличиями (возможность использования привычного атрибута class вместо className, отсутствие необходимости "обертывать" два тега в <div> или <>)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории