Какие минусы JSX важны на практике и как их применять?

У JSX есть реальные минусы — их полезно назвать честно, вместе с тем, как с ними живут на практике.

Требуется сборка

JSX — не JavaScript: без Babel/TS/esbuild браузер его не поймёт. Значит, тулчейн обязателен, «просто подключить скриптом» нельзя. Практика: современные шаблоны (Vite, Next.js) закрывают это из коробки; для песочниц есть htm/createElement.

Смешение разметки и логики

Критика «нарушения разделения ответственности»: в одном файле условия, циклы, обработчики и разметка — при плохой дисциплине компонент превращается в кашу. Практика: разделять по компонентам, а не по типам файлов; логику — в кастомные хуки, оставляя в JSX только структуру.

Синтаксические ловушки

• Атрибуты не как в HTML: className, htmlFor, camelCase-события — при переносе вёрстки нужна конвертация.
• Один корневой элемент (лечится Fragment <>).
• Условия только выражениями: && с числом рендерит 0; тернарники вложенно нечитаемы.
• Пробелы/переводы строк ведут себя не как в HTML.
• Комментарии внутри JSX — {/* ... */}.

Многословность и шум

Логика через map, &&, тернарники в разметке местами шумнее шаблонных директив (v-if, *ngFor). Длинные компоненты с классами Tailwind — «стена символов». Практика: ранние return вместо вложенных тернарников, выделение подкомпонентов, вынесение вычислений выше JSX.

Прочее

TypeScript-дженерики в стрелочных компонентах требуют обходов (<T,>); сообщения об ошибках трансформации бывают невнятными.

Коротко для собеседования

Минусы JSX: обязательная сборка (не работает без компилятора), смешение логики и разметки (риск компонентов-каши), синтаксические отличия от HTML (className, один корень, && с 0), шумность условий и списков. Лечение — дисциплина: логика в хуки, ранние return, подкомпоненты, Fragment.