Frontend‑разработка с AI‑инструментами: от нуля до собственных проектов

Старт: инструменты разработчика, Git, VS Code и настройка среды

В этом курсе вы будете учиться фронтенд‑разработке с опорой на AI‑инструменты, но фундамент остаётся классическим: рабочая среда, редактор, браузерные инструменты, контроль версий и базовые команды. Если эти вещи настроены правильно, дальше вы сможете быстро собирать проекты, уверенно экспериментировать и безопасно откатывать ошибки.

В этой статье вы:

Установите и проверите базовые инструменты (браузер, терминал, Node.js)

Настроите Git и GitHub‑workflow

Подготовите VS Code для фронтенд‑разработки

Узнаете, как встроить AI‑помощников в рабочий процесс без вредных привычек

Что нужно для фронтенда на старте

Минимальный набор:

Современный браузер (Chrome или Firefox)

Инструменты разработчика в браузере (DevTools)

Терминал (командная строка)

Node.js (чтобы ставить зависимости и запускать dev‑серверы)

Git (чтобы сохранять историю изменений)

Редактор кода (VS Code)

Аккаунт на GitHub (чтобы хранить код и делиться проектами)

Ссылки на официальные страницы:

Google Chrome

Firefox

Chrome DevTools (документация)

Node.js

Git

Visual Studio Code

GitHub

Браузерные DevTools: ваш главный «микроскоп»

DevTools помогают понять, что реально происходит на странице: какие стили применились, какие запросы ушли в сеть, какие ошибки в JavaScript.

Как открыть DevTools

Windows/Linux: F12 или Ctrl+Shift+I

macOS: Cmd+Option+I

Ключевые вкладки DevTools

Elements: HTML‑структура и CSS‑стили, поиск причин «почему не применился стиль»

Console: ошибки и логи JavaScript (часто это первое место, куда вы смотрите)

Network: загрузка файлов и запросы к API, статусы (200, 404, 500)

Sources: исходники, отладка с брейкпоинтами (остановка выполнения кода)

Application: storage (LocalStorage, cookies), кэш и состояние приложения

Практическая привычка: если «что-то не работает», сначала:

Откройте Console (есть ли ошибка)

Откройте Network (загрузился ли нужный файл/запрос)

Терминал: зачем он нужен фронтендеру

Терминал — это способ управлять проектом командами: создавать папки, запускать сборку, устанавливать пакеты, работать с Git.

Полезные команды, которые вы будете видеть постоянно:

cd — перейти в папку

ls (macOS/Linux) или dir (Windows) — показать список файлов

mkdir — создать папку

code . — открыть текущую папку в VS Code (после установки VS Code)

Node.js и npm: запуск проектов и установка зависимостей

Node.js — среда выполнения JavaScript вне браузера. Во фронтенде Node нужен не для «сайта на сервере», а чтобы:

ставить библиотеки через пакетный менеджер

запускать dev‑сервер

собирать проект (bundling)

Вместе с Node обычно ставится npm (пакетный менеджер).

Установка

Ставьте Node.js с официального сайта:

Node.js (скачать)

Обычно для новичков подходит версия LTS (долгосрочная поддержка).

Проверка установки

Откройте терминал и выполните:

Если команды выводят версии (например, v20.x.x), значит всё установлено.

Git: контроль версий, без которого проекты «ломаются навсегда»

Git — это система контроля версий: она сохраняет историю изменений в проекте.

Зачем это нужно:

можно откатить неудачное изменение

можно вести разработку по веткам (например, фича отдельно от стабильной версии)

можно работать в команде

можно хранить проект на GitHub

Официальный сайт:

Git (скачать)

Настройка Git (имя и email)

После установки задайте имя и email, которые будут видны в истории коммитов:

Проверить настройки можно так:

Основные понятия Git простыми словами

Репозиторий — папка проекта, где Git ведёт историю

Коммит — «снимок» изменений с сообщением (например, “Add header layout”)

Ветка — отдельная линия разработки (часто есть main как основная)

Working tree — текущие файлы на диске (то, что вы редактируете)

Staging area — «подготовка» изменений перед коммитом

Базовый Git‑цикл (то, что вы будете повторять постоянно)

Создаёте папку проекта и переходите в неё

Инициализируете Git

Редактируете файлы

Добавляете изменения в staging

Делаете коммит

Пример команд:

.gitignore: что нельзя коммитить

Некоторые файлы не стоит хранить в репозитории:

node_modules/ (зависимости можно восстановить через npm install)

.env (секреты, токены)

временные файлы и логи

Создайте файл .gitignore и добавьте туда, например:

Справочник шаблонов .gitignore:

gitignore (репозиторий GitHub)

GitHub: удалённый репозиторий и портфолио

GitHub — это сервис для хранения Git‑репозиториев в облаке. Вы будете использовать его, чтобы:

хранить код и делиться ссылкой

делать резервную копию

показывать проекты как портфолио

(позже) подключать CI и деплой

Полезные официальные материалы:

GitHub Docs

Минимальный workflow с GitHub

Создайте репозиторий на GitHub

Привяжите локальный проект к удалённому репозиторию

Отправьте коммиты командой git push

Команды обычно выглядят так:

Если вы не уверены, как правильно подключить удалённый репозиторий, GitHub показывает готовые инструкции на странице нового репозитория.

!Схема базового цикла: пишем код → коммитим → отправляем на GitHub → проверяем в браузере

VS Code: настройка редактора под фронтенд

VS Code — популярный редактор, удобный для HTML/CSS/JS и современных инструментов.

Visual Studio Code (скачать)

Обязательные возможности, которые стоит включить

Автосохранение или привычка часто сохранять (Ctrl+S / Cmd+S)

Встроенный терминал (меню Terminal → New Terminal)

Форматирование кода (через расширение Prettier)

Рекомендуемые расширения для старта

Поставьте 3–6 расширений и не перегружайте VS Code:

Prettier - Code formatter (форматирование)

ESLint (подсказки по качеству JS/TS)

Live Server (быстрый локальный сервер для простых HTML‑страниц)

GitLens (удобный просмотр истории и авторства строк)

Совет: если вы не понимаете, зачем расширение нужно — не ставьте его «на всякий случай».

Настройка форматирования (идея, не догма)

Частая конфигурация:

Prettier делает форматирование по сохранению

ESLint подсвечивает проблемные места

Если форматирование «ломает» код, не паникуйте: обычно это конфликт настроек ESLint/Prettier. В таком случае проще временно оставить только Prettier и вернуться к ESLint позже.

Папка проекта: базовая структура и порядок

Даже маленькие проекты лучше держать аккуратно:

один проект = одна папка

читаемое имя папки латиницей без пробелов (например, todo-app)

всегда есть README.md с описанием

Пример структуры на старте:

Позже структура изменится под фреймворки и сборщики — это нормально.

AI‑инструменты в настройке среды: как использовать правильно

AI‑инструменты (например, ChatGPT или IDE‑ассистенты) ускоряют работу, но важно использовать их как помощника, а не как «замену пониманию».

Что можно делегировать AI на этом этапе

объяснить ошибку из Console простыми словами

предложить список шагов по установке инструмента под вашу ОС

подсказать команду Git и объяснить, что она делает

сгенерировать черновик .gitignore и пояснить пункты

Что нельзя передавать AI

токены, пароли, содержимое .env

приватные ключи (id_rsa), данные платёжных карт

любые секреты компании/клиента

Пример полезного запроса к AI

Вот шаблон, который помогает получать понятные ответы:

> «Я на Windows/macOS/Linux. Установил Node.js и Git. При выполнении команды ... получаю ошибку .... Объясни причину простыми словами и дай пошаговый план исправления. Если есть несколько вариантов — сравни их по рискам.»

Чек‑лист готовности перед следующими темами

У вас должно получиться:

Открывать DevTools и находить ошибки в Console

Выполнять в терминале node -v и npm -v

Выполнять git init, git add, git commit

Иметь GitHub‑аккаунт и уметь отправить код в репозиторий

Открывать проект в VS Code и запускать встроенный терминал

Что дальше по курсу

После настройки среды вы перейдёте к базовым строительным блокам фронтенда:

HTML: структура страницы

CSS: стили и адаптивность

JavaScript: логика и взаимодействия

Мини‑проекты, где AI помогает быстрее находить ошибки и улучшать код, но решения вы понимаете и контролируете

HTML и CSS: структура, адаптивность, доступность и практика вёрстки

После настройки рабочей среды (браузерные DevTools, VS Code, Git, Node.js) вы готовы к первому настоящему навыку фронтенда: превращать идею или макет в страницу, которая корректно выглядит на разных экранах и остаётся удобной для людей с разными потребностями.

В этой статье вы разберёте:

как устроены HTML и CSS и почему их нельзя «мешать в одну кашу»

как делать смысловую структуру страницы, а не просто «набор блоков»

как верстать адаптивно без магии и хака на хаке

базовые принципы доступности (accessibility), чтобы интерфейс был usable для клавиатуры и скринридеров

практический мини-процесс: от структуры к стилям и проверкам в DevTools

Полезные справочники на весь курс:

MDN: HTML

MDN: CSS

MDN: Веб-доступность

WebAIM: Introduction to Web Accessibility

W3C: WCAG Overview

Как HTML и CSS работают вместе

HTML описывает структуру и смысл контента: что является заголовком, где основная часть, где навигация, где список, где форма.

CSS отвечает за визуальное оформление: отступы, цвета, шрифты, сетку, адаптивное поведение.

Правильная модель мышления:

HTML отвечает на вопрос что это такое

CSS отвечает на вопрос как это выглядит

Если вы сначала делаете смысловую структуру, а потом добавляете стили, то:

проще поддерживать проект

меньше багов с адаптивностью

легче улучшать доступность

AI-помощники дают более точные советы, потому что структура понятна

HTML: структура страницы без «дивного супа»

Вёрстка становится сложной, когда вы используете нейтральные контейнеры для всего подряд и теряете смысл. Вместо этого стремитесь к семантической структуре.

Семантика простыми словами

Семантика означает, что элементы в разметке отражают назначение контента. Например:

header — верхняя часть страницы или секции (обычно логотип, меню, важные действия)

nav — навигация

main — основное содержимое страницы (обычно одно на страницу)

section — крупная смысловая секция

article — самостоятельный материал, который можно читать отдельно

footer — нижняя часть страницы или секции

Семантика помогает:

скринридерам строить понятную «карту» страницы

поисковым системам лучше понимать структуру

вам самим быстрее ориентироваться в проекте

Каркас страницы как план

Ниже пример структурного плана страницы в псевдозаписи (это не код, а способ думать):

Если у вас есть такой план, CSS-сетка и адаптивность становятся значительно проще.

Заголовки и логика документа

Заголовки должны отражать структуру текста, а не просто быть «покрупнее».

Правило, которое спасает от хаоса:

один главный заголовок страницы — h1

дальше вложенность идёт по смыслу: h2 для секций, h3 для подразделов

Если хочется сделать текст крупнее, это задача CSS, а не неправильного уровня заголовка.

Списки, ссылки и кнопки: частые ошибки новичков

Быстрые ориентиры:

если это перечисление однотипных сущностей, используйте список (а не набор строк)

ссылка ведёт на другой адрес или якорь внутри страницы

кнопка запускает действие (открыть меню, отправить форму, удалить элемент)

Если путать ссылки и кнопки, страдает доступность и предсказуемость интерфейса.

CSS: базовые принципы, которые решают 80% проблем

Каскад и почему «стиль не применился»

CSS расшифровывается как Cascading Style Sheets, то есть «каскадные таблицы стилей». Каскад означает, что финальный стиль элемента получается как результат конкуренции правил.

Чаще всего стиль «не работает» по одной из причин:

правило перекрыто другим правилом, которое применяется позже

другое правило более специфично

вы стилизуете не тот элемент (ошибка в селекторе)

Привычка из прошлой статьи: при проблемах сначала смотрите Elements и Computed в DevTools.

Блочная модель (box model)

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

У элемента есть:

content — содержимое

padding — внутренние отступы

border — рамка

margin — внешние отступы

!Схема слоёв блочной модели CSS

Практический совет: почти всегда удобно включать вычисление размеров через box-sizing: border-box, чтобы ширина учитывала padding и border.

Поток документа и варианты раскладки

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

Flexbox — для выравнивания и распределения элементов в строке или колонке

Grid — для двумерной сетки (строки и колонки)

Мини-ориентир выбора:

если у вас одномерная задача (например, меню в одну линию) — Flexbox

если у вас сетка (например, карточки 3 на 2) — Grid

Пример простого Flexbox-выравнивания:

Пример сетки карточек на Grid:

Адаптивность: чтобы страница работала на телефоне и на широком экране

Адаптивность — это не «сделать отдельно мобильную версию», а настроить дизайн так, чтобы он естественно перестраивался.

Основные инструменты адаптивной верстки

гибкие размеры: проценты, rem, vw там, где это уместно

ограничения ширины контейнера через max-width

медиа-условия (media queries), когда нужен скачок в компоновке

современные функции вроде clamp() для плавных размеров (при желании)

Пример контейнера, который ограничивает ширину и центрируется:

Пример адаптации сетки карточек под узкие экраны:

!Как сетка карточек меняется на разных ширинах

Изображения: частый источник «вылезает за экран»

Базовое правило для картинок в контенте:

Так изображение не будет вылазить за контейнер и сохранит пропорции.

Проверка адаптивности в DevTools

В Chrome DevTools используйте режим эмуляции устройств (Device Toolbar). Проверяйте не только «красиво/некрасиво», но и:

не появляется ли горизонтальный скролл

не уезжают ли интерактивные элементы за экран

не становится ли текст слишком мелким

Доступность: чтобы интерфейс был удобен не только мышкой

Доступность (accessibility) — это практика, которая делает интерфейсы пригодными для:

клавиатурной навигации

скринридеров

пользователей с низким зрением или дальтонизмом

пользователей, которым неудобны сложные анимации

Важно: доступность не является «опцией». Это качество интерфейса, как скорость загрузки или отсутствие багов.

База доступности, которую нужно знать на старте

семантическая структура документа

корректный порядок заголовков

понятные названия элементов управления

видимый фокус при навигации клавиатурой

достаточная контрастность текста

Клавиатура и фокус

Проверка, которую должен уметь делать каждый:

откройте страницу

нажимайте Tab и Shift+Tab

убедитесь, что можно добраться до всех интерактивных элементов

убедитесь, что фокус виден

Если вы стилизуете фокус, делайте это безопасно:

Не стоит полностью отключать outline без замены: так вы «ломаете» управление с клавиатуры.

Подписи у полей формы и ошибки

У полей формы должны быть понятные подписи. Если пользователь ошибся, сообщение об ошибке должно:

объяснять, что именно не так

подсказывать, как исправить

быть заметным не только по цвету (например, ещё и текстом)

Осторожно с ARIA

ARIA-атрибуты помогают, когда семантики недостаточно, но на старте безопаснее придерживаться правила:

сначала семантический элемент

потом правильная структура

и только если это невозможно — ARIA

Справочник:

MDN: ARIA

Быстрая проверка доступности

В Chrome можно сделать базовый аудит через Lighthouse.

откройте DevTools

вкладка Lighthouse

запустите проверку (особенно Accessibility)

Документация:

Chrome DevTools: Lighthouse

Мини-практика: как верстать аккуратно и предсказуемо

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

Рабочий процесс вёрстки

Напишите структурный план страницы на бумаге или в комментариях в файле.

Соберите HTML-структуру семантическими элементами.

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

Подключите базовые стили:

- box-sizing: border-box - базовые шрифты - нормальные отступы для контейнера

Постройте раскладку (Flexbox/Grid).

Пройдитесь по адаптивности через Device Toolbar.

Пройдитесь по доступности: Tab, видимость фокуса, понятность кнопок и ссылок.

Сделайте коммит в Git с осмысленным сообщением.

Именование классов без боли

Можно использовать любой стиль, но новичкам удобно соблюдать три правила:

имя класса отвечает на вопрос что это за блок

имена без привязки к внешнему виду, если это возможно

единый стиль написания (например, через дефисы)

Примеры нейтральных имён:

site-header, main-nav, promo, cards, card, button

Плохой сигнал:

left-block, blue-text, big-button (такие названия ломаются при редизайне)

Как использовать AI-инструменты в HTML/CSS с пользой

AI помогает ускорить рутину, но вы должны оставаться тем, кто принимает решения.

Хорошие задачи для AI на этом этапе

превратить описание страницы в семантический план

предложить структуру классов и объяснить, почему так

найти причину, почему стиль не применяется (по описанию селектора и каскада)

предложить адаптивные правила для сетки и объяснить их

подсказать, на что обратить внимание по доступности (фокус, подписи, контраст)

Шаблоны запросов, которые работают

Семантика: «Опиши семантическую структуру для лендинга: шапка с меню, промо, блок преимуществ (6 карточек), отзывы, футер. Верни план в виде дерева элементов и коротко объясни выбор элементов.»

Адаптивность: «У меня сетка карточек 3 в ряд. На 900px хочу 2, на 600px — 1. Предложи CSS на Grid и объясни каждую строчку.»

Доступность: «Проверь интерфейс на базовую доступность: клавиатура, фокус, названия кнопок, контраст. Дай список конкретных правок и как их проверить в DevTools.»

Что AI лучше не доверять без проверки

«магические» наборы стилей без объяснений

советы отключить outline без альтернативы

универсальные медиа-правила без привязки к вашему контенту

Итоговый чек-лист перед следующей темой

У вас должно получиться:

отличать смысловую структуру от декоративной

сверстать простую страницу с header, main, footer, секциями и списками

собрать сетку на Flexbox или Grid

сделать базовую адаптацию через media queries

проверить Tab-навигацию и видимость фокуса

использовать DevTools для поиска причин «почему не так выглядит»

Дальше вы начнёте добавлять интерактивность на JavaScript, и качественная HTML/CSS-база станет вашим фундаментом: JS будет «навешиваться» на понятную структуру, а не пытаться спасать хаос.

JavaScript: основы языка, DOM, события, запросы и модули

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

JavaScript в браузере тесно связан с тем, что вы уже изучили:

HTML даёт элементы, с которыми вы взаимодействуете через DOM

CSS задаёт внешний вид, который вы можете переключать классами

DevTools помогают находить ошибки и проверять состояние

Git помогает безопасно экспериментировать и откатывать изменения

Официальные справочники, к которым вы будете возвращаться постоянно:

MDN: JavaScript

MDN: DOM

MDN: События

MDN: Fetch API

MDN: JavaScript modules

Как JavaScript работает в браузере

В браузере JavaScript выполняется движком (например, V8 в Chrome). Он:

читает и выполняет ваш код

даёт доступ к Web API (DOM, таймеры, сеть)

позволяет реагировать на события (клики, ввод, прокрутку)

Важно различать:

JavaScript как язык: переменные, функции, объекты, модули

Web API: DOM, fetch, события, localStorage

В DevTools это проявляется так:

вкладка Console показывает ошибки и результат console.log

вкладка Sources помогает отлаживать код пошагово

вкладка Network показывает запросы fetch

Основы языка: переменные, типы, выражения

Переменные: const и let

В современных проектах почти всегда достаточно двух ключевых слов:

const — значение нельзя переназначить

let — значение можно переназначить

Пример:

const не делает объект неизменяемым — он запрещает переназначение ссылки:

Типы данных, которые вы будете использовать каждый день

string — строки, например "Привет"

number — числа

boolean — true или false

null — намеренно пустое значение

undefined — значение ещё не задано

object — объекты, массивы, функции

Практическое правило:

если вам нужно хранить сущность с полями — используйте объект

если вам нужен упорядоченный список — используйте массив

Операторы и сравнения

В интерфейсах вы постоянно пишете условия. Для сравнения чаще всего используйте:

=== и !== вместо == и !=

Причина: === не делает скрытых преобразований типов и ведёт себя предсказуемо.

Пример:

Функции: основной строительный блок логики

Функция — это кусок кода, который можно вызывать много раз.

Два самых частых варианта записи:

В фронтенде функции особенно важны для:

обработчиков событий

преобразования данных для отображения

разбиения кода на небольшие понятные части

Чистая функция и функция с побочным эффектом

Полезное различие для UI-кода:

чистая функция возвращает результат и не трогает внешний мир

функция с побочным эффектом меняет DOM, делает запросы, пишет в хранилище

Хорошая привычка: где возможно, отделяйте преобразование данных от изменения DOM.

Объекты и массивы: работа с данными

Объекты

Объект хранит поля по ключам:

Массивы

Массив хранит упорядоченные элементы:

Методы, которые особенно полезны для интерфейсов:

map — превратить список в другой список

filter — отфильтровать список

find — найти один элемент

some и every — проверить условие

Пример фильтрации:

DOM: мост между HTML и JavaScript

DOM — это представление HTML-страницы в виде дерева объектов, с которым работает JavaScript.

!Дерево DOM помогает понять поиск элементов и вложенность

Поиск элементов на странице

Основные методы:

document.querySelector(cssSelector) — первый подходящий элемент

document.querySelectorAll(cssSelector) — список всех подходящих

Пример:

Если querySelector вернул null, значит элемента нет в DOM на момент выполнения кода. Это частая причина ошибок вида Cannot read properties of null.

Практические причины такого бага:

неправильный селектор

скрипт выполняется раньше, чем браузер построил DOM

элемента действительно нет на этой странице

Чтение и изменение текста

Чаще используйте textContent, потому что он работает именно с текстом и безопаснее для новичка.

Классы и стили: связываем JS с CSS

Самая удобная практика — управлять внешним видом через CSS-классы:

Это связывает тему JavaScript с предыдущей статьёй про CSS: вы проектируете классы как переключатели состояния.

Создание элементов и вставка в документ

Частый сценарий: отрисовать список на основе данных.

Если вы строите много элементов циклом, следите за читаемостью: лучше вынести создание элемента в отдельную функцию.

События: как страница реагирует на пользователя

Событие — это сигнал от браузера: клик, ввод, отправка формы, загрузка страницы.

Основной инструмент — addEventListener:

Справочник:

MDN: EventTarget.addEventListener

Объект события

Обработчик получает объект события (часто его называют event или e). В нём есть полезные поля:

event.target — где событие возникло

event.currentTarget — на каком элементе висит обработчик

Пример:

Предотвращение стандартного поведения

Например, форма по умолчанию перезагружает страницу. В SPA-подходе это часто не нужно.

Делегирование событий

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

Плюсы:

меньше обработчиков

работает для элементов, добавленных позже

Пример:

Здесь closest ищет ближайший родительский элемент с нужным селектором.

Запросы к API: fetch, JSON, ошибки

Интерфейсы почти всегда работают с данными. В браузере для HTTP-запросов часто используют fetch.

Справочник:

MDN: fetch

Базовый запрос и преобразование JSON

Что здесь происходит:

fetch(...) отправляет запрос и возвращает Promise

await ждёт результат

response.json() читает тело ответа и парсит JSON

Проверка статуса ответа

Важно: fetch не считает HTTP-ошибки (например, 404 или 500) исключением. Запрос может успешно завершиться на уровне сети, но сервер вернёт ошибку.

Надёжный шаблон:

Полезные источники истины при отладке:

вкладка Network в DevTools

console.log(response.status, response.statusText)

!Помогает связать сеть, обработку ошибок и обновление интерфейса

Обработка ошибок через try/catch

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

Модули: как перестать держать весь код в одном файле

Когда проект растёт, один файл main.js превращается в хаос. Модули позволяют:

разбивать код на файлы по смыслу

явно описывать зависимости

переиспользовать функции

Справочник:

MDN: JavaScript modules

Экспорт и импорт

Пример: файл math.js:

Файл main.js:

Важные детали:

путь ./math.js обычно должен включать расширение .js

имя импортируемых сущностей должно совпадать с тем, что экспортируется (если это не default)

default-экспорт

Иногда удобно экспортировать главное значение по умолчанию.

Файл api.js:

Файл main.js:

!Показывает как разделять код по ответственности

Как запускать модули локально

Браузеру нужно загрузить файлы модулей по HTTP, поэтому открывать файл двойным кликом часто недостаточно.

Практические варианты:

использовать расширение Live Server в VS Code

использовать любой простой dev-сервер из Node.js инструментов (вы познакомились с Node и npm в первой статье)

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

Мини-процесс разработки: соединяем всё вместе

Когда вы делаете интерактивную страницу, полезно работать одинаковыми шагами:

Продумать HTML-структуру и состояния (например, пустой список, загрузка, ошибка).

Описать CSS-классы, которые будут переключаться (например, is-loading, has-error).

Написать JS:

- найти нужные элементы через querySelector - навесить события через addEventListener - при необходимости загрузить данные через fetch - обновить DOM через textContent, classList, append

Проверить DevTools:

- Console: ошибки и логи - Network: запросы и ответы

Сделать маленький коммит в Git с понятным сообщением.

Как использовать AI-инструменты при изучении JavaScript

AI хорошо помогает, если вы задаёте вопросы так, чтобы сохранить контроль над кодом.

Хорошие задачи для AI

объяснить ошибку из Console простыми словами и предложить план проверки

предложить более читаемую структуру функций и модулей

подсказать, как сделать делегирование событий для списка

подсказать, какие проверки добавить к fetch (статус, try/catch)

Шаблоны запросов

DOM и селекторы: «У меня document.querySelector("...") возвращает null. Вот HTML-фрагмент и селектор. Найди причину и предложи 2 исправления, объяснив разницу.»

События: «Я навесил обработчик на .list, но клики по кнопке внутри не работают как ожидаю. Объясни разницу target и currentTarget, предложи делегирование.»

fetch: «Запрос возвращает 404, но catch не срабатывает. Объясни почему и покажи шаблон обработки через response.ok.»

модули: «Разбей этот main.js на модули: api, render, state, events. Верни структуру файлов и кратко объясни ответственность каждого.»

Красные флаги

AI предлагает отключить важные проверки (например, не проверять response.ok)

AI даёт код без объяснений, и вы не понимаете, где у него входы/выходы

AI предлагает небезопасные вставки текста в DOM без объяснения рисков

Итог

После этой темы вы должны уметь:

писать базовый JavaScript с const, let, функциями, массивами и объектами

находить элементы в DOM и обновлять интерфейс

обрабатывать события, включая делегирование и preventDefault

делать запросы через fetch, читать JSON и обрабатывать ошибки

разделять код на модули с export и import

Это база, на которой дальше строятся любые проекты: от маленьких виджетов до приложений на фреймворках. В следующих шагах курса вы будете всё чаще упираться не в «синтаксис», а в архитектуру, состояние и качество пользовательского опыта — и тут сильная база DOM, событий и запросов решает почти всё.

Современный фронтенд: React, компоненты, роутинг, состояние, формы

После статей про HTML/CSS и JavaScript у вас уже есть фундамент: вы понимаете структуру страницы, стили, DOM, события, fetch, модули и отладку в DevTools. Теперь логичный шаг — перейти к компонентному подходу, который используют современные интерфейсы.

React — популярная библиотека для построения UI из компонентов. Она помогает держать код в порядке, переиспользовать части интерфейса и предсказуемо управлять состоянием.

В этой статье вы разберёте:

что такое компоненты и как мыслить деревом UI

props и state: откуда берутся данные и как UI обновляется

хуки useState и useEffect на практике

базовый роутинг в SPA через React Router

формы: controlled components, валидация, ошибки и доступность

как подключать API-запросы и где хранить состояние

как использовать AI-инструменты в React так, чтобы не потерять понимание

Полезные официальные источники:

React Documentation

Vite

React Router

MDN: Working with forms

MDN: Fetch API

Что меняется по сравнению с чистым JS и DOM

В предыдущей статье вы напрямую искали элементы через querySelector, навешивали события и руками обновляли DOM.

В React модель другая:

вы описываете как должен выглядеть UI для текущих данных

React сам обновляет DOM, когда данные меняются

UI строится из компонентов, которые можно переиспользовать

Ключевая привычка: вместо вопроса какие элементы поменять в DOM? вы чаще задаёте вопрос какие данные изменились и как из них получается UI?

!Поток данных: данные формируют UI, события обновляют данные

Быстрый старт проекта на React через Vite

Vite — современный инструмент разработки, который быстро запускает dev-сервер и удобен для обучения.

Команды:

Что вы получите:

локальный dev-сервер

сборку для продакшена

поддержку модулей и современного JS

Связь с первой статьёй курса:

Git используйте с самого начала (маленькие коммиты)

ошибки и логи смотрите в DevTools Console

сетевые запросы проверяйте во вкладке Network

Компоненты: UI как конструктор

Компонент — это функция, которая возвращает разметку интерфейса (в React это обычно JSX). JSX похож на HTML, но это синтаксис для описания UI в JavaScript.

Пример простого компонента:

Главная идея: вы собираете приложение как дерево компонентов.

!Дерево компонентов помогает декомпозировать интерфейс

Правила хорошей декомпозиции

компонент отвечает за одну понятную часть UI

компонент можно переиспользовать без копипаста

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

Props: данные входят в компонент

Props — это входные данные компонента, как аргументы функции.

Пример карточки товара:

Использование:

Практическое правило:

props не нужно изменять внутри компонента

если нужно изменить данные — это обычно означает, что нужно состояние (state) и обработчики событий

State: данные живут в компоненте и меняются со временем

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

Самый важный хук для старта — useState.

Пример счётчика:

Что здесь происходит:

count — текущее значение состояния

setCount — функция, которая обновляет состояние

после обновления состояния React перерисует нужную часть UI

Где хранить состояние

Практическая стратегия:

состояние храните как можно ближе к месту использования

если нескольким компонентам нужны одни и те же данные, поднимайте состояние выше в общего родителя

Списки и ключи: рендер массива данных

Списки — частый случай (задачи, товары, сообщения). Вы обычно делаете map.

Почему нужен key:

React использует key, чтобы понимать, какой элемент списка какой, и обновлять список эффективно

лучше всего подходит стабильный id, а не индекс массива

Эффекты: загрузка данных и синхронизация с внешним миром

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

Пример загрузки пользователей:

Заметьте связь с прошлой статьёй про fetch:

мы проверяем response.ok

мы обрабатываем ошибки

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

Роутинг: несколько страниц без перезагрузки

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

Один из стандартов для React — React Router.

Базовая установка:

Минимальная настройка роутов:

Важно:

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

Routes выбирает нужный маршрут

Route связывает path и компонент element

!Как URL выбирает компонент страницы в SPA

Состояние приложения: локальное, поднятое и общее

В реальных приложениях состояние бывает разных уровней.

Локальное состояние компонента: например, открыто ли выпадающее меню

Поднятое состояние: родитель хранит данные, дети получают через props

Глобальное состояние: данные нужны многим частям приложения (например, текущий пользователь, тема)

Рекомендация для обучения и первых проектов:

начните с локального и поднятого состояния

глобальное подключайте только когда боль действительно появилась

Типичные причины, что пора думать о глобальном состоянии:

вы прокидываете props через 3–5 уровней компонентов

одно и то же состояние нужно одновременно хедеру, сайдбару и нескольким страницам

На практике часто используют:

Context API (встроено в React)

внешние библиотеки (например, Redux), но это лучше оставлять на следующий этап после уверенного React-базиса

Формы в React: controlled components

Формы — одна из самых частых частей UI. В React стандартный подход — контролируемые поля: значение хранится в состоянии, а поле отображает это значение.

Пример формы логина:

Что важно понимать:

value берётся из состояния

onChange обновляет состояние

onSubmit делает preventDefault, как вы уже видели в теме про события

Ошибки и валидация

Простая и практичная стратегия:

валидируйте при отправке

выводите понятную текстовую ошибку

не делайте интерфейс, где ошибка обозначена только цветом

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

Доступность форм

Базовые правила, которые стоит соблюдать всегда:

у каждого поля должна быть подпись

пользователь должен видеть фокус при навигации клавиатурой

сообщения об ошибках должны быть понятными текстом

Связь со статьёй про доступность в HTML/CSS:

используйте семантику и логичную структуру

проверяйте Tab-навигацию

не выключайте фокус без замены

Организация кода: структура папок и ответственность

Когда проект на React растёт, структура становится критически важной.

Один из простых вариантов для небольших приложений:

src/pages — компоненты страниц (роуты)

src/components — переиспользуемые UI-компоненты

src/api — функции запросов

src/utils — утилиты (чистые функции)

src/styles — общие стили

Ключевой принцип из предыдущей темы про модули:

отделяйте чистые функции от кода, который меняет UI или ходит в сеть

Как использовать AI-инструменты в React без потери навыка

AI особенно полезен в React, потому что много шаблонного кода и типовых ошибок. Но важно, чтобы вы контролировали архитектуру.

Хорошие сценарии для AI:

преобразовать описание макета в список компонентов и предложить границы ответственности

объяснить, почему компонент перерисовывается слишком часто, и предложить план проверки

помочь разложить большой компонент на 3–5 маленьких

подсказать, как оформить загрузку/ошибку/пустое состояние

объяснить ошибку хуков (например, почему useEffect запускается не так)

Шаблоны запросов, которые дают качественные ответы:

Декомпозиция: «Вот описание экрана и требования. Предложи дерево компонентов (pages/components), какие props нужны, где хранить state, и почему так.»

useEffect и данные: «У меня useEffect делает fetch. Иногда два запроса подряд. Объясни возможные причины и как проверить в DevTools и коде.»

Формы: «Сделай controlled form с валидацией. Объясни, где хранить ошибки и как показывать сообщения без нарушения доступности.»

Красные флаги:

AI даёт код, где смешаны запросы, рендер и бизнес-логика в одном месте без объяснения

AI предлагает хранить всё состояние глобально без причин

AI советует отключать правила или проверки, не объясняя риски

Итог

Теперь у вас появляется полный цикл современного фронтенда поверх базы HTML/CSS/JS:

UI строится из компонентов

данные приходят через props и живут в state

события меняют состояние, а React обновляет UI

данные с сервера загружаются через fetch и управляются через состояния загрузки и ошибки

роутинг даёт «страницы» без перезагрузки

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

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

AI в разработке и выпуск проектов: промптинг, автогенерация, тесты, деплой

Вы уже прошли базу: настроили среду и Git, научились верстать HTML/CSS, писать JavaScript с DOM и запросами, а затем перешли к React (компоненты, состояние, роутинг, формы). Теперь пора собрать всё в производственный процесс: как использовать AI-инструменты так, чтобы быстрее выпускать проекты, не теряя контроля над качеством.

Эта статья про практику: грамотный промптинг, автогенерацию типовых частей, тестирование, CI и деплой. Цель не в том, чтобы AI писал за вас, а в том, чтобы вы строили понятный процесс, где AI ускоряет рутину.

Полезные официальные источники:

React Documentation

Vite

ESLint

Prettier

Vitest

React Testing Library

Playwright

GitHub Actions documentation

GitHub Pages

Netlify Docs

Vercel Docs

Роль AI в фронтенд-проекте: ускоритель, а не автопилот

В предыдущих темах вы уже использовали DevTools, понимали ошибки в Console/Network и работали с Git. Это важно, потому что лучший способ применять AI в разработке выглядит так:

вы формулируете задачу и критерии готовности

AI предлагает черновик решения

вы проверяете, запускаете, тестируете, улучшаете

вы коммитите маленькими шагами

Если пропустить проверку и просто копировать код, вы получаете типовые проблемы:

код работает “на одном кейсе”, но ломается в краях

снижается качество доступности (фокус, подписи, семантика)

ошибки в сети не обработаны

появляются уязвимости: небезопасная вставка в DOM или утечки секретов

!Диаграмма показывает, где AI ускоряет работу, а где обязательно нужны проверки и тесты

Промптинг для разработки: как получать полезные ответы

Промптинг в разработке отличается от “напиши мне приложение”: вам нужно получать решения, которые встраиваются в ваш проект и учитывают ограничения.

Контекст, который AI почти всегда нужен

Чтобы AI дал применимый ответ, обычно достаточно:

стек и среда: React + Vite, язык, менеджер пакетов

структура проекта: какие папки есть, где что лежит

требования: поведение, состояния (loading/error/empty), доступность

ограничения: без новых библиотек или наоборот “можно подключить X”

фрагменты кода: текущий компонент, хук, роут, тест

ошибка: текст из Console/Network и шаги воспроизведения

Шаблон промпта, который работает для кода

> “Я делаю проект на React + Vite. Нужен компонент/хук/тест с такими-то требованиями. Вот текущий код и структура. Дай решение и объясни, почему так. Предложи минимальный вариант и улучшенный вариант. Добавь шаги проверки через DevTools и тесты.”

Примеры промптов по типовым задачам

Декомпозиция UI: “Вот макет словами: шапка, фильтры, список карточек, пагинация, модалка. Предложи дерево компонентов, где хранить state, какие props нужны, и какие состояния UI должны быть.”

Ошибки запроса: “fetch получает 500. Вот Network-лог и мой код. Где добавить response.ok, как показать ошибку пользователю, и как протестировать этот сценарий?”

Доступность формы: “Есть форма регистрации. Проверь разметку и предложи правки для доступности: label, сообщения об ошибках, фокус, aria только если нужно.”

Красные флаги в ответах AI

Если вы видите такое, делайте паузу и проверяйте:

“просто отключите правило ESLint/TypeScript” без объяснения

“используйте dangerouslySetInnerHTML” без строгой причины и без санитизации

“положите токен прямо в код” или “вставьте ключ API в репозиторий”

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

Автогенерация: что можно ускорять безопасно

Автогенерация полезна там, где много шаблона, а риск ошибок низкий.

Что обычно хорошо генерируется

каркас компонента и базовая верстка

типовые состояния UI: загрузка, ошибка, пусто

стилизация под вашу структуру классов

функции работы с API (обертки над fetch) с проверкой response.ok

тестовые заготовки: arrange/act/assert, моки

документация в README.md: как запустить, как собрать, как задеплоить

Что лучше генерировать осторожно

сложная бизнес-логика и правила валидации

архитектурные решения “с нуля”: state management, кэш, сложные формы

безопасность: любая работа с HTML-строками и вводом пользователя

Мини-правило качества

Если AI сгенерировал код, вы должны уметь ответить на три вопроса:

где входные данные

где выход (что возвращает/что рендерит/что меняет)

как проверить это вручную и тестом

AI для рефакторинга: как улучшать код без поломок

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

Практичный подход “рефакторинг в безопасных границах”

сначала добавьте тест или хотя бы зафиксируйте поведение ручной проверкой

просите AI сделать маленький рефакторинг

запускайте линтер, тесты, проверяйте сценарии

делайте отдельный коммит на каждое улучшение

Пример промпта на рефакторинг

> “Вот компонент на 200 строк. Раздели на 3 компонента: Filters, List, EmptyState. Сохрани поведение. Не добавляй библиотек. Предложи структуру файлов, покажи итоговый код и список проверок.”

Тесты: что и зачем тестировать во фронтенде

Тесты нужны не “для галочки”, а чтобы выпускать изменения без страха.

Уровни тестирования

Unit: тестируют чистые функции и утилиты

Integration: тестируют взаимодействие компонентов, состояние, события

E2E: тестируют приложение как пользователь в браузере

Практическая стратегия для учебных и портфолио-проектов:

покрыть unit-тестами утилиты (форматирование, фильтрация)

покрыть integration-тестами ключевые компоненты (форма, список, загрузка)

добавить 1–3 E2E-сценария (логин-форма, добавление задачи, фильтр)

Инструменты, которые хорошо сочетаются с Vite + React

Vitest для unit/integration

React Testing Library для тестирования UI через поведение пользователя

Playwright для E2E

Пример: unit-тест чистой функции на Vitest

src/utils/filterTasks.js:

src/utils/filterTasks.test.js:

Почему это хороший старт:

функция чистая: легко тестировать

тесты быстрые

рефакторинг безопаснее

Пример: integration-тест компонента с React Testing Library

Идея: тестируйте не “внутренности”, а поведение: пользователь вводит, кликает, видит результат.

AI можно просить:

придумать сценарии тестов по требованиям

подсказать правильные селекторы getByRole для доступности

показать, как мокать fetch для сценариев “ошибка/успех”

Качество перед релизом: линтинг, форматирование, сборка

Перед деплоем вы хотите гарантировать три вещи:

код форматирован одинаково

типовые ошибки ловятся автоматически

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

Минимальный набор проверок

Prettier: единый стиль форматирования

ESLint: ошибки и плохие практики

тесты: хотя бы базовый набор

npm run build: проверка продакшн-сборки

Как просить AI помочь с настройкой

Промпт, который снижает риск “сломанной конфигурации”:

> “Проект React + Vite. Дай минимальную конфигурацию ESLint + Prettier, чтобы они не конфликтовали. Покажи необходимые команды установки, пример конфигов и команды в package.json. Объясни, как проверить, что всё работает.”

Важно: если AI предлагает много плагинов сразу, просите урезать до минимума и добавляйте по одному.

CI: автоматическая проверка на каждом пуше

CI (continuous integration) — это когда GitHub (или другой сервис) автоматически запускает проверки на каждый push и pull request.

Что обычно полезно включить для фронтенда:

установка зависимостей

линт

тесты

сборка

Пример workflow для GitHub Actions

Файл .github/workflows/ci.yml:

Как AI может помочь здесь безопасно:

объяснить каждую строку workflow

адаптировать node-версию под ваш проект

подсказать, почему падает npm ci или npm run build

Деплой: как сделать проект доступным по ссылке

Деплой — это публикация результата сборки (dist) на хостинг.

Для портфолио-проектов чаще всего выбирают:

Vercel: удобно для SPA и React, быстрый старт

Netlify: удобно для статических сайтов и SPA

GitHub Pages: бесплатная публикация статического сайта из репозитория

Что важно понять про SPA-роутинг

Если у вас React Router и маршруты вида /about, то на статическом хостинге при обновлении страницы может быть 404, потому что сервер ищет файл /about.

Решение зависит от платформы:

Netlify: правило redirect на index.html

Vercel: корректная настройка для SPA по умолчанию часто уже подходит

GitHub Pages: иногда удобнее использовать HashRouter, или настраивать поведение под конкретный способ деплоя

AI удобно просить:

“Какой вариант роутинга проще для GitHub Pages и почему?”

“Как настроить редиректы для SPA на Netlify?”

Деплой на Vercel или Netlify

Общий подход:

запушьте проект на GitHub

подключите репозиторий в Vercel/Netlify

убедитесь, что команда сборки npm run build, а папка публикации dist

Плюс:

деплой на каждый push

превью-ссылки для pull request

Деплой на GitHub Pages

GitHub Pages удобен для простых демонстраций.

Важно помнить:

Pages публикует статические файлы

базовый путь может быть не /, а /<repo-name>/

С AI стоит работать так:

попросить точную настройку под ваш репозиторий и базовый путь

проверить результат вручную в браузере

Безопасность и этика: что нельзя делать при помощи AI

AI-инструменты легко превращаются в источник утечек, если не соблюдать правила.

Нельзя отправлять в AI:

токены, ключи, содержимое .env

приватные репозитории и закрытый код компании без разрешения

данные пользователей

Про лицензии и копирование:

если AI генерирует код, он может быть похож на известные фрагменты

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

Практика для портфолио:

добавляйте в README.md, какие технологии использованы

фиксируйте источники дизайна/иконок/шрифтов, если вы их брали

Итог: минимальный “релизный” чек-лист

Перед тем как считать проект готовым и отправлять ссылку в портфолио:

UI работает в основных сценариях: загрузка, ошибка, пустое состояние

нет критичных ошибок в Console

сетевые ошибки обработаны, пользователь видит понятные сообщения

доступность: Tab проходит по интерактивным элементам, фокус виден

линтер и тесты проходят

сборка проходит (npm run build)

проект задеплоен и открывается по публичной ссылке

Когда вы строите такой процесс, AI становится настоящим ускорителем: он помогает писать быстрее, но качество обеспечивается вашим процессом проверки, тестами и дисциплиной коммитов.