Backend пишу на Symfony, а вот Frontend для меня ограничивается только Twig + jQuery.
Когда появляется необходимость в работе с динамическими сущностями, которые должны обновляться без обновления страницы (например, комментарии), начинают вырастать костыли: для комментариев нужно сделать шаблон в Twig, который их выводит в момент загрузки страницы, и "шаблон" в JS, формирующий их вывод во время добавления/изменения через Ajax.
Чувствую, в 2021 это уже неправильный подход.
Расскажите пожалуйста, как правильно (модно, современно) реализовывать фронтэнд сайтов сейчас?
Или вообще "клиент" должен существовать отдельно от "сервера", не иметь ничего общего с PHP и быть на JS, и, быть может, на фреймворке типа Vue/React?
Понимаю, что способов может быть много, интересно как это делаете вы и что вообще сейчас считается "правилом хорошего тона" в разделении "клиента" и "сервера".
Я заядлый бекендщик, поэтому этот мир для меня темный и тернистый, но нужно начать погружаться и сюда.
Спасибо, буду благодарен за любые советы и подсказки, особенно развернутые, они мне очень помогут чуть-чуть углубиться и понять, что сейчас происходит на стороне клиента.
В современном мире действительно стоит разделять backend и frontend. Везде есть свои фреймворки которые стоит использовать для облегчения разработки. Бакенд обычно имеет только api и этого бывает достаточно. А шаблонизатор twig применяют в этом случае для email писем.
Frontend сейчас разнообразен. Это сейчас больше чем CSS+HTML и небольшой функционал на JS. Более того на Frontend сейчас тоже можно делать микросервисы. Одна страница может работать сразу на нескольких JS фреймворках. Например, меню на Vue, а Navbar на ReactJS.
С точки зрения поддержи и развития вы тоже проигрываете. Ведь большой проект требует узких специалистов, в том числе и фронтенд. Если Ваш фронтенд будет на PHP, то на фронтент уже потребуется фул стек разработчик, что дороже и проблематичнее. Значит сложнее масштабирование и развитие. Да и возникают проблемы монорепозитория, куда все изменения с frontend и backend поступают в один репозиторий, без возможности отделения их. Таким образом ко всем разработчикам сразу попадает готовый проект, который легко скопировать и украсть.
Поэтому, если ваш фронт слишком сложный, то его следует отделить. Иначе вам придётся столкнуться с множеством проблем, зависимостью и сложностью как проекта, так и репозитория.
Ну в целом вы сами ответили на свой вопрос - React или Vue или их братья меньшие прекрасно справляются с приготовлением фронта. Вопрос в том, какой тип "приложения" вы пишите. React/Vue все еще пока не очень дружат с SEO (сейчас меня закидают тапками, но это мое мнение, я его никому не навязываю), поэтому на них хорошо делать фронт для мобильного приложения или фронт админки/cms/erp и т.п. Для классического веб-сайта (сайт компании, школы, сообщества), которому важно SEO - фронт лучше писАть "по-старинке".
startproger, "Модно молодежно" это все было лет 5-6 назад, сейчас просто необходимость, ведь если сайт быстрей, страницы переключаться как буд-то без загрузки то это уже преимущество над "старичками", и с СЕО уже давным-давно нет никаких проблем по причине наличия SSR и в частности работы таких фреймворфков как Next.js/Nuxt.js.
По опыту действительно лучше не смешивать, на выходе получается ужас который нужно еще и поддерживать.
Если что сравниваю мешанину с Jquery + PHP или Vue для фронта. Слишком большие проекты не писал, но имея уже текущий опыт могу сказать что это небо и земля. Vue js на фронте чувствует себя прекрасно, ну а данные для рендера берем с бэка по API и парсим json.
Средний
