AMD version of underscore

[jcsrb]

While I'm not entirely clear about the advantages of AMD vs non-AMD is seams that there is a well mentained fork of underscore that supports AMD by https://github.com/amdjs/

This version is used in the Nettuts Backbone Starter Pack

relevant section in the nettuts video 2:54

Is this something we should consider doing as well?

[jcsrb]

I am aware that currently we use the require.js shim, is that preferred over AMD aware plugins? the runtime version of Handlebar doesn't have AMD support but the it's an option when you precompile the templates

[OliverJAsh]

+1 to using the AMD fork of RequireJS.

We're not currently precompiling Handlebars templates by the looks of it. I'm not sure if this is in the scope of Heisenberg because we have no say over how the user does the back-end, but we are looking to build in support for Grunt, so maybe something could be done there? Perhaps a separate issue. /cc @jackfranklin

[jackfranklin]

I am aware that currently we use the require.js shim, is that preferred over AMD aware plugins?

I don't think there's a big difference to be honest (perhaps someone else can prove me wrong - I'm not 100% sure tbh) and as such I'd be more keen to stick with the official versions and shim them rather than use the forks.

We're not currently precompiling Handlebars templates by the looks of it

Could someone explain what exactly you mean by this and also how Handlebars supports AMD through this method (@jcsrb)? I'm not 100% sure I understand here.

[OliverJAsh]

You precompile the templates so that they are served as JavaScript functions immediately, rather than being compiled on the client-side. Handlebars have a page up about using the precompiler.

I'm not that confident doing this, because I haven't done it before, but I know it's a good optimisation to have. My knowledge of the subject has come from Section 2: Precompiled Templates on this page and also, when I played about with using Brunch, the build script (using Grunt, I believe) would precompile the templates and include them in the main.js along with rest of the JavaScripts, which I thought was quite interesting. I think this is what @jcsrb is talking about?

So a template file called home.hbs, for example:

<a href="http://brunch.io/">
  <img src="http://brunch.io/images/brunch.png" alt="Brunch" />
</a>

When built, is precompiled and becomes a module in a file, concatenated along with the rest of the JavaScripts:

window.require.register("views/templates/home", function(exports, require, module) {
  module.exports = Handlebars.template(function (Handlebars,depth0,helpers,partials,data) {
    helpers = helpers || Handlebars.helpers;

    return "<a href=\"http://brunch.io/\">\n  <img src=\"http://brunch.io/images/brunch.png\" alt=\"Brunch\" />\n</a>\n";});
});

Forgive me for my naivety! I'm new to this. Hopefully @jcsrb can help shine a light and brush up my knowledge!

[jcsrb]

My main concern was making it as transparent as possible for newcommers and having all dependencies bee AMD compliant.

As it turned out there are no AMD compliant repositories for all the libraries we currently use. While underscore has a well maintained one that @JeffreyWay chose to use in his recent NetTuts video (link in the first post) , handlebars doesn't.

AMD is available in the original handlebars repository only for precompiled assets as @OliverJAsh detailed very nicely and the only AMD complient handlebars fork I could find is already 9 month old.

I would refrain from precompliation at the current stage for this project, as it adds another level of complexity.

I agree with @jackfranklin to keep using libraries from the original developer as those that we currently use are well maintained.

Therefore we should either use well maintained AMD compliant forks of libraries for keep using the shim for uncompliant libraries. Since the former isn't available we shell keep it at the current state of using the requirejs shim for underscore and handlebars.

Maybe a note in the README or a comment in component.json why some libraries are shimmed and some aren't

[jackfranklin]

This I think is related to issue #7 about the text plugin, I'm still a fan of that and would like to get that integrated myself this evening.

We seem to keep coming up with things to add to the README - perhaps this would be a good time to start editing the wiki so our README doesn't become unmanageable.