ПРЕДУПРЕЖДЕНИЕ

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

1. JSX

А теперь сразу попробую попытаюсь объяснить.

Лично я не считаю TSX/JSX каким то уродливым, вовсе нет. Проблема именно то как этот самый TSX выглядит вместе с реактом… Вот абсолютно каждый из вас когда стартовал проект через create-react-app или vite, видел стандартный пример счетчика.

Вот туть вот он ниже кто не видел (это не оригинальный код а слегка измененный, но суть передана на 100%)

// Counter.tsx
import React, { useState } from 'react';

interface CounterProps {
  initialValue?: number;
  step?: number;
}

const Counter: React.FC<CounterProps> = ({ initialValue = 0, step = 1 }) => {
  const [count, setCount] = useState<number>(initialValue);

  const increment = () => setCount(prev => prev + step);
  const decrement = () => setCount(prev => prev - step);
  const reset = () => setCount(initialValue);

  return (
    <div>
      <h2>React Counter</h2>
      <p>Current count: {count}</p>
      <button onClick={decrement}>-</button>
      <button onClick={reset}>Reset</button>
      <button onClick={increment}>+</button>
    </div>
  );
};

export default Counter;

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

А теперь давайте так же вспомним что в React ты должен оптимизировать все сам ручками и добавлять всякие функции для оптимизации и чуток усложним наш Counter сделав его более производительным

import React, { useState, useCallback, memo } from 'react';

interface CounterProps {
  initialValue?: number;
  step?: number;
}

const Counter = memo(({ initialValue = 0, step = 1 }: CounterProps) => {
  const [count, setCount] = useState<number>(initialValue);

  const increment = useCallback(() => {
    setCount(prev => prev + step);
  }, [step]);

  const decrement = useCallback(() => {
    setCount(prev => prev - step);
  }, [step]);

  const reset = useCallback(() => {
    setCount(initialValue);
  }, [initialValue]);

  return (
    <div>
      <h2>React Counter (optimized)</h2>
      <p>Current count: {count}</p>
      <button onClick={decrement}>-</button>
      <button onClick={reset}>Reset</button>
      <button onClick={increment}>+</button>
    </div>
  );
});

Counter.displayName = 'Counter'; //Для отладки обычно всегда добавляют имя

export default Counter;

И вот здесь вот уже начинается эта фигня мягко говоря, уже слишком много функций внутри функций, зависимости, странный синтаксис, все выглядит как то громоздко для буквально ПРОСТЕЙШЕГО компонента, да даже на нативном JavaScript это будет выглядеть куда приятнее…

Трудно поверить? А вот, смотрите, держите доказательство.

const state = {
  count: 0
};

function render() {
  // Предполагаем, что в HTML есть элемент с id="counterValue"
  const display = document.getElementById('counterValue');
  if (display) display.textContent = state.count;
}

const reactiveState = new Proxy(state, {
  set(target, prop, value) {
    if (prop === 'count' && typeof value === 'number') {
      target[prop] = value;
      render();
      return true;
    }
    return false;
  }
});

const counter = {
  increment(step = 1) {
    reactiveState.count += step;
  },
  decrement(step = 1) {
    reactiveState.count -= step;
  },
  reset() {
    reactiveState.count = 0;
  }
};

export { counter, reactiveState };

Окей хорошо, кто то скажет что мол, это проблема в TSX / JSX, но я скажу вам обратное, нет это проблема синтаксиса самой библиотеки потому что сейчас я вам приведу пример ближайших соседей реакта, это Vue.js и Solid.js, я мог бы взять еще и Preact, но какой смысл если это просто чуть-чуть исправленная версия реакта который еще меньше весит? Я вот тоже не знаю, у нас сейчас идет сравнение именно TSX | JSX.

// Counter.tsx (Solid.js)
import { createSignal } from 'solid-js';

interface CounterProps {
  initialValue?: number;
  step?: number;
}

export const Counter = ({ initialValue = 0, step = 1 }: CounterProps) => {
  const [count, setCount] = createSignal(initialValue);

  const increment = () => setCount(c => c + step);
  const decrement = () => setCount(c => c - step);
  const reset = () => setCount(initialValue);

  return (
    <div>
      <h2>Solid Counter</h2>
      <p>Current count: {count()}</p>
      <button onClick={decrement}>-</button>
      <button onClick={reset}>Reset</button>
      <button onClick={increment}>+</button>
    </div>
  );
};

Ух ты… тоже самое как и в начале когда мы только увидели пример на React но без оптимизации как так? Я где то схитрил?

А вот и нет оказывается что у Solid.js вообще нет таких приколов как useCallback и тд тп. Он работает на новой технологии signals это следующая ветвь развития JavaScript которая я как понимаю в разработке, но Solid видимо написали свою версию или используют что то другое, не знаю, я не вдавался в подробности.

Окей… ладно давайте посмотрим Vue.js так же в TSX | JSX

import { defineComponent, ref } from 'vue';

export default defineComponent({
  name: 'VueCounter',
  props: {
    initialValue: { type: Number, default: 0 },
    step: { type: Number, default: 1 },
  },
  setup(props) {
    const count = ref(props.initialValue);

    const increment = () => { count.value += props.step; };
    const decrement = () => { count.value -= props.step; };
    const reset = () => { count.value = props.initialValue; };

    return () => (
      <div>
        <h2>Vue Counter (TSX)</h2>
        <p>Current count: {count.value}</p>
        <button onClick={decrement}>-</button>
        <button onClick={reset}>Reset</button>
        <button onClick={increment}>+</button>
      </div>
    );
  },
});

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

2. Оптимизация

Вот казалось бы, ладно разработчики нам подарили хуки для того чтобы мы оптимизировали наши приложения. Но как оказывается useCallback / useMemo / memo не всегда нужны и вызывают лишь проблемы с оптимизацией…

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

Хорошо, получается тогда если я по вашему сокращу все функции на алгоритмы эффективные то это будет лишнее. Или все таки нет? К примеру везде выполняется сортировка больших списков и мы переходим к типичной пузырьковой сортировки хотя бы.

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

Но я специально привожу вот такой примитивный пример, вот скажите мне неужели мы разработчики не видим момент когда нужна оптимизация? Конечно видим, и новички и опытные разработчики просто по отзывчивости UI и банально поймут что тут дело пахнет керосином и надо чето делать. Это тупо простейший пример, но реально я просто не понимаю иногда почему когда я занимаюсь в реакте оптимизацией, я либо ее вообще не вижу, либо получается хуже, окей может я реально плох в реакте и даже отрицать это не буду потому что 100% найдутся те самые гуру реакта которые все знают.

Но а теперь по делу, а зачем нам нужны эти средства оптимизации если во Vue.js их нет (окей ладно там есть computed + v-memo и v-once, computed юзается довольно часто, но v-memo и v-once я лишь пару раз за всю жизнь использовал) Та же ситуация и с Solid.js, всех этих усложнений тупо нет, там реально все работает быстрее и лучше.

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

Но в реакте кроме разных техник, ты так же должен оптимизировать то что сами разработчики реакта не додумались сделать внутри библиотеки

Кто то скажет что я забыл про React Compiler который анонсировали с выходом 19 версии и можно уже не писать useCallback + useMemo и все такое, НО ОН НЕ РАБОТАЕТ Б*ЛТЬ!!! ДО СИХ ПОР!!

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

А вот эти самые видосы если кому нужны пруфы:

React Complier

[1 Пункт где четко было сказано что разработчики не выполнили свои обещания] (https://youtu.be/wecHKshrKPQ?t=70)

Theo разбирает React Complier

И из этого вытекает следующий пункт.

3. Фиксы, чтобы было что фиксить

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

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

Я только и слышал что то вроде: Зачем они это добавили вообще? Если что речь идет про новый хук для промисов use

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

Так же обещали что хуки memo | useMemo | useCallback спасут производительность, но как вы уже знаете, данная оптимизация требует ресурсы и могут создать проблемы с производительностью))))

4. Миф о «чистом React» (он же «никто так не пишет»)

Часто защитники React говорят: «Ты просто неправильно пишешь, нормальные разработчики используют useReducer, zustand, redux-toolkit, выносят логику в кастомные хуки».

Но вот в чём соль: если библиотека требует знать 10 способов избежать её проблем — это проблема библиотеки. Почему во Vue я просто пишу count.value++, а в React я должен думать о замыканиях, зависимостях, стабильности ссылок и prev? Почему простой счётчик превращается в мини-лекцию по функциональному программированию?

Добавьте пример с «правильным» React без оптимизаций, который всё равно тормозит на реальном сценарии (например, анимированный слайдер или форма с 20 полями). И покажите, как та же логика на Solid или Vue работает без лагов из коробки.

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

5. Когнитивная нагрузка это главная проблема React

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

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

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

• Расскажите про useCallback.

• Он нужен, чтобы не пересоздавать функцию.

• Зачем?

• Чтобы не перерисовывать дочерний компонент.

• А зачем мемоизировать дочерний компонент?

• Чтобы он не перерисовывался при неизменных пропсах.

• А почему он перерисовывается без этого?

• Потому что функция создаётся заново.

• Так может не надо мемоизировать функцию?

И это уже просто какой то мем, потому что собес превращается в КТО КРУЧЕ ЗНАЕТ РЕАКТ и как решать его подводные камни.

И к этому всему добавляется еще куча классных видос по типу:

• You’re using fetch incorrectly.

• You’re writing the button component incorrectly.

• You’re breathing incorrectly.

• You’re wearing your socks incorrectly.

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

6. Экосистема

Аргумент фанатов: «У React огромная экосистема, всё есть». А вот теперь серьезно, вы реально считаете что миллион библиотек на одну и ту же тему в реакте это нормально??!?!?!

Окей хорошо, ловите контр аргумент который не парируется: огромная экосистема появилась именно потому, что в React не хватает встроенных решений и вам нужны:

• react-router вместо нормального роутера (как во Vue Router)

• react-hook-form вместо встроенной работы с формами (а во Vue — v-model)

• redux/zustand вместо реактивного стейта (а в Solid — глобальные сигналы из коробки)

• react-query | tanstack для кеширования запросов (а в VueUse/SWR уже есть)

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

Фактически React - это ядро, а всё остальное довешивают сторонние библиотеки, которые ещё и конфликтуют друг с другом и тут уже господь бог свидетель (я атеист но я не знаю как уже передать мой баттхёрт) вам не поможет ничего в этой жизни если в реакте начинают конфликтовать библиотеки и не дай бог вы нашли решение, а оно еще и добавляет проблем с производительностью, тут уже никакой useCallback или useMemo не поможет, вам придется свой аналог писать.

7. React DevTools - ужасный проклятый devtools

Вот сейчас разрабы реакта если вы остались и дочитали до этого пункта, вот давайте на чистоту, вот уже чисто как разработчики с разработчиком, React DevTools - Sucks, Давайте просто сравним его с Vue.js DevTools в моем случае будет Nuxt потому что он у меня ближе всех, но отличий от Vue.js DevTools небольшие.

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

Вот ссылка на документацию если кому интересно

Ну вы просто посмотрите на этот девтулз, ну разве он не прекрасен?

И я могу еще больше скриншотов накидать ну лучше чтобы разрабы которые не тыкали этот девтул сами в нем потыкались потому что лучше для фронта пока что я еще не видел девтулза.

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

У вас есть страница с ассетами чтобы быстро просмотреть что у вас есть, у вас так же есть прямая интеграция с вашим основным стейт менеджером Pinia и вы можете в Realtime удобно менять что то и тестировать, что для тестировщиков очень полезно будет.

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

8. Мифы реакта

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

У реакта нет никаких правил, в этом его проблема, нет решений из коробки, это лишь библиотека как было написано ранее, вы лишь создаете свой фреймворк со своими минусами и плюсами… Ну вот реально опять же как разработчик к разработчикам… Ребята, масштабирование проекта, это не заслуга реакта, а заслуга впервую очередь вашего труда, потому что ВЫ придумали решение, ВЫ его вынесли, ВЫ придумали архитектуры, ВЫ так через свою призму посмотрели и приняли такие решения, причем тут реакт??!?!? Объясните мне в комментариях кому не лень, вот просто в чем?!?!?

В кастомных хуках которые просто по факту костыль из за отказа классового подхода в реакте?

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

Да потому что всего этого не было бы если бы сами разработчики реакта исправили бы свои ошибки…

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

React учит правильным паттернам фронтенда

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

Декларативный UI - это круто

Но виртуальный DOM, setState, useEffect с зависимостями - это специфика React. Знания плохо переносятся на другие фреймворки

React легко выучить

Реальность: React легко начать (один компонент, JSX, useState). Но трудно освоить правильно. Порог входа низкий, но порог мастерства - космический!!! Вот щас без шуток и без рофлов, разрабы которые реально невероятно жесткие в реакте, вы молодцы, но опять же какой ценой, к вам реально уважение что вы ее освоили на мастерском уровне.

Самый главный парадокс: React - самый популярный фреймворк, но он даёт самые непереносимые знания

Короче как то так, статья получилась возможно слишком emotional, в чем ее суть? Да хз наверное рассказать не популярное мнение об этом инструменте в 2026 году, хотя судя по stateofjs а так же тенденцией на западе отказываться от реакта, видимо все наконец то поняли что реакт превращает фронтенд разработку именно в тот самый ад когда отрисовка простейшей логики которую раньше делали на PHP + JQuery, стала занимать куда больше времени и требовать куда больше знаний. Вобщем ситуация абсурдная.

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