Feedback

[addyosmani]

As requested, here's my feedback and suggestions for the project:

• I would consider switching out QUnit as the default testing framework of choice in lieu of Jasmine. Whilst QUnit is great and is generally considered de facto when it comes to testing jQuery plugins, I've personally found that more Backbone developers use Jasmine. There's also a considerable amount of more documentation, tutorials and articles about using Jasmine/BDD to test both standard Backbone and RequireJS + BB apps and authors currently writing BB books (other than myself) seem to be opting for it as well. Having spoken to Irene, I know that BB is officially using QUnit for it's own unit tests, but as many of us agree they suck, I don't think we could consider it a good example we could point people at to make-up for the lack of tuts. In this light, I feel it would make more sense and as both QUnit and Jasmine can be easily swapped, perhaps it's not that big of a change to make.
• Have you given any thoughts to internationalization? I'm not sure whether this is something that you would like developers to think about more but it might be useful to provide some boilerplate code that demonstrates how to support i18n. Script loaders like Require.js certainly support this out of the box but maybe it would be of benefit to show people how to support it without? Would definitely help convince those with English as a second language to seriously consider using this.
• In the architectural/filesystem pattern being used, each block of models/views/collections are wrapped within individual modules which we're explicitly calling 'modules' . It's something which may have been discussed in the comments section of the original post by Tim and Irene, but there are developers who are used to either wrapping each view/model/collection into it's own 'module' using RequireJS and AMD whilst others are used to MVC being kept separate and 'modules' only being utility blocks which views etc. access. I think that (especially given the first) it might be of use to clarify how this boilerplate might sit in a RequireJS backed application - maybe even just on the wiki or somewhere else. Fwiw, in my discussions with some of the Yahoo/YUILibrary folk, they actually describe a module/view/collection block wrapped in this manner as a 'widget'. Soo much terminology, so many different meanings :)
• I see that Ben's grunt solution is currently being used as a part of the build process. I haven't had a chance to review it in great depth just yet, but perhaps it would be of benefit to document/discuss why grunt (or other parts of the build process) were opted for over other solutions. Just playing devil's advocate, some BB developers might wonder why they would want to use this over say something with r.js or based on Rake/Jake etc.
• With respect to server reload #10, are you looking for something that allows you to automatically reload when files get changed? I took a very preliminary look into this for H5BP and I know that @mklabs has definitely done more work on this for a few projects. Might be worth reaching out to see if he might be able to help with this.
• Would it be useful at all for there to be an adjacent 'sample' project (say a Todo app or a multi-view gallery) which is based on Backbone Boilerplate? Looking at it from the perspective of a new developer, I would be interested in seeing how one might structure an application using these module blocks of MVC vs. what the common Backbone apps that come with the framework might do out of the box. It could just be me that feels this would be useful, but just thinking of what would help lower confusion.
• Regarding plugins review #6, do you mean Backbone plugins or build-process plugins? :) If you're referring to the former, I think it might be a challenge to find a common set of Backbone add-ons that are used for every project. It would however be useful to maintain a useful list of these in the wiki.

Hope some of this is of help :)

[wookiehangover]

re: Jasmine

I think that's entirely down to opinion whether backboners (there has got to be a better way to say that) prefer Jasmine over Qunit. Speaking personally, after using Jasime exclusively for about 6 months with several backbone apps, I switched to Qunit for a number reasons--the primary being that I feel like the test runner is "better" (better look/feel, stack traces, try/catch options).

I definitely agree that there's more noise in the community about testing Backbone with Jasmine, but I don't think that necessarily is a corollary to best practices. IMO the lynchpin to making backbone apps easier to test is using Sinon.js, not Jasmine.

That said, I'm interested in whatever's pragmatic.

@addyosmani / @tbranyen what do you think about including examples for both test suites?

[addyosmani]

@wookiehangover That's fair enough :) Perhaps having examples for both test suites would be a compromise?

[tbranyen]

Hey @addyosmani thanks so much for the feedback. I'm going to keep this issue open once this open sourced so others can chime in.

• Yes to jasmine, I think it would work really well. How to integrate along side with qunit is the question, maybe two folders?
• Have not given any thought to internationalization, but thats a serious question to be considered
• Totally want require.js devs to feel at home here. Going to work on a r.js build task that will allow you to define your config
  options in one place. Once I get an app working in here with require.js I'll be happy to do a write up.
• Yup Grunt is totally being used here. I'll add something in the readme in the build section about why a task-oriented build process makes sense over something like stitch/hem/r.js.
• I'll look into @mklabs project.
• I think a sample project is a great idea!
• Looking into reviewing Backbone specific plugins

[iros]

I think personally having two different test strategies in place that effectively produce the same result is overkill. We can pick one and stick to it. While the Backbone.js qunit tests are no good, us providing better ones is a worthwhile investment. QUnit is easier to get started with imho, making it a better introductory framework.

Internationalization is nice, but the boilerplate is useful to get started on a new project. Sadly, no one starts with internationalization in mind and if we were to add facilities to this off the bat it would make the development much more complicated for most developers. It's important, but I don't think should be in the core.

I think a sample project should be another github repo.

[webxl]

Re: sample project

This might sound a little crazy, but I think the primary sample should be another than a TODO app. @addyosmani already has a few of those already: https://github.com/addyosmani/backbone-boilerplates. The gallery gets my vote. Perhaps with some HTML5 video/canvas/etc. goodness

[webxl]

+1 for jasmine

[addyosmani]

@webxl I'm not sure if the project you meant to reference was this http://github.com/addyosmani/todomvc, but you're right :) It might be useful just showing the project implemented as a Todo app. They're generally quite simple and would enable someone to easily compare how Backbone's 'out of the box' Todo app compares with a version written using this boilerplate.

@iros +1 on a sample project being in another repo, also +1 on just having one testing framework in there if you think it makes more sense.

[mklabs]

Hi guys,

Firstly, sorry for the delay, but I didn't get any notification for this thread :(

Secondly, a big thanks to @tbranyen for creating this boilerplate. That seems to be exactly what I need.

Thirdly, another big thanks to @cowboy for creating the awesome build tool that is grunt. The more I use it, the more I like it.

That being said and related to #10, I know that @webxl has done some work and opened a pull request regarding this, but I did some parallel work on it today and ended up with something that works quite well.

I've took a slightly different route by using socket.io and wrapping the static server creation in a grunt task.

Here's a gist to illustrate: https://gist.github.com/1621995

Basically, this task creates and setup a connect server (might be an express server as well) with the necessary configuration to setup socket.io. Then a custom middleware is used to trick the static middleware a little bit to inject a client-side script and establish a new websocket connection. The socket object created when a new connection is made is then stored through grunt's configuration (via config('socket', socket)) making it usable from another task (which will most likely be triggered by grunt's built-in watch task). Finally, when changes are detected, grunt would retrigger the foo tasks which will use the socket object(s) to emit back to clients some event (which would trigger a page reload).

If you're ok, I might clean it a little bit and issue a pull request.

[tbranyen]

Hey @mklabs I'd hold off on the pull request for now. I'm working on a new repository to contain all the build tasks. That way they can be tested, documented and distributed outside of the boilerplate project. In the future it'd be nice to have a command line utility to automatically fetch/update them. Maybe even through NPM...

[mklabs]

Sweet. Sounds like a reasonable option and a really good idea. I'd love to see that happen (even more if it's done through npm :p)

[tbranyen]

Okay some updates:

• Still yes to jasmine and the option will be there in a new release option.
• Looking into Jed and figuring out /via documentation how to integrate would help for internationalization
• there is now a requirejs/amd branch that shows how modules sit
• I think Ben does a pretty good job explaining why grunt in his readme, perhaps I can link to that: https://github.com/cowboy/grunt (under why grunt exists)
• still waiting on a task that can be contributed (might write one myself off @mklabs code)
• yes i think a full app should be created
• still want plugin (non-biased) reviews in the wiki

[paulirish]

I feel like we should add a lazyweb-request for someone writing a QUnit adapter to use jasmine syntax. I've heard this from multiple people... they prefer jasmine semantics and syntax but the async and testrunner in qunit is better.

Possible to have the cake and eat it too?

• also on i18n, if its still on the table, messageformat.js is probably a better option, but may be too early regardless, perhaps just in the docs for now

[tbranyen]

Updates to this:

• Jasmine has been added as a test harness
• internationalization is still on the table
• RequireJS is merged and fully integrated
• reload task issue moved to grunt-bbb
• Full app created

[addyosmani]

@tbranyen \o/ That's awesome. Love how this project has evolved!

[tbranyen]

Yeah, seems like the last bits of this feedback are writing up documentation on integrating: https://github.com/creynders/grunt-jasmine-task and http://requirejs.org/docs/api.html#i18n

Once that's done, I think this issue is good to be closed. :)

[tbranyen]

This issue has long since been stagnant, closing now and forever hold its peace.