Question

I am new to CoffeeScript and am trying to get a feel for the best way of managing and building a complex application that will run in the browser. So, I am trying to determine what is the best way to structure my code and build it; with consideration for scope, testing, extensibility, clarity and performance issues.

One simple solution suggested here (https://github.com/jashkenas/coffee-script/wiki/%5BHowTo%5D-Compiling-and-Setting-Up-Build-Tools) seems to be maintain all your files/classes separately – and the use a Cakefile to concatenate all your files into a single coffee file and compile that. Seeems like this would work, in terms of making sure everything ends up in the same scope. It also seems like it makes deployment simple. And, it can be automated, which is nice. But it doesn’t feel like the most elegant or extensible solutions.

Another approach seems to be this functional approach to generating namespaces (https://github.com/jashkenas/coffee-script/wiki/Easy-modules-with-CoffeeScript). This seems like a clever solution. I tested it and it works, but I wonder if there are performance or other drawbacks. It also seems like it could be combined with the above approach.

Another option seems to be assigning/exporting classes and functions to the window object. It sounds like that is a fairly standard approach, but I’m curious if this is really the best approach.

I tried using Spine, as it seems like it can address these issues, but was running into issues getting it up and running (couldn’t install spine.app or hem), and I suspect it uses one or more of the above techniques anyways. I would be interested if javascriptMVC or backbone solves these issues – I would consider them as well.

Thanks for your thoughts.

Answer 1

Another option seems to be assigning/exporting classes and functions to the window object. It sounds like that is a fairly standard approach, but I’m curious if this is really the best approach.

I’d say it is. Looking at that wiki page’s history, the guy advocating the concatenation of .coffee files before compilation was Stan Angeloff, way back in August 2010, before tools like Sprockets 2 (part of Rails 3.1) became available. It’s definitely not the standard approach.

You don’t want multiple .coffee files to share the same scope. That goes against the design of the language, which wraps each file in a scope wrapper for a reason. Having to attach globals to window to make them global saves you from making one of the most common mistakes JavaScripters run into.

Yes, helper duplication duplication can cause some inefficiency, and there’s an open discussion on an option to disable helper output during compilation. But the impact is minor, because helpers are unlikely to account for more than a small fraction of your code.

I would be interested if javascriptMVC or backbone solves these issues

JavaScript MVC and BackBone don’t do anything with respect to scoping issues, except insofar as they cause you to store data in global objects rather than as local variables. I’m not sure what you mean when you say that Spine “seems like it can address these issues”; I’d appreciate it if you’d post another, more specific question.