Почему Facebook, Twitter и GMail предоставляют все свои данные браузеру как JSON, а не HTML?

Если вы заходите в Facebook, Twitter или Gmail и просматриваете источник, вы заметите что-то очень своеобразное. Все ваши твиты и почта отображаются как JSON. Нет угловых скобок. Я предполагаю, что эти данные динамически передаются в DOM. Если вы проверите какой-либо элемент на странице, вы увидите тонны div и других элементов HTML. Ни один из них не использовался в оригинальной разметке. Вопросы:

Почему эти 3 огромные сайты занимают время, чтобы это сделать?
Не было бы быстрее просто использовать HTML?
Сохраняется ли пропускная способность, поскольку полезная нагрузка JSON меньше, чем HTML?
Это потому, что эти сайты в значительной степени основаны на AJAX? Мое предположение было бы первым, но я понятия не имею. Я не уверен, что вам нужно работать в Google Twitter или Facebook, чтобы узнать, почему это так, но эта тактика разделяется между тремя сайтами, поэтому я считаю, что у них есть общая цель. Это заставляет меня думать, что это больше общего.

Ответ 1

Есть несколько причин для их разработки, которые обычно применяются:

Как упоминалось в предыдущих ответах, кеширование может быть использовано в браузере, а полезная нагрузка JSON легче.
Они обеспечивают чистое разделение между службой, логикой пользовательского интерфейса и данными, соответствующими шаблону MVC
- JSON как модель
- JavaScript UI Widget as View, который отображает данные
- Уровень обслуживания как Контроллер, который предоставляет бизнес-логику/службу, которая загружается в слой пользовательского интерфейса.
Архитектура и разделение API, упомянутое в пункте 2 выше, позволяют компании предоставлять несколько каналов без чрезмерной переделки. Подумайте, хотим ли мы создать приложение Twitter для Android:
- JSON as Model остается неизменной, ничего не нужно переделывать здесь, так как данные одинаковы
- Теперь мы изменим представление из HTML на основной пользовательский интерфейс Android, в этом случае нам нужно будет закодировать код слоя пользовательского интерфейса
- Service Layer as Controller остается тем же, и мы не должны ничего делать здесь.
Как вы можете видеть, эта модель предоставляет Google/Twitter возможность передавать в многоканальные каналы без необходимости переписывать их логику. То же самое касается Mobile WebView и обычного Desktop WebView. Все, что нам нужно изменить, это слой UI, а не уровень Data или Controller.

Вот почему они уделили время размышлению над дизайном и архитектурой как таковой. Тесная связь между данными и презентацией потребует от них повторной обработки большого количества кода для доставки по нескольким каналам. Речь идет не о JSON и HTML, а просто о веб-дизайне, но скорее об архитектурном решении, которое позволит им доставлять свой контент на многоканальные (iOS, Android, стороннее приложение, Mobile WebView, Desktop View, Desktop App и т.д.). То, что вы видите в своем HTML-источнике, является проявлением их стратегии в канале WebView.

Ответ 2

Этот метод позволяет браузеру кэшировать HTML (и статические javascripts) и извлекать только строку json. Это довольно быстро и дружелюбно.

Ответ 3

Нет, это не будет быстрее. JSON намного проще создавать на стороне сервера, чем HTML. Насколько я знаю, Twitter также использует Mustache для рендеринга этих данных на клиенте.

Итак, вы просто обслуживаете статические шаблоны (если они кэшированы должным образом, их нужно только один раз загружать) и ваши данные JSON, а затем позволяют клиенту выполнять всю работу рендеринга. Одно из преимуществ заключается в том, что клиент может выбрать, что и как они хотят отображать данные, а другой, что он берет на себя все тяжелые накладные расходы HTML-поколения.

Ответ 4

Мое предположение: во избежание повторения кода, связанного с пользовательским интерфейсом.

Я просто взглянул на исходный код Twitter, и кажется, что они хотели сохранить всю логику пользовательского интерфейса в JavaScript. Это разумно, так как страница Twitter будет продолжать получать новые твиты, поэтому в любом случае им пришлось писать код, связанный с пользовательским интерфейсом, на JavaScript. Таким образом, вместо того, чтобы повторять один и тот же код в бэкэнд, он просто посеял исходные данные для рендеринга твитов во время загрузки страницы с помощью JavaScript.

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

Ответ 5

В основном это разделение представления и данных, принятых на другой уровень. На стороне сервера есть слой, который просто предоставляет данные. В общем, JSON - хороший способ предоставить эти данные. Теперь, как вы представляете его, можно рассматривать отдельно.

Этот JSON может доставляться через веб-сервисы любому заинтересованному клиенту (API Web/Desktop/Mobile/Other). Тогда клиент может решить, как его представить. В Интернете мы используем много javascripts для чтения и анализа этого JSON и управления экраном/DOM.