Идея такая, например на странице нужна заметка (note) - создаем объект на стороне клиента note = new Note(); и при вызове его методов note.save(), note.delete()
на северной стороне эти методы отрабатывают в соответствующих экземплярах Note(1).save(), Note(2).delete() …
Все классы можно наследовать, наращивая функционал: Note -> Post -> Page -> Blog …
Таким образом мы оперируем объектами, это гораздо удобнее чем классическое создание запросов и их обработка.

Есть ли подобные фреймворки? А то создание “колеса” - не тру путь.

Вот вырезка из моего фреймворка (видео, звук ужасный)

В чем революционность идеи? В том, что используются классы? Или в том, что имена классов совпадают (что не всегда хорошо) на клиенте и сервере?

Андрей Светлов
В том, что используются классы?

Ну да, наверно.
У меня на одной странице (в одном из проектов) используется несколько типов объектов: User, Question, Comments… Самих объектов на странице может быть 10..100 и более. И все они работают не мешая друг другу.
Без подобной библиотеки для реализации такого функционала пришлось бы написать кучу кода, т.е. то что есть в подобной библиотеке, дак вот может не писать колесо, а найти готовые решения - что мне и интересно.

ЗЫ: пока писал в голову пришла ещё одна “фишка”: каждый объект на странице имеет какую-то область, если при обработке команды нужно перестроить содержимое области текущего объекта, то нет обходимости указывать id области, можно будет просто вызвать например self.html_self( template ), сейчас реализую.

Исходники если кому интересно.

У нас довольно сложная клиентская часть и весьма сложная серверная. И там и там — объекты, разумеется. coffee script и python, соответственно.
Так вот. Даже если бы это был один язык — назначение объектов совершенно разное. Нет смысла привязывать объекты одной стороны к другим, лежащим на другом конце провода. Лучше уделить внимание протоколу общения. JSON там используется или что иное — все равно следует описать. Мы описываем в функциональных тестах. А затем разрабатываем серверные и клиентские компоненты независимо друг от друга, опираясь только на протокол взаимодействия.

Мы так делаем. И мне кажется, что подход правильный. Если кому-то удобней другое — может, так оно и есть.