Не стоит недооценивать HTML

«HTML – это просто», «Разрабатывать фронтенд проще, чем бэкенд», «После реализации бэкенда обновление UI не должно составлять труда», – за время работы в сфере веб-разработки вокруг меня то и дело звучали эти и другие аналогичные утверждения.

И очень часто они вызывали у меня грусть.

Дело в том, что бо́льшую часть времени я проводила за написанием фронтенда, включая работу с HTML, CSS и JavaScript (по факту в основном TypeScript). Когда кто-нибудь говорит мне о «простоте» моей работы, я начинаю думать, что мои навыки не представляют высокой ценности, и меня может легко заменить любой разработчик…

В статье же я решила описать свои размышления, которые рождались в течение последних двух лет во время работы с людьми из разных команд с разным опытом в HTML-разработке и фронтенд-технологиях в целом. Здесь я озвучу несколько основных своих вопросов «Почему?», сопроводив их возможными ответами.

▍ Почему люди думают, что HTML – это просто?

А что вообще значит «просто»? Простота какого-либо предмета обычно определяется относительно того, кто его рассматривает. Когда я хорошо знаю некую технологию или язык программирования, для меня этот предмет оказывается проще, чем для новичка.

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

• Синтаксис HTML нетрудно выучить. Совмещаем угловые скобки, имена тегов и пары ключ-значение (атрибуты) и готово!
• Синтаксис HTML читабелен как для человек, так и для машины, что является одной из основных идей XML-подобных языков.
• После написания нескольких строк кода в файле .html можно сразу же без компиляции просмотреть результат, открыв его в браузере.
• В HTML низкий порог входа. В некоторых WYSIWYG-редакторах есть опция переключения представления на «код», где можно переделать HTML-версию текста, даже не особо разбираясь в процессе (вам доступно превью, что тут может пойти не так?)
• Браузеры – это прекрасный инструмент, который прощает вам множество ошибок (Дж. Дэвид Айзенберг описывал это в своей старой статье, приводя размышления, которые актуальны по сей день). При открытии HTML-страницы с синтаксическими ошибками браузер всё равно что-то да отрисует. Забыли закрыть тег? Не проблема. Добавили неизвестный тег или атрибут? Браузер его просто проигнорирует. В сравнении с языком, в котором из-за упущенной точки с запятой падает вся программа, такое положение дел действительно воспринимается «простым».

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

▍ Почему люди считают, что фронтенд-разработка – это легко?

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

Стараясь понять «Почему» они так думают, я пришла к такому заключению:

Пользователи и стейкхолдеры проекта зачастую не сталкиваются с бизнас-логикой бэкенда и работают только с UI. Обдумывать размещение разных кнопок, элементов информации или общую работу UI проще, потому что она более осязаема в сравнении со сложными запросами к базам данных или вложенными циклами for и инструкциями if. Бэкенд – это чёрный ящик, который проделывает свою магию и просто выдаёт данные во фронтенд. Фронтенд-разработчику в итоге «просто» нужно отобразить эти данные, добавить цвета и выстроить макет (с помощью CSS), доведя тем самым работу до конца.

К счастью, в этом процессе нам доступно множество библиотек клиентских компонентов. Вам достаточно совместить несколько (готовых) представлений, внести в них данные, и даже не придётся думать о цветах и макетах – разве это не круто? При такой всесторонней помощи почти любой может создавать прекрасные фронтенд-решения, не обладая особым знанием HTML/CSS!

</sarcasm>

▍ Фронтенд руками «не-фронтенд» разработчиков

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

Гейдон описал эту тему в статье «Reluctant Gatekeeping: The Problem With Full Stack»:

[...] если вы возложите все эти и прочие задачи на кого-либо [...], он наверняка окажется значительно слабее в определённых сферах, чем другие. [...] На моём опыте мужчины чаще проявляют себя в знании JavaScript или Python, но не CSS. CSS, который придаёт всему «красоту», считается женским уделом.

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

Почему некорректный HTML-код является проблемой?

Первые проблемы могут начать проявляться после развёртывания кода в продакшене. С ними столкнутся не участвовавшие в разработке пользователи, когда начнут взаимодействовать с продуктом. Некоторые из этих проблем могут стать следствием ошибок в HTML-коде.

▍ Неудобства для пользователя

Разберём проблемы, вызванные некорректным HTML-кодом, с которыми может столкнуться пользователь:

• Неудобные формы (у меня есть отдельная статья с примерами на тему проблем при использовании форм).
• Низкая производительность (на YouTube есть интересный сюжет под названием «Get your ‘head’ straight», в котором Гарри Робертс рассказывает о возможных проблемах в «шапке» HTML-документа.
• Неправильное использование заголовков (h1-h6) или отсутствующие текстовые альтернативы для нетекстового содержимого, что доставляет неудобства тем, кто использует скринридер.
• Неправильное использование или неиспользование интерактивных элементов («Div – это не кнопка!») либо не интуитивный порядок табуляции между ними, что усложняет навигацию и взаимодействие с помощью клавиатуры.
• В принципе всё, что описано на htmlhell.dev.
• Некорректный HTML-код ведёт к некорректной работе JavaScript, а значит, и нерабочей функциональности.

▍ Неудобства для разработчика

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

• …когда HTML-код плохо структурирован, становится труднее писать для него CSS. Иными словами, после подключения к процессу разработки CSS, код HTML зачастую нужно корректировать. Когда у вас есть опыт работы с обоими этими языками, то, скорее всего, ваш HTML- и CSS-код получится удачным и удобным в обслуживании.
• …если HTML-код UI-компонентов вашего проекта окажется недостаточно гибок, то при добавлении новой функциональности вы можете оказаться лишены возможности переиспользовать их или масштабировать проект в принципе, не прибегая к рефакторингу.
• …когда разработчики не работают с платформой, а пытаются заново изобрести колесо, не принимая во внимание возможности браузеров (например, реализуя переход между страницами не с помощью ссылки, а через JavaScript), повышается вероятность возникновения багов, исправить которые без нарушения работы остальной части приложения оказывается сложнее.

▍ Почему это важно?

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

Но я уверена, что мы способны на большее.

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

▍ Дело не только в написании HTML

Я встречала людей, которые начинали свой путь веб-разработки, с головой погружаясь в освоение новейших фреймворков, после чего создавали простой сайт с помощью Angular, пренебрегая изучением основ. Проблема здесь в том, что при отсутствии базовых знаний HTML (CSS или JS) большинство известных фреймворков не помогут вам достичь успеха, скорее, наоборот. В данном случае это можно сравнить с раскалыванием ореха при помощи кувалды. Какие бы вы ни использовали инструменты или новейшие технологии, в конечном итоге в браузер отправляется именно HTML-, CSS- и JS-код, поэтому для создания хороших приложений необходимо знание принципа работы этих языков.

Само по себе написание HTML действительно не является сложным.

Но! Построение пользовательских интерфейсов путём элегантной компоновки языковых возможностей с помощью CSS, создание приятного дизайна и запоминающегося пользовательского опыта требует навыков, которые не стоит недооценивать, как и HTML. Ведь это один из тех языков – возможно, самый важный – которые формируют веб-среду.

Аналогичную позицию в отношении ценности (опыта) веб-разработки разделили:

• Кристиан Хейлманн, который отстаивал самодостаточность фронтенд-разработки как полноценной работы.
• Джереми Кейт, который беспокоился, что мы можем «достичь состояния отрасли, когда стандартным подходом к веб-разработке станет использование сложных сверхинженерных решений».
• Энди Белл, который считает, что фронтенд – это намного больше, нежели построение дизайна.

Давайте перестанем сравнивать веб-технологии и их ценность. Не будем обсуждать, что проще/сложнее или более/менее важно. Давайте работать в командах, прислушиваться и учиться у более опытных людей, независимо от того, являются ли они экспертами в HTML, CSS, TypeScript, PHP, Python или [назовите свой язык]… Давайте вместе сделаем интернет прекрасным пространством и будем ценить людей, которые преимущественно трудятся на фронте фронтенда!

Скидки, итоги розыгрышей и новости о спутнике RUVDS — в нашем Telegram-канале 🚀