@Abyss --- Добавлено --- @TeslaFeo Есть не много но я исправился. Честно) --- Добавлено --- @denis01, @[vs], @Fell-x27 Спасибо за рассуждения на эту тему. Очень благодарен. Просто я думал может быть и я не прав. Но всё таки думаю что правильный вариант работы в паре back and front, это когда back массивчики формирует и в шаблон отправляет. А уже фронт в шаблоне массивчики разбирает а там как ему хочется так и разбирает формирует json и засовывет в js или ещё как то мне пофиг пусть сам скажет как ему удобней так и буду отправлять, но суть в том он вообще сказал что не будет этим заниматься
Это почти золотая середина, когда вы оба понимаете javascript, PHP и как работают сайты. Работаете в паре, так быстрее. Это уже должен решать тот кто платит. Главное что ты внёс рационализаторское решение.
Гнать его нахер и всё. Потому что верстка для конкретного проекта - это не тупо наверстать хтмлок, ты должен продумать общую структуру, компоненты, возможности кастомизации и расширения, при чем желательно с учетом возможностей бэка и хотелок тз. Если он этого не хочет, то пусть идет лесом, ибо тех кто из фотошопа выдаст разметку можно на фрилансе найти за 100 рублей пучок. Серьезно, потом всё равно придется переделывать все что он там наверстал, потому как такие "труды" не пришьешь к бэку ни каким боком. Лишняя трата времени и денег.
Он пытается тобой манипулировать, а ты этому сопротивляешься. Тут вообще не в работе дело. --- Добавлено --- Если ты начальнику скажешь, что кого-то надо гнать, то он подумает, что ты строишь козни по личным мотивам и выгонет тебя.
... кто и что должен делать следуя зоне ответственности и архитектурному строению проекта. Если под front-end в данном случае воспринимается работа с php говном в шаблонах, то удачи в спорах. Это вообще ui-designer какой-то. Ты понял в чем соль оп-поста ? Пиздеж. Он пытается открестится от той параши, которую ему суют. Может чувак там всю жизнь угорает по jQuery и был нанят именно ради компоновки и оживления страницы и не сном не духом о пышке.
@TeslaFeo сделал простое умозаключение исходя из разборок backend vs frontend на тему php кода в шаблонах.
Удваиваю. Хочешь занять фронта? Переходите на какой-нибудь React, переводи сервер с плевания версткой на плевание json-ами, и пусть фронт аки лебедь в этом озере живет. Заняться будет чем каждому, я гарантирую это. С какого-то момента он даже начнет ныть, что у него нагрузка больше твоей. Это вот будет реально разделение сервера и фронта. Между вам будет только JSON, бегающий от клиента к серверу и от сервера к клиенту. И все ваши терки будут упираться только в согласовании его содержимого. Я тебе больше скажу - при таком подходе, каждый может работать независимо от другого, ручками себе набивая типа входящие данные, и делать свое дело. А потом уже "женить" наработки.
Не согласен не все проекты можно взять и легко перевести на реакт или ангуляр. Тем более уже работающие.
@askanim я не понимаю что ты мне пытаешься доказать. Я тебе уже всё пояснил. Да, он верстальщик или недо-фронтенд. Он не тот кто вам нужен. Объясните это ему, а там или ищите замену или найдите решение. /нить
Обычно на одну компетенцию несколько специалистов, что-то надо совмещать. По этому просто нужно договориться.
Оке, ну а UI у вас заканчивается на статичной верстке чтоль, что ему заняться нечем? Для него там нет всяких аякс-приблуд, подгрузок, он уже написал все галереи, редакторы, выделялки лиц на фотографиях? Он уже запилил вам кастомный плеер с защитой контента и все у вас работает сугубо на HistoryAPI, как у взрослых?
Верстальщик в духе "я вижу скрин фотошопа и делаю из него html, а дальше ебитесь как хотите" бесполезен чуть более, чем полностью, если он конечно не приглашенный на один раз фрилансер. Есть те кто решают проблемы бэка, есть те кто решают проблемы фронта. Остальных надо лесом, что бы не терять на них время.
Чтобы он это сделал он должен понимать как работает и сервер и клиент. И вообще чтобы это сделать нужно работать полностью со view иначе получится каша он пишет запросы, а я не знамочи что у него и где буду лазить как ежик в тумане в файликах по view. Для того чтобы вывести какие то данные из бд, а ещё на основе вывода данных из бд могут строится последующие post get запросы. То есть мне проще уже будет самому пост гет запрос писать на сервер, чем постоянно лазить во view выводить данные и после этого говорить ему какой мне отправить нужно запрос и какие данные прислать по тысячи раз переключаясь между вкладками одно дело повернутсья к нему и сказать мне надо это и это и это а другое дело сначала залезть в его код а потом ещё и повернуться ему и сказать. Я думаю это только усложнит задачу и сделает сроки длиннее, нежели я сам буду всё писать.
Лавхак - если согласовывать формат транспорта и порядок обмена данными, не придется лазить как ежик в тумане. Разработайте единый формат для JSON-сообщений между сервером и клиентом. И чтоб сообщение обязательно содержало тип. И специфичные для него данные. И договоритесь, что для такой-то функции будет такой-то тип, такие-то аргументы. И ответ должен выглядеть так-то. И единый AJAX-шлюз для всего на клиенте и единый на сервере. Которые принимают-отправляют, дергая соответственные коллбэки, в зависимости от типа. Если, к примеру, оговоренная функция не готова на сервере, вместо ее ответа пусть сервер отсылает заранее заготовленный ответ-заглушку, удовлетворяющий ранее обговоренному формату, содержащий инфу, которой будет достаточно для клиента. Когда будет готово - ты убираешь заглушку и отдаешь реальные данные. При это тебе даже не нужен клиент. Твое тестирование будет сводиться только к проверке соответствия выдаваемого пакета данных с эталонным. Если ты назвался архитектором, ты должен уметь видеть такие вещи при проектировании. Закладывать их изначально. Изначально продумывать правильный пайплайн, взаимодействие, разделение сфер, упрощение разработки, чтобы одни не ждали других. Вот вас двое. А потом? А будет вас двадцать? Будешь за каждым бегать? Нет же. Задача серверщика - чтоб сервер отдавал данные и принимал запросы. Реализована у клиента работа с ними или нет - уже головняк фронта. Нет? Тогда говори начальнику, что надо нанимать архитектора. Но это дорого. Архитекторы - это сеньоры, либо жирные миддлы. Можно можно. Только чем позже займетесь, тем сильнее будет припекать пониже спины.
Все соцсеточки сейчас работают с полным отделением сервера от клиента тонким транспортным мостиком. И их сервера не плюются HTMLем. Потому что это дорого шопиздец, когда речь идет о нагрузке. Кидаться минимальным набором данных дешевле. Ты же прикидываешь проблемы, связанные с нагрузкой, @askanim? Вот надо будет прикрутить кэш. Будешь там куски верстки хранить? А может проще один раз отдать клиенту, через статику, JS-либу, которая будет собирать страницу уже на месте? Ты представляешь объем экономии трафика, учитывая избыточность HTML? Ты рассчитываешь объемы эффективности использования каналов?
Соцсеточка - штука динамичная и требует мгновенной реакции на события, тут новость добавилась, там сообщение пришло... А значит нужны сокеты, что бы быстро доставлять и главное, сразу же отражать всё это непотребство в браузере. Когда у тебя есть то, что может отрисовать страницу исходя из набора данных - это легко, когда же логика рендера разбита на бэк и фронт начинаются проблемы: надо следить за состоянием и там и там, что бы не отдать ничего лишнего, ну или вообще не то что нужно. Короче, по факту для соцсеточки нужно два проекта - бэк и фронт, общающиеся между собой строго по api. Иначе, как сказал Сурикат, припекать начнет очень скоро и таки беспощадно ))
А в чем проблема? С тем же успехом можешь спросить"у нас весь проект на JS, как его перенести на реакт?". Не важно на чем проект. Важна архитектура. Окей, не реакт. Хотите без него - делайте без него. Генерите верстку хоть жиквери, хоть чистым JS. Это не запрещено, просто на реакте это удобнее реализовано. Суть не в реакте и не в бекбоне. Суть в том, что если хочешь по-взрослому пилить проект, у которого перспектива - хайлоад, то нужно, чтобы клиент занимался клиентской частью, а сервер серверной, и чтобы граница между ними была четко очерчена. И чтобы пересекал ее только транспорт данных.
@askanim jQuery тоже можно, хотя он не заточен. В любом случае изменение архитектуры так, как это описывает @Fell-x27, потребует от фронтендера титанических усилий и задержит разработку. Как объяснить начальнику, почему это важно и почему не делали так сразу - та ещё задачка. Хорошее чтиво: https://m.habrahabr.ru/post/303626/ Это - сегодня, а завтра классические шаблоны вымрут.