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 increased in size, so did also the time required to carry out any debugging or perhaps implementing a change or new feature. 

From reading various blogs and staying somewhat updated, I've read about libraries similar to [Backbone.js](http://documentcloud.github.com/backbone/) and [JavascriptMVC](http://www.javascriptmvc.com/) which both sound like good alternatives in order to make the code more modular and separated.

However as being far from an Javascript or jQuery expert, I am not really not suited to tell what's a good cornerstone in a project where future ease of maintainability, debugging and development are prioritized.

**So with this in mind - what's common sense when starting a project where Javascript and jQuery stands for the majority of the user experience and data presentation to the user?**

Thanks a lot

Answer: 
I would like to recommend using javascript in a functional style which can be helped by abstractions like [coffeescript](http://jashkenas.github.com/coffee-script/) and [underscore.js](http://documentcloud.github.com/underscore/).

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](http://documentcloud.github.com/backbone/) 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](http://documentcloud.github.com/backbone/) 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](https://stackoverflow.com/questions/5083409/pattern-for-javascript-module-pattern-and-sub-module-initialization/5083571#5083571) of a central file manager).

I would also like to advocate the growing possibility of good re-use through [node.js](http://nodejs.org/). 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](http://www.yuiblog.com/blog/2010/09/29/video-glass-node/), [node.js in the browser](https://github.com/Marak/gemini.js), [commonJS in the browser](https://github.com/Raynos/BrowserCJS) Admittedly most of these are WIP and not stable.)
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.