Hacker News Reader

Comment by rhysbb | Hacker News Reader

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

View on HN

> 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.

Amen, amen, 100 times amen. It's a real tragedy that this particular line of FUD has caught on, but hey -- so it goes.

Links, for the curious:

http://backbonejs.org/#examples

http://builtwith.angularjs.org

http://knockoutjs.com/examples/

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.

Here is some more FUD for you ( http://www.thoughtworks.com/articles/technology-radar-octobe... ):

"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'm gonna be puking all day because of that quote.

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.

Reply on news.ycombinator.com