Каковы преимущества обслуживания статического HTML и создания контента с помощью AJAX/JSON?

http://blog.urbantastic.com/post/81336210/tech-tuesday-the-fiddly-bits

Хит из Urbantastic пишет о своей системе генерации HTML:

Весь HTML в Urbantastic полностью статичен. Все динамические данные отправляются через AJAX в формате JSON, а затем объединяются с HTML с использованием Javascript. Иными словами, серверное программное обеспечение для Urbantastic производит и использует исключительно JSON. HTML, CSS, Javascript и изображения отправляются через другой сервис (ванильный сервер Nginx).

Я думаю, что это интересная модель, поскольку она физически отделяет представление от данных. Я не специалист по архитектуре, но, похоже, будет скачок в эффективности и стабильности.

Однако меня беспокоит следующее:

  • [субъективный] Clojure чрезвычайно мощный; Javascript нет. Написание всего контента на языке, созданном для других целей, создаст некоторую боль (представьте, что вы пишете код типа Javascript в CSS). Если у него нет макросистемы для генерации Javascript, Хит, вероятно, постоянно переключается между JavaScript и Clojure. У него также будет много JS-кода; вероятно, намного больше, чем Clojure. Это может быть нехорошо с точки зрения мощности, быстрого развития, краткости и всего того, на что мы смотрим при переходе на языки LISP.

  • [производительность] Я не уверен в этом, но рендеринг всего на компьютере пользователя может запаздывать.

  • [доступность] Если у вас отключен JS, вы вообще не можете использовать сайт.

  • [доступность № 2] Я подозреваю, что большое количество динамического заполнения данных с помощью JavaScript создаст проблемы кросс-браузера.

Кто-нибудь может прокомментировать? Мне было бы интересно прочитать ваше мнение об этом типе архитектуры.

Рекомендации:

  1. Ссылка на обсуждение на HN.
  2. Ссылка на обсуждение по / р / программированию.
Источник

3 ответа

"Весь код HTML в Urbantastic полностью статичен. Все динамические данные отправляются через AJAX в формате JSON, а затем объединяются с HTML с использованием Javascript".

Я думаю, что это стандартная модель RIA. Упорным словом здесь кажется "Все". Потому что на многих веб-сайтах большая часть динамического контента все еще не получена через Ajax, только ключевые функции.

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

Доступность JS действительно является проблемой. Но тогда пользователи, которые хотят испытать AJAX, должны включить JS. Вы провели опрос о том, у скольких из ВАШИХ пользователей она не включена?

Источник

Преимущество заключается в том, что вы можете подать 99% (по весу) контента через CDN (например, Akamai) или даже поместить его на внешнее хранилище (например, S3). Служа только JSON, для сайта почти невозможно получить косую черту.

Источник

Когда AJAX начал набирать обороты, в конце 2005 года я написал клиентский шаблонный движок и в основном превратил свой шаблон блоггера в полноценный AJAX-опыт.

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

Вот как это было сделано.

<div id="blogger-post-template">
<h1><span id="blogger-post-header"/></h1>
<p><span id="blogger-post-body"/><p>
<div>

А потом в JavaScript:

var response = // <- AJAX response
var container = document.getElementById("blogger-post-template");
if (!template) { // template context
    template = container.cloneNode(true); // deep clone
}
// clear container
while(container.firstChild) 
    container.removeChild(template.firstChild);

container.appendChild(instantiate(template, response));

Функция instance создает глубокий клон шаблона, а затем ищет в нем идентификаторы для замены данными, найденными в ответе. Конечным результатом является заполненное дерево DOM, которое изначально было определено в HTML. Если у меня было более одного результата, я просто перебрал код выше.

Источник
Другие вопросы по тегам