rhysbb

http://engineering.twitter.com/2012/12/implementing-pushstat...

I'm not saying you can't build larger applications using Backbone, I'm just saying the journey to completing one and then maintaining it will be harder. Large javascript application used to bw written without any frameworks but I'm not bringing them up as examples. What would be interesting to see would be the same examples written across frameworks in terms of code written, code organization, maintainability and size.

The main issue as I see it is that people choose a framework for a project in a short period of time and larger frameworks tend to take time before you see where they shine. I hear people's reason for going with Backbone because it was really the first major MVC out there and because of it's popularity. When I hear why people go with another framework it's because of features - not popularity.

Add on to this whenever I've talked to people or read blogs on systems made with other frameworks the majority of talks on backbone are how to solve problems they encountered while talks about larger frameworks are how to use new features and get more from your code. Maybe it's just because Backbone has been around longer that we've all had more time to find the hardships, I don't know but time will tell.

Is it FUD to say all this? Probably a little, but if we don't have any fear, uncertainty or doubt when taking on a new project then you probably haven't got any idea what you're getting yourself in to.

there are better frameworks out there for larger projects definitely - but event driven is the best way for larger projects.

Reading this just makes me scared of Backbone for larger projects. Things like having to keep changes to models silent just because a view isn't ready? Backbone is all good and well for small projects, but I think it's be best to look elsewhere for a larger project. The problem is that backbone has a smaller learning curve so people try to get started with it, and it is better than nothing, but in the long run you'll just run in to more dead ends and spend more time on fixing things and getting around edge cases than if you went for a more fully fledged solution like http://emberjs.com or https://github.com/rhysbrettbowen/PlastronJS

A lot of people are finding out that views are the hardest thing to do - especially with Backbone. The problem is that views are tightly coupled to the model so it's hard to build them up. I just wrote http://modernjavascript.blogspot.com/2012/06/v-in-mvc.html for another post but believe that it could be helpful in this situation. You'd need to actually write a Backbone.controller class and move the logic in to there but then you could create a whole lot of Backbone.Views that were generic and could be hooked up through the Control (I'd also like to see a Backbone.MultiView or something that could take several views in and then re-emit the changes and allow people to add in several small component views in to a large view either for a collection or a model.

I wrote https://github.com/rhysbrettbowen/PlastronJS which is an MVC for Closure Tools. I agree with Jeremy on this. but just as an extra with some features I put in PlastronJS that you might want to think about adopting or rolling your own on top of the MVC of your choice.

4. Just create a object store that acts as a factory that will return the same object. In plastronJS there is already an mvc.Store that does this for you.

6. I built on top of goog.ui.Component that has a dispose() method that gets called automagically. I added in methods on the control that will dispose the event handlers when the control is disposed (plus it only has on handler for each type and will react based on an element test).

7. I like the router separate as it decouples the routing string. Instead I use a route and then have a mediator broadcast the new route which controls can listen to.

9. Why would you do this? if you are then you're doing it wrong.

I think people are missing the main points of the article - so here they are again:

"Or, don’t trust what “wise” elders tell you."

"My recommendation: learn the language, and use it to your liking; and don’t rely or blindly accept what any “wise elders” tell you. Try to do something new and crazy every day. You might not end up using the crazy, but it’s the best way to master JavaScript. Develop your own style that you are comfortable with. Experiment."

these points are still up for argument, but really they are pretty trivial. __You__ should __experiment__ with them and see if they are okay to use for yourself. The main trick will be if they make your code easier to understand and/or perform better _everywhere_. As long as it helps one of those cases without the detriment of the other then go ahead, just be aware of why people argue over them.

todomvc is a good way to make people aware of the different frameworks and gives a quick guideline to their "style". If anyone is doing anything more complex then they should be spending the time on each framework's page to evaluate which one has the features they need and if the framework's own documentation and website hasn't got documentation that you need then you probably shouldn't be using it anyway.