Expert JS React Developers for TUI wanted. Join Ciklum and get a $4000 sign-on bonus!
×Закрыть

React vs Vue.js: что изучать в 2021 году

Всем привет! Меня зовут Владислав Василенко, работаю на должности Software Engineer в компании Dev.Pro. В повседневных задачах я использую Angular, поэтому все последующие рассуждения построены на опыте изучения данных инструментов и использования в различных pet projects.

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

Данная статья не призвана стать началом очередного холивара на тему, что лучше. Рассуждений об этом и так хватает в сети. Главной целью материала является желание помочь выбрать технологию для изучения в 2021 году. Это актуальный вопрос как для начинающих программистов, так и для более опытных, которые думают о том, чтобы переключиться на что-то новое.

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

История

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

React — JavaScript-библиотека с открытым исходным кодом, созданная Джорданом Валке из Facebook. Перед компанией стояла задача улучшить процессы создания и рендеринга интерфейсов, ведь Facebook необходимо было разрабатывать и поддерживать. Уже на тот момент это был огромный проект, а существующих технологий не хватало. Впервые React использовался в новостной ленте Facebook в 2011 году и позже в ленте Instagram в 2012-ом. Но лишь в 2013 году сообществу разработчиков на конференции JSConf US был представлен исходный код. Прошло уже много времени, вышли сотни апдейтов, фиксов и дополнений функционала, но с тех самых пор React остается самым популярным среди 3 гигантов.

На сегодня версия 16.14.0 от 14 октября 2020 года является самой актуальной. За счет своей популярности и удобства многие крупные компании используют эту библиотеку для разработки своих продуктов. Среди них Facebook, Netflix, Yandex и многие другие.

Vue.js — JavaScript-фреймворк, созданный в 2014 году Эваном Ю, бывшим сотрудником Google, хотя разработку он начинал еще в стенах компании. Факт того, что полноценный фреймворк был создан одним программистом, — одно из главных отличий Vue, ведь за остальными стоят технические гиганты. На начальном этапе Эван полностью занимался написанием кода, обновлением документации, исправлением багов и продвижением своего детища.

С момента появления Vue прошло 6 лет, и уже сейчас он сравнялся по популярности с Angular от такого гиганта, как Google. Самый свежий релиз Vue 2.6.11 был представлен 13 декабря 2019 года. Но 18 сентября 2020 года была показана версия 3.0, которая уже в скором времени станет основной. Смешение возможностей других успешных JavaScript-фреймворков, одна из лучших документаций (лучшая на китайском) и легкость начала работы делает его таким популярным. Среди крупных компаний, которые пользуются всеми преимуществами Vue, отмечу Zoom, GitLab, Behance, Font Awesome.

Популярность

Количество библиотек и фреймворков для JavaScript неуклонно растет. Каждый год появляются новые «убийцы», которые обещают более высокую производительность, более удобное использование и меньшее количество багов. Этот процесс нельзя остановить, за ним лишь остается следить, чтобы не оказаться в ситуации, когда твой стек будет устаревшим.

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

Google Trends — статистика поисковых запросов довольно точно показывает интерес разработчиков к различным технологиям.

На данном графике приведены данные за последние 12 месяцев. Если взглянуть на них, становится очевидно, что React уверенно удерживает лидерскую позицию. Количество запросов по нему превышает более чем в два раза показатели Vue.js. Но все же это не дает нам право однозначно отодвинуть Vue на задний план.

Stack Overflow Developer Survey — ежегодно самый популярный форум программистов проводит собственное исследование, в котором могут принять участие все желающие.

Если обратить внимание на результаты опроса 2020 года на тему самого любимого веб-фреймворка, то здесь разрыв между React и Vue.js составляет чуть меньше 3%. Теперь ситуация не выглядит такой однозначной, как после первого графика.

Github Stars — по количеству звезд у репозитория можно с легкостью сказать о популярности чего-либо среди разработчиков.

На текущий момент у React 157 тысяч звезд, в то время как у Vue.js — 174 тысячи. Если смотреть только на эти данные, то Vue явно лидирует, а значит, нет никакого смысла тратить время на React. Но, как я упоминал выше, необходимо всегда обращаться к нескольким ресурсам, чтобы получить полную картину.

The State of JavaScript — опрос, посвященный исключительно JavaScript. Где, как не здесь, можно выявить настоящее отношение разработчиков к используемым инструментам.

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

npm trends — простой, но информативный инструмент, который позволяет сравнить количество загрузок пакетов.

Как видно из графика, количество скачиваний React и сопутствующих ему библиотек превышает показатели Vue.js в четыре раза.

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

По состоянию на 21.10.2020
ТехнологииLinkedInIndeedDjinniDOU
React15139001023434
Vue.js281148216139

Как видно из графика, React не оставляет никаких шансов Vue.js.

Поддержка, комьюнити, документация

Как бы много не шутили о том, что программисты занимаются только копированием кода со Stack Overflow и гуглением ответов, но это составляет немалую часть повседневной жизни разработчика, особенно во время изучения новой технологии. Порой банальное центрирование дива может загнать в угол. Для опытных программистов важно иметь возможность обратиться к технической документации, а главное, чтобы она была понятно написана, что бывает не всегда. Давайте сравним эти характеристики.

React — «вместе мы сила, а порознь погибнем». Данный афоризм лучше всего описывает неоднозначную ситуацию с этой библиотекой. С одной стороны, сообщество программистов насчитывает десятки тысяч специалистов из разных стран. Практически невозможно столкнуться с проблемой языкового барьера. А с другой стороны, назвать документацию самой библиотеки и огромного количества пакетов для нее исчерпывающей — точно нельзя.

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

Глядя на Stack Overflow, который содержит более 255 тысяч вопросов по #reactjs, также появляются некоторые мысли. С одной стороны, можно не беспокоиться за отсутствие ответа на интересующий вопрос, а с другой — усомниться в качестве библиотеки. Ведь если что-то работает хорошо, то должны ли возникать вопросы? Еще одно большое преимущество React — огромное количество обучающих материалов.

Vue.js — истинный король документации, которая по праву считается его визитной карточкой. На сайте фреймворка можно найти подробное и качественное описание и на английском, и на русском языке. Отдельного внимания заслуживает китайская версия документации, которая не только считается самой лучшей, но и была написана самим создателем фреймворка. Кстати, это сыграло немаловажную роль в популяризации Vue. По данным за 2018 год, половина респондентов из Китая использует этот фреймворк.

И хоть Vue.js стремительно развивается, но комьюнити по-прежнему не достигло размеров React. Это влечет за собой как меньшее количество обучающих материалов, так и трудности в поиске ответов на интересующие вопросы. На данный момент на Stack Overflow присутствует более 66 тысяч вопросов по #vuejs. Можно ли считать это хорошим результатом за 6 лет? Такая же двузначная ситуация, как и с React. Это может говорить как о качестве фреймворка, так и о слабом комьюнити.

Сравнение React и Vue.js

В этом разделе поговорим о схожих чертах, преимуществах и недостатках. Начнем с общего, которого много. Это неудивительно, ведь Эван Ю использовал React в качестве вдохновения для написания собственного фреймворка. Из общего эти инструменты имеют:

  • Virtual DOM (реализация во Vue.js значительно производительнее и стабильнее);
  • реактивность и компонентная структура;
  • использование дополнительных библиотек для внедрения роутинга, управления глобальным состоянием и прочего;
  • поддержка PWA;
  • поддержка TypeScript;
  • обратная совместимость, простая миграция версий.

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

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

React можно считать хулиганом из мира веб-фреймворков. Он нарушает все правила, так называемые best practices. Если все время до этого считалось необходимым разносить разметку, стили и JavaScript по отдельным файлам, то с появлением JSX, где все может находиться в одном месте, мнения разработчиков разделились. Одни считают, что это упрощает разработку, позволяет сразу находить ошибку, так как React не скомпилируется, если чего-то не хватает или, наоборот, присутствует что-то лишнее. А другие говорят, что это только сбивает с толку и усложняет весь процесс. Чтобы было понятнее, я приведу отрывок, который содержит в себе разметку со стилями:

import React from 'react';
import './Homework.css';
export const Homework = (props) => {
     return (
          <div className="homeworkTasks" color='blue'>
               <p className="homeworkDescription">
                    {props.description}
               </p>
               <div className="homeworkDone" onClick={props.done}>
                         x
               </div>
          </div>
     );
};

Сперва такой синтаксис сильно сбивает, но потом, написав какое-то количество строк, вы перестанете обращать внимание на HTML и CSS внутри JavaScript.

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

<template>
     <div class="homeworkTasks">
          <p class="homeworkDescription">{{homework.description}}</p>
          <div class="homeworkDone" @click="done(homework)">
               х
          </div>
     </div>
</template>

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

Каждый подход имеет свои преимущества и недостатки. Для использования React необходимо освоить JSX, чтобы писать шаблоны — разобраться с DSL. Но если абстрагироваться от всего этого, то можно сделать вывод, что подход Vue.js более прост в освоении, а также позволяет сделать больше с меньшим количеством кода (например, с v-on модификаторами). Но не будем на этом останавливаться и перейдем к следующему различию.

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

React для управления глобальным состоянием данных использует сторонние библиотеки. Самой популярной среди подобных является Redux. Ее популярность обусловлена тремя принципами, которых она придерживается:

  • единственный источник правды;
  • состояние только для чтения;
  • изменения вносятся с помощью чистых функций.

Для простоты понимания работы ниже приведена схема Redux-flow.

Вообще связка слов React-Redux настолько тесна, что многие забывают о том, что Redux — это отдельная библиотека, которая может использоваться даже с обычным JavaScript или Vue.js.

Как я упоминал раньше, Эван Ю вдохновлялся React и брал оттуда самое лучшее. Так как встроенного решения по управлению данными в библиотеке не было, он решил создать собственный модуль для Vue.js под названием Vuex.

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

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

Что же учить

И React, и Vue.js имеют свои преимущества и недостатки, чем-то они похожи, а чем-то различаются. Можно сделать следующие выводы:

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

Исходя из всего написанного выше, в 2021 году для изучения я бы выбрал React. Он признан международными компаниями, удерживает лидерские позиции на рынке, для него существует обилие обучающих материалов. А если вдруг не согласны, то я всегда рад выслушать противоположную точку зрения, которой вы можете поделиться в комментариях!

👍НравитсяПонравилось2
В избранноеВ избранном6
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: Soundcloud | Google Podcast | YouTube


Лучшие комментарии пропустить

Шо то прекрасная технология, шо это, и эти две технологии прекрасны настолько, шо я имел бы их во всех проектах
©

Стаття м’яко кажучи така собі. Є купа питань, як до автора, так і до редакції DOU. Якщо подивитися профілі автора, то побачимо, що досвіду в автора 1 рік і 3 місяці, і з них лише 5 місяців у ролі працівника компанії. 3 місяці вивчення верстки, 3 JS і потім початок вивчення React (взято звідси www.facebook.com/...​ro/posts/3393159770779600 ), на мою думку явно не досить, щоб рекомендувати який framework вивчати в 21 році. З іншого боку зважаючи на те, що структура статті типова для даної теми (таких текстів в англомовному сегменті вагон і це описові статті які не вникають в суть проблеми) то тут вже виникає питання до DOU, навіщо публікувати таке.

Тепер по суті статті. Початок, як я зазначив вище це типовий текст, що складається з
Історії фреймворків
Статистики
Якихось загальних відмінностей
Висновки.

Судячи по історії вже можна зробити висновок, що або автор не займається Vue, або текст дуже старий оскільки на момент публікації Vue 3 вже як місяць (+\-) вийшов.

Тепер про циферки. Щодо трендів і скачувань — це не показник, бо React вийшов раніше, і відповідно його база розробників і використання буде завжди більшою. Просто тому, що індустрія це не тільки стартапчики, а ще і серйозний бізнес, який якщо робить вибір framework, то тримається цього вибору всерйоз і надовго. Звідси відповідно і кількість вакансії — оскільки треба ж підтримувати давні проекти, розвивати їх. Автор не враховує, крім кількості вакансій є ще велика кількість спеціалістів, і зважаючи на довгу присутність React на ринку виникає ситуація — «Куди ви лізете, все занято». За роки життя React набралася така кількість спеціалістів, що роботодавець має великий вибір людей з досвідом. Відповідно конкуренція зависока. Тому шансів, на мою думку в початківців з React менше.

Щодо community — автор не наводить жодних цифр про розміри, тай не зможе — нема валідних цифр. Відповідно його висновки погані. Кількість запитів на StackOverflow — може свідчити лише про ряд моментів

Кількість людей які вивчають чи працють з framework
Кількість сексу, яка світить з даним framework. Цей пункт це моє особиста думка вироблена за роки досвіду — якщо питання не гуглиться то скоріше за все воно очевидне. З Vue очевидності судячи з цифр більше.

Тепер про порівняння. За React не буду говорити, не спеціаліст. За Vue — автор не розбирається. Бо flow, який він показав взято з першої статті по запиту vuex data flow, а не навіть з документації. Так звісно, можна робити так як на картинці, але підхід показаний в документації є набагато правильнішим.

І щодо висновку. Хочеться порадити автору (і не тільки) в 2021 (і далі) вчити не frameworks, а вчитися програмувати. Вчіть Javascript, вчіть HTML, СSS. Frameworks це цукор, який суттєво спрощує життя в одних моментах, але вгробить вас в інших якщо ви не знаєте мови. Вчіться програмувати — писати хороший, оптимізований код, який би ви гордо могли показати на співбесіді. А frameworks \ libraries народжуються та вмирають. Знаючи мову — легко освоїти любе і різне. Успіхів.

Во Vue проще вкатиться, и на нем проще писать простые/средние проекты (это не значит что нельзя писать большие). Во Vue почти всё есть из коробки, а чего нету (store, router), то поддерживается тем же Эваном Ю, в итоге максимальная интеграция и поддержка (и документация уровня самого Vue), и нету ломания головы с «а что же взять, Redux или MobX». React хорош своей управляемостью и кастомизацией, но всё это нахрен не нужно на мелких/средних проектах, а сложность увеличивает ой как сильно. А на больших проектах что React нужно применять с умом, что Vue.

По поводу трендов и «скачиваемых библиотек на npm» — вообще нифига не показатель. Ибо во Vue ты скачал две либы (стор и роутер), и тебе больше ничего не нужно (кроме каких-то сложных UI-компонент). В React же нужно докачать styled-components (если юзается), для Redux еще что-то для асинхронщины (если не юзать MobX), при этом обычно это не 1+1, а 2+1/2 пакета. Учитывая что есть такое разнообразие в экосистеме, естественно будет порождаться куча запросов в google по поводу «а че мне выбрать» и куча скачиваний стаффа в npm.

Если говорить о возможностях Vue по сравнению с React, то Vue3 полностью догнал так понравившееся всем Composition API и хуки React-а, при этом оставив ПОЛНУЮ (лишь немного изменив старое API) поддержку старого синтаксиса.

Ну и добавлю, что в свое время джуном я никак не мог вкатиться в React, ибо всегда нужно что-то скачать чтоб фича завелась, куча непонятного кода и тд. Переключившись на Vue я его понял за неделю и без проблем начал работать над большим проектом в большой команде. Понятно что это очень субъективный поинт, но думаю для новичков это СУПЕР важно. Естественно через пару лет я понял React тоже за неделю-две, но осадочек остался.

Ну и что заметил на своей практике — обожатели React постоянно супер агрессивные и ведут себя как нечто элитное по сравнению с теми кто пишет на Vue/Angular.

С работой конечно проще, когда знаешь React. Но это только на стадии джуна. Как только ты становишься хорошим спецом, то открывается мир кучи вакансий на Vue, правда в основном вне Украины. Да и хорошему спецу становится вообще пофиг на фреймворк, ведь это лишь инструмент :)

Изучать надо JavaScript — фреймворк или библиотеку познаешь на проекте (или создашь еще одну :) ...

102 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Для enterprise проектів краще ніж Angular альтернативи немає

Гарно накинув. Ніт, модель Ангуляра не дозволить йому летіти довго та безболісно. З розростанням проекту деградація швидкості розробки буде катастрофічною.

Прибульці та крипторептилоїди обирають Z-framework. :D

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

А что в этом смешного? Это действительно библиотека (внезапно).

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

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

А так-то вот есть про разницу фреймворков в одной картинке twitter.com/...​41399925793705986/photo/1

Не дуже зрозумів картинки, бо у React нема CLI і ніколи не буде.

А як же create-react-app?

Це просто інсталятор бандла react-scripts.
React це не фреймворк, там нема рекомендованої структури, нема архітектурних патернів, тому CLI для генерації сутностей не буде ніколи.

Інша справа — фреймворки на базі React, там все цілком можливо.

Ну она, скорей всего, про наличие готовых решений, не про наличие cli.

А что в этом смешного? Это действительно библиотека (внезапно).

Походите по собеседованиям там от супер синьйоров услышите не только что реакт фреймворк а и много смешной отсебятины.

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

а поэтому он часто очень краток :) пространные статьи он писал лет 10-15 тому.

Извините за долгое вступление об источнике

Vlad Balin (gaperton)
Костыли, говно, и е*анина
#javascript Эта картинка вызвала оживленную дискуссию в MoscowJS.
(там Диаграмма Венна с названиями фрейморков)
skynin.xyz/...​6966028968720558313_n.jpg
Люди не понимают разницу между е*аниной, костылями, и говном. Это очень просто, я сейчас объясню.

Костыли — это в своей природе рациональная штука, она решает реальную проблему. Просто делают это кое-как, через жопу, и на скорую руку. Вот, скажем, если ваш программист с тяжелым вздохом говорит — «ладно, сейчас сговнякаем что-нибудь» — будьте уверены, он приготовился делать костыли. «*уяк, *уяк, и в продакшн».

А вот е*анина — это совсем другое дело.
Она никакого отношения к рациональной реальности не имеет.
Она берется не из нее, а целиком из мозга.
Это победа интеллекта над разумом.
Это, сцуко, Торжество Идеи.

Другими словами, если костыли — это недостаток ума или (чаще) времени, то е*анина — это напротив, избыток и того и другого.

С другой стороны, говно — это просто говно. Если у программиста руки растут из жопы (что в случае программиста надо понимать не буквально, а как отсутствие элементарного эстетического чувства), то независимо от наличия времени и ума не получаются ни костыли, ни е*анина. А выходит какое-то говно. Об этом явлении пишут поэты:

Олег за все берётся смело
Все превращается в говно
А если за говно берётся
То просто тратит меньше сил

Все просто, ну. Русский язык точен. Как можно эти вещи перепутать.

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

P.S. (мой)
У нас на проекте Vue
Прекрасно справляется, фронтендеры в восторге от вещей из коробки Nuxt.js
мне и самому понравилось как легко он решает проблему с SSR

Причем, если выбирать из крайностей то фронтендеры у нас скорей «веб ремесленники» а не «тру программисты делающие доклады об ФП». Прагматичные, а не «академики» и хайпующие о новых фреймворках.
и продукты выходят вполне годные у них. (2 несвязанных никак проекта у нас), и с хорошей скоростью разработки.

Потому что лучший инструмент тот, которым лучше всего владеет команда.

Стаття м’яко кажучи така собі. Є купа питань, як до автора, так і до редакції DOU. Якщо подивитися профілі автора, то побачимо, що досвіду в автора 1 рік і 3 місяці, і з них лише 5 місяців у ролі працівника компанії. 3 місяці вивчення верстки, 3 JS і потім початок вивчення React (взято звідси www.facebook.com/...​ro/posts/3393159770779600 ), на мою думку явно не досить, щоб рекомендувати який framework вивчати в 21 році. З іншого боку зважаючи на те, що структура статті типова для даної теми (таких текстів в англомовному сегменті вагон і це описові статті які не вникають в суть проблеми) то тут вже виникає питання до DOU, навіщо публікувати таке.

Тепер по суті статті. Початок, як я зазначив вище це типовий текст, що складається з
Історії фреймворків
Статистики
Якихось загальних відмінностей
Висновки.

Судячи по історії вже можна зробити висновок, що або автор не займається Vue, або текст дуже старий оскільки на момент публікації Vue 3 вже як місяць (+\-) вийшов.

Тепер про циферки. Щодо трендів і скачувань — це не показник, бо React вийшов раніше, і відповідно його база розробників і використання буде завжди більшою. Просто тому, що індустрія це не тільки стартапчики, а ще і серйозний бізнес, який якщо робить вибір framework, то тримається цього вибору всерйоз і надовго. Звідси відповідно і кількість вакансії — оскільки треба ж підтримувати давні проекти, розвивати їх. Автор не враховує, крім кількості вакансій є ще велика кількість спеціалістів, і зважаючи на довгу присутність React на ринку виникає ситуація — «Куди ви лізете, все занято». За роки життя React набралася така кількість спеціалістів, що роботодавець має великий вибір людей з досвідом. Відповідно конкуренція зависока. Тому шансів, на мою думку в початківців з React менше.

Щодо community — автор не наводить жодних цифр про розміри, тай не зможе — нема валідних цифр. Відповідно його висновки погані. Кількість запитів на StackOverflow — може свідчити лише про ряд моментів

Кількість людей які вивчають чи працють з framework
Кількість сексу, яка світить з даним framework. Цей пункт це моє особиста думка вироблена за роки досвіду — якщо питання не гуглиться то скоріше за все воно очевидне. З Vue очевидності судячи з цифр більше.

Тепер про порівняння. За React не буду говорити, не спеціаліст. За Vue — автор не розбирається. Бо flow, який він показав взято з першої статті по запиту vuex data flow, а не навіть з документації. Так звісно, можна робити так як на картинці, але підхід показаний в документації є набагато правильнішим.

І щодо висновку. Хочеться порадити автору (і не тільки) в 2021 (і далі) вчити не frameworks, а вчитися програмувати. Вчіть Javascript, вчіть HTML, СSS. Frameworks це цукор, який суттєво спрощує життя в одних моментах, але вгробить вас в інших якщо ви не знаєте мови. Вчіться програмувати — писати хороший, оптимізований код, який би ви гордо могли показати на співбесіді. А frameworks \ libraries народжуються та вмирають. Знаючи мову — легко освоїти любе і різне. Успіхів.

Учить, что компании требуют для работы, в большинстве React.

Компаниям вообще нужны UI/UX Frontend. По хорошему от специалиста ждут умения работать на любом из фреймверков и вообще без него, плюс умение изучить новый если понадобится для проекта. Из коментариев специалистов видим что большинство владеет сразу двумя фреймверками (и это минимум) но предпочитают тот или иной.

Шо то прекрасная технология, шо это, и эти две технологии прекрасны настолько, шо я имел бы их во всех проектах
©

объясните в каком слове здесь сарказм?

Не можу пояснити це логікою, але після прочитання статті в мене особисто залишилася думка, що на React взагалі не варто витрачати час. В мене особисто дуже небагато досвіду розробки фронту. Трошки працював з jQuery, трошки з Angular десь по пів року з кожним. Судячи з того, що я прочитав у React набагато вищий поріг входження та суттєво нижча якість рішення в цілому. Тобто засвоїти цей інструмент досконало теж складніше, іншими словами витрати часу на здобування знань суттєво вищі з самого початку до самого кінця. Тобто єдиний вагомий аргумент «за React» — легше знайти роботу. Мені він здається трошки хибним. В тому сенсі, що легше за все знайти роботу саме в тій галузі де є найкращі знання та навички. А знання та навички легше за все здобуваються якщо інструмент дійсно до вподоби. Ну, то таке. Мені взагалі-то не дуже подобаються люди, яки прийшли в програмування виключно заради грошей. Намагаюсь таких уникати. З дитинства вважаю, що займатися слід в першу чергу тим, що дійсно приносить задоволення. Всі інші критерії, на мій погляд, є другорядними. Але, маю визнати, що оскільки однакових людей не існує, можливо для когось мій підхід не є взагалі релевантним.

З дитинства вважаю, що займатися слід в першу чергу тим, що дійсно приносить задоволення.

Згоден, але жити за щось треба, тому люди обирають працювати з тим що можливо продати.

Жодних заперечень. Просто вибір — це така дивна річ. Кожна людина обирає різні речі з різних міркувань. :)

Мені взагалі-то не дуже подобаються люди, яки прийшли в програмування виключно заради грошей. Намагаюсь таких уникати.

React, Angular и подобные фронтенд фреймворки сложны даже для опытных программистов.
Даже если писать и бек и фронт на одном языке, то все равно разработка тормозится в 2-3 раза.

для себя недавно открыл StimulusReflex (made by Basecamp) для Rails другим подходом для фронтенда с минимальной логикой на клиенте.

React is Dead. Long live Reactive Rails!
medium.com/...​iewcomponent-cd061e2b0fe2

А ще є ось таке диво: dotnet.microsoft.com/...​ps/aspnet/web-apps/blazor Для мене особисто, як .Net розробника виглядає як потенційно оптимальне (але це — не точно). Але в статті йдеться саме про порівняння Vue.js & React.js. Проте, з тим, що майбутнє веб-розробки скоріш за все за використанням однієї мови для розробки фронта й бека я мабуть все ж таки погоджусь. Це природній шлях.

Мені взагалі-то не дуже подобаються люди

Так даже лаконичнее было бы.

Це вже взагалі інша дискусія. ;)

там є специфічні нюанси тому краще не треба

Изучать надо JavaScript — фреймворк или библиотеку познаешь на проекте (или создашь еще одну :) ...

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

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

Когда у тебя есть несколько лет опыта работы на живых проектах с нормальной кодовой базой, то ты просто привыкнешь писать нормальную кодовую базу. Только специально постаравшись человек будет начать писать говнокод :)

Это в наших галерных реалиях к сожалению на работу стараются брать только с «опытом в фреймверке». Хотя если подумать — это бред, фреймверк изучить относительно просто. Но например разбираться в UI/UX — это значительно большая квалификация. Проще говоря можешь знать фреймверк — но что с помощью него делать (решать конкретную бизнес проблему) не знаешь. Но в условиях аутсафинга — что делать часто берет на себя клиент, а кодировать сажает дешевую раб. силу. Вот только клиент часто сам не знает что делать.

Мне больше нравится забугорное определение — «спагетти код». Более четко отражает суть — все намешано между собой, и невозможно разобраться что и где. И соответственно добавить новую фитчу в такой код крайне проблематично, а исправлять баг можно неделями и т.д. и т.п. Альтернатива — лазанья код четко структурированный и документированный. От фреймверка как и от языка программирования — это мало чем зависит. Зато от квалификации программистов очень сильно, создавать лазанья код надо специально учится (иначе очень дорого выйдет как у первопроходцев).

Правда на работу нигде не возьмут, но то такое

изучил javascript — наваял redux или сходу познал rxjs? сомневаюсь чё-т

Да, трудно создать сходу (и не все смогут), но ведь именно так эти библиотеки/фреймворки и появились... как инструменты для решения конкретной задачи со своими pro & cons. Так было с Эриком Майером в 90-х (создал Microsoft Rx), и так было в 2015 году с Даниилом Абрамовым и Эндрю Кларком (создали Redux).
Инструментов много, и владеть ими всеми нереально. Но при хороших фундаментальных знаниях можно быстро разобраться и научиться — не это ли одно из главных преимуществ толкового программиста?

Вакансии реально решают как по мне, а гугл тренды вообще ни о чем. Опрос на стеке тоже не отображает реальной популярности. При этом SO тренды вполне себе отображают картину по применению в РЕАЛЬНЫХ проектах, а не разный мусор с гитхаба или звездочки. Простой пример когда звездочки не актуальны есть пакет requests и есть axios. Первый уже депрекейтед, а второй уже чуть ли не по умолчанию идет в большинстве проектов, но при этом звездочек и скачек у него значительно меньше.

Во Vue проще вкатиться, и на нем проще писать простые/средние проекты (это не значит что нельзя писать большие). Во Vue почти всё есть из коробки, а чего нету (store, router), то поддерживается тем же Эваном Ю, в итоге максимальная интеграция и поддержка (и документация уровня самого Vue), и нету ломания головы с «а что же взять, Redux или MobX». React хорош своей управляемостью и кастомизацией, но всё это нахрен не нужно на мелких/средних проектах, а сложность увеличивает ой как сильно. А на больших проектах что React нужно применять с умом, что Vue.

По поводу трендов и «скачиваемых библиотек на npm» — вообще нифига не показатель. Ибо во Vue ты скачал две либы (стор и роутер), и тебе больше ничего не нужно (кроме каких-то сложных UI-компонент). В React же нужно докачать styled-components (если юзается), для Redux еще что-то для асинхронщины (если не юзать MobX), при этом обычно это не 1+1, а 2+1/2 пакета. Учитывая что есть такое разнообразие в экосистеме, естественно будет порождаться куча запросов в google по поводу «а че мне выбрать» и куча скачиваний стаффа в npm.

Если говорить о возможностях Vue по сравнению с React, то Vue3 полностью догнал так понравившееся всем Composition API и хуки React-а, при этом оставив ПОЛНУЮ (лишь немного изменив старое API) поддержку старого синтаксиса.

Ну и добавлю, что в свое время джуном я никак не мог вкатиться в React, ибо всегда нужно что-то скачать чтоб фича завелась, куча непонятного кода и тд. Переключившись на Vue я его понял за неделю и без проблем начал работать над большим проектом в большой команде. Понятно что это очень субъективный поинт, но думаю для новичков это СУПЕР важно. Естественно через пару лет я понял React тоже за неделю-две, но осадочек остался.

Ну и что заметил на своей практике — обожатели React постоянно супер агрессивные и ведут себя как нечто элитное по сравнению с теми кто пишет на Vue/Angular.

С работой конечно проще, когда знаешь React. Но это только на стадии джуна. Как только ты становишься хорошим спецом, то открывается мир кучи вакансий на Vue, правда в основном вне Украины. Да и хорошему спецу становится вообще пофиг на фреймворк, ведь это лишь инструмент :)

Если я правильно понимаю, главное преимущество реакта — в среде юайщиков он очень модный. А кому ехать — а не шашечки, то Ву больше подходит.

Нууу, React тоже норм. Он мощный и позволяет управлять рендером на любом уровне. Но Vue тоже умеет это делать, если писать не темплейты а render-functions. Но на мелких/средних проектах такое управление никому нафиг не нужно.
На Vue намного проще начать писать проект. Буквально одну команду нажал в vue-cli и твой проект запущен и готов работать. Тебе не нужно думать над тем что выбрать, ведь всё и так идеально работает между собой.

Так что конкретно для меня да, Vue это про «сел и начал писать проект», а React это вечно метание из пустого в порожнее «а давайте в этот раз возьмем вот этот стор, и вот так писать стили. Почему? Ну блин оно новое, в твиттерах все хвалят!», а потом через месяц «блять вот тут баг непонятный, а вот тут стало писать логику в разы сложнее и тд». Даже на моем текущем проекте тим-лид выбрал одно, пришел через месяц синьер и обосрал решение тим лида, я вообще сижу плююсь ибо оба их решения говно и можно было сделать все проще. А на Vue ты приходишь, видишь один и тот же подход везде и просто пишешь бизнес-логику дальше.

React это вечно метание из пустого в порожнее «а давайте в этот раз возьмем вот этот стор, и вот так писать стили. Почему? Ну блин оно новое, в твиттерах все хвалят!», а потом через месяц «блять вот тут баг непонятный, а вот тут стало писать логику в разы сложнее и тд». Даже на моем текущем проекте тим-лид выбрал одно, пришел через месяц синьер и обосрал решение тим лида, я вообще сижу плююсь ибо оба их решения говно и можно было сделать все проще. А на Vue ты приходишь, видишь один и тот же подход везде и просто пишешь бизнес-логику дальше.

Был/есть такой фреймворк, Ember.js. Там на большинство типовых задач есть рекомендуемый способ решения. Роутинг — из коробки, слой для работы с данными — разрабтывается теми же людьми и при использовании ember-cli доступен «из коробки». Чего нет из коробки, как правило есть сторонняя библиотека.

Казалось бы, всё замечательно. А фреймворк фактически умер. На него мало новых проектов, и часто при поиске работы с ember находишь «переписать на react».

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

А может потому, что Ember не имел чего-то, что есть в текущем React и Vue (shadow DOM там, или реактивность)? Я не застал Ember, потому хз почему он умер и какой у него функционал. Все же есть Angular, который живее всех живых и при этом в нем вообще ВСЁ идет из коробки.

React это вечно метание из пустого в порожнее

Тому що Rеact це бібліотека для view-layer, а не фреймворк. Інструмент нижчого рівня.
Ось Next.js — це приклад повноцінного фреймворка на Ract.

А теперь давайте пойдем и спросим любого React-девелопера нужна ли ему голая библиотека для view-layer? Он скажет «нет», ибо ему нужен фреймворк со стором, роутером, плагинами и тд.

А для чого потрібен фреймворк, коли для більш-менш серйозного проекту його треба буде розширювати сторонніми модулями?

А какими это модулями нужно расширять Vue? :) vue-cli автоматом докинет router и store по желанию, если они нужны конечно (мало ли у вас плагин на сторонний сайт и нужен чисто Vue). И собственно всё — этого хватит для проекта любого размера. В принципе в React так же, вот только на трех проектах я видел три разных сторы, а от этого код и архитектура приложения менялись значительно.
Всегда всё сводится к тому, что это всё одно и то же. Зачем холиварить тогда?

Apollo, наприклад.

Всегда всё сводится к тому, что это всё одно и то же

Мы можем на этом закончить?) Вордпресс тоже нужно подключать к реакту и вью, а точнее вью и реакт к вордпрессу. Это факт и всё тут. К чему он? Да к тому же что и факт об Apollo.

Можешь подсказать новичку несколько хороших источников знаний по Ву кроме официальной доки?
Раза 3 я пробовал начать осваивать Ву и как-то не продвинулся

На Udemy есть хороший курс от Maximilian Schwarzmüller, называется «Vue — The Complete Guide (w/ Router, Vuex, Composition API)». Он покрывает полностью все аспекты и юзкейсы фич Vue. Также у него есть такой же по качеству курс по Nuxt.js (SSR для Vue). Больше ничего такого я особо не использовал во время обучения — только опыт. В телеграме есть еще чат t.me/vuejs_ru, там около 9к человек — новичкам всегда помогают :)

Спасибо за Schwarzmüller.
В телеге я подписан, но помощь чата хороша, когда уже есть хоть какая-то отправная точка.
Иду на udemy

Не «очєнь модний», а стандарт де-факто.

На сколько я знаю на Реакте писать кода всегда приходится больше, и сама либа больше, а возможностей при этом меньше.

Ну бизнес-логика по коду всегда одинаково занимает) А вот UI-составляющая — согласен. В React очень много «идеологических» ограничений, которые очень мешают писать код. Они созданы якобы чтоб не выстрелить себе в ногу (хотя можно просто иметь опыт чтобы этого не делать), только при этом кода получается столько, что вникать становится сложнее. Но если тебе сложно, то это ты лох, а не код написан сложно :) Всё что я понял от комьюнити React-а.

В React очень много «идеологических» ограничений, которые очень мешают писать код.

Было бы интересно увидеть примеры таких ограничений. А то, звучит, как «эти козлы, которые мешают нам жить...» :)

Из того что мне больше всего не нравится — дочерний компонент не может общаться с родительским путем эвентов. Нужно из родителя прокидывать callback функции в дочерний компонент путем пропсов. В итоге есть куча пропсов, куча callback-ов, и неудобный интерфейс.

Также есть много топителей за иммутабельность, но я с этим не сталкивался ибо с React всегда юзал MobX (удобный аналог Vuex, но с кучей проблем, аля отсутствие адекватного инспектора в browser devtools или неочевидное поведение реактивности (хотя справедливости ради, MobX не ради React создавался)).

Ну а про html/css-in-js я даже не хочу запинаться, ибо кто-то любит, а кто-то не любит. Для меня отсутствие писать обычный html или css с удобством это ограничение.

дочерний компонент не может общаться с родительским путем эвентов. Нужно из родителя прокидывать callback функции в дочерний компонент путем пропсов. В итоге есть куча пропсов, куча callback-ов, и неудобный интерфейс.

Я это, наоборот, считаю полезным ограничением, так как любое взаимодействие компонента с внешним миром идёт через props и только через них. Да и, с другой стороны — если не через props, то как передавать дочернему компоненту event handlers от родителя?

Также есть много топителей за иммутабельность

Что и неудивительно, ибо в основе react/redux лежит функционально-реактивный подход. Он либо «заходит», и тогда ты понимаешь, почему в реакте определённые вещи сделаны именно так, либо нет, и тогда удобнее писать на Angular или Vue с их более приближённой к классическим MVC / MVP парадигмой.

Хотя, в последние версии Ангуляр тоже завезли FRP, но, как я понял, там это опция, а не единственный «православный» подход.

Я это, наоборот, считаю полезным ограничением, так как любое взаимодействие компонента с внешним миром идёт через props и только через них. Да и, с другой стороны — если не через props, то как передавать дочернему компоненту event handlers от родителя?

А во Vue компонент и не взаимодействует с внешним миром. Во Vue дочерний компонент по какому-то событию внутри себя (нажалась кнопка, сработала логика) просто выбрасывает именованное событие наружу, аля
"ChildComponent @form-submitted="someCoolHandlerInParentComponent"
и родительский компонент может это увидеть и сделать что угодно. Это не сильно отличается от прокидывания callback в дочерний элемент, но идеологически мне больше нравится когда дочерний компонент сам говорит «я сделал что-то, знай об этом ЕСЛИ хочешь», нежели чем когда родитель говорит ребенку «когда сделаешь что-то, вызови вот эту функцию».

Он либо «заходит»

Либо не заходит, как мне :)
Хотя опять же, во Vue есть strict mode, когда данные стейта стора могут меняться только в мутациях. А как вы эту мутацию напишите, как чистую функцию или нет — лишь вам решать. За это мне Vue и нравится — пиши как захочешь, при этом без анархии в экосистеме. Мой любимый подход — мутирование стейта только мутациями, а чтения из стейта только из геттеров. В итоге — единое место изменения данных, единый источник правды.

Во Vue дочерний компонент по какому-то событию внутри себя (нажалась кнопка, сработала логика) просто выбрасывает именованное событие наружу

Во vue есть какой-то специальный event bus для этого?

В целом, наверное, при желании так можно сделать и в реакте. Более того, даже уже готовое решение есть: www.npmjs.com/package/react-event-bus

Но, в реакте, это нужно только тогда, когда дочерний компонент никак не меняет глобальное состояние сам, иначе нужно делать dispatch(ACTION), а не событиями кидаться. И, видимо, нужно довольно редко, раз подобные решения не особо популярны и активно не развиваются.

Нету во Vue никакого event bus :) Просто компонент может эмитить свои эвенты при этом никакого состояния не изменяя — родитель подписывается на эти эвенты и делает уже что захочет. И это не имеет никаких ограничений по сравнению с props=>callback, но при этом гораздо красивее и логичнее. При этом коллбеки в пропсах никто не отменял — хочется — юзай.

А event bus или dispatch(action) это уже совсем другая вещь, для общения компонент на глобальном уровне.

Подскажите, а в чем принципиальная разница между:
«определить handler» в родителе, условно назовем его someHandler, подписать его на какой-то ивент (что тоже код), и затем емитить этот ивент в child-компоненте ( что-то вроде this.emit(’submitClick’), не знаю как это точно во Vue выглядит)

и межу:
все тем же someHandler, строчке onSubmit={someHanlder} (аналог подписки на ивент во Vue), и вызове этого метода.в child компоненте ровно в том же месте где бы вы вызвали this.emit(’submitClick’) ( опять же точный синтаксис я не знаю)

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

Кол-во пропсов в этом случае плюс-минус одинаково с количеством различных возможных ивентов которые будет «выплевывать» child компонент :)

Принципиальной разницы нету. А вот идеологически — много.
props во Vue всегда отвечают за данные. А events отвечают за их обработку и передачу. Я люблю это разделение и мне оно очень удобно. Так же как и разделение hmtl/css (хотя Vue позволяет юзать и JSX тоже).
Мне не нравится как React пихает всё в одну кучу.

Также, во vue-devtools я вижу все эвенты, которые произошли, и могу их откатить. Т.е. дебаг-процесс просто супер удобный. То же самое что и redux events history, вот только во Vue это есть не только у Vuex, но и у любого компонента. Удобно ведь? Да :)

Если хочется более развернутый ответ и больше мнений — погуглите vue events vs callbacks.

Сейчас нету фреймворков у которых есть что-то супер отличительное от другого фреймворка. Они все выполняют свои задачи одинаково хорошо. Просто у всех разные подходы решения этих задач. Так что это просто вкусовщина.

Если хочется более развернутый ответ и больше мнений — погуглите vue events vs callbacks.

верно ли я понял, что в VueJS

  • emit для одностороннего уведомления кого-то выше по уровню(вместо callback prop типа onClick)
  • scoped scots для управление рендерингом части(вместо render prop)
  • биндинг функции через ":"(прямой аналог callback prop, но при этом я нагуглил кучу статей, которые обзывают это плохой практикой)
?

1. Да
2. Scoped slots для прокидывания верстки из родителя в ребенка с контекстом родителя. Т.е. родитель полностью управляет тем, что лежит в scoped slot-е ребенка.
3. Скорее-всего имеется в виду «@», а не «:» — через двоиточие биндятся атрибуты, аля класс, тайтл, плейсхолдер и тд. Я конечно хз что вы читали, но эвенты вместо коллбек пропсов это идеология Vue, потому плохой практикой это может быть только для выходцев из React

но эвенты вместо коллбек пропсов это идеология Vue

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

Ага, понял. Плохая практика скорее миксовать подходы callback props (это возможно только через биндинг через двоеточие, ибо так передаются пропсы, потому это не bad practice) и events. А так, это ведь одно и то же. Опять же, иногда при вызове callback props нужно получить какие-то данные от родителя, и получить их в виде результата функции более правильно чем создавать еще одну пропсу на получение данных и вызывать эвент

Как по мне, в такой код сложно потом вникать. Искать каждый раз кто подписан на ивент чтобы понять что происходит?

Вы явно не туда думаете. НИКОГДА не нужно искать кто куда подписан. Component имеет внутренний стейт и внутренние экшны. Как только Component решает выплюнуть эвент, он это делает. А слушает ли кто-то этот ивент или нет, Component-у вообще плевать. В итоге достигается независимость компонентов.

Вот вы идете по улице зимой, подскользнулись на льду, упали и слегка прикрикнули «Бля*ть!». А услышал ли вас кто-то или нет, вас не волнует. Но условный дворник может вас услышать и примет решение убрать лед в том месте.

Вы явно не туда думаете. НИКОГДА не нужно искать кто куда подписан.

И когда программа работает неправильно или когда ты новый фронтендер на старом проекте — тоже ничего не нужно искать? Удивительно просто

Я не понимаю что вам нужно искать? Есть parent со своей логикой, есть child со своей.
Условный parent это Form, а child это InputField. Child при фокусе, вводе значения, клике на Copy, и тд просто выплевывает свои эвенты. Вы в parent просто в hmtl-коде навешиваете слушатели на эти эвенты. Когда фокус внутри child-а произошел, parent это видит и делает че ему вздумается. Child-у же при этом вообще побоку кто там что сделал — он эвент выплюнул и живет себе дальше.

А если вы ищите связи между компонентами глобально в проекте, то для этого есть стора, или event bus. Но в React нету панацеи от поиска этих связей.

Поймать ивент что, может только прямой родитель?

Да, потому мы и обсуждаем events vs callbacks. Такие эвенты ловит только parent component.

// parentComponent template
div
ChildComponent @some-event-happened="parenHandlerCalled"

// childComponent
... some logic
this.emit(’some-event-happened’, someData)

Выглядит как усложнение кода без нужды

Интересно понять где здесь усложнение) callback-пропсы предлагают то же самое, только их еще описывать нужно, а эвенты не нужно. Наоборот все упрощено

react/redux лежит функционально-реактивный подход

На сколько я понимаю, в Vue как раз есть функция реактивности, а вот в React её вообще нет. Вызывай руками setState, это не про реактивность. Весит в 2 раза больше, при этом того же функционала не содержит.

Эм, а что для вас реактивность?

дочерний компонент не может общаться с родительским путем эвентов

Хто заважає юзати івенти, крім совісті і best practices? :)

Почитайте дальше что я имею в виду под эвентами во Vue.

В реакті можна зробити то саме.
В батьківському компоненті підписуємось на івенти, в дочірньому — емітимо їх. Для цього можна юзати будь-який івент емітер, написаний для голого js.

Ну да) А во Vue можно callbacks в props прокидывать. Так к чему эти поинты?

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

В чем причина таких радикальных мер воздействия ?

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

На Vue притомні розробники за EventBus теж б"ють

В React очень много «идеологических» ограничений

WUT? Там взагалі ніяких обмежень нема, крім декларативного підходу до керування DOM.

Ну и что заметил на своей практике — обожатели React постоянно супер агрессивные и ведут себя как нечто элитное по сравнению с теми кто пишет на Vue/Angular.

😀

Спасибо за статью, хорошее сравнение.
Интересно было бы узнать есть ли какие-то закономерности статистики использования Vue.js\React в привязке к бэкенду (PHP, .Net, Java, Node.js и т.д.).

Коллеги говорят, что есть сильная корреляция между Vue и PHP.

Даже скорее не с PHP вообще, а конкретно с Laravel фреймверком который нынче топовый по популярности из PHPшных.

Потому что Laravel вроде-бы очень тесто и удобно интегрирован с ним. А так, на деле, без разницы, это ведь просто общение по сети. По крайне мере в моем опыте Vue юзался и с Go, и с Питоном, и с PHP, и с нодой, и с RoR. По React опыт у меня не такой разношерстный, но с PHP, Node и Питоном тоже вполне ок работать.

Laravel в році 2016 активно топив за Vue, що забезпечило останньому добру популярність

В Java у нас Spring Web Flux (на новых проектах) для «реактивных» фреймверков. Но на практике большинство проектов сильно старше чем сам подход синглпейдж. И в принципе этот поход очень не плох для разного рода админок, бекофисов и социальных сетей, но для фронт апликейшена интернет магазина например — это не всегда самое удачное решение.

прагматизм = реакт
для души = вуй

Что с бутсрапом 4-м лучше сочетается ? В своем акт проекте vue bootstrap пробую пользовать т.к. мне показалось более легковесным. Но я бекенд :)

У нас юзали на React, вроде вполне себе. Но я когда на ангуляре писал предпочитал MaterialUI+ css flex. Тоже бекенд=)

Для меня большое значение имеет — responsive ui. Я разное пробовал Foundation 6, Material и т.п. но в конечном итоге всеже пришел именно к 4-му бутстрапу. И если мне не получится использовать ни Vue ни React с бутстрапом, я лучше откажусь от реактивных single page и буду использовать Bootstrap с JQuery и бекендом на Spring MVC чтобы не морочить себе голову с связкой JS+Spring Web Flux. Непосредственно верстка у меня занимает больше всего времени, и бустрап ее ускоряет (для меня) даже не в разы — на порядки.

Не знаю как бутстрап, я пообовал UIKit 2 — замечательно работает с реактом, и обычно даже никакой специальный код для связки не нужен. Впрочем написать компоненты реакта для любого ui фреймворка не должно быть большой проблемой. Может и готовые есть пакеты

Есть и React Bootstrap и Vue Bootstrap. В обоих случаях это неофициальные сборки, где JQuery код переписали на React и Vue. Но реакт мне сломал голову (возможно потому что я не юайщик и не понимаю как его готовить). При этом Ву получилось прикрутить, да и документация показалась сильно проще.

Но реакт мне сломал голову

Потому что Vue как и Angular ближе к традиционному MVC/MVVM подходу с разделениями шаблона и кода.

Попробуй вместо бутстрапа bulma или tilewind...
ПС я тоже бэк :)

Если вы про tailwindcss, то он достаточно низкоуровневый и совсем не то же самое что бутстрап

Да, про него.
Просто бутстрап довольно тяжёленький по весу да ещё и жКвери тянет за собой.
Для прототипа конечно гуд

Просто бутстрап дает готовые элементы интерфейса, а tailwind только универсальные классы, а компоненты вроде дропдаунов, календарей и прочего строить самому. Хотя с реактом это довольно легко и удобно делать, но всё же лишняя работа

Подписаться на комментарии