Шаблонизация в веб приложениях: сервер, клиент, смешанная?

#angularjs #сервер #клиент_сервер #проектирование #веб_программирование

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

1. Клиентская шаблонизация с json rest api

Достаем из базы данные => отдаем их на клиент в json/xml => разбираем данные на клиенте,
создавая объекты по клиентским моделям => добавляем каждую полученную модель в DOM. 

плюсы:  


пользователь ждет только нужные ему данные  
в процессе загрузки данных можем показать красивый прелоадер


минусы:


дублируем модели
лишний раз напрягаем клиентский браузер шаблонизацией


2. Тоже rest api, только шаблонизация, в целом, серверная

Достаем из базы данные => создаем из них html код => отдаем на клиент html => на
клиенте просто пихаем полученный html в DOM не думая.
Этот способ мне кажется самым практичным, но о нем почему-то практически не пишут.
Я просто что-то не то читаю, или есть серьезные недостатки, которых я просто не вижу?

плюсы:


первых два из пункта выше  
не дублируем модели


минусы:


выглядит так, будто их нет


3. Классическая серверная шаблонизация... только сервер

Выбираем данные из базы => на сервере это все дело делаем в html, но не кусочек страницы,
а всю страницу целиком => отдаем на клиент заново всю страницу.

плюсы:


не дублируем модели


минусы:


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


Вопросы


Какие еще есть вариации?
Кто что использует в своих проектах (личных, рабочих, как делают крупные компании...)? 
Почему? 
Какие плюсы и минусы я пропустил/не понял? 
В каком случае что использовать лучше? 

    

Ответы

Ответ 1

Кто что использует в своих проектах (личных, рабочих, как делают крупные компании...)?

Крупная компания, более 20 разработчиков на проекте бывает.

Либо полный server-side, либо полностью client-side, смешивание только в очень специфичных
случаях (возможно бывают такие, сам не встречал).

Server-side для проектов, где можно обеспечить full-stack разработчиков, чтобы и
сверстать по мелочи, и скрипт на JS написать и запрос к базе сформировать смогли и
т.д. Мобильные приложения не требуются, предоставления API для третьих лиц тоже. Чаще
всего проекты, где веб-интерфейс минимален перспектив развития интерфейса нет.

Client-side если команда большая, разделить можно на фронтэндщиков, бекендщиков,
мобильщиков. Минусы - расходы на поддержку линии API. Чаще всего такой подход применяем,
причем API first (у нас RAML).

Была пара проектов в практике, где ответственность за отображение поделили  между
сервером и клиентом, очень неприятные впечатления: постоянные вопросы о том, кто за
что должен отвечать, вопросы согласованности (например динамически формируемая форма
на клиенте и ее перезаполнение в случае ошибочного сабмита). Требования к разработчикам
очень высокие, нужно знать и client-side и server-side технологии.


Ответ 2

Во втором случае на самом деле есть куча минусов (кстати, слова "REST API" к нему
неприменимы - потому что это не REST и не API).


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


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



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

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