Почему React?
Сегодня никого уже не удивить фронтэнд-фреймворками. Используются они везде и повсеместно, став де-факто стандартном современного веба. Язык Javascript, лежащий в их основе, считается одним из самых перспективных сегодня и в ближайшем будущем, потеснив в том числе и лидеров бэкэнд-отрасли.
Тематические источники пестрят вакансиями фронтэнд-разработчиков, предлагая достойный уровень оплаты и большой выбор проектов. Фактически, они вывели профессию верстальщика на другой уровень, дав новую перспективу развития и профессионального и карьерного роста, сломав старые парадигмы веб-разработки.
Поговорим сначала о том, почему вообще появились фронтэнд-фреймворки, в чем состоит их принципиальная новизна, как они закрепились в современном вебе и получили широкое распространение, и где их применение оправдано.
Раньше любое веб-приложение (сайт) рассматривали как монолитную структуру, в которой превалировала серверная часть (как правило, на основе традиционной CMS либо MVC-фреймворка), а визуал (или фронтэнд) представлял собой лишь один из продуктов, получаемый в результате функционирования ядра. То есть, бэкэнд определял целиком и полностью, что получит пользователь и в каком объеме. Это была та самая статическая верстка, которую очень любят поисковые системы. Весь интерактив прикручивался к этой верстке при помощи внешних скриптов, включаемых (как правило) уже после загрузки самого HTML-документа.
Какого-то единого подхода тут не было, поэтому порядок и правильность исполнения скриптов были только на совести верстальщика (либо фулл-стек разработчика). По мере развития проекта верстка менялась, добавлялись/убирались какие-то блоки, добавлялись новые скрипты, старые зачастую не убирались (чтобы вдруг не сломалось). Поддерживать такой интерфейс в рабочем состоянии становилось все труднее - росло число “костылей” или заплаток, призванных устранить сиюминутные проявления неработоспособности элементов визуальной части.
Следующий этап, к которому приходили разработчики - это сборка бандлов (пакетов). Бандлы были первой попыткой упорядочить весь разрозненный javascript-код, включаемый в документ с целью обеспечить ему всю необходимую интерактивность и удобство использования. Бандл (в его нормальном понимании) - это транспилированный (для максимальной совместимости), изолированный из глобальной области и объединенный в один файл весь необходимый код для обеспечения необходимого функционала интерактивности на странице. Иногда из бандла в целях максимизации быстродействия исключались особо тяжеловесные библиотеки (типа jQuery), доступные через CDN. Хороший бандл, как правило, собирался не просто путем конкатенации всех скриптов из директории исходников, а на основе какого-то файла-манифеста, явно определявшего, что и в какой последовательности включать в выходной пакет.
Однако, фактически бандлы не привносили ничего качественно нового в выходной продукт, так как по сути своей представляли все тот же внедряемый javascript-код, работающий с уже сгенерированным DOM-деревом документа. Стили элементов же загружались из другого такого же бандла, применялись из них лишь те, которые соответствовали свойствам имеющихся в DOM-дереве элементов. Остальные просто игнорировались.
Время шло, и параллельно с этим UX-дизайнеры генерировали все более сложные и изощренные интерфейсы, пользователи становились более искушенными, а программисты старались, потели, и пытались заставить работать все это быстро, без сбоев и на всех возможных клиентских устройствах.
С подачи лидеров отрасли все чаще в умы разработчиков стали проникать идеи про компонентный подход к интерфейсу и про то, что представление в нем вторично и должно являться лишь результатом воплощения логической модели, реализовать которую и призваны те самые фронтэнд-фреймворки.
Продолжение следует...
Ссылки