Approach to handle javascript on bigger projects?

Question

After discovering jQuery a few years ago, I realized how easy it was to really make interactive and user friendly websites without writing books of code. As the projects increas

Answer 1

My suggestion would be is to isolate as much javascript as possible into external js files, outside of your views, and simply reference them in the headers. Not only does this allow javascript re-use from page to page, but it separates your concerns on a fair level, spreading out your code to allow for easier debugging (easier by my beliefs anyway). In addition, this makes your js a little bit more secure as it is not rendered directly onto the browser page. Granted, that security is fairly negligible since tools like firebug or IE's Developer Tools can access layered away javascript files.

Second, I would suggest using a tool like unto compress.msbuild to (at final compile for deployment) compress all your custom-written javascript to whatevertheirnameis-min.js. Not only does compacting everything to a single line actually reduce load and run-times for your code, it also obfuscates it into more secure. It is significantly more difficult to take apart a -min file, much less find any specific functions when all the code is a single line.

Answer 2

Check out this book, mainly chapter 10 http://jqfundamentals.com/book/index.html#chapter-10

Answer 3

I would like to recommend using javascript in a functional style which can be helped by abstractions like coffeescript and underscore.js.

Also minimising the cross module interaction and relying on an event driven code is a great way to keep your entire project organized. I defiantly like the way that backbone.js handles the module-view weak coupling by having view's bind the change events on modules.

Functional event based code is great for macro structure. I would also advice coupling javascript to the DOM. (Again backbone.js has a great example of how the model is completely dom independant and even the views aren't dependant on the dom. For all you care the views could be shooting data down a WebSocket)

I'm personally also a fan of having one central file manager rather then having a complicated require/include structure on every page. Load javascript modules from your central loader based on a page by page feature detection. (See here for an example of a central file manager).

I would also like to advocate the growing possibility of good re-use through node.js. There are quite a few people working on porting browser code verbatim to node.js or copying node.js code verbatim to the browser. (see YUI3 running on nodejs, node.js in the browser, commonJS in the browser Admittedly most of these are WIP and not stable.)

Answer 4

Both Backbone.js and JavascriptMVC are great examples of using a framework to organize large projects in a sane way (SproutCore and Cappuccino are nice too). I definitely suggest you choose a standard way of deal with data from the server, handling events from the DOM and responses from the sever, and view creation. Otherwise it can be a maintenance nightmare.

Beyond an MVC framework, you should probably choose a solution for these problems:

• Dependency management: how will you compile and load javascript files in the right order? My suggestion would be RequireJS.
• Testing: testing UI code is never easy but the guys over at jQuery have been doing for a while and their testing tool QUnit is well documented/tested.
• Minification: you'll want to minify your code before deploying to production RequireJS has this built in but you could also use the Closure Compiler if you want to get crazy small source.
• Build System: All these tools are great but you should pull them all together in one master build system so you can run a simple command on the commandline and have you debug or production application. The specific tool to use depends on your language of choice - Ruby => Rake, Python -> Write your own, NodeJS as a build tool (i like this option the most) -> Jake

Beyond that just be aware if something feels clunky or slow (either tooling or framework) and refactor.