Ок, раз мнений пока нет напишу о своем личном, конкретном опыте. На русском, т.к. удобней излагать объемные мысли именно так.
Оговорюсь сразу, я поклонник MooTools еще с тех времен когда на mootools.org были примеры реализации всяких там аккордионов и других эффектиков. Позже все разнесли по Code и More, подняли порог вхождения в фреймворк, стали взрослей. С jQuery знаком посредственно, но это, на сколько мне известно, более библиотека для эффектов (кидайте уже камни), с очень низким порогом вхождения. Там очень удобные селекторы, повторяющие CSS и вообще все очень мило, куча плагинов и все такое.
Опыт:
Представьте себе большое html5 приложение под WebKit с десятками различных зависимых и не зависимых друг от друга страниц, настройки которых хранятся в сотнях json файлов.
Речь о интерфейсе платежного терминала. Приблезительно понять о чем можно из моего видео-демонстрации: http://www.youtube.com/watch?v=wiXzU6R6NRw
Все этапы работы, прорисовки интерфейсов и эффекты -- javascript. Задача сделать плавный, быстрый интерфейс, который бы работал на старом оборудовании, при этом перезагрузка страницы нежелательна и от этого нужно уйти. Реакция на нажатие должна быть мгновенна и очевидна, срок разработки -- "ВНЕЗАПНО".
Подход:
Как бы вы подошли к реализации подобного? Уточню, в основе всего лежит масштабируемость, в какой-то момент может быть сломана концепция, из-за чего нужно уменьшить количество неизбежных переделок.
Первое что отпадает само собой -- функции с названиями типа mainPage_show(), mainPage_changeCat(), mainPage_selectProvider(). Сейчас реального js кода - 186кб в 23х файлах не учитывая mootools и вся эта логика должна оставаться читаемой при любых объемах.
Прототипы отпадают из-за того что я их не понимаю. Однако, есть код который реализует инпуты, в нем как раз используются прототипы. Состоит из 300 строк и является нечитаемым практически полностью, так что в эту сторону даже не хочется смотреть в таком проекте.
ООП которое предоставляет мутулз или простое представление объектов в виде:
var MyClass = {
"foo": function(args){
return "bar"
}
}
MyClass.foo()
позволяет быстро проэцировать имеющий опыт разделения логики и таки уложиться во ВНЕЗАПНЫЙ дедлайн. Почему именно mootools.Class, а не подобие приведенного выше примера или другая реализация? Просто я умею им пользоваться и оно нормально работает.
И так, разделяем логику на экраны:
Основной экран - содержит колонку с категориями и провайдерами в категориях
Экран ввода реквизитов - обычно это ввод номера телефона или номера договора, или логина/емейла, от чего зависит тип отображаемой клавиатуры - цифровая или буквенная (с русскими/украинскими буквами и английской раскладкой)
Экран оплаты - всегда стандартное отображение. Картинка выбраного оператора, сетка комиссии для выбранного оператора, какая-то информация, и реакция на деньги и нажатие кнопки оплатить
Все хорошо. Делаем. Все работает полгода-год. Появляется необходимость показывать (исходя из настроек) экран паркомата первым, а не основной экран. В случае модульной реализации нужно создать класс, по ранее определенным стандартам и в зависимости от настроек сделать не new MainPage(), а new MainParkingPage() и все работает.
Далее, внезапно появляется необходимость принимать не только одно поле для ввода, а два или три, например для платежа на WebMoney нужно спросить еще и номер телефона. Как быть? Архитектура ведь этого не предусматривала... Придется переписывать архитектуру. Если все модульное и с подобием ООП, мы можем определить в настройках вебмани, что теперь отрисовку ввода реквизита будет выполнять другой класс, а в методе реакции на выбор провайдера добавить условие, при котором будет вызываться метод show() у произвольного класса, а не у стандартного. В произвольном же, мы наследуемся от стандартного и дописываем еще один экран перед оплатой. Ничего не ломается, ничего не рефакторится координально.
Собственно, вот. Я благодарен мутулзу за то, как им удалось реализовать привычное ООП в javascript из-за чего я не потратил много времени на рефакторинг по мелочам. Конечно, такого можно достигнуть и используя другие методы разработки, но будет ли это так эффективно, вот что мне хотелось бы обсудить 
