Почему бы мне просто не создать целое веб-приложение в HTML-шаблонах Javascript и Javascript?
Я перехожу к той точке приложения, где мне нужно начать кэширование вещи, и это заставило меня задуматься ...
- В некоторых частях приложения я визуализирую строки таблицы (jqGrid, slickgrid и т. Д.) Или причудливые строки div (как в New Twitter), беря чистый JSON и прогоняя его через что-то вроде Mustache, jquery.tmpl и т. Д. .
- В других частях приложения я просто отображаю информацию в чистом HTML (серверные шаблоны HAML), а если есть поиск / разбивка на страницы, я просто перехожу на новый URL-адрес и загружаю новую HTML-страницу.
Теперь проблема заключается в кэшировании и удобстве сопровождения.
С одной стороны, я думаю, что если бы все было построено с использованием HTML-шаблонов Javascript, то мое приложение могло бы обслуживать только макет / оболочку HTML и кучу JSON. Если вы посмотрите на исходный код HTML в Facebook и Twitter, то в основном это то, что они делают (95% json / javascript, 5% html). Это сделает так, что моему приложению нужно только кэшировать JSON (страницы, действия и / или записи). Что означает, что ты d попал в кеш, независимо от того, были ли вы каким-то удаленным разработчиком 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 потребуется 1) более целенаправленное тестирование чистого javascript ( jasmine ) и 2) интеграция javascript в интеграционные тесты капибары. Это всего лишь вопрос времени и работы, но, вероятно, важен.
- Техническое обслуживание . Избавляемся от HAML. Я люблю HAML, его так легко писать, он печатает красивый HTML ... Он делает код чистым, упрощает обслуживание. Используя javascript, нет ничего более лаконичного.
- SEO . Я знаю, что Google обрабатывает ajax
/ #! / Path, но не понял, как это повлияет на другие поисковые системы и как старые браузеры обрабатывают его. Похоже, это потребует значительной настройки.