Frontend разработка — Введение в веб-разработку

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

Как пример, давайте рассмотрим среду выполнения практических заданий на Хекслете. Первое, что бросается в глаза при работе с ней, это отсутствие классической веб-схемы «запрос-ответ». Страница никогда не перезагружается, а сам сайт в этот момент выглядит как полноценный редактор кода. На самом деле, это и есть полноценный редактор кода 🙂

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

Уже в начале 90-х стало понятно, что существующих решений недостаточно для создания интерактивных (динамичных) сайтов. Компания Netscape Communications (создавшая один из первых и, в свое время, лучших браузеров) разработала специальный язык, выполняющийся в браузере. Этот язык сначала назывался LiveScript, а затем был переименован в JavaScript. Он не имеет никакого отношения к языку Java, но в те года Java быстро становилась популярной и этим фактом решили воспользоваться создатели JavaScript, использовав слово Java в названии языка.

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

Общий принцип работы JavaScript в браузере следующий. Кроме HTML, с сервера подгружаются JS-скрипты, которые затем начинают выполняться на странице. Браузер не просто умеет исполнять JS, но также предоставляет возможности по манипулированию как самим браузером (ограниченно), так и элементами на странице (посредством DOM API).

Благодаря этому стало возможно создавать сайты, по возможностям не уступающие обычным приложениям. Microsoft Office для многих ушел в прошлое, а на его место встал Google Docs. Даже сложнейший инструмент Photoshop уже представлен онлайн. Социальные сети наполнены разнообразными приложениями, построенными на базе современных фронтенд-технологий. Ну и, конечно, игры.

Важно понимать, что Frontend-разработка не является неотъемлемой частью веб-разработки. Реальная потребность в богатом интерфейсе возникает не на каждом втором сайте. К тому же, введение логики во фронтенд существенно усложняет и удорожает разработку. А сайты, чей фронтенд целиком строится в браузере, называют Single Page Application (SPA).

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

Нарастание сложности привело к выделению категории людей, которых называют фронтендерами. Здесь остановимся поподробнее. Часто говорят «нам нужен фронтендер». За этой фразой может скрываться многое. В какой-то момент стало не модно говорить «верстальщик», и его тоже заменили словом «фронтендер». Итого получается, что под фронтендером имеют ввиду следующее:

1. Верстальщик.
2. Программист на JS и одновременно верстальщик.
3. Программист на JS, хорошо знающий верстку, но без задач на нее.

Все три — это совершенно разные люди.

Я, например, неплохо знаю JS и пишу много фронтенда Хекслета, но при этом совершенно не умею верстать и, более того, ни за какие коврижки не готов этим заниматься.

Верстальщики, как правило, знают базовый JS, но программировать зачастую не умеют. Иногда они немного работают с jQuery и добавляют простые интерактивные элементы на страницу. Хороший верстальщик — это не генератор HTML из макетов, а специалист по представлению информации и интерфейсов в контексте веб-страниц. Он знаком с принципами дизайна в широком смысле этого слова, юзабилити, пользовательского опыта и вопросов взаимодействия людей с цифровыми интерфейсами.

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

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

Особенности разных подходов к организации разработки и специализации в командах больше относятся к процессным историям. Если вам хочется немного ближе познать эту область, посмотрите различия между component teams и feature teams.

Главное, что хочется донести до всех, кто планирует стать фронтенд-программистом: такой человек в первую очередь программист, а во вторую уже фронтенд.

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

Сборка фронтенда современного приложения использует вовсю возможности экосистемы серверного js: пакетный менеджер, процессинг (пре- и пост-), серверный рендеринг (генерация страниц на сервере для ускорения доступа и улучшения SEO). Кроме того, все чаще для управления состоянием на клиенте начинают использовать базы данных. Даже браузеры уже содержат в себе встроенную базу данных.

Но это еще не все. Как показывает практика, корнем большинства проблем, возникающих у любых разработчиков, является незнание операционных систем. Причем, сами программисты далеко не всегда осознают это (Парадокс Блаба и Эффект Даннинга-Крюгера). Они вновь и вновь задают вопросы, ответы на которые (и многие другие) есть в классических книгах по устройству ОС. Не говоря уже о том, что многие задачи, с которыми сталкиваются разработчики, так или иначе решены на уровне ОС. Те, кто обладают соответствующими знаниями, находятся на два шага впереди своих коллег и могут не только быстро понимать источник проблемы, но и находить более оптимальные пути решения, опираясь на опыт поколений.

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

Остались вопросы? Задайте их в разделе «Обсуждение»

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

2022: действительно ли разработка фронтенда проще, чем бэкенда?

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

Почему некоторые программисты говорят, что фронтенд проще, чем бэкенд?

Почему некоторые, обычно старшие, программисты говорят, что бэкенд сложнее, чем интерфейс? Вероятно, потому что в 90-е годы разработка фронтенда действительно была не такой уж сложной. Конечно, были проблемы с совместимостью браузеров, а JavaScript был недостаточно развит и глючил. Тем не менее интерфейс веб-сайта был довольно простым — как с точки зрения дизайна, так и с точки зрения технических стандартов программирования. Не было никаких интерфейсных фреймворков, таких как React, Vue или Angular, и большая часть прикладной логики выполнялась на бэкенде. По этой причине разработка бэкенда в 90-е годы была намного сложнее, чем разработка фронтенда.

Чем фронтенд сложнее?

Давайте выделим причины, почему фронтенд-разработка может быть сложнее:

1) Необходимость идти в ногу с быстро меняющимися возможностями.

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

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

Не похоже, что эти изменения прекратятся в ближайшее время. Так что нужно иметь в виду постоянно меняющийся ландшафт фронтенд-разработки.

2) Больше принципов, которые следует иметь в виду: дизайн, пользовательский интерфейс, функционал интерфейса, программирование.

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

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

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

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

3) Дополнительные инструменты для изучения.

Постоянно меняющийся ландшафт также означает, что нужно осваивать больше инструментов, чтобы оставаться на высоте. С заменой Gulp и Grunt на Webpack, Angular на React и множеством других инструментов, внедряемых каждый день, таких как Yarn и NPM, нужно держать руку на пульсе, чтобы не остаться за бортом. Иногда, честно говоря, кажется, что ты никуда не идешь, просто чтобы не отставать.

4) Тестирование и тестовые наборы.

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

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

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

Почему бэкенд сложнее фронтенда?

Есть конкретные причины, почему бэкенд-разработку можно считать более сложной:

1) Более крутая кривая обучения начинающих.

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

2) Менее визуальный, чем интерфейс.

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

3) Множество внутренних языков

Наконец, бэкенд может быть сложнее в освоении, потому что существует много бэкенд-языков: PHP, C#, Java, Python, Ruby и т.д. А во фронтенде — только HTML, CSS и JavaScript. Очевидно, есть чему поучиться, но большая часть основана на этих языках.

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

Так что же на самом деле проще: разработка интерфейса или бэкенда?

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

Как говорится, без труда не вытащить и рыбку из пруда!

Простыми словами о «фронтенде» и «бэкенде»: что это такое и как они взаимодействуют

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

Рассказывает Хьюго Ди Францеско, веб-разработчик

На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

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

Давайте начнем с определений.

Фронтенд — все, что браузер может читать, выводить на экран и / или запускать. То есть это HTML, CSS и JavaScript.

HTML (HyperText Markup Language) говорит браузеру, каково содержание страницы, например, «заголовок», «параграф», «список», «элемент списка».

CSS (Cascading Style Sheets) говорит браузеру, как отображать элементы, например, «после первого параграфа отступ в 20 пикселей» или «весь текст в элементе body должен быть темно-серым и написан шрифтом Verdana».

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

Бэкенд — все, что работает на сервере, то есть «не в браузере» или «на компьютере, подсоединенном к сети (обычно к Интернету), который отвечает на сообщения от других компьютеров».

Прим. ред. Профессия бэкенд-разработчика вошла в топ наиболее сложных IT-профессий.

Для бэкенда вы можете использовать любые инструменты, доступные на вашем сервере (который, по сути, является просто компьютером, настроенным для ответов на сообщения). Это означает, что вы можете использовать любой универсальный язык программирования: Ruby, PHP, Python, Java, JavaScript / Node, bash. Это также означает, что вы можете использовать системы управления базами данных, такие как MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached.

Структура взаимодействия бэкенда и фронтенда

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

Серверные приложения

В этом случае HTTP-запросы отправляются напрямую на сервер приложения, а сервер отвечает HTML-страницей.

Между получением запроса и ответом сервер обычно ищет по запросу информацию в базе данных и встраивает ее в шаблон (ERB, Blade, EJS, Handlebars).

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

Связь с использованием AJAX

Другой тип архитектуры использует для связи AJAX (Asynchronous JavaScript and XML). Это означает, что JavaScript, загруженный в браузере, отправляет HTTP-запрос (XHR, XML HTTP Request) изнутри страницы и (так сложилось исторически) получает XML-ответ. Сейчас для ответов также можно использовать формат JSON.

Это значит, что у вашего сервера должна быть конечная точка, которая отвечает на запросы JSON- или XML-кодом. Два примера протоколов, используемых для этого — REST и SOAP.

Клиентские (одностраничные) приложения

AJAX позволяет вам загружать данные без обновления страницы. Больше всего это используется в таких фреймворках, как Angular и Ember. После сборки такие приложения отправляются в браузер, и любой последующий рендеринг выполняется на стороне клиента (в браузере).

Такой фронтенд общается с бэкендом через HTTP, используя JSON- или XML-ответы.

Универсальные/изоморфные приложения

Некоторые библиотеки и фреймворки, например, React и Ember, позволяют вам исполнять приложения как на сервере, так и в клиенте.

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

Вне фронтенда и бэкенда

Автономный фронтенд

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

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

Легкий бэкенд

Бэкенд, в свою очередь, становится легче и легче. Такие технологии, как хранилища документов и графовые базы данных, приводят к сокращению количества обращений к бэкенду для повторного агрегирования данных. Задача клиента — уточнить, какие данные ему нужны (базы данных графов), или извлечь все различные фрагменты данных, которые ему нужны (REST API).

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

Размытые границы

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

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

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

При подготовке материала использовались источники:
https://ru.hexlet.io/courses/intro_to_web_development/lessons/frontend/theory_unit
https://ru.hexlet.io/blog/posts/2022-deystvitelno-li-razrabotka-frontenda-prosche-chem-bekenda
https://tproger.ru/translations/frontend-backend-interaction