Как я понимаю, шаблонизаторы (mustache, ejs, twig, etc.) применяются для динамической генерации страниц, передачи данных с бэкенда на фронтенд (например, если загружается профиль пользователя, страница отрендерится сразу с его данными).
Но какой это имеет смысл, если все данные можно просто дёргать из фронтенда через api бекенда?
Какие есть преимущества у первого подхода и у второго?
Или, может быть, их можно/нужно на одном сайте совмещать? В таком случае, для каких задач лучше подходит первый подход, а для каких второй?
Какой смысл имеет в родителях, если уже я есть и уже на ногах? :):)
У них дата рождения разная
До всяких реакто-шмерактов появилось это все... Да и они не первые, Твиг -- просто улучшенный Smarty
Клиент-серверный подход сделал взрыв в середине десятых, кроме того сейчас еще не все команды на нем.
Спроси также про JQuery -- зачем он нужен, если Егор уже выучил Реакт
Кроме того не всегда есть или даже нужен полноценный реакт-программист, тк банальный новостной портал или интернет-магазин не особенно во фронте нуждается, при том что все уже работает, инфраструктура проще на порядок, все индексируется и работает как часы...
Максим Федоров, про реакт и jQuery я и так понимаю. Я понимаю, что для проектов попроще нужны и технологии попроще, тем более, что и разработчики получатся дешевле. И также я понимаю, что jQuery это всё-таки больше подход из прошлого, но он и более простой.
Но это сравнение, мне кажется, не вполне корректно. Ведь, как я понимаю, подход с рендерингом на сервере сейчас применяется не меньше, чем подход с дёрганием api. Если это не так, прошу поправить. А так же оба эти подхода одинаковы по простоте использования/реализации.
Какие у них практически различия? Ведь у этих двух подходов наверняка есть какие-то преимущества и недостатки, которые делают их более или менее уместными в зависимости от ситуации/потребностей заказчика.
Руководитель frontend направления, предприниматель
1. Можно совмещать
2. Можно не совмещать.
3. Преимущества отдачи бэка — все готовое, не надо ждать или насиловать себе ногу, настраивая пререндер, например.
4. Безопасность: все, что лежит во фронте — видит любой желающий, все, что есть в логике шаблонизатора или бэка не видит никто, даже когда он отрендерен.
5. Не актуален для SPA на REST API (кривлю чуть душой).
И т.д. втекающие и вытекающие последствия.
Сравнивать бэк-шаблонизаторы по принципу их действия с фронтом, ИМХО, не самая здоровая затея, так как работают они по-разному.
Егор Левоненко, нет, решение принимается на основе задачи.
В случае SPA обычно предполагается REST API (что вовсе не обязательно), следовательно используется стек в виде JS-фреймворка, в котором просто нет backend-а по определению, а есть шаблоны, которые строятся на базе ответов из API.
И все же еще раз скажу — стек, подход и все остальное решают в первую очередь задачи, которые стоят перед разработчиками. Не модное решение (хотя чаще всего именно оно), а именно задача. Ну и призма навыков и знаний. Факторов в действительности много.
Арсений Матыцин, спасибо. Поэтому я и задал этот вопрос, чтобы понять, когда задача располагает к одному подходу, а когда к другому. Чтобы в следующий раз у меня не возникало вопроса "а что же здесь лучше использовать?"
К слову, разве в случае SPA бэкендом не будет сервер, на котором крутится API и вся бизнес-логика?
Егор Левоненко, все верно, бизнес-логика крутится на бэке, обмен происходит через http-протокол, SPA просто показывает то, что пришло в ответ на запрос.
Само SPA приложение может крутится где угодно, хоть у тебя на локальному компьютере, главное, чтобы можно было отправлять запросы и получать ответы, т.е. скорее всего интернет-соединение.
Поэтому я и задал этот вопрос,
Нюансов, пожалуй очень много на самом деле. В принципе могу сказать, что для чего-либо функционального используется схема, где бэк независим и взаимодействует с окружающим миром через web api (Если что API это не только запросы с ответом типа json в интернете), а морда, она же приложение, она же чаще всего SPA крутится где-то в сторонке. На уровне с приложениями для устройств. Это позволяет обеспечить одинаковый подход к обращениям к основной логике при абсолютно диком разнообразии конечного продукта.
Тем не менее это нужно далеко не всегда + я еще раз акцентирую внимание на безопасности. Не всегда, например для лендоса все это не нужно. Для сайта, который не использует расчеты, а просто отдает контент — тоже. Бложик какой на коленке — там вообще оптимально использовать какой-нить Jekyll, который не входит в обсуждение и так далее.
А в плане безопасности тут тоже все просто, в SPA часто зашивают логику пользователя и администратора. Все, что разделяет юзера от манипуляций на сервере — шифрованный токен, который его браузер хранит при входе в систему. При этом неважно, вошел он или нет, вся логика просто вывалена в виде JS-ника, который заходи, смотри какие обращения на сервер могут быть и иди пытайся порушить что-нибудь.
Конечно, есть подходы корректнее, но из-за того, что так модно, о безопасности думают в последнюю очередь. Не самый очевидный фактор.
При этом следует отметить, что если ты делаешь сайт, который загрузился и вот он весь — вся динамика тебе не нужна, лучше просто вывалить все в шаблонизатор. Ну может где-то асинхронных компонентов напихать.
Простой
