История изменений

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

Вполне реальная проблема в том, что если от сайта требуется логика на клиенте (а без неё никуда, так как юзеры привыкли к обновлениям данных в реальном времени, отсутствия полных перезагрузок страниц, валидации форм по мере ввода и т. д.) сложнее alert(«Hello world»), то есть 1000 способов как сделать неподдерживаемую лапшу и 1 способ на эту тысячу написать хоть немного что-то поддерживаемое. А фреймворки дисциплинируют разработчиков соблюдать некоторую относительно удачную структуру приложения и использовать определённые best practice, которые описаны в сотнях туториалов.

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

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

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

Вполне реальная проблема в том, что если от сайта требуется логика на клиенте (а без неё никуда, так как юзеры привыкли к обновлениям данных в реальном времени, отсутствия полных перезагрузок страниц, валидации форм по мере ввода и т. д.) сложнее alert(«Hello world»), то есть 1000 способов как сделать неподдерживаемую лапшу и 1 способ на эту тысячу написать хоть немного что-то поддерживаемое. А фреймворки дисциплинируют разработчиков соблюдать некоторую относительно удачную структуру приложения и использовать определённые best practice, которые описаны в сотнях туториалов.

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

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