Я уже много лет занимаюсь разработкой сайтов и в частности single page application сайтов. Причем общие тенденции в отрасли идут в сторону последних. Поскольку у меня большой практический опыт в их создании, назрела пора как-то систематизировать эти знания и оформить в виде готового фреймворка или библиотеки и выложить всем в свободный доступ.
Этот пост - попытка систематизировать требования к будущему фреймворку и описать базовые принципы функционирования single page application сайтов.
Все данные между клиентом и сервером передаются в формате JSON. Никаких генераций HTML на стороне сервера. HTML на стороне сервера генерируется только при начальной загрузке страницы. Больше никогда! При навигации по сайту URL сайта меняется с помощью HTML5 History API. Формат URLов при этом остается такой-же как и для обычного сайта.
Клиент запрашивает только те данные, которых у него нет. Например, если пользователь ходил по сайту, и зашел на страницу, на которой уже был, браузер покажет ее сразу-же, вообще без обращения к серверу. Исключения из этого правила только одно - запрос на изменение часто меняющейся информации (часто обновляемые ленты новостей, список пользователей онлайн, персональных информеров и т. д.)
Для сохранения совместимости с существующими сайтами, а так-же индексируемости сайтов (если это контент-прект), при обновлении страницы, сервер выдает HTML-страницу, а дальнейшее хождение по сайту происходит AJAX-методом. Отсюда вытекает два следствия: 1. Шаблонизатор должен быть общий для серверной и клиентской части сайта, то есть один HTML-шаблон должен быть понятным и серверному шаблонизатору и клиентскому (дублирование шаблонов - это плохо). 2. Все ссылки должны быть именно ссылками с корректным атрибутом HREF, а при клике на "ссылку" JS перехватывает событие. При таком подходе, как бонус, сайт будет работать при выключенном JS.
Аналогично следует поступать и с отправкой форм, хотя вопрос спорный - может увеличится количество автоматизированного спама.
CSS и JS файлы необходимо объединять. На одной странице должны быть один CSS и один JS файл. Для каждого экрана сайта эта пара разная. Для совсем простых сайтов можно сделать исключение и сделать одну пару на несколько экранов. Для сложных и очень сложных сайтов (для ускорения начальной загрузки) файлы можно разбивать на два - первая пара нужна только для того, что-бы отобразить первый экран и у пользователя создалось ощущения быстрой загрузки. Как только первая пара загрузилась, подгружается вторая, которая реализует весь остальной функционал сайта.
Для лучшей управляемости кэширования статики на клиенте, необходимо сделать две вещи:
1. что-бы браузер кэшировал статику, когда это надо, необходимо отправлять ему заголовки разрешающие это деталь и указывать срок устаревания файла в плюс бесконечность.
2. что-бы браузер запрашивал новые версии файлов с сервера, когда они изменились, необходимо менять названия файла. Как минимум добавлять в параметр номер версии (именно номер версии а не время или рандом!). Как максимум - менять название файла, например так: /static/MD5(название сборки + версия).js. Казалось бы очевидный пункт, но многие сайты так не делают.
Все что попадает в браузел - HTML, JS и CSS, необходимо сжимать. Так как сжиматели всех этих форматов работают независимо друг от друга, они не сжимают, например, названия классов, что-бы не поломать работоспособность кода. Так как названия классов (особенно при БЭМ-верстке) очень длинные - необходимо отдельный алгоритм для их сжатия.
Продолжение следует.