Где заканчивается верстка и начинается frontend-разработка?

Когда начинающий разработчик получает готовый макет сайта, кажется, что основная задача – лишь правильно сверстать страницы. Но как только сайт становится интерактивным, появляются новые вопросы: откуда взять данные, как обработать действия пользователя и как связать разные части приложения между собой? Именно здесь появляются задачи, которые уже нельзя решить только с помощью HTML и CSS.

Верстка как отправная точка, а не вся frontend-разработка

Сначала разберемся, что вообще называют версткой. Если дизайнер подготовил макет сайта, разработчику нужно превратить его в страницу, которую пользователь сможет открыть в браузере. Он создает структуру страницы, размещает элементы, настраивает их внешний вид и адаптирует интерфейс под разные размеры экрана. Это и есть основная задача верстки: передать внешний вид и структуру готового макета в браузере. Здесь используются HTML и CSS, HTML отвечает за структуру страницы, а CSS – за ее внешний вид.

Но готовый макет показывает только то, как страница должна выглядеть. Он не объясняет, что произойдет после нажатия на кнопку, откуда появятся товары в каталоге или что увидит пользователь, если данные не загрузятся.

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

JavaScript как основа интерактивности

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

Для этого во frontend-разработке используется JavaScript. С его помощью можно реализовать:

• открытие и закрытие модальных окон
• переключение вкладок
• проверку введенных значений
• отправку формизменение содержимого страницы

Одно действие пользователя может запускать сразу несколько изменений. Например, после выбора фильтра нужно изменить список товаров, а при отправке формы – проверить введенные данные и показать результат.

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

В небольшом учебном проекте такие данные можно заранее прописать в коде. Но что делать, если эти данные должны меняться без изменений в коде? Здесь frontend начинает взаимодействовать с сервером.

Работа с данными и сервером

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

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

Клиентская часть приложения (frontend) отправляет серверу запрос и получает от него ответ. К примеру, так можно получить список товаров, отправить данные формы или узнать информацию о пользователе. Для такого взаимодействия frontend использует API – интерфейс, через который приложение может отправлять запросы серверу и получать от него данные.

Вот что нужно понимать любому frontend-разработчику:

• как frontend отправляет запросы
• какие данные приходят с сервера в ответ на запрос
• что такое HTTP и JSON
• что происходит, если при запросе возникает ошибка

При этом сервер не всегда отвечает сразу и не каждый запрос заканчивается успешно. Нужно продумать, что увидит пользователь во время загрузки и что произойдет, если сервер вернет ошибку или вообще не ответит. Например, вместо списка товаров он увидит сообщение «Не удалось загрузить данные» и кнопку «Попробовать снова».

Работа с данными – это уже не только их отображение на странице. Frontend-разработчику нужно понимать, откуда данные приходят, как они попадают в приложение и что происходит с ними после получения. Но данные недостаточно просто получить – их нужно хранить где-то внутри приложения и следить за тем, как они меняются.

Состояние приложения

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

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

Состояние может хранить разные данные:

• выбранные пользователем фильтры
• товары в корзине
• введенный текст в поисковой строке
• информацию об авторизации
• выбранный способ доставки

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

Архитектура и организация кода

Чем больше в приложении состояний и логики, тем сложнее становится код. Рано или поздно возникает вопрос: как все это организовать? Когда проект небольшой, его код может казаться простым и понятным. Если у нас есть всего несколько страниц, немного JavaScript-кода, то достаточно легко найти нужный файл или разобраться, какая часть кода за что отвечает.

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

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

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

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

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

Git, зависимости, сборка и окружение

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

Для хранения истории изменений и совместной работы используют Git. С его помощью разработчики могут сохранять разные версии проекта, видеть изменения и объединять свою работу.

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

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

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

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

Где же проходит эта граница на практике

Теперь посмотрим на весь процесс целиком на примере интернет-магазина.

В начале у разработчика есть только макет. Его нужно превратить в страницу в браузере: создать структуру, разместить элементы, настроить стили и адаптировать интерфейс под разные размеры экрана. На этом этапе основную роль играет верстка.

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

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

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

Так страница постепенно перестает быть просто сверстанным макетом. Чем больше поведения, данных и связей появляется у страницы, тем больше frontend-разработчик работает уже не только с ее внешним видом.

Заключение

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

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

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

Автор статьи: Кирилл Потягин, выпускник курса «Frontend-разработчик».