Как стать автором
Обновить

Комментарии 53

Что дальше? Расскажете чем процессор отличается от системного блока?
Как и в данном случае, это будет зависеть от внутренней потребности.
Чей внутренней потребности? Зачем рассказывать об этом хабру?
Мне не хочется повторять предисловие, но хочется спросить, где такая публикация более уместна, на ваш взгляд.
Такая обширная, когда всё можно было сократить только к пункту «закрепление» – нигде. Сокращённо подошло бы для какого-то вконтактовского паблика для начинающих, наверное. Но на хабре писать о том, что такое HTML и CSS – как минимум странно.
Идея насчёт паблика небезынтересна, большое спасибо. Когда-нибудь воспользуюсь ей.
НЛО прилетело и опубликовало эту надпись здесь
потому что есть разрабы, на полном серьезе причисляющие ко фронтэнду серверный код, который отдает пользователю эти самые html, css и js
Вы считаете это бэкендом?
мне интересно услышать ваше определение что относится ко фронтэнду, а что к бэкэнду.
если исходить из определения, что фронтэнд — это совокупность пользовательских программ, кода и статических ресурсов, выполняющихся на клиенте, а бэкэнд, соответственно, — совокупность того же, но уже на сервере, то да, — так называемый «фронтэнд сервер» — это самый что ни на есть бэкэнд

Добавьте к определению фронтенда "и средства их доставки (опционально генерации)" и получите фронтенд-сервер, как минимум nginx/apache/iis/..., отдающий статику без дерганья приложения и проксирующий (возможно с трансформацией) запросы к динамике на бэкенд-сервер.

то есть, человек, пишущий код для такого сервера, например на PHP будет front-end developer?

Классические PHP-приложения объединяют в одном "инстансе" фронтенд- и бэкенд-серверы, в рамках одного процесса выполняя и бизнес-запрос (грубо — обращение к базе), и рендеринг HTML. Современные же, aka "(микро)сервисы", не рендерят HTML, отдавая либо непосредственно клиенту, либо фронтенд-серверу только данные, например в JSON/XML, обрабатывая только бизнес-запрос.

еще более сузим вопрос.
человек, который пишет ту часть кода, которая отвечает за получение данных с app-сервера а не html (twig,jinja etc) — тоже front-end developer?
и да, вам не показалось, я действительно хочу довести ситуацию до абсурда, когда белое будет названо черным

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

Я бы предпочел не заострять внимание на технической стороне, ибо реализовать можно что угодно и как угодно (да еще и спрятать это таинство от разработчика, как ASP.NET Web Forms, а жесткие определения здесь невозможны без кучи уточнений.

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

А чтобы враг молча отдал оружие, уточните, что отдельно взятая страница — уже интерфейс, а внутри неё работает фронтенд

Определитесь что ли.
Давайте вместе. Что вас смущает?
А что такое «Бэкенд»?
Его не существует, это выдумки невежд!
А если учесть, что «клиентская сторона» — это перевод термина «фронтенд»?
Термин «клиентская сторона» больше похож на перевод client side.
Причём чаще употребляется «сторона клиента»
Очевидно, что это одно и то же) client side противопоставляется server side, frontend — backend.
Сервер для передачи фронтенда на сторону клиента.

А бэкенд сервер — для передачи бэкенда?

Для отдачи и обработки данных.

Только фронтенд? Данные он не передает?

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

А зачем это нужно в реальной жизни?)

Разделять фронтенд и бэкенд. Обычный уже пример — nginx, отдающий статику и проксирующий вызовы api к json/xml бэкенду, может по http, может по, например, fastcgi или wsgi. То есть фронтенд сервер ничего не знает про данные, а бэкенд сервер ничего не знает про фронтенд, про html и css. Практическая польза — раздельное масштабирование, строгое разделение команды на фронтендеров и бэкендеров — как минимум нет споров о том, кто должен натягивать верстку на шаблонизатор бэкенд- движка :), возможность простого подключения клиентов, которые тоже ничего не знают о html/css, например нативные мобильные приложенияю

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

В том-то и дело, что благодаря технологиям типа React и Angular бэкенд-сервер уже не рендерит для фронта верстку, фронт получает статический html с одним пустым дивом, содержимого которого формирует сам. Да, ещё в функции фронтенд сервера может входить генерация первой страницы для таких сайтов, но опять же все данные он получит с бэкенд-сервера, так что последнему будет все равно, браузер к нему делает запрос или фронтенд-сервер, который отдаст результат браузеру или поисковику.

Я далек от хипстерского современного фронта, но он же не имеет доступа к файловой системе клиента и не умеет (повсеместно) в клиентские БД? То есть будут запросы к бэкенду на любой чих. Проксирование данных на «фронтовов бэкенде» — это сложное решение, как мне кажется, без особой пользы увеличивается количество подсистем, требующих поддержки.
То есть будут запросы к бэкенду на любой чих

Да, если не держать локальный кеш, не зависящий от HTTP заголовков.


Проксирование данных на «фронтовов бэкенде» — это сложное решение

Не понял, где проксирование?

Не понял, где проксирование?

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

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

фронтенд-бэкенде

Всё чудесатее и чудесатее.

Сам в шоке)

Опять сарказм не поняли..


/````````Фронтенд````````\
Клиент <=> Фронтенд-сервер <=> Бэкенд-сервер
           \_____________Сервер____________/
В каждой шутке есть доля шутки. В принципе, если под «Сервер» понимать единое приложение, то SPA так и работает. Но деплой, да и вообще поддержка одного приложения — это недостаточно весело, правда?)

Очень часто "Сервер" не единое приложение, а, минимум три: веб-сервер со статикой ("фронтенд-сервер"), апп-сервер и СУБД. И нормально деплоится

перестал читать сразу после небрежного определения интерфейс

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

Согласен. И что Вы, товарищи всёзнающие, под любым знакомым Вам материалом в комментариях какаете?

Перед тем, как потратить свое время на написание статьи, следовало проконсультироваться со специалистом с опытом.
Клиент — программа(в том числе прошивки приборов), запрашивающие данные или услугу у сервера. Услуга — обработка данных.
Клиент не оперирует удаленными данными! Он их получает от сервера и обрабатывает локально.

Сервер — производит вычисления по запросам клиентов или выполнять любую другую регулярную рабготу.
Может сам выступать клиентом при подключении к другим серверам.

Интерфейс — средство взаимодействия. Чего с чем — определяется из контекста. В литературном языке трубуется явно укзать.
Пользовательский интерфейс(UI) — средство взаиомдействия пользователя с ПО.
Порграммный интерфейс(API) — средство взаимодействия программ между собой.
Аппаратный интерфейс — взаимосвязь аппаратных компонент(шлейфы, разъемы и пр)

Фронтенд — новомодное нерусское слово. Альтернативное название — клиентский код, код обрабатывающий данные, полученные от сервера.
Я и специалист с опытом, который меня консультировал, плюсанули бы вам, если бы не нулевая карма.
Зачем публиковать на Хабре то, что и так очевидно всем его посетителям?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий