Давайте по порядку.
Про велосипеды
Моя разработка делается по системе. Сперва я составляю документы, в которых расписаны сценарии: что должен делать фреймворк, и как именно. Потом на основе этих документов я составляю требования. Потом уже на основе требований делаю проэктирование. И только потом пишу код. Но фреймворк это действительно нереально сложная штука, поэтому с первого раза у меня не получился ни один слой.
Слой Scope + виды - я переписал раз 10 почти с нуля. И еще несколько раз частично. Причем был такой момент, когда я сказал "ну все, наконец то готово!". А потом достал маленькое требование из бэклога... "ё моё, опять все переделывать". Примерно после 7 раза.
Refresher - 3 раза с нуля
Шаблонизаторы - 3 раза с нуля
Data - 1 раз полностью, и много раз по кусочку
mixin.Observable - 1 раз полностью
Анимация - примерно раза 3...
Еще бывало за один рефакторинг я заменял штук 500 использований какой-то функции по всему коду. Так что у меня серьезная система, выбранная осознанно.
Насчет стиля кода
Локальные переменные у меня именуются через подчеркивание, даже если там лежит функция:
var my_cool_function, my_cool_variable
Но функция из API класса никогда не будет названа my_cool_function, правильно myCoolFunction.
Почему подчеркивание вместо camel: у меня есть серверный PHP движок в разработке, и я взял один стиль чтоб не путаться.
Но примеры, которые привел fancy - они не все из моего кода.
Например, если у меня действительно есть что-то вот такое, то это нужно исправить:
if(n)
a = 5;
В моем коде есть такие штуки, но в одну строку - в основном DEBUG проверки. Если к ним добавить скобки и разнести на 3 - то код становится практически нечитаемым, пробовал.
У меня всегда один var на функцию. Исключение - пример todo_app - им так нравится, и это их правила. Есть хорошая причина использовать один var на функцию - variable hoisting.
http://designpepper.com/blog/drips/v...ction-hoisting
Помогает избежать ошибок.
Приватные методы
Приватный метод - это не тот метод, который используется внутри фреймворка. Приватный метод - это метод, который нельзя вызывать извне. Тут у меня закралось подозрение, что вы, fancy, никогда не программировали на C++...
Если во фреймворке есть код, который используется только внутри фреймворка - то это мусорный код. У меня весь код - для программиста. Все методы в моих классах, даже приватные - можно переопределить (во всем фреймворке есть всего 3 исключения, которые нужно будет пометить как final, когда добавлю поддержку в ClassManager).
Надеюсь, правильно понял.
Насчет MooTools - мне тоже не нравится что он расширяет прототипы глобальных объектов.
Поэтому у меня есть Firestorm. Со временем я буду переписывать MooTools и переносить его функциональность в Firestorm, и там будет все как вы и написали. Когда тесты будут.
Про жесть
this.Text$broadcastInDOM();
О, это вызов родительского метода. Так работает моя система классов. И благодаря этому она такая быстрая. Предлагаю разобраться по учебникам. Если будут предложения получше, когда разберетесь - пишите.
var element = this._input_container.getDOMElement();
Тут все в полном порядке. "_input_container" - приватная переменная, getDOMElement - публичная функция. Все вместе - часть красивой и гибкой Системы. Что с этим не так?
API у меня - произведение искусства. Но не современного, в котором каждая мусорка это искусство, а старого. Когда люди еще читали книги про рефакторинг, паттерны, и шарили C++.
"пробуй себя в js в Москве"
Думаю, еще успею. И я уже давно не студент.
Кстати, mail.ru и Яндекс - это фактически иностранные фирмы на российском рынке.