[ktusznio]

This approach is fine for small projects but you'll run into organizational problems once your application's complexity grows. For example, how many event listeners are you going to pile into that $(document).ready callback before you decide to break things up? How do you organize your code if/when you separate your listeners.

Another aspect your code doesn't address is fetching/posting data from/to the server, which leads to many more tangles, especially once you start duplicating code between models, etc.

Anyway, this isn't a criticism by any means. If such a lightweight approach is working well then you're doing it right. I'm just pointing out that things can get hairy as your app needs to do more and more.

[Arnor]

In my current project I have 20 listeners in the ready function. I can see how it would get pretty nasty if I got up to the 100+ range. I think that would be settled by tacking on a listeners method to each of the models:

    ...
    $(document).ready(function () {
        n.Product.listeners();
        n.Cart.listeners();
    });
    ...

Ooo... I like that, maybe I'll implement that...

Regarding the fetching/posting data, I have an ajax method on the applicable model. Fortunately, I'm writing the server app as well so I got to make some decisions on that end that simplify the approach (e.g. everything goes through POST, all data comes back as JSON.) I suppose that makes the AJAX acronym imprecise... AJAJ?

[waltsu]

I hope that you realize that when you've divided your listeners to Product and Cart objects, you've created a "lightweight" Model representation. Next thing you probably need is to fetch those Products and Carts from the server, and you add fetch()-function to them. Soon you'll realize that you've rewritten for example Backbone's Model class. With the exception that your solution has probably more bugs.

[Arnor]

That's a good point. However, it's till tempered by the fact that I haven't added ~40kb to the app to get it.