Грамотная организация кода

[trasher]

Всем привет!
Собственно, разрабатываю сайты с использованием JS уже достатоно давно (использую jQuery), но вот недавно подвернулся довольно крупный проект и в связи с этим задался таким вопросом: а как наиболее правильно и грамотно структурировать код?

К примеру, у меня много обработчиков событий после $(document).ready вешается, но часть из них используется только на определенных страницах. Аналогичная ситуация с бОльшей частью кода: все функции тупо в одном файле, но юзается на странице на одной только процентов 20-30 из них. Или плевать на это: юзер загрузил файл, он попал в кэш и все, уже неважно?..

Другой пример, на странице необходимо повесить обработчики событий на нажатие клавиш. Что же, в середине страницы подключать файл с функциями для обработки нажатий клавиш, а ниже делать блок <script>, где инициализировать этот код? По-моему, не совсем изящно.

Вот как лучше устроить структуру кода, всех функций?
Как я понимаю, желательно на странице инициализировать только то, что потенциально может использоваться на ней, но какими способами можно это сделать(выстроить такую структуру)? Разбить все на классы?
С ООП в JS особо не работал, если честно.

Конечная цель: чтобы обилие функций (и в дальнейшем увеличение их кол-ва) не сказывалось на скорости работы браузера.

P.S. Кстати, что лучше использовать: bind или live? Различия между функциями знаю, но с точки зрения производительности браузера что лучше? live, вероятно, постоянно мониторит появление новых элементов -- влияет ли это как-то на скорость?

Всем спасибо за внимание.

[PeaceCoder]

постоянно мониторит появление новых элементов -- влияет ли это как-то на скорость?

не элементов а при событии проходится по всем элементам от источника (до document если ничего не подходит) с проверкой селекторов. Обилие .live при событии mousemove|over|out - браузер загнется.

[subzey]

…зато для click .live подходит шикарно. Единственное, что не радует, так это то, что Рейсиг решил полностью забить на capturing.

PeaceCoder, в Вашей библиотеке же будет capturing? (Ну, а для кривого априори IE — setCapture(), свойства onbeforeactivate, ondeactivate и прочие радости)

[PeaceCoder]

PeaceCoder, в Вашей библиотеке же будет capturing?

Можно реализовать, но скажите хоть 1 плюс этой фишки ?

[x-yuri]

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

почему в середине? Конечно, в конце

Как я понимаю, желательно на странице инициализировать только то, что потенциально может использоваться на ней, но какими способами можно это сделать(выстроить такую структуру)? Разбить все на классы?

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

Конечная цель: чтобы обилие функций (и в дальнейшем увеличение их кол-ва) не сказывалось на скорости работы браузера

попробуй поразбивать свои скрипты на более маленькие (не от фонаря, естественно) и померяй производительность

[twolf]

trasher,
http://www.ozon.ru/context/detail/id/3159814/
http://www.ozon.ru/context/detail/id/2457392/
http://www.ozon.ru/context/detail/id/1308678/
Осилите - станете гуру

[subzey]

PeaceCoder,
Фазу capturing (в нормальных браузерах) проходит любое событие, в то время, как bubbling — только те, для которых исторически так сложилось.

К тому же, обработчики на фазе capturing запускаются раньше DOM0-обработчиков и bubbling. Да и почти любое событие проходит при capturing через document в любом случае.

Кто контролирует спайс capturing, — контролирует Вселенную.

[x-yuri]

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

[B~Vladi]

Плохо искал?

Не дочитал видимо

[x-yuri]

Не дочитал видимо

ну а что там такого интересного написано? Лучше бы написал пару статей и не в таком нудном стиле (вот такие вот от нее у меня впечатления остались)