Кто они и в чём между ними разница?
06.07.2021, 18:05
Первые чуваки занимаются логикой программы.
Вторые чуваки занимаются внешним видом программы.
Когда первые чуваки делают внешний вид программы, он у них получается из ног вон руки, но в большинстве случаев получается. Когда вторые чуваки делают логику программы, она у них получается... Просто не получается, потому что бэкэнд сложнее фронтэнда.
Вторые чуваки занимаются внешним видом программы.
Когда первые чуваки делают внешний вид программы, он у них получается из ног вон руки, но в большинстве случаев получается. Когда вторые чуваки делают логику программы, она у них получается... Просто не получается, потому что бэкэнд сложнее фронтэнда.
Так, а кто тогда ненавистный JavaScript?
Нет. Бэкэнд делает движок, его логику, физику, скриптовой движок, анимационный движок и прочую программисткую и заумную матанскую чепуху. Фронтэнд делает анимации, модельки, интерфейс, пишут диалоги, пишут скрипты и создают сцены в игре. (Но стоит помнить, что нарисовать и составить сцену - фронтэнд, но вот то, как объекты в сцене будут себя вести по игровой логике - это уже вопрос бэкэнда. Хотя в этом случае граница может частично стереться, так как тот же разработчик скриптового движка будет сидеть и писать скрипты чтобы оживить условную сцену, заставить НПЦ ходить туда-сюда, говорить заранее записанные фразы и так далее. Нужно смотреть конкретные примеры, условия и задачи).
Проще говоря, фронтэнд работает с тем, что пользователь видит непосредственно. Бэкэнд работает с тем, что пользователь не видит, но без чего программа не будет работать или не будет создавать полезную работу (в данном случае, быть игрой).
Проще говоря, фронтэнд работает с тем, что пользователь видит непосредственно. Бэкэнд работает с тем, что пользователь не видит, но без чего программа не будет работать или не будет создавать полезную работу (в данном случае, быть игрой).
Это не так если говорить про игры. Иначе в случае онлайн игры или игры которая так или иначе взаимодействует с внешним сервером у тебя выйдет 2 бэкэнда. Для игр обычно делят на UI-тим (чисто логика пользовательский интерфейс и всё что с ним связано), core-тим (движок/основная игровая логика) и backend-тим (сервер, базы данных, etc.). Но при этом если проект/команда небольшие то фронтом могут называть клиентскую часть (от юи до бизнес логики).
Для AAA разделение еще сложнее:
Есть UI которые пилят пользовательский интерфейс
Есть Gameplay которые пилят игровую логику
Есть Engine которые пилят и допиливают движок
Есть Network которые занимаются взаимодействием с сервером
Есть Render которые занимаются разными графичискими эффектами и оптимизациями
Есть Tools которые пилят вспомогательные тулзы
и это всё только программисты
Есть UI которые пилят пользовательский интерфейс
Есть Gameplay которые пилят игровую логику
Есть Engine которые пилят и допиливают движок
Есть Network которые занимаются взаимодействием с сервером
Есть Render которые занимаются разными графичискими эффектами и оптимизациями
Есть Tools которые пилят вспомогательные тулзы
и это всё только программисты
Ну я откровенно упростил, что бы без сложностей и деталей пояснить не знакомому явно с темой человеку суть его не правоты.
а по сабжу:
Ты упустил бекэнд (серверный). А там и инженеры баз данных, если продж многопользовательский там может быть серверный Gameplay (вся логика расчета реальных коллизий и регистрации попаданий) и т.д.
И да, тут мы только о программерах говорим.
а по сабжу:
Ты упустил бекэнд (серверный). А там и инженеры баз данных, если продж многопользовательский там может быть серверный Gameplay (вся логика расчета реальных коллизий и регистрации попаданий) и т.д.
И да, тут мы только о программерах говорим.
Зависит от проекта, в целом. Со всякими ангулярами и вью может быть так, что почти всё висит на клиенте (ненавижу подобный подход). Но оставлять важную логику на фронтэнде нельзя. Например, логику проверки входящих данных, ибо с клиента можно отправить что угодно и как угодно.
Одно время было популярно делать обширную логику на фронте. Даже в крупных конторах. Но от этого ушли по банальным причинам безопасности. Слишком много логики в браузере, и ты не заметишь, как на клиент начнут летать внутренние данные, которых там быть не должно ни при каких обстоятельствах.
Всё ты правильно был уверен, EpicMan2 выше явно не программист. Внешним видом продукта занимаются дизайнеры, согласовывая этот самый внешний вид с продуктовой командой.
Одна из задач фронтенд программистов этот дизайн претворить в жизнь, но не следует забывать что это естественно не их единственная задача. Весь клиентский функционал тоже на них.
Я не знаю какого хуя распространено мнение, что фронтенд легче или при его разработке можно забить хуй на архитектуру приложения.
Если я работаю сейчас над приложением на котлине и пишу в основном логику, я что бэк разработчик получается?
Одна из задач фронтенд программистов этот дизайн претворить в жизнь, но не следует забывать что это естественно не их единственная задача. Весь клиентский функционал тоже на них.
Я не знаю какого хуя распространено мнение, что фронтенд легче или при его разработке можно забить хуй на архитектуру приложения.
Если я работаю сейчас над приложением на котлине и пишу в основном логику, я что бэк разработчик получается?
12 лет в профессии, начинал с бэка, перешёл на фронт. По моему опыту фронт сложнее, а самый ад это мобильные приложения.
Я так и объяснил. Или та часть, которую видит пользователь, перестала входить во "внешний вид программы"? Или "серверная часть, обработка данных, алгоритмы выдачи" перестала входить в логику программы?
Нашлёпкой формы для отправки обратной связи занимается фронтэнд, а вот обработкой письма и его отправкой по назначению (условной компании) занимается уже бэкэнд.
Нашлёпкой формы для отправки обратной связи занимается фронтэнд, а вот обработкой письма и его отправкой по назначению (условной компании) занимается уже бэкэнд.
Не стоит забыть про категорию фулстак чуваков, мастера на все фреймворки
На моей второй работе я (бэкенд) заменял не только фронтенда, но и бизнесаналитика, проджект менеджера, qa, дизайнера (частично). Все, сука, 10 лет, по мере необходимости, не смотря на то, что контора выросла с 10 до 300 человек, кадров постоянно не хватало. А на некоторых проектах и всех одновременно. Вообще никаких проблем не было - справляться с их работой, хотя никаких курсов я не проходил для этого. И проекты не кустарные, для именитых брендов.
Первый - ютубей filthy frank, Второй - певец joji
Бэкенд обслуживает фронтенд. Обычно на бэкенде реализована бизнес-логика, а на фронтенде - прикладная. Например, сервер, который обслуживает веб-приложение - это бэкенд, а клиентская часть - фронтенд. С другой стороны БД, обслуживающая сервер - это тоже бэкенд, а сервер - уже фронтенд. Абдулла, который заворачивает тебе шаурму - это бэкенд, а кассир - фронтенд. Все отностительно и зависит от точки зрения, просто в паре сервер/клиент это используется чаще всего.
бэк берёт bootstrap, готовый шаблон для bootstrap, прикручивает его к server side шаблонизатору и уже получает адекватный интерфейс, с которым можно работать.
Про css не совсем понял - css2 простой как правда, а css3 для "сделать красиво" обычно и не нужен
фронт тоже может поставить wordpress или bitrix и получить что-то минимально рабочее, но как-либо их кастомизировать он не осилит.
Про css не совсем понял - css2 простой как правда, а css3 для "сделать красиво" обычно и не нужен
фронт тоже может поставить wordpress или bitrix и получить что-то минимально рабочее, но как-либо их кастомизировать он не осилит.
Адекватный интерфейс... ахахах, мяу. Он будет настолько же адекватный, как бэк написанный фронтом. Тут куча бэкенд разрабов чтоль повылазило, которые пытаются всем доказать какие они важные и нужные? И то и то в данный момент очень обширные и сложные темы, и хрен ты что адекватное быстро сделаешь попытавшись перейти с фронта да бэк и наоборот, к чему эти меринья письками?
>Он будет настолько же адекватный, как бэк написанный фронтом
и что же такого интересного есть в арсенале фронта для (полу)статичной странички?
>И то и то в данный момент очень обширные и сложные темы, и хрен ты что адекватное быстро сделаешь попытавшись перейти с фронта да бэк и наоборот
за пределами SPA, фронт +/- такой же, как и 10 лет назад, а SPA, как известно, нужен далеко не всегда и далеко не везде.
Флексы, гриды и прочее - иной подход к тем же задачам, ничего фундаментально нового там нет.
и что же такого интересного есть в арсенале фронта для (полу)статичной странички?
>И то и то в данный момент очень обширные и сложные темы, и хрен ты что адекватное быстро сделаешь попытавшись перейти с фронта да бэк и наоборот
за пределами SPA, фронт +/- такой же, как и 10 лет назад, а SPA, как известно, нужен далеко не всегда и далеко не везде.
Флексы, гриды и прочее - иной подход к тем же задачам, ничего фундаментально нового там нет.
Я конечно такой себе кодер, но флексы, гриды, это верстка, при чем тут фронт? Если тебе не нужно SPA и что-то подобное микросервисное, и у тебя монолит, то зачем тебе фронт, тебе нужен верстальщик. Это все равно что я буду говорить что бэк без работы с базой данных такой же как и был, он просто раздает статику.
>Я конечно такой себе кодер, но флексы, гриды, это верстка, при чем тут фронт?
все верстаки теперь гордо именуют себя junior front-end developer
>Это все равно что я буду говорить что бэк без работы с базой данных такой же как и был, он просто раздает статику.
static site generator это называется. Отличная тема, на самом деле. И да, она имеет отношение к бэку.
все верстаки теперь гордо именуют себя junior front-end developer
>Это все равно что я буду говорить что бэк без работы с базой данных такой же как и был, он просто раздает статику.
static site generator это называется. Отличная тема, на самом деле. И да, она имеет отношение к бэку.
>Тут куча бэкенд разрабов чтоль повылазило, которые пытаются всем доказать какие они важные и нужные?
кмк, к фронтам относятся не очень хорошо вообще все, даже за пределами программирования - во многом благодаря именно им вэб стал таким жирным и тормознутым, а браузер - самой ресурсоёмкой программой на компьютере.
кмк, к фронтам относятся не очень хорошо вообще все, даже за пределами программирования - во многом благодаря именно им вэб стал таким жирным и тормознутым, а браузер - самой ресурсоёмкой программой на компьютере.
Ну конечно, это же не вина распространения интернета, и попыток дизайнеров выпендриться в извращенности внешнего вида сайта, плавных переходов, и размеров изображений. Ни один сервер не выдержит современных нагрузок, если все расчеты возьмет на себя. Хотя кривые кодеры тут тоже причастны, но реальная проблема далеко не в них. У меня лично мазила жрет 5гб при 50+ открытых вкладках.
>распространения интернета
а это здесь причём?
>выпендриться в извращенности внешнего вида сайта
например?
>плавных переходов
анимации в css3 выполняются на видеокарте и стоят копейки, пользуйтесь
>размеров изображений
вообще не проблема, даже я писал авторесайзер с кэшированием для modx более 5 лет назад
>Ни один сервер не выдержит современных нагрузок, если все расчеты возьмет на себя
выдать отрендеренную разметку вместо json'a - это конечно невероятная нагрузка, а тучи ajax-запросов на каждый чих - ну бывает, ничего страшного
а это здесь причём?
>выпендриться в извращенности внешнего вида сайта
например?
>плавных переходов
анимации в css3 выполняются на видеокарте и стоят копейки, пользуйтесь
>размеров изображений
вообще не проблема, даже я писал авторесайзер с кэшированием для modx более 5 лет назад
>Ни один сервер не выдержит современных нагрузок, если все расчеты возьмет на себя
выдать отрендеренную разметку вместо json'a - это конечно невероятная нагрузка, а тучи ajax-запросов на каждый чих - ну бывает, ничего страшного
А весь этот модный css и js который потом отрендерится на видеокарте храниться на ней же? При чем тут распостранение интернета? Серьезно? А как будет поживать твой сервачек, если ему надо будет выдавать по 10к рендеров в секунду, на 1к пользователей, который сидит на нем, на каждый их чих типо наведения на менюшку? А если пользователей будет под 100к как у какого нибудь онлайн магазина? А если миллионы как у Гугла, истаграма, фейсбука?
Очень важное мнение человека, который считает, что "осилить язык", или, тем более, "осилить фреймворк" - это достижение.
Когда-нибудь ты поймёшь, что это дело недели, это приходит с опытом.
Другое дело, что от некоторых языков и фреймворков хочется блевать, а от распыление обязанностей, когда один и тот же человек и швец и жнец, нужно бежать как можно дальше.
Когда-нибудь ты поймёшь, что это дело недели, это приходит с опытом.
Другое дело, что от некоторых языков и фреймворков хочется блевать, а от распыление обязанностей, когда один и тот же человек и швец и жнец, нужно бежать как можно дальше.
Я в курсе, что освоить технологию нормальному инженеру не проблема. Been there, done that. Любой язык или фреймворк - это инструмент для решения вполне конкретных задач. Распыление обязанностей, это когда инженера просят столы таскать. Нормальный архитектор должен уметь много чего. Да у него будет основной домен, но быть чистым фронтом после 15 лет работы инженером - это пиздец. Как и чистым бэком.
Меня наоборот жутко бесит, когда на проекте у тебя нет свободы действий, когда тебя загнали в рамки одной платформы, и ты не можешь ни запилить апи на беке, ни даже глянуть как оно запилено. А потом по всей системе идут баги интеграции, потому-что бек и мобайл не договорились друг с другом о деталях протокола общения
Для меня эта хуета со специализацией звучит вообще как отмазка для ленивых жоп, которые не хотят учить что-то новое. Да, первые года 3 лучше фокусироваться на чем-то одном, но дальше? Как, блять, расти? Ты не узнаешь новых парадигм, не поймешь проблем фронта или бэка, не будешь знать как хостится прилага и какие возможности есть у AWS или гугла. Какой язык лучше для определенной задачи? Какой ты нахуй инженер в таком случае?
шо то..., шо то...
правая картинка в обоих случаях
правая картинка в обоих случаях
Не согласен, сильно зависит от проекта. Если там высоконагруженный сервис где даже сборщик мусора ручками оптимизировали то бэк сложнее.
В большинстве случаев фронт сложнее, больше выбор как реализовать любую фичу, 20 библиотек на средний проект и сшить это всё вместе чтобы работало на разных разрешениях и разных браузерах, и ещё как-то тестить.
В большинстве случаев фронт сложнее, больше выбор как реализовать любую фичу, 20 библиотек на средний проект и сшить это всё вместе чтобы работало на разных разрешениях и разных браузерах, и ещё как-то тестить.
Чтобы написать коммент, необходимо залогиниться
