Но появляются мысли вот какие: ты пишешь “Без Prototype Lite в первом случае я бы прожил легко”. Но, представь себе ситуацию, что проект надо развивать и необходимо добавить еще фунционал.

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

Что до монстрообразности, то любой продукт, который умеет много, сложен и нелегок. Без этого никак. Потому что мало того что ему надо обрабатывать стандартные ситуации, он должен еще обрабатывать чужие и свои баги, а также оставлять возможность для повторного использования и расширения, т.е. создавать абстракции на каждый чих. Отсюда и монстрообразность.

Про плагин - у тебя есть файрбаг, посмотри как у людей :)
Hint: не хватает overflow:auto

И конечно, как показала практика, не надо было бояться Яхи..
Но появляются мысли вот какие: ты пишешь “Без Prototype Lite в первом случае я бы прожил легко”. Но, представь себе ситуацию, что проект надо развивать и необходимо добавить еще фунционал. Если ты не используешь PrototypeLight тебя два пути: переписать все под какой-либо тулкит или дописать функционал самому. Причем последний вариант чреват вероятным повторением ситуации. Если ты уже используешь ProrotypeLight, то скорее всего тебе достаточно будет преключиться на полную версию и скачать пару плагинов..
Отсюда напрашивается ошибочный сомнительный вывод — всегда и везде сразу же надо юзать могучие универсальные библиотеки. Я до конца не уверен сомнительно или ошибочно ли использовать могучие тулкиты для всего, но такова общая тенденция и это как минимум настораживает. Примеры того, что люди отвыкают мыслить просто, даже приводить нет смысла — они кругом.. :(
И в то же время постояно появляются примеры того, что “сложномыслие” оправдало себя в последствии.

И это только одна сторона проблемы. Сама проблема глубже и шире. Яха спугнула монстрообразностью. Этой тенденции подвержены и серверные (да и десктопные) приложения. Наращивание функционала увеличивает не только размер, но и усложняет API для разработчика, и, зачастую, UI для пользователя. Последнее представляется мне наиболее опасным с точки зрения “торговца готовым продуктом”. Я еще хочу написать об этом позже, когда дойду до софта.

PS: поставил этот плагин — все равно рвет ленту..

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

Мой пример. Я давно использую YUI. При этом все равно возникает куча своего кода, который часто бесит. При этом для YUI (как и для JQ и Prototype) есть офигенная надстройка - Ext. Объем занрузки его поначалу отталкивает. Однако сейчас я уже крепко сомневаюсь в том, что мой код поверх YUI занимает меньше места и более хороший, чем был бы код, написанный поверх Ext, вместе с самим Ext.

В любом случае, все зависит от того, для чего тебе это нужно. Для пары эффектов на одном сайте с выплывающими фиговинами и т.п. я брал Prototype Lite, и писал анимацию сам. На другом, где куча диалогов, драгдропа, автокомплита и прочего аджакса, загружается почти полностью YUI и куча моих надстроек. Без Prototype Lite в первом случае я бы прожил легко. Без YUI во втором мне бы пришлось написать что-то свое типа YUI. По объему, наверно, оно было бы меньше, но по качеству - сомневаюсь.

P.S. Женя, убери этот ужас с листингом, поставь себе http://www.softwaremaniacs.org/soft/highlight/ :)

1. Как выбрать подходящий момент? Начать рефакторить рано — разработка сведется к “рефакторингу ради рефакторинга”. Опаздать — проще переписать, чем отрефакторить.
2. Для одного постоянно и стабильно развивающегося проекта, с четкой структурой и требованиями это единственный верный путь. Легкость поддержки совместимости версий, удобство обновлений. Про серверную часть я позже скажу отдельно, а в вот случае с вышеупомянутым жабаскриптом: обновить несколько десятков сайтов одновременно практически нереально, а обновлять надо одновременно, потому что ядро системы одно и модули, использующие JS, прийдется так или иначе обновлять. При этом на большинстве сайтов, SVN, к сожалению, после рефакторинга либо потянет за собой конфликты, либо форсированно убъет сайт-депендент кастомайзы.