React в 2021. Нужно?

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

Конкретизируйте вопрос: для чего и кому?

Нормально. Но Vue и Svelte немного лучше, как и Preact

для чего и кому?

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

Поясню про легаси. Нужно, чтобы юниор мог легко подхватить начатое. А не так, что скажут: дед, что ты тут за writeonly старьё навалял, сдать нахрен в утиль вместе с тобой. Как это происходит с нашей перловой кодобазой.

Не легаси ещё, мейнстрим. Слишком мало пока у более свежих фреймворков отличий от react, особенно на реальных более-менее нагруженных приложениях. Да и концепты те же.

Подождём ещё лет 5, может быть что-то изменится совсем:)

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

Реакт – торт.

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

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

пиши на Elm

Ну да, то-то гугл включил preact в поддерживаемые проекты:

https://www.opennet.ru/opennews/art.shtml?num=54242

Так уже стабилизировалось. Сейчас 3 столпа: react (и клоны), vue, svelte

Уже ничего нового не изобретут до полного прихода webassembly, а там уже мы увидим как попрут аналоги flash/flex целым зоопарком, где будут целостные приложения по типу апп для айфона, со всем медиа в кишках одним блобом подписанным, блоб будет загружен в браузер и в браузере начнёт своё представление как flash-ролик со всякими сетевыми наворотами типа realtime tcp/udp, http3/4, эра web 3.0

Сейчас мы грузим браузер один раз и ходим по сайтам, а в будущем будем на каждом сайте грузить «свой», созданный разрабами сайта, браузер внутри браузера. Как сон внутри сна 🤣

Реакт не торт потому, что ручками писать все эти jsx в больших проектах - то ещё говно и страдание, vue рулит своими template

Все крупные компании, что я видел с использованием реактом - прикручивают к нему свой шаблонизатор, создавая vue из костылей

Некоторые из них, кстати, пишут об этом в своих блогах, и на хабре) что у реакт куча минусов

Нет, реакт всё ещё нужно, потому что конкурентных решений почти нет или «те же яйца только в профиль».
Если будешь работать в один смычок - будет легче на каком-то этапе найти на фронтенд студня. Если начнётся «реакт - не модно, сейчас всё далют на <что угодно>» - гони в шею.

Прежде всего, для справедливости, я бы хотел заметить, что React сам по себе — неудачное решение. Фейсбуку нужно было какой-то общее решение для всей их фронтент разработки, Angular им плохо подходил, они попытались сделать что-то более годное, у них не получилось. Более парадоксально то, что получившийся плохой фреймворк подхватила куча индусов, начавших совать его к месту и не к месту — спасибо им за то, что теперь даже вебсайты с простейшим текстом грузятся по 5-10 секунд и не работают с отключенными скриптами.

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

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

Реакт не торт потому, что ручками писать все эти jsx в больших проектах - то ещё говно и страдание, vue рулит своими template

Я последний год пишу на Vue, и не могу согласиться. На бумаге гладко, а как начинаешь пользоваться, то сразу возникает вопрос: люди, которые этот фреймворк пишут, вообще пишет самими SPA? Потому что я в упор не могу понять решений, которые они принимают. Например: у меня есть составное значение, объект-запись с несколькими полями; я хочу этот объект отредактировать. В случае одного монструозного компонента я могу просто написать <input v-model="object.field"/>. Если же я решил грамотно разделить код на компоненты, то у меня получается, что объект становится свойством компонента. Однако, в таком случае назначенный свойству объект и прочитанное изнутри компонента свойство становятся разными объектами, где изменения распространяются снаружи вовнутрь компонента, но не распространяются в обратную сторону. Потому для редактирования внутри компонента я должен делать копию (props->data) значения, потенциально при этом добавляя еще и watch для отслеживания внешних изменений назначенного свойства. Для отправки изменений наружу я должен после редактирования обновлять внешний объект через событие «update:propname», а само свойство будет с модификатором sync, вроде propname.sync="object". Среди вариантов еще есть передача полей отдельными свойствами, но мой самый-самый любимый костыль:

data () {
    return {
        privateData: defaultValue,
    }
},
props: {
    prop: Object,
},
mounted () {
    this.privateData = this.prop;
},

Такой финт позволяет использовать поля privateData как угодно в v-model, поскольку this.prop и this.privateData в таком случае ссылаются на один и тот же объект, и потому взаимозаменяемы. В Svelte, к слову, эта проблема решена через «bind». Зачем заставлять программиста так извращаться, когда изначально Vue основана на сквозном глобальном отслеживании значений независимо от местонахождения? И именно благодаря этому механизму, к слову, в Vue не нужны никакие Redux/MobX — они уже есть из коробки. Потому Vue уже по этому пункту на голову выше React — но только потому, что React слишком уж убог.

Вы уже прочувствовали мою боль? А я только начал. Это первая проблема, которая отталкивает от написания компонента — ты хочешь просто накидать пару input-ов, а тебе приходится вокруг них воротить кучу обвязки или тупо прокидывать элементарные свойства руками, потому что код внутри компонента не похож на код связи компонентов, очень не похож.

Второй большой пласт проблем Vue — это то, как организованы компоненты внутри. Как в случае исходных компонентов на чистом JS (Vue.component('button-counter', { data: ... }), так и в случае шаблонов (<template>...</template><script>...</script>) секции data, methods, props, computed разнесены друг от друга, и все они разнесены от самой структуры объектов компонента (template). Такая организация работает для нескольких десятках строчек, но в случае достаточно крупного кода разработка скатывается в прыгание на сотни и тысячи строчек кода. А разнести в разные компоненты это нельзя, потому что смотри выше — код увязнет в сплошном взаимодействии компонентов. Можно писать JS-код в секции <template>, но вот проблема — в <template> он интерпретируется значительно иначе, чем в <script>, например,

<<input v-bind:value="value" v-on:input="mydata = $event.target.value />"

<input v-bind:value="value" v-on:input="onInput/>"
...
onInput (event) {
    this.myData = event.target.value;
}

Предлагаю читателю, незнакомому с Vue, в качестве домашнего задания узнать, что же такое $#!@ть $event, и почему оно не имеет ничего общего с $refs, $options, $parent, etc, которые являются атрибутами объекта Vue в отличие от $event, являющейся локальной переменной.

В целом, причина возникновения второго пласта проблем во Vue проста: архитекторы упоролись ООП, прийдя к состоянию оторванности от реального мира. Все эти секции data, methods, props, computed — это ненужная шелуха, так не пишут на JavaScript. Как минимум эта проблема устранена в Svelte, где вместо объектов с секциями пишется классический JS в произвольной организации, что позволяет располагать связанный код рядом. Аналогично по поводу JS кода в шаблоне: в идеале я хотел бы копипастить JS код между секциями <script> и <template>. Я только не в курсе, можно ли в Svelte так делать.

Еще бы можно было затронуть третий пласт — плохая способность взаимодействия с простым JS кодом, для которого, например, может быть очень нежелательно наличие реактивных обработчиков в больших и сложных структурах данных, поскольку это сильно ударит по производительности. Позиция разрабов Vue по этому поводу простая: всё реактивное, что фронтенд, и больше ничего быть не может. То есть, фреймворк не терпит себе альтернатив: его неудобно встраивать туда, где нет Vue, и код без Vue тяжело встроить во Vue. Вы хотите забросить html статику внутрь компонента? Вам придется использовать Vue компонент с <div v-html="..." />, иначе ваши изменения потрутся — и то не всё может оказаться гладко. Опять же, я не в курсе, решена ли эта проблема в Svelte или нет.

Некоторые из них, кстати, пишут об этом в своих блогах, и на хабре) что у реакт куча минусов

Напоследок чутка расскажу, почему React плох. Фундаментальная причина заключается в том, что создатели реакта на самом деле аки туземцы подражали функциональному реактивному программированию — отсюда, собственно, и название «React».

И первые грабли, об которые они сразу же ударились — это как создать глобальное состояние. Функциональщики не любят глобальные состояния, но в чистых функциональных языках, вроде Haskell, все-таки есть механизмы, чтобы не сильно напрягаясь прокидывать сквозь все уровни вызовов глобальные состояния. С этой проблемой будто в первый раз столкнулись создатели React — в конце-концов они сделали систему контекстов. Но сколько времени прошло! Поддержка появилась только в 16.3 — это 2018 год, а до тех пор программисты городили собственные костыли, прокидывали состояния руками, но большинство пользовалось Redux. Redux, который только делает поддержку еще сложнее, заставляя на простейший чих править несколько файлов. Даже сам создатель Redux не рекомендует пользоваться своей библиотекой:

https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367

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

https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html

Вторая же, менее значимая проблема в 2020 году — это отсутствие необходимости в виртуальном DOM. Браузеры способны эффективно обновлять DOM напрямую, без необходимости генерации промежуточных структур. Собственно, такой режим есть и в React:

https://reactjs.org/docs/uncontrolled-components.html

Правда, в таком варианте React сдает свои полномочия и превращается в тыкву.

Для Vue эта проблема чуть менее актуальна, потому что он генерирует новый виртуальный DOM только для изменившихся компонентов, в отличие от React, который перестраивает всё дерево заново, не пересчитывая только неизменившиеся дочерние компоненты.

Но проблема неэффективного обновления DOM по состоянию на 2020 год не стоит так остро, потому что у всех уже по 16 Гб оперативы, 100 Мбит/с интернет, и к тормозящим сайтам люди уже привыкли. А вот разработка по прежнему стоит очень дорого. Можно посмотреть на это с другой стороны: неэффективность разработки на React значит, что у разработчиков React еще очень долго будет много работы, а значит можно смело делать ставку на изучение этого фреймворка — она окупится в перспективе.

Нет, реакт всё ещё нужно, потому что конкурентных решений почти нет или «те же яйца только в профиль».

Откуда инфа? Вот моя: https://2019.stateofjs.com/front-end-frameworks/

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

Да. Потому у Hacker News такой ублюдочный вебсайт — потому что никто, кроме его создателя, не может разобраться в коде на диалекте лиспа, созданном тоже создателем сайта. С другой стороны, через месяц-другой любой мало-мальски способный студень сможет освоиться с любым JS фреймворком, потому твой тезис справедлив только при поиске студня на фрилансе для работы на несколько дней.

Vue не нужны никакие Redux/MobX — они уже есть из коробки

И называется Vuex. Рекомендую.

Вы уже прочувствовали мою боль?

Не зря ведь придумали централизованное управление состоянием, ой, не зря %)

Вот еще по теме управления состоянием (на примере скобкоты, но принципы универсальные):

https://purelyfunctional.tv/guide/state-in-re-frame/

Vue не нужны никакие Redux/MobX — они уже есть из коробки

И называется Vuex. Рекомендую

Между нами есть отличие: я полностью прочитал сорцы Vuex. Если выкинуть из них отладочные фичи, инъекцию атрибута $store, довольно сомнительный механизм организации модулей хранилища и горячего изменения их структуры, и совсем бесполезный механизм подписки на вызовы commit/dispatch, которыми никто не пользуется, то исходный код Vuex представляет из себя примерно вот это:

var Store = function Store (state) {
    this._vm = new Vue({
        data: {
            $$state: state
        }
    });
}

Store.prototype.replaceState = function replaceState (state) {
    this$1._vm._data.$$state = state;
};

var prototypeAccessors$1 = { state: { configurable: true } };

prototypeAccessors$1.state.get = function () {
    return this._vm._data.$$state;
};


prototypeAccessors$1.state.set = function (v) {
    {
        assert(false, "use store.replaceState() to explicit replace store state.");
    }
};

Object.defineProperties( Store.prototype, prototypeAccessors$1 );

Как вы понимаете — очень полезная библиотека.

Вы уже прочувствовали мою боль?

Не зря ведь придумали централизованное управление состоянием, ой, не зря %)

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

Вот еще по теме управления состоянием (на примере скобкоты, но принципы универсальные):
https://purelyfunctional.tv/guide/state-in-re-frame/

Чот довольно примитивненько. А конкретно: не затронут вопрос того, что делать, когда в приложении много структур данных, не являющихся ни локальными для конкретного компонента, ни глобальными для всего приложения. То есть, они относятся к одной форме с полями, или к одной задаче (из многих), или просто некоторому сложному компоненту со вложенными компонентами и их сложным взаимодействием. Тот же Vue (и скорее всего Svelte) использует один и тот же механизм для любой локальности данных (если на минутку забыть про кривую работу свойств).

Webassembly слишком медленно приходит, скорее очередной раз что-то другое придёт. Да и стоимость разработки шибко выше. Есть у нас пару проектов на webassembly, включая blazor wasm, всё там мягко говоря так себе. Сильно сомневаюсь, что они всё это допилят до возможности писать полноценные приложения. А вот наоборот, допилить десктопные оси до поддержки ios приложений и android - это уже происходит. Новый мак вполне себе пример. Мелкософт пилит андроид под венду. Учитывая тенденции написания мобильных аппликух первее сайта(даже у нас среди старпёрных ынтерпрайз заказчиков уже было такое) и то, что у многих молодых сегодня просто нет ПС ни в каком виде, даже в виде ноута, думаю мобильные приложения всё и захавают.

Ну остаётся ещё вариант, что какой-нибудь гугл через год или два просто выпустит пускалку apk через webassembly, с единым google плей для android и chrome, вот тогда да, будет нам переход:)

не являющихся ни локальными для конкретного компонента, ни глобальными для всего приложения

Это еще как? Бывают переменные глобальные, локальные и средние?

относятся к одной форме с полями

Компонент формы.

или к одной задаче (из многих),

Глобальное состояние.

или просто некоторому сложному компоненту со вложенными компонентами и их сложным взаимодействием

Некоторый сложный компонент или глобальное состояние.

Я смотрю, тебе не надо, чтобы проще, тебе надо пострадать и заебаться %)

бесполезный механизм подписки на вызовы commit/dispatch, которыми никто не пользуется

Ну точно, так и есть.

Что-то vue мне совсем не нравится. Есть предчувствие, что весь этот сахарок будет кучно стрелять в голову.

view = pure-function(state) — это хорошо, это отлично. Но это решение только одной части проблемы. Еще нужно как минимум

• управлять этим самым state. Удобнее это делать, когда он более-менее в одном месте, а не раздристан по всему приложению, и его обновление контролируемо.
• управлять внешними эффектами (принимать сигналы из внешнего мира и отправлять их обратно).

Таким образом, реакт нужен, но одного реакта недостаточно.

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

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

Vue же.

Тут два процесса параллельно идут.

С одной стороны многие мобильные приложения это по сути веб приложения, сделанные как угодно, в том числе с react native, который нечто посередине. Причём такие приложения, могут и не запускаться в браузере совсем или отображаться и работать хуже, чем на мобилках(привет тикток и прочие).

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

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

PS: у меня и мама и тёща сидят в основном в мобильнике, и их никто не подсаживал. Так само случилось при смене телефона. У мамы так вообще интернет только на мобильнике нормальный:)

Ты ещё спроси, нужен ли тайпскрипт. Но там хотя бы интерфейсы искаропки

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

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

Тайпскрипт это для галеры наверно. А так всё усложнять на ровном месте не вижу смысла. Лучше уж настоящего борща навернуть типа reasonml. Но это на локалхосте только, может руки и дойдут когда-нибудь.

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

Это понятно. В данном случае как раз надо. Хотелось бы конечно нормальный гуи-клиент, но это долго и бесперспективно. От одной мысли о Qt становится тоскливо.

Я кстати прототип интерфейса уже пишу на тикле. Так намного проще, чем сразу ломать башку о браузерные технологии.

Так что смысла заморачиваться и делать сайт как бы и нет

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

А это уже зависит от заказчика. Кто-то заказывает только ios, кто-то только android, кто-то всё вместе, да ещё и сайт прикупит. Что до инопланетности, то согласиться с этим не могу никак. Современный веб более инопланетен и по сложности разработки наблюдается лишь рост. Основная проблема с эплом в том, что нужны именно эплодевелоперы, потому что разработчики кросс-платформы могут от маков плеваться. Но это хоть и сложный кадровый вопрос, но решаемый вполне себе. Также как найти хороших веб разработчиков та ещё задачка.

От одной мысли о Qt становится тоскливо.

А, ты просто неосилятор.

Дык, в профиле же написано.

Откуда инфа?

С рынка труда

Вот моя: https://2019.stateofjs.com/front-end-frameworks/

Сам собрал?

Потому у Hacker News такой ублюдочный вебсайт

Причём тут HN и всё остальное? Где там реакт?

усложнять

Подход очень простой. Если create-hipster-app конфигурит тебе весь тулчейн - используешь его, иначе в пень. Если таких несколько - выбираешь сахара и наворотов по максимуму.

Дык, в профиле же написано.

Так другое написано, и одно второму не мешает.

не являющихся ни локальными для конкретного компонента, ни глобальными для всего приложения

Это еще как? Бывают переменные глобальные, локальные и средние?

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

относятся к одной форме с полями

Компонент формы

И что с ними происходит при исчезновении формы? Я уже догадываюсь, что ты предложишь копировать/транслировать значения, но что если, грубо говоря, я вызвал панельку редактирования некоего заголовка? И эта панелька не является родительским компонентом или дочерним для заголовка и родительского компонента заголовка. Хорошо, когда всё красиво и иерархично, но по мере роста проекта исключения появляются чаще и чаще. Если выкидывать эти данные в глобальное состояние, то глобальное состояние очень быстро превратится в помойку и просто в какие-то костыли из данных со временным ключем.

или к одной задаче (из многих),

Глобальное состояние

Угу, все-таки превращать в помойку глобальное состояние. Ну типа зачем было играться в локальность и неизменяемость данных, когда в итоге все пути ведут в глобальное изменяемое состояние? Ну то есть я согласен с тем, что расщепление глобального состояния, создание временных глобальных состояний — это удобный подход. Я и сам так делаю. Но я и не строю иллюзий по поводу красивых архитектур на локальных данных.

бесполезный механизм подписки на вызовы commit/dispatch, которыми никто не пользуется

Ну точно, так и есть

Зачем нужна подписка на изменения во фреймворке, в котором подписка делается простым чтением значения? На сайте re-frame почему-то приведено сравнение с React+Redux, но стыдливо скрыто сравнение со Vue, потому что пример на Vue будет в полтора раза короче примера re-frame.

<html>
  <div>
    <h2>Counter</h2>
    <div>
      <button @click="counter--" />
      <span>{{ counter }}</span>
      <button @click="counter++" />
    </div>
  </div>
</html>
<script>
  import Vue from 'vue';
  Vue.prototype.counter = new Vue({
    data: { counter: 0 }
  });

  var app = new Vue({
    el: '#counter',
  });
</script>

20 строк, против 26 строк примера на re-frame и 55 строк на React. При том, что на самом деле некоторые строки на re-frame по-хорошему заслуживают разбиения, потому что все строки на Vue и React тупы до безобразия. И это то, каким изначально должен был быть Vue. Заметь, как легко и просто реализовано глобальное состояние. Но архитекторы у руля уехали в какую-то лютую дичь с секциями в компонентах, а вместо элегантного глобального состояния соорудили какую-то дичь из кучи модулей, (vuex) где тот же counter в простейшем случае должен был быть объявлен как:

<html>
  <div>
    <h2>Counter</h2>
    <div>
      <button @click="$store.commit['setCounter', $store.state.counter - 1)" />
      <span>{{ counter }}</span>
      <button @click="$store.commit['setCounter', $store.state.counter + 1)" />
    </div>
  </div>
</html>
<script>
  import Vue from 'vue';
  import Vuex from 'vuex'

  Vue.use(Vuex)

  const store = new Vuex.Store({
    state: {
      counter: 0
    },
    mutations: {
      setState (state, content) {
        state.counter = content;
      }
    }
  });

  var app = new Vue({
    el: '#counter',
  })
</script>

Уже чувствуете, как говном запахло?

Что-то vue мне совсем не нравится. Есть предчувствие, что весь этот сахарок будет кучно стрелять в голову

Да. Потому в Svelte попытались кол-во сахарка минимизировать, чтобы заиметь простые и очевидные конструкции. Не в последнюю очередь кучу сахара, в том числе v-model, произошло именно из-за убогости некоторых архитектурных решений. В Svelte ты пишешь bind:propname — и всё. Но в Vue у тебя свойства обратно связываются только через события, а обработчики автоматически генерируются аж через два механизма: v-model и propname.sync. И оба в конечном счете требуют на стороне компонента явного вызова $emit('update:propname', value) . Все эти проблемы в принципе отсутствуют в Svelte, ты просто пишешь на JS как на JS.

Учитывая тенденции написания мобильных аппликух первее сайта(даже у нас среди старпёрных ынтерпрайз заказчиков уже было такое) и то, что у многих молодых сегодня просто нет ПС ни в каком виде, даже в виде ноута, думаю мобильные приложения всё и захавают

Я кстати тоже обдумывал этот вариант. Но это как-то сложно и/или дорого. По-хорошему нужны нативные клиенты под каждую платформу, но и сайт тоже нужен. Всяко проще сделать только сайт, а там как пойдёт

Вот. Неочевидный факт, но SPA/Electron/etc не является истинно кроссплатформенным решением, потому что ресурсоемко и сильно не нативно.

Если юзеру не надо лопатить килозаписи у себя в браузере - реактивное говно не нужно. Оно существует только чтобы серваки разгрузить

И это неправильный ответ. Потому что особо на JS не полопатишь килозаписи, на самом деле — WebAssembly скорее для этого предназначен. В конце-концов, килозаписи вполне себе лопатили до всяких реактов и васмов на обычных JS/jQuery.

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

Лучше уж настоящего борща навернуть типа reasonml. Но это на локалхосте только, может руки и дойдут когда-нибудь

ReasonML хорош. Вот как пишется на нем вышеупомянутый пример со счетчиком:

https://reasonml.github.io/reason-react/docs/en/usestate-hook

чувствуете, как говном запахло

Согласен, для приложения из одного счетчика городить управление состоянием не нужно. Излишне.

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

Откуда инфа?

С рынка труда

Рынки труда бывают разные. Самые вкусные вакансии тебе открыто никто не предложит.

Вот моя: https://2019.stateofjs.com/front-end-frameworks/

Сам собрал?

Нет, не я. Я согласен с тем, что выборка могла быть нерепрезентативной. Но, тем не менее, картину она примерно отображает: про Svelte знает мало людей, но те, кто знает, довольны этим фреймворком. Коммерческое IT само по себе весьма инертно, так что это не сюрприз для меня.

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

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

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

а как мне вытащить цифирку из соседнего компонента

<input :value="siblingComponent.value" />

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

какого хрена левый компонент лезет грязными лапами в мое состояние и меняет его по своему усмотрению (кстати, интересно, какой именно из 100500 существующих)?

Вешается watch с immediate=true на состояние и отслеживается нарушитель по стэку. К сожалению, отсутствие эффективных механизмов работы с неизменяемыми данными — это общая проблема JS, и решить ее можно только транспиляцией из языка, где эти механизмы есть. Вроде ClojureScript или ReasonML.

Я про тот кейс, что юзеру надо лопатить килозаписи, не машине

Я про тот кейс, что юзеру надо лопатить килозаписи, не машине

Пардон, не так понял сначала твое сообщение. Тогда ты скорее прав чем нет, но даже в этом случае существуют фреймы HTML, которые позволяют грузить маленькую страничку при перелопачивании. Или тупо совать этот HTML в какой-то блок через AJAX-запросы. Тезис из предыдущего ответа остается: реакт и прочие нужны для организации большой сложной фронтенд-системы — никакой задачи больше они не решает. Если перелопачивание килозаписей не предполагает сложного фронтенда, то React может быть излишним.

а как мне вытащить цифирку из соседнего компонента

Я имею в виду что-то вроде

<ParentComponent ...>
   ...
       ... 
           ...
               <Comp1 ...>
   ...
       ... 
           ...
               <Comp2 ...>

и компоненту Comp1 нужно добыть данные из Comp2. Каноничный путь — передать их с событием на n уровней вверх, засрать ими состояние ParentComponent, передать через props на n уровней вниз (засрав по дороге состояние еще n промежуточных компонентов). Совсем не похоже на удаление миндалин через ректум.

С централизованным состоянием: Comp1 -> db -> Comp2. Слишком просто, на мое место наймут студентов, а я пойду работать в яндекс.еду. Надо поднаворотить угара!

<input :value=«siblingComponent.value» />

Ага, еще и ссылку на соседа тоже через n уровней передать. Чюдесно. Совсем не пахнет %)