...

On a more minor note, the "home panel" (which appears when the discussion tab is first loaded and contains help and the control for subscribing to notifications) is currently feature flagged. That feature flag should be removed, and a separate one should be added to control only whether the notification subscription control appears.

Front End (CoffeeScript/JavaScript)

General Stuff

CoffeeScript => JavaScript

Per the more general organizational direction, we should avoid adding new CoffeeScript code and gradually convert our CoffeeScript code to JavaScript.

require.js and file paths/names

We should use require.js for this code. One of the nasty consequences of not having done so is that the directory structure and file naming are crafted so that the files are loaded according to dependency order. This results in files that are not in the right place, oddly named classes and files, and multiple classes in one file. As we implement require.js, we should be sure to fix all of these problems.

Better use of the Backbone framework

RESTful data transfer

Backbone has nice facilities for fetching and persisting data via REST APIs. Once the LMS APIs are rewritten to adhere more to the REST pattern, we can simplify the front end code by taking advantage of these.

Use events to communicate between views instead of shared state

Currently, we have several instances where the same model or collection is used by multiple views, and such views communicate by modifying the model or collection and/or setting callbacks. In some cases, this is desirable (e.g. any update to a Thread from any view will cause its rendering in the sidebar to update accordingly). In other cases, this can be confusing (e.g. NewPostView having a collection to which it adds new posts). We should think carefully about whether shared state or events are appropriate for each situation.

Use .listenTo instead of .on

http://stackoverflow.com/questions/16823746/backbone-js-listento-vs-on