Богатые приложения: тяжелая клиентская сторона, немного легкая серверная
Я думаю, вам стоит взглянуть на JavaScript-фреймворки, которые реализуют какой-то паттерн модель-представление-контроллер на стороне клиента (если вы этого еще не сделали).
Вот цитата из обсуждения об одной из этих платформ, backbone.js . Я думаю, что это относится к вашему вопросу об управлении библиотеками JavaScript.
<...> если у вас есть приложение с большой интерактивностью JavaScript или одностраничное приложение, в котором весь интерфейс основан на JavaScript (это так для нас), то это помогает структурировать ваш клиент сторонний код с немного большим размахом, чем предоставляет jQuery.
В нашем случае рабочее пространство DocumentCloud фактически является пустым тегом тела, и вся HTML-визуализация и интересная логика происходят в моделях и представлениях JavaScript - вам никогда не придется обновлять страницу. Код Rails на стороне сервера становится меньше и менее сложным, по существу, его делегируют для выполнения валидации и аутентификации и для предоставления JSON клиенту. Подумайте, GMail, или новый Twitter, или 280 слайдов ...
Да, Rails были упомянуты, но подождите, архитектура остается прежней, если вы используете Django (или Flask, или любой веб-фреймворк вообще):
Серверная часть реализует API. Он в основном предоставляет, принимает, проверяет сериализованные данные.
piston или django-tastypie хороши для этого, например.
Клиентская сторона делает необходимые AJAX-запросы для извлечения данных, отображает представления данных, отображает шаблоны, делает запросы на сохранение данных и т. Д.
Например, Backbone.js предоставляет, помимо всего прочего, прототип Model. Вы можете расширить его (или подкласс, если вы используете CoffeeScript) и привязать к вашей серверной модели, указав URL соответствующего ресурса tastypie. После этого вам не нужно беспокоиться о синхронизации: вы просто делаете my_model.save(), а Backbone.sync за кулисами выполняет запрос AJAX и обновляет экземпляр модели сервера.
Организация файлов в клиентском приложении
Я недавно начал использовать поздний завтрак . По сути, он предоставляет скелет для многофункционального приложения, сочетая CoffeeScript как лучший JavaScript, backbone.js для классов MVC, eco для шаблонов javascript, stylus как препроцессор css и другие полезные вещи (и предоставляя удобный интерфейс командной строки: brunch watch, brunch build). Предлагаю посмотреть, как организованы файлы в поздних проектах.
Ведение отдельных проектов
В настоящее время Django не облегчает управление тяжелым клиентским приложением. Вы должны сами понять, как, скажем, вы должны организовывать библиотеки.
В то же время многие инструменты для построения, которые минимизируют и оптимизируют скрипты и таблицы стилей (например, requirejs), довольно сложно интегрировать в обычный рабочий процесс разработки проекта Django. И вам, скорее всего, понадобится один из этих инструментов, если вы планируете создать полнофункциональное приложение на JavaScript.
Создание приложения внутри вашего проекта - вариант, но, я думаю, это немного усложнит ситуацию. У вас уже есть два более или менее отдельных приложения, так почему бы не пойти дальше и разделить проблемы дальше - просто работать с двумя фактически отдельными проектами? Один проект будет основан на Django для серверной стороны, а другой, например, brunch - для клиентской.
Мы начали делать это с нашим последним проектом, и я лично считаю, что это делает вещи более управляемыми и с ними легче работать.
Обновление: Я думаю эта публикация довольно хорошо справляется с суммированием плюсов и минусов в разделении проектов.