Краткий ответ: что б вы не сделали, это все является html-шаблонами. Потому что в итоге все рендерится в html. Натягивать его куда-то сразу или нет, завист от поставленной задачи, целей и ресурсов. Например, если вы хотите сделать шаблон и выставить его на Envato, то нет ровно никакого смысла верстать его именно под друпал.
Длиииииииинный ответ:
Вам, прежде чем задавать такими глобальными философскими вопросами, сначала надо получше структурировать осознание тех самых процессов разработки.
И для начала, например, отделять идеальное от реального.
Как происходит в реальном мире?
У человека есть идея
С ней он идет к бизнес-аналитику. Тот, в свою очередь, указывает на базовые ошибки, недочеты, формирует какую-то общую картину продукта
Потом он знакомит человека-заказчика с архитектором. На своем языке аналитик объясняет архитектору задачу. Архитектор решает, какой стек технологий лучше всего применить в данном случае.
Далее архитектор идет к проектному менеджеру и ставить уже конкретные задачи.
Менеджер распределяет и доводит задачи до разработчиков и идет на поиски дизайнеров и юзабилистов, которые решают, зачастую уже с заказчиком, как будет выглядеть интерфейс.
После чего результат работы дизайнеров и юзабилистов передается верстальщикам, что бы он мог воплотить их реализацию в машинное представление.
После этого верстальщик отдает html в руки front-end разработчика, который в простейшем случае подключает плагины jquery, в сложном - делает SPA.
Ну, а дальше, по крайней мере сегодня, завист от того, толтый клиент или тонкий. Если сделана SPA, то господа backend'erы могут ограничиться документацией API. А если рендер идет в основном на сервере - то будут "натягивать" результат работы фронтендера на свой движок.
А после этого в игру может вступить (а может и раньше, для поднятия тестового\стейджинг окружения) - администратор для деплоя на серверы. Или даже группа оных, модно именуемых сегодня - DevOps
К чему так много писанины? К тому, что б понять, как примерно выглядит идеальный процесс. Конечно, все описано очень абстрактно, какие-то з венья могут дублироваться, могут дробиться на более узкоспециализирвоанные и т.д., но в общем случае часто выглядеть должно как-то так. Хорошо о процессе расписано у Ф. Брукса (например, Мифический человекомесяц).
Так вот, а в реальном мире, конечно же, все эти роли может выполнять даже 1 человек. Благо, обилие сегодняшних готовых технологий, сервисов, высоких уровней абстракции, фримиум моделей и документаций, разжеванных в марктинговых целях - позволяет.
Мораль: спрашивается, если это все может сделать 1 человек, то зачем городить целый хор разных чуваков, называть их модными словечками и настолько сильно обкрадывать карман заказчика?
Все дело в том, какие цели и ресурсы. И когда за "серьезность" решения хочется заплатить - вначале, или уже в хайлоад-продакшене (уже много модных словечек употребили).
И на самом деле, на перспективных проектах, получается так, что цена ошибки с каждой "роли" по нисходящей - увеличивается. Например, если вы выловили ошибку на уровне общения с бизнес-аналитиком - это дешевле, чем выловить ее в процессе продумывания архитектором решения. А поймать ошибку при отрисовке дизайна - дешевле, чем во время натягивании очередной фичи бекендерами.
Вывод: всегда исходить из задачи, целей и ресурсов. Знание html нужно в любом случае, backender вы или frontender. А сверстанный голый статический html имеет гораздо более высокий показатель переиспользования, чем шаблон друпала.
Простой
Простой
