Should we use backbone?

[yornaath]

Im forking this discussion of the tech stack discussion.

The question is "should we use Backbone and or require.js"?

Personally I like the backbone - require.js combo very much. Its easier to structure the app and compartmentalize it into well defined modules en entities.

However, It can be cumbersome and to much off a threshold if one is not familiar with it.

On the other hand if one wants to learn backbone and requirejs this is an excellent project to learn it by using it.

Thoughts?

[peirix]

Yeah, that last part is what I realized yesterday. That if I ever want to learn how to use a proper JS mvc library, this is as good a time as any to do it. So I'm coming around to the idea of using backbone. Haven't looked too much into the code yet, but it looks a bit overwhelming at first. Maybe we could meet up one day and go through the ideas of backbone, because the website was useless...

[alexyork]

I have pushed some code under /examples/plain-js/ of how I envisaged the project to be, if we do not choose Backbone. I have made it as simple as possible, with pretty good unit test coverage.

[yornaath]

That looks solid! I think il let you two decide if you want to use backbone or not. Either way Im happy ^_^

[yornaath]

Btw, Im home in Kragerø for the summer so I won't have the chance to meet up before the start of august. But id love to do so when I get back!

[alexyork]

My comments on the Backbone implementation are the following:

Pros:

• It is a comprehensive and feature-rich framework that gives us a lot for free;
• JavaScript MVC frameworks are interesting and worth learning;
• It seems like it would be a good way to organise large JS apps.

Cons:

• The decision to use Backbone seems to leak throughout the entire design (every line of JavaScript seems to be deeply linked to Backbone, meaning we are tied down to it forever). Tying ourselves down to a 3rd party framework at such an early stage seems like a mistake;
• By quickly glancing at the code, it is almost impossible to get a "quick overview" as to what is actually happening, without understanding many other Backbone concepts first (hard to see exactly what code is running, hard to find functions, views, etc);
• Unit testing does not seem easier than unit testing plain JavaScript;
• There are several other JS libs that it has a dependency on (underscore and (to some extent) require.js);
• Backbone seems too complex for such a small app.

When I wrote my other implementation, I consciously wanted to combat a lot of the cons:

• It keeps it simple;
• The unit tests are really simple, and test our code independently of any 3rd party vendor libs;
• Our code creates abstractions over any 3rd party libs we use (for instance, the unit tests or the calling code in app.js know nothing about the fact that under the hood we use linq.js and MicroTemplating) and therefore we can swap out these implementations quickly and painlessly without changing any calling code or any unit tests;
• 3rd party vendor libs I chose are tiny, and do not "leak" into the design of the app.
• It is easy to get a quick overview of the code by glancing at the code and navigating around it.

Do you guys have any similar comments or pros/cons, etc, so that we can make an informed decision about which route to go down?

[yornaath]

• "Unit testing does not seem easier than unit testing plain JavaScript"

I dont agree on this point, where you have to test all your functions, like getting all, templating and such. I don't have to do that with backbone, because the built ins are so thoroughly tested. What I do have to test is my own custom functions like app/collections/Talks.prototype.search

• "it is almost impossible to get a "quick overview" as to what is actually happening, .."

I think this is more because I use require.js than backbone to be honest. It adds a lot of boilerplate for defining modules and dependencies. But we don't have to use requirejs. We can use the pattern of object namespacing like you did in your code. example:

  TrondheimTDC.TalksCollection = Backbone.Collection.extend( {} )

I agree it makes easier to see where an object lives and its always available in global namespace under TrondheimTDC.

I don't feel backbone is ass intrusive as you portray it. Think of Backbone.Model as a class that extends native Object and Backbone.Collection as a class that extends native Array. The view is where you do DOM event binding and handling and discourages binding of events elsewhere in the code. This is a good thing in my opinion as it compartmentalizes the view logic.

All that aside I also agree that it might be overkill for such a small project!

[alexyork]

Thanks for explaining some stuff, there :-)

Since you said it yourself, Backbone might simply be overkill for such a small project. My vote, as you have probably guessed, is to use plain old vanilla JavaScript and stay away from 3rd party libs as much as possible. Where we do use them, they should be hidden away behind our own abstractions in a manner that is easy to swap out with different implementations (exactly as I have done with linq.js and MicroTemplating).

In general, I am a "framework skeptic" as you have probably guessed ;-)

[alexyork]

I have been looking into Backbone and your example a little more carefully this last couple of days. I have changed my mind! It is awesome.

I think we should use it for this project. It is exactly what we need:

• A way to organise a JavaScript-heavy web app;
• Built in templating via Underscore.js;
• A clean way to separate DOM event handling from the rest of your JS.

However, my grumblings about it being hard to "get an overview of what is happening" were in part due to Require.js, like you pointed out. I wasn't sure which parts were Backbone and which parts were Require, and looking at the code without experience of either was pretty confusing. Since all Backbone code was wrapped inside Require functions, and the Backbone objects were sometimes given different names in the context of a Require parameter... it was even more confusing :-)

I think Backbone will give us a lot of benefits on this project. I think Require won't give us all that many benefits, but it will make learning Backbone a little trickier for me and Pål. Require seems to be a way to load JS into modules in a way that doesn't pollute the global namespace. I can see how that would be a big problem on a large project with loads of devs writing JS code without knowing what each other are doing. But that won't really happen on this project, since the app is so small and we are cooperating so tightly. Let's ditch Require for now, and go with Backbone. We also don't need MicroTemplating because Underscore has that built-in.

Just now I have pushed some code similar to the example you made - but without Require. I wrote it from scratch, taking parts of your code, and parts from other examples on the web... which was a great way for me to learn Backbone.

This was a big help when learning Backbone: http://backbonejs.org/examples/todos/index.html

Thoughts?

[alexyork]

BTW, yes it also might be a good idea to do this, since we aren't using Require:

TrondheimTDC.TalksCollection = Backbone.Collection.extend( {} )