Прочитал в одной статье, что фронтенд - это видимая часть сайта, которую видит пользователь, а бекенд - это та часть сайта, которая не видна пользователю, то есть "невидимая". В связи с этим возник вопрос, вёрстка относится к фронтенду или же к бекенду? Ведь пользователь видит не сам HTML-код, а только то, что отрисует браузер, исходя из полученного кода. Подскажите, пожалуйста.
Александр, вы неверно понимаете.
Фронт это что видит чувак в браузере.
Бэк это то к чему он стучится. Бэк может формировать фронт, но сейчас он этого как правило не делает
что запускается на машине пользователя, называют фронтендом.
А то что исполняется на сервере - бэкендом.
не вводите людей в заблуждение.
У приложения вообще может не быть серверной части, но при этом без бэка приложение будет бесполезно.
Фронт - это UI (в случае web это HTML+CSS+та часть JS которая отвечает за обработку событий от пользовательского ввода и формирует пользовательский вывод)
Бэк - это логика приложения, она может быть как на серверной части так и на клиентской.
Дмитрий Беляев, Сергей Горностаев, это зависит от терминологии.
Да, действительно существует такая трактовка, когда фронт - это (G)UI, а бэк - бизнес-логика.
Но обычно всё-таки под фронтом понимают вообще всё что в браузере происходит, включая бизнес-логику.
А под бэкендом понимают исключительно серверные штуки.
Гораздо проще отталкиваться от практики, а практика склоняется ко второму варианту.
Иначе бы фронтендеры занимались только вёрсткой, были бы "бэкендеры", которые пишут только код в браузере, а верстальщиков бы не существовало как термина.
Сергей Горностаев, например, у Вас есть некий калькулятор на сайте и Вы считаете все прямо в браузере, а не ходите за вычислениями на сервер. Та часть, которая производит расчет - это бэкенд. А фронтендом здесь будет та часть, которая рисует пользователю формочку этого калькулятора и реагирует на действия пользователя с ней.
Или вот еще пример, на этом сайте подключены яндекс метрика и гугл аналитика, которые много чего делают прямо в браузере, однако фронтенда у них вообще нет, только бэкенд. Рядовой пользователь их вообще не видит.
А вот посмотрите сколько различных апи есть в брузере чисто для бэкенда
Дмитрий Беляев, ну вы ж реакты с ангуляром бэкэндом наверное не называете, хотя там внутри тоже много чего интересного сделать можно, калькулятор, например
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 случайных разработчика, то их набор специализаций будет различаться, да где-то будут пересечения, но полный набор всегда будет разный, ибо каждый строит свое развитие индивидуально и с учетом собственных потребностей и интересов.
Отвечая на Ваш вопрос, интеграцией метрики должен заниматься разработчик, у которого есть специализация по работе с метрикой или тот который готов ее очень быстро освоить, разработкой калькулятора должен заниматься тот, кто умеет в разработку интерфейсов (это из мира фронтенда) и умеющий переносить математические формулы в код (а это уже бэк), а при отсутствии в команде человека с обеими специализациями задачу разработки калькулятора придется разделить на двух людей.
Дмитрий Беляев, ну короче действительно вопрос терминологии.
На самом деле, разделение по ролям/скиллам мне нравится больше чем тупо бэк/фронт/фуллстек, тк оно не отражает реального положения дел.
Например на прошлой работе мы делали плагины для одного таск трекера - 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 никуда не делась, поэтому и дали этим частям кода свои термины.
Простой
