Json только веб-приложение. Каковы минусы? (или профи)

Ответ 1

Это все более распространенная модель с такими инструментами, как GWT и ext-js. Сложные веб-приложения, такие как GMail, уже более 90% создавали JS-DOM. Если вы разрабатываете традиционный веб-сайт типа "журнал", в основном написанный для чтения, этот подход будет излишним. Но для сложного приложения, которое хочет избежать обновления страницы, вполне может быть уместно.

Один недостаток заключается в том, что для него не требуется браузер, поддерживающий JavaScript, также легко вычислить ресурсы, необходимые для приложения, чтобы он доходил до того места, где ему нужен довольно мощный браузер. Если вы работаете в Chrome на ПК верхнего уровня, вы можете запустить приложение на менее мощной машине, такой как нетбук или мобильное устройство, и найти, что он стал довольно вялым.

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

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

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

Ответ 2

Помимо вопроса, который вы указываете, есть еще один: скорость. Но это не обязательно большая проблема, и на самом деле использование JSON, а не HTML может (более медленные соединения) улучшать, а не затруднять скорость.

Веб-браузеры оптимизированы для рендеринга HTML, как целых страниц (например, обычно), так и фрагментов (например, innerHTML и различных оболочек для него, таких как jQuery html или Prototype update). Там вы можете много сделать, чтобы минимизировать влияние скорости работы через возвращаемые данные и результат, но ничего не будет так быстро, как захват некоторой HTML-разметки с сервера и сброс ее в браузер для отображения.

Теперь, при этом, это не обязательно будет большой проблемой. Если вы используете эффективные методы (некоторые примечания в этой статье), и если вы в первую очередь визуализируете результаты, создавая HTML-строки, то вы собираетесь (опять же, через innerHTML или обертки для него), или если вы раздираете только несколько элементов за раз, маловероятно, что будет какая-либо заметная разница в скорости.

Если вместо этого вы создаете существенные деревья, создавая и добавляя отдельные элементы через DOM API или обертки для него, вы, скорее всего, заметите влияние производительности. Это похоже на правильную вещь, но это связано с множеством поездок по границе DOM/JavaScript и означает, что браузер должен представить версию DOM вещей вашему коду на всех промежуточных этапах; в отличие от этого, когда вы передаете ему строку HTML, она может сделать свою работу и прорваться через нее на полной скорости вперед. Вы можете увидеть разницу в этом тесте производительности. Это существенное.

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

Ответ 3

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

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

Вам также нужен эффективный способ управления HTML-фрагментами/шаблонами. Очевидно, что есть несколько хороших модулей для создания шаблонов - Mustache.js, Underscore template и т.д., Но хранение поверх фрагментов HTML может вызвать некоторые головные боли обслуживания. Я стараюсь хранить HTML-шаблоны в отдельных файлах и динамически загружать их через вызовы Ajax (плюс кеширование для минимизации HTTP-запросов).

Изменить - еще один символ:

Синхронизация данных - если вы используете базу данных сервера в качестве "авторитета" ваших данных, тогда важно синхронизировать данные между сервером и клиентом. Это еще более актуально, если изменения данных на одном клиенте затрагивают несколько клиентов. Затем вы попадаете в сферы работы с реальными асинхронными обновлениями, что может вызвать некоторые интересные концептуальные проблемы. (К счастью, использование фреймворков и библиотек, таких как Socket.IO и Backbone.js, действительно может облегчить задачу).

Изменить - профи:

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

Кроме того, он позволяет более эффективно связывать данные с вашими представлениями. Скорее всего, если вы обрабатываете данные на стороне клиента, у вас будет своя структура, позволяющая организовать данные и использовать ORM - будь то Backbone.js, Knockout.js или что-то подобное. Вам больше не нужно беспокоиться о хранении данных в атрибутах html или во временных переменных. Все становится намного более управляемым, и это открывает двери для действительно сложного развития пользовательского интерфейса.

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

Ответ 4

Я думаю, что самое важное - это то, что вам нужно, если вы хотите создать интерактивное приложение, дающее настольный компьютер, например, почувствовать, что нужно развивать клиентскую сторону. Использование структуры Javascript, такой как backbone.js или knockout.js, действительно поможет в организации и поддержании кода. Преимущества уже подробно изложены в предыдущих ответах. Что касается производительности при рендеринге в отношении рендеринга на стороне сервера, здесь есть хорошая запись в блоге, которая задумалась. http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/