Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

Взаимодействие frontend и backend разработчиков

Всем привет!
Столкнулся со следующей проблемой. Есть шаблоны в backend (Django, Django template engine), c логикой и вложениями и есть front-end шаблоны, которые на стадии разработки часто меняеются, причём меняются большими кусками (разработчик использует Jade) и при каждой мелочи бывает заменяется столько, что diff на том же github просто ни о чем не говорит.

Вопрос: Как backend(у) с наименьшими затратами времени поддерживать актуальность своих шаблонов? Буду рад услышать о том как это происходит у вас.

Какие варианты я вижу:
1. Позволить front-end(у) работать с back-end репозиторием и дать ему возможность работать с шаблонами напрямую.
2. Настроить процесс разработки так, чтобы конечный шаблон фронтенда генерировался с блоками кода back-end(a)
3. Оставить всё как есть, backend-разработчик вручную будет вносить изменения в шаблоны при каждом изменении (крайне неэффективно)

Наверняка есть ещё куча вариантов, у всех есть свои плюсы и минусы. Многие из них создают дополнительную сложность. Что используете вы? Наверняка есть какие-то отработанные решения.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Всем огромное спасибо! Действительно интересно слышать разные позиции. Даже удалось понаблюдать за битвой мнений )) Всё очень полезно. Сделал для себя вывод, что вариант 1 (общий репозиторий) для длительной работы в одном проекте, со стабильной командой — самый работоспособный вариант.

Используем первый вариант вкупе со вторым. Да, бывают проблемы, но если коммуникация налажена — то их становится значительно меньше.

Мне кажется, лучше иметь все шаблоны на одной стороне. Короче

Django template engine
это зло в вашем случае.

Верстальщик должен генерировать из Jade backend-шаблоны. И всем будет хорошо.
Как пример погуглите доклад Jade+PHP, суть таже.

Посмотрел, интересно, Twig по синтаксису похож на Django Template Engine. Но опять таки, ок, верстальщик включает элементы логики движка, но работать-то они не будут, то есть он не сможет посмотреть как оно выглядит вживую без того, чтобы закачать свой шаблон на сервер. Но согласен, для удобства верстальщика, если привык использовать Jade и может работать с общим репозиторием то это вариант.

У верстальщика тоже должно быть поднят env/сервер/etc, чтоб он мог видеть это все вживую.

... есть еще частая проблема рассинхронизация хтмл в проекте и у верстальщиков.

Одна из причин — у вордпресов с джангами есть средства генерации хтмл кода. Их конечно можно не использовать, но тогда придется писать вручную привязки к данным. А если их использовать — то чтобы верстальщик не сломал его и им нужно обучать.

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

И такой вид замедления разработки не решается приглашением фронтендщика в серверные темплейты.
Если этот затык действительно начинает увеличивать сроки, то надо переходить или к БЭМ, или менять порядок разработки: не натягиваем верстку, а делаем средствами фреймворка структурную верстку — которую потом цсс превращаем в то что сотворил дизайнер, а если не получается — то просим дизайнера малость упростить творчество в проблемных местах.

То есть нужно понимать, что индивидуальный дизайн не обязательно делается ручной версткой. Но если пошли путем ручной верстки — то просто пустив верстальщика на сервер проблемы нет решить. А конфликты на почве совместной ответственности — не заставят себя долго ждать.

лучший способ — дать доступ front end-у к работе с шаблонами на back end-e. И вот почему:
— есть возможность сразу протестировать на реальном сайте, набитом разношерстной информацией;
— не нужно лишний раз дергать back end разработчика по мелочам, у него больше времени на другие нетривиальные задачи;
— нету пробки в процессе разработки, когда back end разработчик не может оторваться сейчас от другой задачи и задерживается тестирование на front end;
— поднимается компетентность front end разработчика в вопросах шаблонизации на back end.
Это конечно все субъективно и зависит от многих дополнительных факторов: загруженность, deadline-ы, уровень компетенции специалистов, etc..

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

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

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

или когда модель поменялась, — звать верстальщика переверстывать?

в те меса где должны быть данные пихает рыбубек разработчик замяет левые тексты выводом реальных данных
то есть сверстан скажем список, в 5 элементов, чтобы заказчик утвердил,
и — какой рыбой помочь заменить его результатом обхода массива, модели, ...?
прикольно когда на классы цепляется логика работы UI, а верстальщик не в курсе
достаточно легко разруливается в общем случае:
1. специальная нотация для классов-якорей(например, префикс js-)
2. запрет на привязывание каких бы то ни было стилей к ним
3. в код-ревью учитывать

Конечно все разруливается, проблеме то сто лет в обед.
Только названные способы не универсальны. Потому что требуют подготовки верстальщика.

А нередко верстальщик — сторонний и непостоянный. И ему не очень интересно осваивать эту «придурь» программистов.

Если же всеми этими правилами программист украшает хтмл, то вот она и рассинхронизация когда придет отрефакторенная верстка, потому изменился дизайн, нут ка, вручную и смердж теперь.

js-префиксы — это уже лет 5 как стандарт индустрии, какая ещё «подготовка верстальщика», какая «придурь программистов»? Выкиньте вашего верстальщика на мороз.

выкинуть то несложно.
вопрос только — сколько времени будет закрываться вакансия, на освободившееся место.

вы о дефиците программистов слышали?
с верстальщиками нужного уровня — тоже самое.

а так конечно, если все участники проекта — реальные синьоры — проблем нет.

а лучше синьоры-фулстеки — и верстают круто и быстро, и на ангуляре бац, бац педалят, и спрингом с хибером их не испугать.

всех остальных — на мороз, и будет успех!

меня вот тоже надо выкинуть на мороз, я за более чем 20 лет так и не стал фулл-стек синьором.
и думаю свыше 90% доучан надо выгнать на мороз :)

Ну на рынке хватает толковых верстальщиков, что работают за 600-1000$. Предложите им 1000-1500 и закроете вакансию.
Не надо пытаться найти мастера на все рукифулстек-девелопера, который умеет всё и ничего толком, проходили уже в нулевые, были у нас «веб-мастера».

Предложите им 1000-1500 и закроете вакансию.
когда EPAM закроет все свои вакансии например хотя бы в разделе «Работа» на доу — тогда можно будет и послушать советы — как быстро закрывать вакансии ;)
Предложите им 1000-1500
«Не учите меня жить, лучше помогите материально»

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

пусть идут на мороз такие заказчики — дельный конечно совет.

примерно в духе
у них нет хлеба, так пусть едят пирожные.

были у нас «веб-мастера».
и потребность в них осталась.

и в вакансиях вполне так и пишут
Full Stack Developer

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

а платить одному мозгу можно в полтора раза больше, вместо как двоим — в два раза.

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

на мороз небольшие проекты?

Ну EPAM вакансии закрывает достаточно быстро, просто он открывает новые и набирают ещё и ещё и ещё. И кстати верстальщиков там почти нет.

Нет 1000-1500 (это кстати ещё немного) на всего одного человека на проект? Ну наверное есть деньги мучатся и тратить кучу времени других тоже дорогих специалистов.

Я проработал 10 лет в веб-студии, где специализировались именно на небольших и очень быстрых проектах (хотя есть и большие на поддержке), и там было жёсткое разделение скилов, проекты сдавались в срок, деньги зарабатывались, компания росла.

Нет 1000-1500 на всего одного человека на проект?
при бюджете в 2-3k на месяц? конечно легко!
Я проработал 10 лет в веб-студии
«аргумент блондинки» не рассматриваю. принципиально.

Я сдал сотни проектов с бюджетом 2-3k на весь проект. Проект сдавался за 2 недели с верстальщиками с зп 600-1200 и не с одним таким на проекте, а с двумя-тремя людьми одновременно (один ведущий и пару в помощь ему).
Ещё и на бонусы хватало.

Нет 1000-1500 на всего одного человека на проект?
Я сдал сотни проектов с бюджетом 2-3k на весь проект.
а с двумя-тремя людьми одновременно
с зп 600-1200

я не пойму ваших цифр.

например

Я сдал сотни проектов
Проект сдавался за 2 недели

365/7/2 = 26 проектов в год.
сдал сотни проектов — то есть минимум в таком темпе вы сдавали проектов около 4ех лет. а раз множественное число то — больше.

у меня какие-то сомнения.
вы были пиэмом в веб студии эти минимум 4ре года?

а то что с верстальщиками за 600-800 можно успешно сдавать проекты, даже когда они не хотят следовать упомянутой «придури» программистов — обычное дело.
и выходит дешевле, чем брать верстальщика за 1500.

По цифрам всё просто: норм верстальщик получает 600-1000$ jobs.dou.ua/...uage=&spec=&exp1=2&exp2=5
Я с такими и работал.

Вам нужен норм. верстальщик на проект, говорите негде найти — я вам советую предлагать 1000-1500 чтоб закрыть вакансию.

PM 4+ года, да, но также 10 лет руководил отделом верстки (и верстал сам) поэтому выпустил много всего. Проектов было больше чем 26 в год, ведь в веб-студиях проекты идут паралельно несколько штук (5-10).

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

вы из тех кто считает что остальные такие кретины, что не в курсе что вакансии можно закрывать быстро, предлагая топовые зарплаты :D

да, такие вот кретины сплошь кругом, вы вот на одного такого время потратили :)

По цифрам всё просто: норм верстальщик получает 600-1000$
но предлагать надо 1500.

логика!

Вам нужен норм. верстальщик
норм. верстальщик — это 600-1000$

1500$ — это уже не норм. вы не находите? я так думаю что верстальщики в Яндекс получают в разы больше. ориентироваться на яндексные зп верстальщиков — будет нормальным? в смысле — адекватным?

нормы зарплат устанавливаются исходя из предложения на рынке заказов.
значит для ненорм верстальщика надо ненорм проекты.

PM 4+ года, да, но также 10 лет руководил отделом верстки

но я так и не понял, почему для нормальных проектов, вы предлагаете затраты на ненормального верстальщика в ненормальных проектах.

В Яндексе маленькие зарплаты, 1500$ у верстальщиков там бывает, но не у всех и ни о каких «в разы больше 1500» даже речь не идёт. «Работать в нашем банке большая честь».

Я предлагаю всего-лишь взять нормального верстальщика на проект. Нормальные обычно уже где-то работают и получают свои минимум 600-800. Поэтому чтоб они перешли к вам — вам надо предложить значительно больше.

Ну или искать тот случай, когда человек сам решил уйти с компании (что-то его не устраивает) и его вполне устроит переход и на такую-же точно зп в другую. Такое тоже есть.

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

в Яндексе не бывает, а вот мелкая студия — должна предложить верстальщику 1500$.

Я предлагаю всего-лишь взять нормального верстальщика на проект.
вы тролите что-ли?

я ж давно уже отшутился на тему этого гениального в своей простоте предложения стать миллионером и махом решить тьму мелких бытовых проблем :)

Нормальные обычно уже где-то работают и получают свои минимум 600-800.
то есть там и не могут платить больше, а вот «у нас» — точно смогут!

мы да, мы такие особенные, что на тех же проектах, с теми же бюджетами заказчика можем в отличие от них платить не 600-800, а 1200-1500. и остальным тоже, php программистам как джавистам например. да, чего там жлобиться!

да, арифметика и логика у вас очень доходчива.
спасибо.

Они так платят потому что нанимают их ещё джунами (точнее трейни) и постепенно повышают рейт. Для вас это раньше был бы тоже реальный хороший вариант, я сам так делал — нанимал на 300-400$, прокачивал и постоянно поднимал зп, человек выростал, через год получал 600, ещё через год — 700-800.

Сейчас так не получится, потому что большие компании сами гребут студентов прямо из-за парт к себе на подкурсы, платят эти же деньги, вот только перспектив в большой компании больше + нанимают они сотнями(!), и маленьким компаниям ничего не остаётся, точнее остаются те, кого выгнали из подкурсов «лидеров рынка» за неуспеваемость.

Ну нанимать на 300 можно и щас, «войти в айти» хотят все, желающих выстроится очередь от Градусника до Лесопарка, вот только кого брать? Большие компании берут лучших, напичкивают их сразу разжёванными готовыми знаниями и получают на выходе джунов со знаниями мидлов. А у вас кто будет менторить этих трейни, кто их хоть чему-то научит, если вы даже на 1000$ верстальщика не хотите взять.

маленьким компаниям ничего не остаётся, точнее остаются те, кого выгнали из подкурсов «лидеров рынка» за неуспеваемость.
т.е. вы предлагаете платить неуспевающим больше чем в больших компаниях.

или я чего-то опять не так понял?

знаете, я часто слышал от менеджеров, и потом убедился что вообще-то так и есть
хороший менеджер выстраивает работу исходя из доступных ресурсов. плохой — жалуется что работу невозможно выстроить потому что у него не хватает нужного количества ресурсов: денег, нужного качества людей, а вот если бы ему дали...

я не ставлю под сомнения ваши качества менеджера.
поэтому раз вы даете советы как плохой менеджер, считаю что вы просто тролите.

за сим откланиваюсь

т.е. вы предлагаете платить неуспевающим больше чем в больших компаниях.
или я чего-то опять не так понял?
я предлагаю следующее:
  1. Уволить нынешнего верстальщика, нанять нормального. На цене можно сэкономить поискав среди тех, кто сам задумывается о смене работы, тогда получится выйти на 600-800. Не требовать знаний ангуляра и т.д, вам же нужен просто хороший верстальщик, а не js-dev, что криво-косо может что-то заверстать. Но повышать зп все равно придётся в будущем, иначе он уйдет от вас. Повышение рейта привязать к доходу который приносят свёрстанные им проекты (растёт маржа — растёт его рейт).
  2. К нему в команду нанять парочку трейни за 200-300$, он их подтянет до нужного уровня, поднимете им рейт на +50+100 и они будут с удовольствием педалить, т.к. на галеры их без знаний angular не возьмут + там своих хватает.

ммм.. ну раз вы таки просите «перейти на личности», ок.

о своей нынешней ситуации.

Уволить нынешнего верстальщика, нанять нормального.
некого уволнять.
в нынешней команде — у нас нет верстальщика. и не планируется. а постоянные три дизайнера — есть. и основной состав — «веб-мастера» которые в состоянии верстать php кодом.

сам я бекэнд, команда решила потратится не на верстальщика, а на тру бекенд программиста плюс тим+тех лида на будущее (простите за нескромность). заходящие проекты все усложняются, у команды вполне виден успех в бизнесе. но слабоваты скилы в «настоящем программировании», в налаживании процесса разработки, документировании, контроле качества и т.п.

когда надо — берется на фриланс биржах, если предыдущие были заняты.

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

у нас нет потока 2ух недельных заказов.
и не будет.
сайтами-визитками мы не занимаемся.
лендингами в дополнение к основному заказу — да. поэтому дизайнерам работы хватает.

К нему в команду нанять парочку трейни за 200-300$
см. выше.

если вы не в состоянии наладить эффективную работу с верстальщиками с фриланс биржи за 400-600(если брать на ставку), а только за 1500, то это не значит что и такие кретины как мы этого не можем :)

вы видать мотоцикл в глаза не видели. а сразу начинали с Комацу.

Я выше написал что нанимал на 300-400 и строил отдел. Не с фриланс-биржи (это невыгодно и неэффективно), а на постоянке, у меня было 9-11 человек в команде. С ограниченными бюджетами, сроками и всё такое.

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

. Не с фриланс-биржи (это невыгодно и неэффективно)
а нам выгодно :)

и эффективно.

извините за уже мой «аргумент блондинки»: А вот я знаю случай.

вот я в такой случай и попал — нам — выгодно и эффективно.

у меня было 9-11 человек в команде.
у нас столько же.
и зачем нам верстальщик, если почти все, даже я, можем верстать?
Не иметь постоянно верстальщика в компании — оч плохо
смотря в каком секторе заказывающего бизнеса.

в e-commerce — верстальщика может на постоянку загрузить только команда наверное с человек 50.

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

я, еще и потому что лиду команды понравился мой хоть недоделанный но все же информативный о своем видении:
Сам себе ПиЭм slysak.hol.es

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

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

тогда впервые и стал работать с фрилансерами верстальщиками.

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

топикастер-"мотоциклист" рассказал о проблемах.
а вы ему — так бери Комацу, и не будет у тебя ЭТИХ проблем.

вон, есть фирмы которые применяют Комацу сплошь на своих проектах, и

EPAM вакансии ... И кстати верстальщиков там почти нет.
и проблем ЭТИХ нет.

в моей последней джавовской фирме, у нас тоже не было проблем с верстальщиком. был один, на полставки, на 60 человек разработчиков.

никаких с ним проблем действительно не было.

Комацу это что?
В ЕРАМ почти нет вакансий на верстальщиков, а самих верстальщиков там хватает.

js-префиксы
всегда раздражала эта херь, неужели просто нельзя писать адекватный цсс...

Чем раздражала? Что в вашем понимании адекватный? Выше человек описывает реальную проблему когда таких классов нет и функциональность css/html и js нельзя разделить:

  • нельзя сделать ещё один такой блок, но без привязанного к нему js,
  • или наоборот ещё один такой блок, с таким же js-поведением, но с другим оформлением
  • или просто при рефакторинге удалили/переместили/изменили имена классов, перенесли их на другой блок и т.д.

допустим у вас есть карусель, есть джс логика и то как она выглядит — соотвественно вы вешаете класс carousel, далее у вас там кнопочки влево вправо, вы соотвественно называете carousel__button, и точно так же нужна логика и вид, а цсс класс в данном случае заменяет имя тега.

сейчас уже готовы вебкомпоненты, вы же не будете содаватаь отдельно веб компонент для того чтобы стайлить и для того чтобы джс логику вешать, верно? то же самое здесь.

Как-то слишком сумбурно, не понял что вы хотели сказать.
Вешать стили на кастомные имена компонентов вместо юзания классов или что? И как вам это поможет с разделением логики и представления? Я выше привёл 3 реальных проблемы, как вы их решите?

суть в том что дублируете логику.

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

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

или просто при рефакторинге удалили/переместили/изменили имена классов, перенесли их на другой блок и т.д.
в этим вам никакой подход не поможет. случайно рубанули класс с префиксом, или без него.
эти проблемы именования. если имя класса отображает то чем оно есть — проблем не будет.
вот вам пример: есть кнопка «влево», на которой висит class="button button__left"

Кнопка выглядит одинаково и в карусели, где листание происходит через js, и в пагинаторе, листание которого производится на сервере. Решение с добавлением «js-whatever» в первом случае выглядит вполне приемлимым

class="button button__left"
пример ужасного именования. назвать button в листалочке кнопку все равно что назвать заменить класс Controller в какомнибудь пхп фреймворке на Object.

приведите пример нормального именования и этой проблемы

“navigation-link navigation-link__left”

для стилей эти имена катят. для того чтобы навешать джс — не катят.
джс тут подходит чтото типа .carousel__navigation-link[data-direction="left"]

а navigation-link для js сильно неочевидное имя

С позиции архитектуры — хорошо, так как минимизирует лишний код, но с позиции взаимодействия — не очень, так как глядя только на html код невозможно понять на что подвязан js. Новый разработчик будет вынужден перед каждым изменением html ковырять js на предмет привязки к конкретным css классам (что усугубится, если вы уволитесь/заболеете/умрёте). Понятно, что с каруселью все очевидно, но если это что-то посложнее либо менее очевидное, то может добавить лулзов =)
Решение — договоренность в команде использовать либо якоря, либо дата-аттрибуты.

менее очевидное
специально по этому я и напсиал что
navigation-link для js сильно неочевидное имя

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

Согласен, прошли к консенсусу :)

например у вас кнопка красная имеет класс button
А вам говорят — хочу ещё одну такую красную кнопку тут же, рядом. Только с другим js.

И ещё одну такую же кнопку, с тем же js, но на другой странице и не красную, а зелёную.

в этим вам никакой подход не поможет. случайно рубанули класс с префиксом, или без него.
Это жизнь. Пришли правки по дизайну. Изменили — поломали.

...или карусель под миниатюры с другим размером кнопок
и в итоге у нас и так появится класс «carousel_prev_button», без префикса, с единственным свойством «left: 0» и неявно закрепленным поведением.
[это я поддерживаю, а не спорю]

случайно рубанули класс с префиксом, или без него.
в случай код-ревью/просмотра лога вариант с префиксом не требует анализа не измененного кода("удаляем js-cancel — а тут не предполагалось изменение поведения — похоже, лажа" против «о, боже, тут мы веразаем класс из списка, а что, если от него что-то зависит?! надо посмотреть остальные файлы проекта»)
если имя класса отображает то чем оно есть — проблем не будет.
да, с префиксом как раз и отображает — «я добавлен исключительно как якорь, ради привязки поведения»
ога вариант с префиксом не требует анализа не измененного кода
согласен, это единственный реальный плюс префиксов — от всего остального оно никак не помогает
да, с префиксом как раз и отображает — «я добавлен исключительно как якорь, ради привязки поведения»
если вы говорите слово машина — то это и образ и функциональность.

если вы говорите кнопка — то это и обаз и функциональность

если вы говорите кнопка влево — то это образ кнопки, с немного другим содержимым, и дополнительным функционалом

сейчас уже готовы вебкомпоненты
ага. готовы.
caniuse.com/#search=components
до полноценной инкапсуляции с сохранением гибкости — еще педалить и педалить.
вы же не будете содаватаь отдельно веб компонент для того чтобы стайлить и для того чтобы джс логику вешать
директивы ангуляра так и предполагали.
и ничего, все живы.

я не реальном использовании а о подходе

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

Не решит оно всех проблем.
Вы и сейчас можете инлайновые стили забабахать (или по-модному Atomic), ну или через css-modules изолировать стили (или через ещё кучу способов для изоляции). Вот только дальше что? Изолировали и что?

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

Никакие свистоперделки не заменят необходимость продумывать архитектуру.

я о том, что имена классов можно использовать по этому принципу. инкапсуляция цсс к тому что я описал не имеет особого отношения.

в целом, вы кастомные теги можете юзать уже сейчас.

я о том что
<div class="carousel js-carousel">

не имеет смысла, это примерно равносильно:
<carousel>
<js-carousel></js-carousel>
</carousel>

не имеет смысла, это примерно равносильно:
<carousel>
<js-carousel></js-carousel>
</carousel>
А вас не смущает, что аттрибуты в HTML в принципе используются как для изменения внешнего вида(устаревший width, например, или универсальный style), так и для поведения(disabled, type, name в случае input[type=radio]).

Или вы исключительно-исключительно про class?

Окей. тогда вместо class="button js-agree-button" будет class="button" role="agree-button". концептуально изменилось что-то?

я не против аттрибутов. очень часто они очень хорошо вписываются. если чисто функциональное чтото, то я болле чем за использование их а не классов.

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

role="agree-button"
выглядит по лучше, ибо классы без смысла (как анкор для джс, без изменения вида), выглядт странно.

это как я создам объект который будет служить ключом дргуго ключа объекта, причем связь 1 ту 1

То что ещё и в role мусора написали вместо WAI-ARIA.

резонно.
окей.
data-control-id вас устроит?

Не забывайте ещё

carousel {display: block;}
js-carousel {display: block;}
…
и так для каждого бессмысленного куска шаблонизаторакастомного тега

сверстать ul из 5 елементов

а окажется 3 или 7 элементов, которые нужно вывести.
PHP программист так и будет переверстывать каждый раз?

У нас на одном проекте была похожая проблема. ХТМЛ генерировался на сервере при помощи специфического шаблонизатора, который фронтенд-разработчики не знали, потому поначалу они просто делали статичный ХТМЛ, заливали его в отдельную папку в гите, а бэкендщики уже «натягивали» верстку на шаблонизатор.
Но со временем фронтендщикам стало интересно, как же оно там работает, и они сами потихоньку начали пилить свои вьюхи в этом специфическом шаблонизаторе.
Закончилось тем, что БЕ-разраб просто закидывал заглушку с переменными, которые можно использовать в шаблоне (ну, или очень базовый ХТМЛ), а ФЕ уже крутили там всё через циклы, условия и прочие возможности шаблонизатора.

Так что, думаю, и в вашем случае со временм возможен первый вариант.

Отлично, спасибо за «жизненную историю» :) Вижу что большинство работает с общим репозиторием. Присутствует некое опасение того, что фронтенд-разработчик или верстальщик что-то там может случайно запороть и нужны будут дополнительные временные затраты на тестирование и исправление, но без этого, видимо, никуда. Наверное стоит просто попробовать эту модель работы.

Чтобы минимизировать возможности что-то запроть, можно внедрить практику ревью кода при помощи, например, gerrit. Ну, и обучать верстальщиков хотя бы базовым вещам того же Django template engine)

Основной репозиторий на github, но для больших проектов gerrit наверняка есть смысл использовать, спасибо за наводку. )

это массовейшая проблема везде, где есть генерация хтмл на сервере. да и нередко и на настоящем SPA.

общих решений имхо нет.
если квалификация верстальщика позволяет, то вариант 1.

но обычно — не позволяет, потому что «в шаблоны backend вставляется логика, вызовы моделей, а то и дергание контролеров, и т.п., в которую и новенький на проекте въедет не быстрее чем собственно в программный код.

есть много причин, почему «разделение формирования данных и их представления» провалилось там где генерация хтмл на сервере.

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

вариант 3 — самый массовый.

он звучит так
«программист сам натягивает верстку на Wordpress»
ну или если крутой, то
«программист сам натягивает верстку на Magento»

итого, для варианта 3 — заводится 2 репозитория.
верстальщик обязан делать комиты подробно.

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

Хочется быть уверенным в том, что такая свобода не повысит количество багов.
это только практика в конкретном случае покажет.

например если бекендщики любят навороченные модели, то обучить правильно их обходить в верстке — та еще задачка.

Хорошо когда фронтенд-разработчики сами проявляют интерес к бекэнд-шаблонам
тоже когда как.

любопытство может и пройти. а обязанность останется, и может возникнуть вполне закономерный вопрос — если я уже выполняю часть работы программиста, то может пора бы уровень оплаты повысить, за эту работу?

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

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

кстати, им кусочки хтмл давал верстальщик :)
а они их в js темплейты нарезали.

и тоже, верстальщика в джс обычно не пускали.

ну, сказать что совсем не было пользы низя. но любопытство быстро ушло. и тоже, верстальщика в джс обычно не пускали.
:-D

на мой взгляд лучее решение — это один репозиторий на весь проект и четкое соглашение, что делает фронтэнд разработчик, а что бэкенд(ну типа что бы фронтэндщики не лезли править модели, а бэкендщики css и js)

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

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

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

то есть, бекенд генерирует целиком страницу, в которой потом фронтенд динамически перерендеривает отдельные части?
ну, да, надо как-то прийти к единственному месту для правок.
нечто среднее между 1 и 2: одни и те же шаблоны используются как на фронтенде, так и на бекенде.
цель: чтоб не было разницы между измененным на клиенте состоянием и перезагруженной страницей

Спасибо за ответ. Не уверен что правильно объяснил. Вот в чем проблема — фронтенд разработчик или, допустим, верстальщик, делает изменения у себя, рендерит отредактированные страницы целиком и отправляет бекенд-разработчику новую версию (пушит в репозиторий), последний должен внести изменения в свои шаблоны. Используется стандартный Django template engine, шаблоны которого нет возможности генерировать standalone, вне проекта, т.е. так чтобы фронтенд мог у себя сразу править, тестить со всеми условиями и переменными.

У вас что-то подобное происходит?

я не совсем понял.
результат работы фронтендера — это голый(jade не в счет, как и SASS/LESS) HTML+CSS безо всякий динамики в плане контента? а потом кому-то надо из этого создать django template?

можно таки использовать один и тот же движок шаблонов.
просто фронтендер передает на написанные шаблоные замоканные данные.
а бекендер тянет реальные данные из БД и трансформирует их в структуру, которую ждет шаблон, созданные и протестированный фронтендщиком.

а потом кому-то надо из этого создать django template?
да, пока бекэнд делает свои шаблоны на основе того что получает от фронтэнда

По одному движку да, но я не пока нашел возможности использовать DTE отдельно.

а зачем отдельно? там просто надо систему для управления данными.
тот самый тупл, шо передается в шаблон, чтоб была возможность задать руками в виде JSON.

тот самый тупл
имелся в виду словарь. выпендриться хотел, уж лучше бы написал «хэш» :)

Подписаться на комментарии