Я дошел до точки приложения, где мне нужно начать кэшировать вещи, и это заставило меня задуматься ...
- В некоторых частях приложения я визуализирую строки таблицы (jqGrid, slickgrid и т. Д.) Или необычные строки div (как в новом Twitter), захватывая чистый JSON и запуская его через что-то вроде Mustache, jquery.tmpl и т. Д. .
- В других частях приложения я просто отображаю информацию в чистом HTML (серверные HAML-шаблоны), а если идет поиск / разбиение на страницы, я просто захожу на новый URL и загружаю новую HTML-страницу.
Теперь проблема в кешировании и поддержке.
С одной стороны, я думаю, что если бы все было построено с использованием HTML-шаблонов Javascript, то мое приложение могло бы обслуживать только макет / оболочку HTML и несколько JSON. Если вы посмотрите на исходный HTML-код Facebook и Twitter, то в основном это то, что они делают (95% json / javascript, 5% html). Это сделало бы так, чтобы моему приложению требовалось только кэшировать JSON (страницы, действия и / или записи). Это означает, что вы попадете в кеш, независимо от того, работали ли вы с каким-нибудь удаленным API-разработчиком, обращающимся к JSON-API, или веб-приложением с ограниченным доступом. То есть мне не нужно 2 кэша, один для JSON, другой для HTML. Похоже, это сократит мой кеш-накопитель пополам и немного упростит работу.
С другой стороны, я думаю, что из того, что я видел / испытывал, генерирование статического HTML-кода на стороне сервера и его кэширование, похоже, намного лучше с точки зрения производительности кросс-браузерно; Вы получаете графику мгновенно, и вам не нужно ждать этой доли секунды, пока javascript ее отобразит. StackOverflow, кажется, делает все в простом HTML, как и Google, и вы можете сказать ... все появляется сразу. Обратите внимание, что на twitter.com страница пуста в течение 0,5-1 секунды, и страница разбивается на части: javascript должен отображать json. Недостатком этого является то, что для чего-то динамического (например, бесконечная прокрутка или сетки) мне бы пришлось создавать шаблоны javascript в любом случае ... так что теперь у меня есть серверные HAML-шаблоны, клиентские javascript-шаблоны и многое другое. больше в кеш.
У меня вопрос: есть ли консенсус о том, как к этому подойти? Каковы преимущества и недостатки вашего опыта смешивания двух по сравнению со 100% с одним по другому?
Обновление:
Вот некоторые причины, которые влияют на то, почему я еще не принял решение использовать 100% шаблоны JavaScript:
- Производительность . Формально не проверял, но из того, что я видел, сырой html рендерит быстрее и плавнее, чем кросс-браузерный html, сгенерированный javascript. Кроме того, я не уверен, как мобильные устройства обрабатывают динамический HTML с точки зрения производительности.
- Тестирование . У меня есть много интеграционных тестов, которые хорошо работают со статическим HTML, поэтому переключение на javascript-only потребует 1) более сфокусированного тестирования на чистом javascript ( jasmine ) и 2) интеграции javascript в интеграционные тесты capybara. Это просто вопрос времени и работы, но, вероятно, это важно.
- Техническое обслуживание . Избавляемся от ХАМЛ. Я люблю HAML, его так легко написать, он печатает красивый HTML ... Он делает код чистым, он облегчает обслуживание. Что касается javascript, нет ничего более краткого.
- SEO . Я знаю, что Google обрабатывает ajax
/#!/path, но я еще не понял, как это повлияет на другие поисковые системы и как старые браузеры справляются с этим. Похоже, это потребовало бы значительных настроек.