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: 
Both Backbone.js and JavascriptMVC are great examples of using a framework to organize large projects in a sane way ([SproutCore](http://www.sproutcore.com/) and [Cappuccino](http://cappuccino.org/) 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](http://requirejs.org/).
* Testing: testing UI code is never easy but the guys over at jQuery have been doing for a while and their testing tool [QUnit](http://docs.jquery.com/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](http://code.google.com/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](http://rake.rubyforge.org/), Python -> Write your own, **NodeJS** as a build tool (i like this option the most) -> [Jake](https://github.com/jcoglan/jake)

Beyond that just be aware if something feels clunky or slow (either tooling or framework) and refactor.
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.