Вёрстка — фронтенд или бекенд?

Question

[Александр]

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

Comments

[Lord_Dantes]

Answer 1

[true]

верстка это UI

Answer 2

[Василий Банников]

Пользователь никогда не видит код, а рисованием занимается браузер, а не разработчик.

По тому html, css, js и прочее, что запускается на машине пользователя, называют фронтендом.
А то что исполняется на сервере - бэкендом.

Comments

[Александр]

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

Получается что это определение неверное?

[Владимир Коротенко]

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

[Василий Банников]

Александр, ну типа. Только ваш тезис, что пользователь не видит html, а значит это бэк - не правда.

[Дмитрий Беляев]

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

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

Фронт - это UI (в случае web это HTML+CSS+та часть JS которая отвечает за обработку событий от пользовательского ввода и формирует пользовательский вывод)
Бэк - это логика приложения, она может быть как на серверной части так и на клиентской.

[Сергей Горностаев]

Дмитрий Беляев, бэкенд на клиентской части? Это как? Пример привести можете?

[Василий Банников]

Дмитрий Беляев, Сергей Горностаев, это зависит от терминологии.
Да, действительно существует такая трактовка, когда фронт - это (G)UI, а бэк - бизнес-логика.

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

Гораздо проще отталкиваться от практики, а практика склоняется ко второму варианту.
Иначе бы фронтендеры занимались только вёрсткой, были бы "бэкендеры", которые пишут только код в браузере, а верстальщиков бы не существовало как термина.

[Дмитрий Беляев]

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

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

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

https://developer.mozilla.org/ru/docs/Web/API/Beac...
https://developer.mozilla.org/en-US/docs/Web/API/W...
https://developer.mozilla.org/en-US/docs/Web/API/B...
https://developer.mozilla.org/en-US/docs/Web/API/E...
https://developer.mozilla.org/ru/docs/Web/API/Fetch_API
https://developer.mozilla.org/en-US/docs/Web/API/F...
https://developer.mozilla.org/ru/docs/Web/API/Inde...
https://developer.mozilla.org/ru/docs/Web/API/Paym...
https://developer.mozilla.org/ru/docs/Web/API/Web_...
https://developer.mozilla.org/ru/docs/Web/API/Web_...
https://developer.mozilla.org/ru/docs/Web/API/Web_...
https://developer.mozilla.org/ru/docs/Web/API/Web_...
https://developer.mozilla.org/ru/docs/Web/API/WebR...
https://developer.mozilla.org/ru/docs/Web/API/WebS...

[MaxKozlov]

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

[Василий Банников]

Дмитрий Беляев, ок. Калькулятор и интеграцию метрик должен делать фронтенд разработчик или бэкенд-разработчик?

[Дмитрий Беляев]

MaxKozlov, реакт - это чисто UI либа, и это инструмент для фронтенда, а вот redux - это чистый бэкенд.
И кстати, SSR в реакт - это хороший пример, когда фронтенд обитает на сервере.
Ангуляр - это уже application фреймворк, и в нем есть как инструменты для фронтенда, так и для бэкенда.

[Дмитрий Беляев]

Василий Банников, разделение разработчиков на фронтенд и бэкенд - это бред из конца девяностых начала нулевых, притом появилось оно именно с началом развития web разработки.
Есть узкие специализации:
- разработка интерфейсов (по сути верстальщик + пользователь UI фреймворка/либы), опять же можно разделить на web, mobile, desktop
- разработка логики, с разделением на языки/фреймворки/платформы (браузер, android, iOS, windows, linux, микроконтроллеры, и т.д.)/инструменты (MySQL, PostgreSQL, MongoDB, Redis, другие БД, Nginx, Apache, другие WEB сервера, HTTP, DNS, RDP, DHCP, NetConf, другие протоколы)
- разработка вспомогательного инструментария и инфраструктуры, опять же делим на библиотеки, инструменты сборки, инструменты статического анализа и т.д.
У востребованного на рынке разработчика таких специализаций будет несколько, в каких-то он будет более прокачен, в каких от менее, а какие-то будет изучать прямо по ходу работы. Но если взять 2 случайных разработчика, то их набор специализаций будет различаться, да где-то будут пересечения, но полный набор всегда будет разный, ибо каждый строит свое развитие индивидуально и с учетом собственных потребностей и интересов.

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

[Дмитрий Беляев]

Dr. Bacon, а что, web разработка какая-то особенная, что она вдруг отличается от всего остального ПО?

[Василий Банников]

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

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

[Дмитрий Беляев]

Dr. Bacon, как раз таки без контекста не понятно, если нужен разработчик фронтенда, то стоит уточнить под web (а что делать будет? WordPress тюнить или может тильду? или же на либах/фреймворках писать? а на каких? jQuery/Ext.js/Angular/Ember/React/Vue/Svelte) или под mobile (а какой mobile? Android/iOS или кроссплатформенный на Xamarin/Flutter/ReactNative) или под desktop (опять же Qt/GTK/WPF/Electron), с разработкой бэкенда все еще сложнее, так как направлений просто очень много

[Дмитрий Беляев]

Василий Банников, да, о том и речь, что это терминология. Только у терминов есть их исходные значения и есть переосмысленные теми кто не совсем в теме (в случае с фронт/бэк, например, переосмысленные манагерами (именно так, через "а" и "г"), которым понадобилось разделить разработчиков по задачам, а лучше ничего придумать не смогли). Это как с MVC, у которого с десяток трактовок, а исходную (где Модель - это модель бизнеса/процесса, Вью - это вывод пользователю, а Контроллер - обработка пользовательского ввода) знают единицы, ибо актуальна она была в 70х-80х, когда все это руками писали, но термин то красивый, вот и прикручивает каждый под свой кейс и со своей трактовкой.

[Дмитрий Беляев]

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