Как вы управляете своими файлами Javascript?

Прежде всего, Компрессор YUI.

Сохранение их организованности зависит от вас, но у большинства групп, которые я видел, есть только придумать соглашение, который имеет смысл для их применения.

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

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

У меня будет папка для всего javascript и подпапка для сторонних / общих библиотек, а также подпапки для каждого компонента сайта, чтобы все было организовано.

Например:

/
+--/javascript/
    +-- lib/
    +-- admin/
    +-- compnent1/
    +-- compnent2/

Затем прогоните все через минификатор / обфускатор в процессе сборки.

Я использую это в последнее время: http://code.google.com/apis/ajaxlibs/

И затем есть папка «jscripts», в которой я храню свой собственный код.

Организация

Все мои скрипты хранятся в структуре каталогов, которой я следую всякий раз, когда работаю на сайте. Структура каталогов обычно выглядит примерно так:

+--root
   |--javascript
      |--lib
         |--prototype.js
         |--scriptaculous
            |--scriptaculous.js
            |--effects.js
            |--..
      |--myOwnScript.js
      |--myOwnScript2.js

Если, на случай, если я работаю в команде, используется чрезмерное количество скриптов, я обычно создаю каталог обычай, в котором мы будем организовывать скрипты по взаимосвязи. Однако это случается не так уж и часто.

Сжатие

Хотя существует множество различных компрессоров и обфускаторов, я всегда возвращаюсь к Компрессор YUI.

Включение

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

В моем последнем проекте у нас было три типа файлов JS, все они внутри папки JS.

1. Код библиотеки. Набор функций, используемых на большинстве страниц, поэтому они были объединены в один или несколько файлов.
2. Классы. У них были свои собственные файлы, организованные в папки по мере необходимости, но не обязательно.
3. Специальный JS. Код, относящийся к этой странице. Они были сохранены в файлах с тем же именем, что и страницы JSP, на которых они должны были запускаться.

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

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

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

Кэл Хендерсон (известный на Flickr) написал Быстрое обслуживание JavaScript некоторое время назад. Он охватывает доставку активов, а не организацию, но может ответить на некоторые из ваших вопросов.

Вот список пунктов:

• Да, вам следует объединять файлы JavaScript в процессе производства, чтобы минимизировать количество HTTP-запросов.
• НО вы можете не захотеть объединяться в один гигантский файл; вы можете разбить его на логические части и распределить стоимость передачи на несколько страниц.
• Сжатие gzip - это хорошо, но вам не следует передавать заархивированные ресурсы в IE <= 6, поэтому вы также можете уменьшить / сжать свой JavaScript.

Я добавлю несколько собственных пунктов:

• Вы должны найти решение, которое будет работать как для разработки, так и для производства. В режиме разработки он должен загружать дополнительные файлы JavaScript по запросу; в производстве он должен объединять все заранее. Переключение с одного поведения на другое должно быть таким же простым, как установка флага.
• Rails 2.0 обрабатывает все это через кеш активов; другие платформы веб-приложений могут предлагать аналогичные решения.
• Как следует из другого ответа, размещение сторонних библиотек в каталоге lib - хорошее начало. Вы также можете разделить свои собственные JS-файлы на подкаталоги, если это имеет смысл. В идеале вы сможете организовать их таким образом, чтобы файлы в данном подкаталоге можно было объединить в один файл.