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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Во 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, правда в основном вне Украины. Да и хорошему спецу становится вообще пофиг на фреймворк, ведь это лишь инструмент :)

А я считаю не только по курсу НБУ, а «по какому курсу больше гривен получится». Потому всегда считаю по НБУ и по курсу по банка. Может и теряю пару гривен, но парочка аудиторов и бухгалтеров советовали именно так, чтоб налоговая вообще не смогла прикопаться

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