3 ms·

I fully agree. That's one of the reasons when I'm a part of a team and I need to make a decision about a framework, I usually go with Backbone. It's source cod

I fully agree. That's one of the reasons when I'm a part of a team and I need to make a decision about a framework, I usually go with Backbone. It's source code consists of one file that can be understood for less than an hour. Last non-sense in this complexity is the boom of JavaScript framework specific languages that pop up. Like ReactJS and recently Angular 2.0 is preparing their own language for using it's platform.

mrcwinn 12y ago
I completely agree about Backbone. Backbone is a very simple tool. You can do a lot of damage if you're not yet a very good developer (or a very good Backbone developer), but if you care about your craft and the design of your application, it's fantastic. In fact, having the flexibility to make decisions about your application, forces you to make good design decisions. That is the mark of a great developer. With these other frameworks, which might be very large or very slow or very complicated, they enforce that design on you. For most projects, who cares? Use whatever is fun for you to use. Learn 'em all. But at a certain scale, it matters deeply what you hitch your wagon to.
- jashkenas 12y ago
  As the person who has been resisting adding more magic to Backbone for several years ... it's awfully nice to hear this sort of thing. Cheers.
  - ak39 12y ago
    Hi, thanks for the great work on Backbone! Appreciate it. How does Backbone relate to the points the original article makes? What are your comments?
3pt14159 12y ago
I completely disagree about Backbone. Sure, what Backbone does can be understood in about an hour, but since it isn't very opinionated and since it doesn't do very much for you, you end up having to figure out every single codebase you step into. Yes, Ember is annoying when it isn't working. I once spend four days (!!) tracking down why something wasn't working when I was first learning Ember, but I can look at any Ember code base and understand it in under an hour whereas with Backbone and Angular I see people implementing their own (often broken) patterns and solutions.
- drinchev 12y ago
  I think your argument benefits my opinion. I'm using Backbone exactly for the reason that you state you've been. I don't want to put a client ( I work as a freelancer ) in the position to look for someone that knows framework "A" or "B". Also I'm pretty sure "A" or "B" will soon be obsolete and the successor will need to change the whole codebase, instead of improving it. I'm not talking about Ember, actually I'm also using it, but when it happens to go for scalable project I would prefer Backbone, because of team members learning curve and potential developers availability.
  - LunaSea 12y ago
    I think he's arguing that Backbone.js in itself is fine but since it doesn't do much you have to add plugins or write your own implementation of the missing parts. The issue with that is that the learning curve is now higher because the chances that a developer knows those missing parts that you added or coded is increasingly small. Btw, I'm a heavy Backbone.js user so I still think it's a better option compared to other MVC flavours but I do have the problem that a lot of things related to data binding and UI animations is custom built and have the issue described above.

mrcwinn 12y ago

I completely agree about Backbone. Backbone is a very simple tool. You can do a lot of damage if you're not yet a very good developer (or a very good Backbone developer), but if you care about your craft and the design of your application, it's fantastic. In fact, having the flexibility to make decisions about your application, forces you to make good design decisions. That is the mark of a great developer. With these other frameworks, which might be very large or very slow or very complicated, they enforce that design on you. For most projects, who cares? Use whatever is fun for you to use. Learn 'em all. But at a certain scale, it matters deeply what you hitch your wagon to.

jashkenas 12y ago
As the person who has been resisting adding more magic to Backbone for several years ... it's awfully nice to hear this sort of thing. Cheers.
- ak39 12y ago
  Hi, thanks for the great work on Backbone! Appreciate it. How does Backbone relate to the points the original article makes? What are your comments?

3pt14159 12y ago

I completely disagree about Backbone. Sure, what Backbone does can be understood in about an hour, but since it isn't very opinionated and since it doesn't do very much for you, you end up having to figure out every single codebase you step into. Yes, Ember is annoying when it isn't working. I once spend four days (!!) tracking down why something wasn't working when I was first learning Ember, but I can look at any Ember code base and understand it in under an hour whereas with Backbone and Angular I see people implementing their own (often broken) patterns and solutions.

drinchev 12y ago
I think your argument benefits my opinion. I'm using Backbone exactly for the reason that you state you've been. I don't want to put a client ( I work as a freelancer ) in the position to look for someone that knows framework "A" or "B". Also I'm pretty sure "A" or "B" will soon be obsolete and the successor will need to change the whole codebase, instead of improving it. I'm not talking about Ember, actually I'm also using it, but when it happens to go for scalable project I would prefer Backbone, because of team members learning curve and potential developers availability.
- LunaSea 12y ago
  I think he's arguing that Backbone.js in itself is fine but since it doesn't do much you have to add plugins or write your own implementation of the missing parts. The issue with that is that the learning curve is now higher because the chances that a developer knows those missing parts that you added or coded is increasingly small. Btw, I'm a heavy Backbone.js user so I still think it's a better option compared to other MVC flavours but I do have the problem that a lot of things related to data binding and UI animations is custom built and have the issue described above.