Гм, есть несколько разных соображений :) Не очень "сильных", но FYI.
1. Твой пример с чатиком плох. Ты вполне можешь знать ссылку до того, как картинки докачаются. Клиент может уметь генерировать новые глобальные идентификаторы сам, или может попросить сервер выдать ему такой, ещё до окончания закачки.
2. Возможность генерировать HTML на сервере важна для того, чтобы делать gradual service degradation вместо 100% failure. Например, сервис вроде ЖЖ может сгенерировать статичные HTML для популярных страниц с кучей комментов, выложить их на отдельный хостинг и во время ДОС-атаки делать очень дешёвый редирект, или просто выдачу отрендеренной страницы из кэша вместо дорогих запросов в базу, чтобы зачитать содержимое поста и комментов.
Ещё (предположу, что) она может быть важна с архитектурной точки зрения: ты таким образом уменьшаешь количество потенциальных багов, когда для какого-то состояния на клиенте нет корректной серверной репрезентации, и, как следствие, будут всякие неприятные сайд-эффекты, невозможность зарефрешить страницу без потерь и всё такое прочее. В идеале пара {URL, динамическое состояние пользователя на сервере} должны полностью определять страницу, чтобы её можно было перерисовать по рефрешу, или если пользователь пересядет в другой обозреватель и т.п.
3. В общем случае для поисковиков нужно писать отдельный рендеринг engine (и он может быть куда проще, потому что тебе не нужна динамика), что полностью снимает любую аргументацию в пользу оптимизации UI-фреймворка под какие-то потребности поисковиков.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2015-03-10 01:50 am (UTC)Не очень "сильных", но FYI.
1. Твой пример с чатиком плох. Ты вполне можешь знать ссылку до того, как картинки докачаются. Клиент может уметь генерировать новые глобальные идентификаторы сам, или может попросить сервер выдать ему такой, ещё до окончания закачки.
2. Возможность генерировать HTML на сервере важна для того, чтобы делать gradual service degradation вместо 100% failure. Например, сервис вроде ЖЖ может сгенерировать статичные HTML для популярных страниц с кучей комментов, выложить их на отдельный хостинг и во время ДОС-атаки делать очень дешёвый редирект, или просто выдачу отрендеренной страницы из кэша вместо дорогих запросов в базу, чтобы зачитать содержимое поста и комментов.
Ещё (предположу, что) она может быть важна с архитектурной точки зрения: ты таким образом уменьшаешь количество потенциальных багов, когда для какого-то состояния на клиенте нет корректной серверной репрезентации, и, как следствие, будут всякие неприятные сайд-эффекты, невозможность зарефрешить страницу без потерь и всё такое прочее. В идеале пара {URL, динамическое состояние пользователя на сервере} должны полностью определять страницу, чтобы её можно было перерисовать по рефрешу, или если пользователь пересядет в другой обозреватель и т.п.
3. В общем случае для поисковиков нужно писать отдельный рендеринг engine (и он может быть куда проще, потому что тебе не нужна динамика), что полностью снимает любую аргументацию в пользу оптимизации UI-фреймворка под какие-то потребности поисковиков.