Зачем нужен frontend, если всю начинку сайта или проекта можно реализовать с помощью backend'a?

Question

[Алексей Костюхин]

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

Сами посмотрите. Все глобальные веб-проекты, которые есть, реализованы с помощью серверной части.
Например: поиск по картинке. Реализован с помощью python.
2. Нейросети: если есть на сайте какая-то функция для статистики и т.д. Для преобразования простых детских рисунков в произведения исскусства - все это реализовано на серверной части, с помощью серверных языков. Таких как phyton, node.js, PHP

Для чего нужны такие языки, как JavaScript, HTML, CSS и тому подобное?

Comments

[Roman]

Все смешалось кони люди.
https://ru.wikipedia.org/wiki/Front_end_и_back_end

[Алексей Костюхин]

Roman, Я написал о том, что на СЕРВЕРНОЙ ЧАСТИ можно написать все то, что пишется на frontend'e
А на frontend'e не напишешь ничего, что можно реализовать на серверной.

Доступ к серверу, безопасность, тонкие сетевые настройки. Тунелирование трафика и тому подобное.

[sim3x]

А как реализовать показ, того что выдал бек без хтмл и цсс?

И как сделать на бекенде что-то наподобии жмаил?

Все глобальные веб-проекты, которые есть, реализованы с помощью серверной части.

и фронта. Даже если там нет интерактива и жс впринципе

Например: поиск по картинке. Реализован с помощью python.

нет

[Roman]

sim3x,

Еще это значит, что человек, который знает только фронт - не знает почти ничего.
Потому как, если я back-end'ер, то я сам смогу все написать и реализовать и заставить сервер при этом работать и показывать то, что я хочу.

[alex]

Алексей Костюхин,

можно весь интерфейс реализовать с помощью серверной части

на чем вы собрались его реализовывать?

[sim3x]

Roman,

Для чего нужны такие языки, как JavaScript, HTML, CSS и тому подобное?

google: serverless

[Roman]

sim3x, а я то что, я все написал в первом комментарии.
мне все ясно стало после ноды и яваскрипт.

[Антон Спирин]

Сами посмотрите. Все глобальные веб-проекты, которые есть, реализованы с помощью серверной части.

Неправда.

Я написал о том, что на СЕРВЕРНОЙ ЧАСТИ можно написать все то, что пишется на frontend'e

И как же вы собрались работать с браузерными API на стороне сервера?

с помощью серверных языков. Таких как phyton, node.js, PHP

node.js это не язык.

[Алексей Костюхин]

Alex, python, node.js php.

[alex]

Алексей Костюхин, теперь объясните мне и окружающим, как мне завести .php и .py файлы в браузере?

непонятно для чего заданный и какие цели преследующий вопрос от некомпетентного человека у которго node.js это язык. решили что-то доказать, сказав что фронтенд не нужен, задав вопрос фронтендерам. sick!

[Сергей delphinpro]

Ага. А давайте вы вконтактик напишете без html/css/javascript. Вот тогда будет о чем разговаривать.

Не вопрос, а толстый троллинг.

[Алексей Ярков]

Последний день перед выходными в школе? Что за странное поверхностное мнение?

[Антон Швец]

Сергей delphinpro, вконтач без html можно написать в виде нативного приложения. Тоже фронтенд будет.

[Lord_Dantes]

html/css зачем такие языки. Я вот тоже не понимаю зачем вот это все гоу парсить соседные сайты и вставлять свои данные и вообще норм будет

Answer 1

[profesor08]

Релизуй реактивность на php. Или давай чего попроще, отобрази в браузере красную кнопку на php без использования HTML и CSS, а изюминкой добавь чтоб при нажатии пользователю выскакивал алерт "Hello world", не используя JavaScript.

Comments

[Volodimir Babeshko]

Плохие примеры, в большей части бред, при чем тут реактивность, если можно, к примеру вообще обойтись без нее, 90% сайтов работают без этой самой реактивности, бекенд не выводит сайт - он (при классическом бекенде) просто выводит HTML+CSS, таким же самым образом можно сказать - "а нарисуй красную кнопку без HTML+CSS на <любой язык программирования>", ну и алерты можно сделать через таргет на ЦСС. Поэтому чтобы человеку объяснить зачем нужен фронтенд - нужно самому понимать зачем это нужно, а не плохие примеры давать.

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

[profesor08]

Konstantin Abaiev,
HTML + CSS === Frontend, что еще придумаешь? Или есть аргументы против?

[Volodimir Babeshko]

profesor08, во-первых «придумаете», а во-вторых, учите матчасть и будет Вам счастье и не пытайтесь свои кейсы и мировозрение возводить в абсолют, и если Вы один из тех, кто пихает JS куда ни попадя только лишь потому, что не умеет и не знает как по-другому это сделать, то хотя бы не пытайтесь учить людей

[profesor08]

Konstantin Abaiev, чтоб отобразить алерт не писать 1 строчку js, а вводить новый элемент в виде чекбокса и задавать стили элементу в зависимости от состояния чекбокса? А если надо показать 10 разных алертов, то вводить 10 разных элементов и 10 разных чекбоксов? И делать обращение к серверу с загрузкой всего html, по каждому чиху? Так что если вы один из тех, кто пихает подобные конструкции куда ни попадя только лишь потому, что не умеете и не знаете как по другому это сделать, то хотя бы не пытайтесь учить людей. Выучите матчасть, и будет вам счастье.

[Volodimir Babeshko]

profesor08, Я не программист вообще-то, я говорю как человек, который знает что это и работает с разработчиками, часть разработчиков не знает как работает бек и выучили один фреймворк на JS и по каждому чиху пихают вместо обычной верстки (которую тоже зачастую даже верстать не могут) пихают монструозные бандлы фреймворка для того, чтобы показать слайдер или ещё чего, что точно не стоило бы делать. Я не против JS, понятно, что есть масса кейсов, когда делать на чистом CSS это извращение и бывают случаи, когда использование JS фреймворка даже не оправдано, а необходимо, НО фронт-енд в контексте вопроса - это функциональное разделение бека и фронта на две отдельные части и в этом контексте фронт как полностью самостоятельная единица не нужна.

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

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

Answer 2

[nrgian]

1) "Все на сервере" - так уже делали. Начиная с зари эпохи начала доступности компьютеров. Гуглите dumb terminal. И существовали до недавнего времени в широком обиходе кое-где, несмотря на веб-технологии. Например, во Франции.

2) Вам никто не мешает написать на Python как серверную часть, так и клиентскую часть.

3) JavaScript, CSS, HTML - это просто потому, что вместо установки на компьютере пользователя отдельной программы для каждого сервера придумали одну общую программу - браузер, внутри которой уже реализуются клиенты для различных серверов. Ну и исторически так сложилось, что внутри браузера поддерживаются только эти 3 языка на сегодня. Если вы не желаете использовать эти языки, не желаете использовать браузер - то см. п. 2)

Comments

[Артем Андреев]

Chrome --headless

[nrgian]

Артем Андреев,

Chrome --headless

И? Вы вопрос то изначальный читали?
Что там останется от взаимодействия с пользователем?

P.S.:
SlimerJS лучше, чем "безголовый Хром".
Ресурсов жрет не в пример меньше и управляется удобнее.

[Артем Андреев]

nrgian, я про то что Front все-таки необходим, а так это безголовое получается все

Answer 3

[АртемЪ]

• Во первых бэкэнд это долго - к примеру вам нужно изменить один символ на странице, страница весить пять мегабайт. Вы посылаете запрос на сервер, ждете когда его сервер обработает, и скачиваете новыую страницу с измененным символов. В итоге скорость замены одного символа на странице 0,5 -200секунд.
  А на фронтенде вы можете менять поменять за 0,5секунд этот символ хоть сотню раз.
  
• Во вторых бэкэнд это дорого - фронтэнд позволяет разгрузить сервер, выполняя задачи на клиенте - в результате сайт можно хостить на недорогом хостинге, а в случае бэкэнда хостинг может потребоваться в сотни, а то и тысячи раз дороже.
  

Для чего нужны такие языки, как JavaScript, HTML, CSS и тому подобное?

• JavaScript нужен чтобы писать программы так же как и питон например или C.
  
• HTML языком программирования не является и служит для разметки страниц.
  
• СSS языком программирования не является и служит для описания стилей.
  

Для преобразования простых детских рисунков в произведения исскусства

Детские рисунки изначально являются произведением искусства. Их нельзя преобразовать в произведения искусства.

все это реализовано на серверной части, с помощью серверных языков. Таких как phyton, node.js, PHP

Не бывает серверных языков - бывают языки программирования.

Comments

[Алексей Костюхин]

Вы сможете реализовать взаимодействие с нейросетями на js?
Или написать ИИ на Js?

[АртемЪ]

Алексей Костюхин, Конечно. В чем проблема то?
У js разумеется есть ограничения, например написать драйвер видеокарты на нем будет крайне затруднительно.
А вот нейросеть - без проблем.
Другое дело, что нейросети удобнее писать на других языках, например тот же пайтон более удобен, хотя бы тем что есть куча готовых библиотек.

А так - на JS пишут веб сервисы, его используют в браузерах, на нем можно написать игру, на нем можно написать скрипт для администрирования БД, можно написать обычное оконное приложение под винду, или под линукс.

[Volodimir Babeshko]

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

[АртемЪ]

Konstantin Abaiev,

поэтому нельзя говорить, что бекенд это долго или дорого

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

[Volodimir Babeshko]

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

[АртемЪ]

"пинг обычно - это несколько миллисекунд, если не учитывать качество мобильного интернета" - попингуйте сервер в США, или в Австралии.

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

Answer 4

[sharpross]

JavaScript, HTML, CSS - Что бы оформить информация поступающую с бэкенда + снизить нагрузку на бэк.
Мы можем отрендерить странички на клиенте сразу и постепенно подгружать лишь небходимые данные с бэка.
В итоге сервер отдаёт минимум информации, а иначе серверу придётся ещё тратить время на отрисовку новой страницы при каждом запросе.

Comments

[Алексей Костюхин]

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

[Алексей Костюхин]

Еще это значит, что человек, который знает только фронт - не знает почти ничего.
Потому как, если я back-end'ер, то я сам смогу все написать и реализовать и заставить сервер при этом работать и показывать то, что я хочу.

А frontend'ер получается отрезан от мира, если ему нужен будет динамичный веб-сайт.

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

[sharpross]

Ну частично это правда, хотя у фронтовиков есть свои методы используя JS (node.js, mongodb и т.д.) писать серверные части.
Чисто для меня их проблема как раз в JS, в сожалению он не типизированный.

[Hyubert]

Алексей Костюхин, Вы немножко ошибаетесь, современный фронт намного сложнее чем вы думаете... Есть вещи которые вы только лиш с бэком не сделаете.... а на счет хранения данных, так есть возможность хранить дание на клиенте - localStorage, indexDB, так и специализировные платформы на подобие firebase.

[Антон Швец]

sharpross, node.js и монго не имеют никакого отношения к фронту. Проверка типов есть в статических анализаторах flow и typescript. Без них разработка на js превращается в ад

Answer 5

[vgorbatenko]

Все правильно // всю начинку сайта только и надо реализовывать на бэке // никого не слушай // делай.

Comments

[Алексей Костюхин]

Сарказм ?

Answer 6

[Дима Паутов]

JavaScript, HTML, CSS - в браузере нужны для того, что бы ваши данные визуализировать для пользователя, а phyton, node.js, PHP нужны для того, что бы эти данные предоставить

1)

Таких как phyton, node.js, PHP

- node.js это JavaScript
2)

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

- а на чём вы собираетесь строить это, кроме как на JavaScript, HTML, CSS

Вся текущая красота интерфесов react, vue, angular даёт нам возможность разграничить нагрузку. Пускай сервер занимается тем, чем должен, логикой и вычислениями. А браузер, на основе данных бекенда рисует нам странички. Тем самым мы высвобождаем много ресурсов для сервера, что бы ему это всё не генерировать.

Comments

[Алексей Костюхин]

Я писал выше:
Еще это значит, что человек, который знает только фронт - не знает почти ничего.
Потому как, если я back-end'ер, то я сам смогу все написать и реализовать и заставить сервер при этом работать и показывать то, что я хочу.

А frontend'ер получается отрезан от мира, если ему нужен будет динамичный веб-сайт.

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

[Дима Паутов]

Алексей Костюхин, скорее вы отрезаны от мира и не понимаете, что для чего создано. С чего вы решили, что бекендер может писать и фронт и бек, а фронтендер не может писать фронт и бек? Я с лёгкостью напишу бек на ноде с restAPI и vue. Браузер не должен общаться с базой, это не безопасно вот так вот напрямую общаться с базой. Компьютер пользователя не настолько мощный, чем сервера, которые созданы для обработки большого кол-ва данных за доли секунд. А браузер пользователя повиснет, как только ему нужно будет обработать огромные массивы данных. Для это и существует разграничение

заставить сервер при этом работать и показывать то, что я хочу.

а показывать вы будете при помощи чего? просто текст на страницу выведете? Без оформления? Без таблиц? Без графиков? Без форм?

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

Answer 7

[Виктор]

Какой жирный наброс. Даже если я сейчас предложу отказаться от бекенда и слать sql-запросы прямо из браузера, у меня и то получится не так толсто.

Comments

[Антон Швец]

используя firebase можно слать запросы к бд из браузера. И запускать хранимые в бд процедуры. Для какого-нибудь протипа отлично.

Answer 8

[lukoie]

Это нужно чтобы перенести часть функционала(читай нагрузку) на клиента.