Фреймворки для чайников

Исторически сложилось, что все браузеры, мобильные и десктопные, на всех платформах понимают всего лишь три вещи: HTML, CSS и JavaScript (не путать с Java!).

Были попытки подружить браузеры с другими технологиями: Visual Basic, Java, ActiveX, — но все они провалились, потому что производители железа и браузеров не смогли договориться об открытых стандартах. Остались только открытые стандарты, разрабатываемые публичными консорциумами и рабочими группами. Например, W3C разрабатывает HTML и CSS.

Итак, у нас есть три технологии.

HTML отвечает за структуру страницы.
CSS — за ее оформление (визуальное и адаптив для разных экранов).
JavaScript — за взаимодействие страницы с пользователем (по изначальной задумке; сейчас-то уже практически вообще за все).

Каждая технология развивается независимо, у каждой есть несколько версий. Самые свежие на сегодня версии: HTML5, CSS3, ECMAScript 2018 (это стандарт JavaScript).

Браузеры тоже развиваются независимо. Кто-то (то Internet Explorer, то Safari) отстает от стандартов, кто-то (обычно Chrome или Firefox) бежит впереди и внедряет экспериментальные фичи.

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

Вдобавок HTML и CSS — это не языки программирования, а языки разметки: один лишь синтаксис, набор команд — конструкций и правил — для представления содержимого страницы. Ну, к примеру, в них нет как таковых классов, объектов, функций, методов, присущих языкам программирования.

Чтобы наделить веб-сайт функциональностью и бизнес-логикой, приходится подключать язык программирования на стороне сервера или на стороне клиента (в браузере), а чаще всего — и там и там.

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

Это замедляет разработку. Потому верстальщики и программисты ищут способы использовать продвинутые инструменты вместо «чистых» JavaScript, HTML и CSS.

Пример с таблицей

Чтобы проиллюстрировать пример неэффективности всей этой связки, возьмем такую простую конструкцию, как таблица.

В HTML есть набор тегов для создания таблицы (основные из них — table, th, tr, td). С их помощью можно создать только сетку таблицы с минимальными настройками внешнего вида: задать ширину колонок, размеры ячеек и в принципе всё.

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

Всё это на HTML и CSS невозможно сделать, потому что в HTML нет такого объекта, как таблица, и нет методов работы с ней, которые поддерживались бы любым браузером. Разработчики стандарта 20 лет назад не предполагали, что пользователи захотят работать с содержимым веб-страницы.

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

Для всего этого в HTML и CSS нет подходящих решений, потому на помощь приходит JavaScript — язык программирования, который может манипулировать объектами в структуре HTML и применять к ним стили CSS.

Когда-то для этого использовали другие языки (Visual Basic, например), пытались применять другие технологии (Adobe Flash, например), но JavaScript всех вытеснил. И не в последнюю очередь благодаря JavaScript-библиотекам.

Библиотеки

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

И появились библиотеки — наборы готовых функций на JavaScript, выполняющие типовые операции с HTML-кодом страницы. Пример такой библиотеки — jQuery.

Этих библиотек за двадцать с лишним лет существования JavaScript появилось великое множество. Программистам приходилось комбинировать библиотеки, дружить их между собой, обновлять (ведь каждая развивается своим чередом), следить за совместимостью. Да еще самим код писать — не все же есть в библиотеках.

Подход с библиотеками до сих пор живет. В небольших проектах достаточно подключить одну-две библиотеки для конкретных улучшений. Например, чтобы рисовать красивые графики, подключаем бесплатный Chart.js или платный AmCharts. Если нужна анимация и отзывчивость интерфейса — тот же jQuery, для работы с элементами интерфейса есть смысл взглянуть на Sencha Ext JS и т. п.

И тут появились фреймворки

Для HTML+CSS тоже стали появляться подобные «полуфабрикаты» — заготовки из кусков кода, которые решают типовые проблемы верстки. Например, многоколоночная верстка, закрепленный на странице хедер или футер и прочие типовые задачи, которые выгоднее решить один раз, а потом применять в новых проектах.

Так появились первые фронтенд-каркасы разработки, или фреймворки.

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

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

Самый известный образец HTML+CSS-фреймворка — Bootstrap (вот примеры, вот один из компонентов — карусель, вот другой — кнопки).

Важно, что все сделано на стандартных HTML и CSS и будет работать (и работать более или менее одинаково) во всех браузерах.

Фреймворки уже содержат подогнанные друг к другу совместимые библиотеки, так что разработчику не нужно ничего обновлять, помнить про ограничения и заботиться о совместимости. Так, многие компоненты Bootstrap содержат код на JavaScript с использованием библиотеки jQuery.

Другой известный фреймворк, Foundation, кроме jQuery использует библиотеки Modernizr и FastClick.

Два фреймворка в приложении будут конкурировать за базовые вещи. К примеру, один захочет 12-колоночную сетку, другой — 16-колоночную; они могут использовать одинаковые названия методов JavaScript для разных целей и т. д.

Поэтому между собой фреймворки несовместимы: нужно определиться и выбрать один. Если у вас проект на Bootstrap, а вам нужны вот такие вот звездочки из Foundation — то поженить их не получится. (Но можно самому запилить звездочки для Bootstrap и поделиться ими как плагином. Конечно же, кто-то это уже сделал.)

Так вот, идем дальше

Главная проблема современного веба — разрозненность технологического стека. Невозможно выучить все технологии, знать и уметь их правильно готовить.

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

В общем, для разработки одного приложения требуется столько разных специалистов, что возникло вполне естественное желание как-то объединить некоторые технологии. Если гомогенизировать технологический стек — расширить набор HTML-компонент и тесно подружить их с бэкендом — то фулстек-программист сможет взять на себя всю разработку, от хранения данных до обработки пользовательского взаимодействия.

В то время (речь сейчас идет о передовой мысли десятилетней давности) страницу из структуры и данных собирал сервер. Брал данные из БД, брал шаблон страницы, заполнял его, показывал нужные пользователю контролы и отправлял браузеру.

Стали появляться серверные фреймворки, позволяющие писать на бэкенде код, автоматически генерирующий верстку:

GWT и Vaadin — специализированы для Java;
Telerik — для .NET;
Kivy — для Python;
Shoes — для Руби и т. д.

JavaScript наступает

И вот в 2009 году — весьма важная веха в истории веб-разработки — появился NodeJS, программная платформа, которая существенно расширила возможности JavaScript.

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

На фронтенде тем временем началась борьба за качество кода. Типичный код клиентской части на JavaScript с использованием jQuery обычно не отличался хорошей организацией: писать легко, чинить сложно. JavaScript-фреймворки должны были исправить это: они навязывали разработчику структуру кода, взамен позволяя удобнее управлять им.

Фреймворки, специализированные под определенный бэкенд, оказались не очень удачным экспериментом. Даже PhoneGap — библиотека под «Андроид» — тихонько умирает, вытесняемая ReactNative (до него мы еще дойдем). Хотя вот специализированные Vaadin и Telerik выжили и развиваются своим чередом.

Реактивные фреймворки

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

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

Такие фреймворки называются реактивными, потому что в них состояние интерфейса автоматически реагирует на изменение данных. Если сказать «вот эта переменная управляет цветом вон той кнопки», а потом поменять переменную — цвет кнопки изменится сам, перекрашивать ее вручную не надо.

NB: Реактивное программирование — вариант многопоточного, при котором вместо системы «запрос — ожидание ответа — получение ответа — обработка» работает принцип «запрос (послали и забыли) — ответ — обработка ответа».

Примеры: React, Angular, Vue и еще десятки менее известных.

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

А на фронтенде JS-фреймворк делает всю чистовую работу: рисует контролы, анимирует их, проверяет данные, представляет их в соответствии с локальными настройками пользователя и реализует бизнес-логику.

Ну вот те же самые таблицы. Что с ними делала, например, библиотека jQuery — и как поступают реактивные фреймворки?

jQuery: таблица вместе с данными и дизайном была заполнена на сервере, а в браузере jQuery только манипулировала этой таблицей (например, сортировала ее).
React, Angular, Vue: структура таблицы генерируется фреймворком прямо на клиенте, в нее вставляются пришедшие с сервера данные.

Между браузером и сервером передаются только данные и иногда — новые куски шаблона и правила. Реактивные фреймворки незаменимы для реализации концепции Single Page Application, когда всё происходит на одном экране.

Надстройки

JS-фреймворки сразу же обросли библиотеками GUI-компонентов, или надстройками, которые решают конкретные вопросы отзывчивого и богатого GUI в рамках конкретного фреймворка.

Примеров множество: KendoUI — набор UI-компонент для jQuery, React, Angular и Vue, ReactStrap — Bootstrap для React, ReactNative — GUI фреймворк от “Фейсбука” и т. д.

Некоторые надстройки реализованы для нескольких фреймворков, Onsen, например, или тот же KendoUI. Если клиент собирается разрабатывать мобильное приложение современным способом (то есть в виде HTML5 SPA / HybridApp), но пока не знает, будет ли он использовать React, Angular или Vue, то нужна одна из таких универсальных надстроек.

Итак, вот как теперь выглядит веб-проект или мобильное приложение:

бэкенд на любом языке программирования;
фронтенд, обычно состоящий из JS-фреймворка (React, Angular, Vue) и надстроек.

Вот пример, как KendoUI реализует работу с таблицей. Компонент Grid можно вставить в любой проект на React и получить сразу и фильтрацию, и сортировку, и экспорт в Excel и PDF, и всё что угодно. Использовать это можно «из коробки» в любом проекте с любым языком программирования на бэкенде, лишь бы на фронте был React.

Вот тут можно почитать про надстройки (GUI-библиотеки) подробнее: