Честно говоря, доводы у автора какие-то сомнительные.
Автор упоминает Redux, но говорит, что в него не углублялся. Далее продолжает осуждать передачу состояния через контекст. При этом, тот самый менеджер состояния (Redux, Mobx и другие) забирает на себя большую часть бизнес логики. Запросы, синхронизации и т.д. Оставляя самим компонентам только переменные ВИЗУАЛЬНОГО состояния. Которые либо вообще не пробрасывются в детей, либо опускаются только на один уровень. Вот тебе и разделение на View и Model.
Проектируюя фронтовое приложение (а не страничку) не получится ограничится только лишь одним реактом. Либо тебе придется писать компоненты высокого уровня, следиться за провайдерами и перусложнаять код.
Но автор опускает эту тему, пытаясь вилкой съесть гороховый суп.
Но в конце статьи, автора задаёт вопрос: " а зачем нам вообще нужен гороховый суп, если можно уменьшить количество ингредиентов и будет вкусный свежий горох без бульона"
Согласен с автором, что если у тебя простейший одностраничник - можно вынести всю логику на бек. Но современные интерактивные web приложения в таком подходе проиграют, потому что пользователь зажрался. Пользователю нужна интерактивность, попапы, UI как на мобиле и чтобы все светилось. Но. Пользователь платит деньги. И он будет платить тем, у кого удобнее и красивее.
Вот и получается, что менеджеры ничего не понимают, им нужно больше кнопок, но приложение, которое делает всё понимающий разработчик с одной кнопкой - никто не покупает.
Фронт и правда переусложнен. НО React это не весь фронт. Это библиотека которая хорошо делает свое дело в создании реактивности.
А вот пихать в него бизнес логику, это уже пытаться есть гороховый суп вилкой.
Могу быть где-то не прав, но это лично мой взгляд на ситуацию с позиции React разработчика.
Честно говоря, доводы у автора какие-то сомнительные.
Автор упоминает Redux, но говорит, что в него не углублялся. Далее продолжает осуждать передачу состояния через контекст. При этом, тот самый менеджер состояния (Redux, Mobx и другие) забирает на себя большую часть бизнес логики. Запросы, синхронизации и т.д. Оставляя самим компонентам только переменные ВИЗУАЛЬНОГО состояния. Которые либо вообще не пробрасывются в детей, либо опускаются только на один уровень. Вот тебе и разделение на View и Model.
Проектируюя фронтовое приложение (а не страничку) не получится ограничится только лишь одним реактом. Либо тебе придется писать компоненты высокого уровня, следиться за провайдерами и перусложнаять код.
Но автор опускает эту тему, пытаясь вилкой съесть гороховый суп.
Но в конце статьи, автора задаёт вопрос: " а зачем нам вообще нужен гороховый суп, если можно уменьшить количество ингредиентов и будет вкусный свежий горох без бульона"
Согласен с автором, что если у тебя простейший одностраничник - можно вынести всю логику на бек. Но современные интерактивные web приложения в таком подходе проиграют, потому что пользователь зажрался. Пользователю нужна интерактивность, попапы, UI как на мобиле и чтобы все светилось. Но. Пользователь платит деньги. И он будет платить тем, у кого удобнее и красивее.
Вот и получается, что менеджеры ничего не понимают, им нужно больше кнопок, но приложение, которое делает всё понимающий разработчик с одной кнопкой - никто не покупает.
Фронт и правда переусложнен. НО React это не весь фронт. Это библиотека которая хорошо делает свое дело в создании реактивности.
А вот пихать в него бизнес логику, это уже пытаться есть гороховый суп вилкой.
Могу быть где-то не прав, но это лично мой взгляд на ситуацию с позиции React разработчика.
А как же Индия? Туда можно Кока-колу толкать. А потом, глядишь, и в Африке кого-нибудь начнут прокачивать