Почему бы мне просто не создать все веб-приложение в Javascript и Javascript HTML-шаблонах?

Я добираюсь до места в приложении, где мне нужно начинать кешировать вещи, и это заставило меня задуматься...

В некоторых частях приложения я обрабатываю строки таблицы (jqGrid, slickgrid и т.д.) или фантастические строки div (например, в New Twitter), захватывая чистый JSON и запуская его через нечто вроде Mustache, jquery.tmpl и т.д..
В других частях приложения я просто представляю информацию в чистом HTML (на серверных шаблонах HAML), а если есть поиск/разбиение на страницы, я просто перехожу на новый URL-адрес и загружаю новую HTML-страницу.

Теперь проблема заключается в кэшировании и ремонтопригодности.

С одной стороны, я думаю, если бы все было построено с использованием Javascript HTML Templates, то мое приложение будет служить только макетом/оболочкой HTML и связкой JSON. Если вы посмотрите на источник в Facebook и Twitter HTML, это в основном то, что они делают (95% json/javascript, 5% html). Это сделало бы так, что моему приложению нужно было только кэшировать JSON (страницы, действия и/или записи). Это означает, что вы попали в кеш независимо от того, был ли вы каким-то удаленным разработчиком api, обращающимся к JSON api, или к веб-прокси-сайту. То есть, мне не нужны 2 кэша, один для JSON, один для HTML. Похоже, что он сократил мой кэш-хранилище пополам и немного упростил ситуацию.

С другой стороны, я думаю, из того, что я видел/испытывал, создавая статическую HTML-серверную сторону и кэшируя это, кажется, намного лучше, чем мудрый кросс-браузер; вы получаете графику мгновенно и не должны ждать, что split-second для javascript для ее рендеринга. StackOverflow, кажется, делает все в простом HTML, так же как и Google, и вы можете сказать... все появляется сразу. Обратите внимание, что, хотя на twitter.com, страница пуста для .5-1 секунд, а фрагменты страницы: javascript должен отображать JSON. Недостатком этого является то, что для любой динамической (например, бесконечной прокрутки или сетки) мне все равно придется создавать шаблоны javascript... так что теперь у меня есть серверные шаблоны HAML, клиентские javascript-шаблоны и многое другое больше для кэширования.

Мой вопрос в том, есть ли какой-либо консенсус относительно того, как подойти к этому? Каковы преимущества и недостатки вашего опыта смешивания двух против 100% с одним над другим?

Update:

Некоторые причины, из-за которых я еще не принял решение идти со 100% -ным шаблоном javascript, следующие:

Производительность. Формально не тестировались, но из того, что я видел, raw html отображает быстрее и быстрее, чем javascript-сгенерированный html-браузер. Кроме того, я не уверен, как мобильные устройства обрабатывают динамический html-результат.
Тестирование. У меня много интеграционных тестов, которые хорошо работают со статическим HTML, поэтому переход на javascript-only потребует 1) более целенаправленного тестирования pure-javascript (jasmine) и 2) интеграция javascript в тесты интеграции capybara. Это всего лишь вопрос времени и работы, но это, вероятно, важно.
Обслуживание. Избавиться от HAML. Мне нравится HAML, так легко писать, он печатает довольно HTML... Он делает код чистым, он упрощает обслуживание. Идя с javascript, нет ничего более сжатого.
SEO. Я знаю, что google обрабатывает ajax /#!/path, но не понял, как это повлияет на другие поисковые системы и как старые браузеры обрабатывают его. Похоже, что для этого потребуется значительная настройка.

Ответ 1

Постоянное личное хранилище данных.

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

Также у вас проблемы с более старыми браузерами. Если вы не используете FF4/Chrome или IE9, тогда существует большая разница между обработкой данных и построением страниц на клиенте и сервере.

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

Но в целом приложение действительно может быть полностью построено в javascript и использовать шаблоны. Различные конструкции и javascript-движки достаточно продвинуты для этого. Для этого достаточно популярных фреймворков. Чистые веб-приложения javascript больше не являются экспериментами и прототипами.

О, и если бы рекомендовали рамки для этого, взгляните на backbone.js.

Безопасность

Не забывайте, что мы не доверяем клиенту. Мы нуждаемся в проверке серверов. JavaScript интерпретируется, динамичен и может управляться во время выполнения. Мы никогда не доверяем клиентскому вводу.

Ответ 2

Я использовал для смешивания этих двух подходов, но затем полностью переключился на рендеринг на стороне клиента, потому что в действительности было тяжело обрабатывать тяжелый JavaScript. В качестве полного решения можно рекомендовать подход JavaScriptMVC framework.

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

Затем для вашего API, следуя принципам REST, кеширование является одним из ключевых ограничений. Поэтому, если ваше приложение поддерживает HTTP-кеширование должным образом для данных JSON и использует сжатые клиентские шаблоны, вы даже можете увидеть улучшение производительности.

Ответ 3

Я мог бы быть здесь, но...

Вы когда-нибудь смотрели CouchDB? (У меня нет связи с BTW). Я мог бы ошибаться, но ваша ситуация звучит так, как будто она идеально подходит для использования Apache CouchDB Я еще не использовал его сам, но я немного поглядел на него, и это очень интересная база данных.

Это база данных на основе документов, которая использует REST api для соединений (очень универсальная и простая в использовании). Он также очень ориентирован на JSON, очень быстрый и крошечный след; они говорят, что он может проживать на телефонах и других встроенных приложениях, но в то же время должен быть чрезвычайно масштабируемым (вверх). Если у вас большой пользователь JS (который вы похожи на вас), вы можете быть рядом с ним.

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