Подробнее
frontend dev doing backend
backend dev doing frontend
it юмор,программирование,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,смешные картинки,фото приколы
Первые чуваки занимаются логикой программы. Вторые чуваки занимаются внешним видом программы.
Когда первые чуваки делают внешний вид программы, он у них получается из ног вон руки, но в большинстве случаев получается. Когда вторые чуваки делают логику программы, она у них получается... Просто не получается, потому что бэкэнд сложнее фронтэнда.
И слава святым фрикаделькам. Одно время модно было пихать этот лютый пиздец в бекенд, и у меня подгорало. Хорошо, что сейчас наигрались, и похоронили ноду на бэке.
А вне веба никто из адекватных людей эту дичь и не думал использовать. Так и представляю себе какой-нибудь банк, у которого обработка транзакций идёт на js без проверок типов, и хранится это всё в json мусорнике ака "nosql".
Бэк - балки, сваи, фундамент, несущие стены. Фронт - внешняя отделка, мебель, двери и прочее необходимое для нормального юзанья домика. Джава - тот кривой сарай неподалеку в котором дед хранит старый мотоблок)))
Нет. Бэкэнд делает движок, его логику, физику, скриптовой движок, анимационный движок и прочую программисткую и заумную матанскую чепуху. Фронтэнд делает анимации, модельки, интерфейс, пишут диалоги, пишут скрипты и создают сцены в игре. (Но стоит помнить, что нарисовать и составить сцену - фронтэнд, но вот то, как объекты в сцене будут себя вести по игровой логике - это уже вопрос бэкэнда. Хотя в этом случае граница может частично стереться, так как тот же разработчик скриптового движка будет сидеть и писать скрипты чтобы оживить условную сцену, заставить НПЦ ходить туда-сюда, говорить заранее записанные фразы и так далее. Нужно смотреть конкретные примеры, условия и задачи).
Проще говоря, фронтэнд работает с тем, что пользователь видит непосредственно. Бэкэнд работает с тем, что пользователь не видит, но без чего программа не будет работать или не будет создавать полезную работу (в данном случае, быть игрой).
Это не так если говорить про игры. Иначе в случае онлайн игры или игры которая так или иначе взаимодействует с внешним сервером у тебя выйдет 2 бэкэнда. Для игр обычно делят на UI-тим (чисто логика пользовательский интерфейс и всё что с ним связано), core-тим (движок/основная игровая логика) и backend-тим (сервер, базы данных, etc.). Но при этом если проект/команда небольшие то фронтом могут называть клиентскую часть (от юи до бизнес логики).
Для AAA разделение еще сложнее: Есть UI которые пилят пользовательский интерфейс Есть Gameplay которые пилят игровую логику Есть Engine которые пилят и допиливают движок Есть Network которые занимаются взаимодействием с сервером Есть Render которые занимаются разными графичискими эффектами и оптимизациями Есть Tools которые пилят вспомогательные тулзы
Ну я откровенно упростил, что бы без сложностей и деталей пояснить не знакомому явно с темой человеку суть его не правоты.
а по сабжу: Ты упустил бекэнд (серверный). А там и инженеры баз данных, если продж многопользовательский там может быть серверный Gameplay (вся логика расчета реальных коллизий и регистрации попаданий) и т.д.
Всегда был уверен что фронт - функциональная часть клиентского интерфейса, плюс дизайн и свистоперделки, а бэк - серверная часть, обработка данных, алгоритмы выдачи и т.д.
Зависит от проекта, в целом. Со всякими ангулярами и вью может быть так, что почти всё висит на клиенте (ненавижу подобный подход). Но оставлять важную логику на фронтэнде нельзя. Например, логику проверки входящих данных, ибо с клиента можно отправить что угодно и как угодно.
Одно время было популярно делать обширную логику на фронте. Даже в крупных конторах. Но от этого ушли по банальным причинам безопасности. Слишком много логики в браузере, и ты не заметишь, как на клиент начнут летать внутренние данные, которых там быть не должно ни при каких обстоятельствах.
Всё ты правильно был уверен, EpicMan2 выше явно не программист. Внешним видом продукта занимаются дизайнеры, согласовывая этот самый внешний вид с продуктовой командой.
Одна из задач фронтенд программистов этот дизайн претворить в жизнь, но не следует забывать что это естественно не их единственная задача. Весь клиентский функционал тоже на них. Я не знаю какого хуя распространено мнение, что фронтенд легче или при его разработке можно забить хуй на архитектуру приложения.
Если я работаю сейчас над приложением на котлине и пишу в основном логику, я что бэк разработчик получается?
А "UX-ер" по твоему не дизайнер? Ты даже если просто загуглишь "UX", пояти везде эти две буквы будут сопровождаться словом дизайн, я уже не говорю про вакансии.
да, UX-дизайн, верно ) но ты ж пишешь про внешний вид, а UX, в первую очередь, про поведение и логику: например, на какой странице и где должны находиться кнопки, блоки с контентом, почему такой состав и т.п.
Я так и объяснил. Или та часть, которую видит пользователь, перестала входить во "внешний вид программы"? Или "серверная часть, обработка данных, алгоритмы выдачи" перестала входить в логику программы?
Нашлёпкой формы для отправки обратной связи занимается фронтэнд, а вот обработкой письма и его отправкой по назначению (условной компании) занимается уже бэкэнд.
выкинь эту каку ) лет 10 назад вполне катило, сейчас задолбаешься все в одно рыло поддерживать - технологии расплодились и усложнились на всех сторонах
На моей второй работе я (бэкенд) заменял не только фронтенда, но и бизнесаналитика, проджект менеджера, qa, дизайнера (частично). Все, сука, 10 лет, по мере необходимости, не смотря на то, что контора выросла с 10 до 300 человек, кадров постоянно не хватало. А на некоторых проектах и всех одновременно. Вообще никаких проблем не было - справляться с их работой, хотя никаких курсов я не проходил для этого. И проекты не кустарные, для именитых брендов.
Бэкенд обслуживает фронтенд. Обычно на бэкенде реализована бизнес-логика, а на фронтенде - прикладная. Например, сервер, который обслуживает веб-приложение - это бэкенд, а клиентская часть - фронтенд. С другой стороны БД, обслуживающая сервер - это тоже бэкенд, а сервер - уже фронтенд. Абдулла, который заворачивает тебе шаурму - это бэкенд, а кассир - фронтенд. Все отностительно и зависит от точки зрения, просто в паре сервер/клиент это используется чаще всего.
Да нихуя! Если все время сидишь на back end, толком не знаешь css, и ебешься с этим говном как можешь, а потом оно становится не поддерживаемым. Да, back dev может сделать рабочую версию, но красивую как требует дизайнер - хуй тама
бэк берёт bootstrap, готовый шаблон для bootstrap, прикручивает его к server side шаблонизатору и уже получает адекватный интерфейс, с которым можно работать.
Про css не совсем понял - css2 простой как правда, а css3 для "сделать красиво" обычно и не нужен
фронт тоже может поставить wordpress или bitrix и получить что-то минимально рабочее, но как-либо их кастомизировать он не осилит.
Адекватный интерфейс... ахахах, мяу. Он будет настолько же адекватный, как бэк написанный фронтом. Тут куча бэкенд разрабов чтоль повылазило, которые пытаются всем доказать какие они важные и нужные? И то и то в данный момент очень обширные и сложные темы, и хрен ты что адекватное быстро сделаешь попытавшись перейти с фронта да бэк и наоборот, к чему эти меринья письками?
Я конечно такой себе кодер, но флексы, гриды, это верстка, при чем тут фронт? Если тебе не нужно SPA и что-то подобное микросервисное, и у тебя монолит, то зачем тебе фронт, тебе нужен верстальщик. Это все равно что я буду говорить что бэк без работы с базой данных такой же как и был, он просто раздает статику.
>Тут куча бэкенд разрабов чтоль повылазило, которые пытаются всем доказать какие они важные и нужные?
кмк, к фронтам относятся не очень хорошо вообще все, даже за пределами программирования - во многом благодаря именно им вэб стал таким жирным и тормознутым, а браузер - самой ресурсоёмкой программой на компьютере.
Ну конечно, это же не вина распространения интернета, и попыток дизайнеров выпендриться в извращенности внешнего вида сайта, плавных переходов, и размеров изображений. Ни один сервер не выдержит современных нагрузок, если все расчеты возьмет на себя. Хотя кривые кодеры тут тоже причастны, но реальная проблема далеко не в них. У меня лично мазила жрет 5гб при 50+ открытых вкладках.
>выпендриться в извращенности внешнего вида сайта например?
>плавных переходов анимации в css3 выполняются на видеокарте и стоят копейки, пользуйтесь
>размеров изображений вообще не проблема, даже я писал авторесайзер с кэшированием для modx более 5 лет назад
>Ни один сервер не выдержит современных нагрузок, если все расчеты возьмет на себя выдать отрендеренную разметку вместо json'a - это конечно невероятная нагрузка, а тучи ajax-запросов на каждый чих - ну бывает, ничего страшного
А весь этот модный css и js который потом отрендерится на видеокарте храниться на ней же? При чем тут распостранение интернета? Серьезно? А как будет поживать твой сервачек, если ему надо будет выдавать по 10к рендеров в секунду, на 1к пользователей, который сидит на нем, на каждый их чих типо наведения на менюшку? А если пользователей будет под 100к как у какого нибудь онлайн магазина? А если миллионы как у Гугла, истаграма, фейсбука?
как-то мы с фулопсом и девстеком замутили проект.. ну, прям, проектище! Так и хотелось крикнуть и перевернуть мир... а получилось как обычно - пукнуть и уснуть )))
Очень важное мнение человека, который считает, что "осилить язык", или, тем более, "осилить фреймворк" - это достижение. Когда-нибудь ты поймёшь, что это дело недели, это приходит с опытом. Другое дело, что от некоторых языков и фреймворков хочется блевать, а от распыление обязанностей, когда один и тот же человек и швец и жнец, нужно бежать как можно дальше.
Я в курсе, что освоить технологию нормальному инженеру не проблема. Been there, done that. Любой язык или фреймворк - это инструмент для решения вполне конкретных задач. Распыление обязанностей, это когда инженера просят столы таскать. Нормальный архитектор должен уметь много чего. Да у него будет основной домен, но быть чистым фронтом после 15 лет работы инженером - это пиздец. Как и чистым бэком.
Это, конечно, в контексте вэба. Также надо иметь понимание облачных сервисов, это вообще дэвопс, но удачи сделать нормальную архитектуру без понимания базовых вещей.
Меня наоборот жутко бесит, когда на проекте у тебя нет свободы действий, когда тебя загнали в рамки одной платформы, и ты не можешь ни запилить апи на беке, ни даже глянуть как оно запилено. А потом по всей системе идут баги интеграции, потому-что бек и мобайл не договорились друг с другом о деталях протокола общения
Для меня эта хуета со специализацией звучит вообще как отмазка для ленивых жоп, которые не хотят учить что-то новое. Да, первые года 3 лучше фокусироваться на чем-то одном, но дальше? Как, блять, расти? Ты не узнаешь новых парадигм, не поймешь проблем фронта или бэка, не будешь знать как хостится прилага и какие возможности есть у AWS или гугла. Какой язык лучше для определенной задачи? Какой ты нахуй инженер в таком случае?
> потому-что бек и мобайл не договорились друг с другом о деталях протокола общения
Потому что полное описание протоколов общения должно быть написано и утверждено(в виде документации) ДО того, как это имплементируется как на фронте, так и на беке.
Это какая-то сказочная ситуация. Обычно все происходит так: надо запилить вот такую хуйню, работать она должна так-то. Как вы это будете делать - не наша беда. Выполнять! Какое описание протоколов? Какая документация? О чем вы вообще?
Ну вот потому, когда я вижу вакансию "требуется fullstack девелопер", я читаю "у нас нихуя нет денег на команду бэк, команду фронт, команду аналитиков, техрайтеров, и менеджеров, потому мы хотим нанять всё это в одном лице за цену одного человека".
Ну да, зато на "не галерах" есть просто мутные приказы, людей не хватает, пара фуллстек девов делает всё, от настройки продакшна до фронта, бека, и немножко таскают столы при переездах, никакой документации, никаких ТЗ, всё на словах, и у руководства 7 пятниц на неделе. Видел я такую "радость". Это, тащемта, та же галера, только вместо сотни гребцов - полтора фуллстека, которые, как в том анекдоте, если им фонарь повесить, ещё и ночью грести будут. Да и без фонаря будут, в таких конторах хуй кто следит, чтобы разрабы не перегорали от работы.
Блять, поработай хоть год в стартапе, пройди сид раунд хотя бы на лям, а потом распрягай мне о специализации. Заебись идти в компанию, в которой 1к+ гребцов и петь о специализации. Только ты тогда простой слесарь, а не инженер. Пришел, тасок из трекера взял, отсюда и до обеда похерачил говнокод и свалил.
Когда-то они все были нищщими стартапами. Я щитаю каждому проэкту нужен человек-паровоз, который вытащщит его в самом начале. Без такого человека этап со списком тасочек никогда не наступит
Не согласен, сильно зависит от проекта. Если там высоконагруженный сервис где даже сборщик мусора ручками оптимизировали то бэк сложнее. В большинстве случаев фронт сложнее, больше выбор как реализовать любую фичу, 20 библиотек на средний проект и сшить это всё вместе чтобы работало на разных разрешениях и разных браузерах, и ещё как-то тестить.
Продвинутая
Ргоггёепс!
разработка
Бесплатный курс от экспертов*9^^
Старт курса: сентябрь Подать заявку
Заполни анкету-
августа
заполни анкету-резюме чтобы мы могли оценить твой опыт
г Пройди 1
отправим письмо с
результатами
проверки анкеты-
резюме и пригласим
на интервью А
Стар
Если бы Rammstein занимались программированием вместо музыки
do
do class do doss if. do
do class do class if.
doI
do class do class if do class if! do class if inline do class if inline do class if inline bool this delete define
this do int break sizeof public try if struct for auto static...
Вторые чуваки занимаются внешним видом программы.
Когда первые чуваки делают внешний вид программы, он у них получается из ног вон руки, но в большинстве случаев получается. Когда вторые чуваки делают логику программы, она у них получается... Просто не получается, потому что бэкэнд сложнее фронтэнда.
чьё применение сегодня по большей части - запустить webpack, который запустит компилятор, транспилер, минификатор и иногда даже обфускатор
на бэке оно никогда высоко не взлетало и уже никогда не взлетит
Одно время модно было пихать этот лютый пиздец в бекенд, и у меня подгорало. Хорошо, что сейчас наигрались, и похоронили ноду на бэке.
Так и представляю себе какой-нибудь банк, у которого обработка транзакций идёт на js без проверок типов, и хранится это всё в json мусорнике ака "nosql".
Смотря на чем написан проект
вот тоже всякая хуйня в голову лезет
Хотя и не так, как js и баш.
Остальное, запиленное криворукими обезьянами, говно проще игнорировать
Проще говоря, фронтэнд работает с тем, что пользователь видит непосредственно. Бэкэнд работает с тем, что пользователь не видит, но без чего программа не будет работать или не будет создавать полезную работу (в данном случае, быть игрой).
Есть UI которые пилят пользовательский интерфейс
Есть Gameplay которые пилят игровую логику
Есть Engine которые пилят и допиливают движок
Есть Network которые занимаются взаимодействием с сервером
Есть Render которые занимаются разными графичискими эффектами и оптимизациями
Есть Tools которые пилят вспомогательные тулзы
и это всё только программисты
а по сабжу:
Ты упустил бекэнд (серверный). А там и инженеры баз данных, если продж многопользовательский там может быть серверный Gameplay (вся логика расчета реальных коллизий и регистрации попаданий) и т.д.
И да, тут мы только о программерах говорим.
Одна из задач фронтенд программистов этот дизайн претворить в жизнь, но не следует забывать что это естественно не их единственная задача. Весь клиентский функционал тоже на них.
Я не знаю какого хуя распространено мнение, что фронтенд легче или при его разработке можно забить хуй на архитектуру приложения.
Если я работаю сейчас над приложением на котлине и пишу в основном логику, я что бэк разработчик получается?
Смелое утверждение.
Я сократил объяснение до максимально понятного простому человеку, не вдаваясь в более глубокие подробности.
Нашлёпкой формы для отправки обратной связи занимается фронтэнд, а вот обработкой письма и его отправкой по назначению (условной компании) занимается уже бэкэнд.
А ещё есть "фуллстек разработчики", которые как морская свинка...
Про css не совсем понял - css2 простой как правда, а css3 для "сделать красиво" обычно и не нужен
фронт тоже может поставить wordpress или bitrix и получить что-то минимально рабочее, но как-либо их кастомизировать он не осилит.
и что же такого интересного есть в арсенале фронта для (полу)статичной странички?
>И то и то в данный момент очень обширные и сложные темы, и хрен ты что адекватное быстро сделаешь попытавшись перейти с фронта да бэк и наоборот
за пределами SPA, фронт +/- такой же, как и 10 лет назад, а SPA, как известно, нужен далеко не всегда и далеко не везде.
Флексы, гриды и прочее - иной подход к тем же задачам, ничего фундаментально нового там нет.
все верстаки теперь гордо именуют себя junior front-end developer
>Это все равно что я буду говорить что бэк без работы с базой данных такой же как и был, он просто раздает статику.
static site generator это называется. Отличная тема, на самом деле. И да, она имеет отношение к бэку.
кмк, к фронтам относятся не очень хорошо вообще все, даже за пределами программирования - во многом благодаря именно им вэб стал таким жирным и тормознутым, а браузер - самой ресурсоёмкой программой на компьютере.
а это здесь причём?
>выпендриться в извращенности внешнего вида сайта
например?
>плавных переходов
анимации в css3 выполняются на видеокарте и стоят копейки, пользуйтесь
>размеров изображений
вообще не проблема, даже я писал авторесайзер с кэшированием для modx более 5 лет назад
>Ни один сервер не выдержит современных нагрузок, если все расчеты возьмет на себя
выдать отрендеренную разметку вместо json'a - это конечно невероятная нагрузка, а тучи ajax-запросов на каждый чих - ну бывает, ничего страшного
"ничего не понятно, но очень интересно" (С)
>А если пользователей будет под 100к как у какого нибудь онлайн магазина? А если миллионы как у Гугла, истаграма, фейсбука?
мальчик не знает что такое "горизонтальное масштабирование"? или мальчик думает, что весь fb крутится на одном сервере?
И сколько rps выиграет сервер, если отдаст отрендеренную страничку не целиком за раз, а серией аяксов?
Когда-нибудь ты поймёшь, что это дело недели, это приходит с опытом.
Другое дело, что от некоторых языков и фреймворков хочется блевать, а от распыление обязанностей, когда один и тот же человек и швец и жнец, нужно бежать как можно дальше.
Потому что полное описание протоколов общения должно быть написано и утверждено(в виде документации) ДО того, как это имплементируется как на фронте, так и на беке.
Видел я такую "радость". Это, тащемта, та же галера, только вместо сотни гребцов - полтора фуллстека, которые, как в том анекдоте, если им фонарь повесить, ещё и ночью грести будут. Да и без фонаря будут, в таких конторах хуй кто следит, чтобы разрабы не перегорали от работы.
правая картинка в обоих случаях
В большинстве случаев фронт сложнее, больше выбор как реализовать любую фичу, 20 библиотек на средний проект и сшить это всё вместе чтобы работало на разных разрешениях и разных браузерах, и ещё как-то тестить.