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
> Backbone is all good and well for small projects, but I think it's be best to look elsewhere for larger projects.
This is such ridiculous FUD, and I'm surprised every time I hear it. Compare the apps built with Backbone section of their site against similar lists of any competing framework. There are some seriously complex apps there. More big ones than any competitor.
Just because a framework is minimal doesn't make it ill suited for large projects. That goes for all frameworks, not just js ones. And yet I see this argument trotted out against minimalist frameworks in every language I work in.
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.
"Backbone.js is a great example of an abstraction pushed too far. While we initially liked the ease of wire-up, in practice it suffers from the same issues as all such data-bound frameworks from WebForms to client/server tools. We find that it blurs the framework and model too much, forcing either bad architectural decisions or elaborate framework hackery in order to preserve sanity.
As the industry shifted from desktop GUI development to the web, it seemed natural to port the most successful patterns and designs to the new paradigm. After 15 years of trying, we feel that there are still no component-based frameworks that have successfully achieved this. We recommend not attempting to make web development into something that it fundamentally is not. It is time to accept the page and request-based nature of the web, and focus on the frameworks that support - rather than work against - these concepts."
This is diametrically opposed to my experience, and I'm really surprised by the stance of ThoughtWorks on the matter. Hope I'm not doing a disservice by spreading the FUD. My belief is that most of the competing JavaScript frameworks are abstractions (and magic) pushed too far.
I'd argue that the problems in large projects are primarily architecture problems, that backbone's philosophy of 'bring your own architecture' means how well an app is structured is entirely up to its authors rather than defined by library choice. Something like your plastronjs or emberjs are saying 'Here, do it like this'. Which is good. Sometimes.
I've certainly run into many issues using backbone for moderately sized applications (form workflows, several different types of records, etc) but every time I get myself out of them I gain general javascript knowledge rather than domain specific knowledge about framework xyz. I'd much rather know how to effectively manage memory in javascript than how to use a particular framework.
Following the same argument, you should probably have started with assembler - because, then you would have gained a significant amount of knowledge about the system ( at such a deep level ).
The point of programming is about creating abstractions, so that you dont have to think in terms of the underlying infrastructure. The higher the level of abstraction, the faster you can code, the faster your output will be and faster the business can progress towards a product.
The question is : Is the end goal of your project a product for a business or a means for you to learn the nitty-gritties of javascript?
That's great, if you frameworks abstractions aren't leaky. Which they almost certainly are.
At that point the question is whether the troubleshooting, as stated, will teach you about how to solve the problem with javascript in general or framework specific contortions to work around it.
Assuming that all frameworks are leaky and writing from scratch is almost always a waste of time. Even if something is leaky and you spend a week trying to fix it, it will probably still be faster to build using those abstractions than to build something from scratch.
In my current company, we were building a multi page form for registration. It took us ( 2 guys ) a whole of 3 weeks ( with html and css pre built! ) to bring it to a level that is acceptable. I had built the same with angular earlier because I was trying to show that it could be done faster and with lesser code. The guys in management did not accept it because it is still "new". So we spent 3 weeks building this which would have taken around 3-5 days in angular.
You raise an interesting point. That technique was developed in response to a difficult part of the migration. I had stories coming in for subsequent pages of an rss feed, but I didn't want to re-render the story view until I had a chance to work with the un-rendered story views.
I realize this can be a bit complicated, but at some point you'll be wishing you could just turn off an event from firing because it's interfering with a juggling act. This is what that technique is used for.
But any project that reaches a certain scale will tend towards having some unfortunate ties between models that makes a more-than-ordinary transition hard to accomplish. It can be done, but I'm not quite there, and I suspect many other developers aren't either. This one's a stopgap.
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.
Sorry how they are tightly coupled in backbone? I have a number of beefs with backbone.js but coupling between the model and views (or the views and anything) is not one of them. In fact I mostly only use backbone for the views and the convenient event binding.
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.
If that's all he had said, there wouldn't be so much pushback. But instead, he's setting himself up as a "wise" elder dispensing advice, and (ironically) much of what he's said is wrong.
If his point two was, for example: "You should always test received wisdom. You've probably heard not to use 'with', but do you know why? Well, let's write a quick benchmark, here's some code with 'with' and here's some without. And if we benchmark it like so...hey look! The code with 'with' is a little clearer, but it's glacially slow! And now you know not just why and when to avoid 'with', but how to test other language features too!"
But instead, basically, he said "Hey, don't listen to those idiots who say not to use 'with', listen to me! And I say it's awesome!" This is unhelpful on multiple levels.
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.
