3 ms·
I've used Backbone for a couple projects. Then I used Angular because I liked the two way binding and easy access to history. Still, I generally find that these
by Arnor 13y ago
I've used Backbone for a couple projects. Then I used Angular because I liked the two way binding and easy access to history. Still, I generally find that these frameworks get in the way for most of my projects. I tend to use the following structure:
(function () {
'use strict'
var n;
$(document).ready(function () {
// Event listeners here
$('#some-id').on('click', n.Product.respond_to_some_click);
}
// Sometimes I omit the n variable and just pollute the global namespace because I'm BA like that.
n = {
Product: {
respond_to_some_click: function() {
// Do some stuff
}
},
Cart: {
},
Whatever: {
}
}
}());
This structure keeps things pretty well organized without a real need for a framework. So far this has been a really comfortable alternative to a heavy framework. I can't wait to get it ripped to shreds and see how I can improve :)
- popotamonga 13y agoLaunching a massive project with that exact same structure soon. No problems at all. Feels so flexible.
- ktusznio 13y agoThis 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 13y agoIn 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 13y agoI 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 13y agoThat's a good point. However, it's till tempered by the fact that I haven't added ~40kb to the app to get it.
- WiseWeasel 13y agoWhy not have a hashchange listener going to a hash-parsing router function, and make #some-id an anchor to a hash link with slash-separated parameters, or just use Backbone's router to handle your request? Then you don't need to keep track of a bunch of element id references.