We Keep Coding

How can I introduce modules to a legacy javascript project?

I'm a developer on a very large, many-page web app. We're making a push to improve the sanity of our javascript, so I'd like to introduce a module loader. Currently everything is done the old-fashioned way of slapping a bunch of script tags on a page and hoping for the best. Some restrictions are:
Our html pages are templated, inherited, and composed, such that the final page sent to the client brings together pieces from many different source html files. Any of these given files may depend on javascript resources introduced higher up the chain.
This must be achievable piecemeal. The code base is far to large to convert everything at once, so I'm looking for a good solution for new pages, and for migrating over existing pages as needed.
This solution needs to coexist on the same page as existing, non-module javascript. Some things (like menus and analytics) exist on every page, and I can't remove global jquery, for instance, as it's used all over the place.
Basically I'd like a way to carve out safe spaces that use modules and modern dependency management. Most tutorials and articles I've read all target new projects.
Requirejs looks like a decent option, and I've played with it a bit. Its fully async nature is a hindrance in some cases though - I'd like to use requirejs to package up global resources but I can't do that if I can't control the execution order. Also, it sucks to have the main function of a page (say, rendering a table) happen after secondary things like analytics calls.
Any suggestions?

That's a lot to ask for. :-) So here are my thoughts on this:
Usually, when you load a web page - everything that was being displayed is wiped so that the new incoming information does not interfere with what was already there so you really have only a couple of options (that I know of) where you can keep everything in memory in the browser and yet load new pages as needed.
The first (and easiest) way is to use FRAMES. These are not used much anymore from what I've seen but each FRAME allows you to display a different web page. So what you do is to make one frame use 100% and the second one use "*" so it isn't seen. You can then use the unseen frame to control what is going on in the 100% frame.
The second way is to use Javascript to control everything. In this scenario you create a namespace area and then use jQuery's getscript() function to load in each page as you need it. I did this once by generating the HTML, converting it to hex via bin2hex(), send it back as a javascript function and then unhexing it in the browser and applying it to the web page. If it was to completely replace the web page you do that and if it was an update to a web page you just inserted it into the HTML already on the web page. Any new javascript function always attaches itself to the namespace. If a function is no longer needed, it can be removed from the namespace to free up memory.
Why convert the HTML to hex and then send it? Because then you can use whatever characters you want to us (like single and double quotes) and it doesn't affect Javascript at all. There are fairly fast hex routines available on GitHub (see my toHex and fromHex routines).
One of the extra benefits of using getScript() is that it can sometimes also make it almost impossible for anyone to see your code then. A fluke in how getScript() works which is documented.

when building a website, should I refer to javascript libraries in specific user controls or in the master page?

which of following cases is strongest with regard to client side (JavaScript) library referencing and loading.
Please note that I assume the web solution is well designed so that the components are well encapsulated
Also, just to be clear, the master page I am talking about could be a user control or anything that holds all library references and loaded at the site-load regardless of the content of the site at the moment
1 - include references (link href) for all custom (e.g. 3rd party) libraries in the master page.
it's arguable this is easy to maintain because all references are in one place.
it's also arguable that it's easy to perform library upgrades so you don't need to hunt within the solution where the library is referred to update it's reference.
2 - include reference to libraries in their specific user controls
shouldn't this improve performance as the website only loads libraries when required.
e.g. one can refer to the JavaScript libraries that works for maps within the user control that deals with maps with contrast to loading maps libraries even when there's no map on the current view.
This encapsulates components well. for example, a developer who tries to fix a bug in the map component will see all the libraries it refers to when he opens the map user control. This stops the need to go through the master page and see which libraries are used.

I don't think this is the right way to think about it.
The only reason not to load all libraries is performance. The debug reason you give is too minor to consider.
You can increase performance in many different ways. By far the easiest, most straightforward and attainable is to minify all your JavaScript into one file. You can additionally use a compiler like Google's Closure Compiler or Yahoo YUI Compressor to get a smaller filesize and faster execution.
If at this point you still have performance issues (that can be attributed to network latency) then maybe look into lazy loading your libraries.
This doesn't mean you should forgo the guidelines of dependency injection. Any good framework will offer you a mechanism for dependency injection. This should make switching to solution 2 at a later point fairly trivial.

Benefits of creating new modules in my application

Could anyone explain me what is the pourpuse of create new modules in angularjs application, I have already read the documentation, but we are not quite sure about when is appropiate to create a new module or use our own application module when you create a new service, directive, etc..

I would like to add some thoughts after reading a bit more about the subject:
JAndy, you are right in the general concept, but to be more specific in when do you have to use angularjs modules I think I got a clear answer in this post
Basically we have 3 ways of structuring our angularjs projects:
angular-seed
Yeoman
Structure the project in Modules
Depending of how big is your project you can take one aproach or another.
Basically writing new modules in angularjs helps you to pack functionalities that are related, one of the advantages of this approach is if a new developer comes into your team he can get a general overview and find things easier than if you only have one module, another one is to reuse functionality accross other projects.

I'd like to answer this question in a more general style than being specific.
Why was the ISS not build as one gigantic station instead of multiple independent modules ? The reason behind modules is to separate responsibilities, decouple a construction, etc. In terms of programming it means to have logic, spread over multiple small modules. That way, you not only know exactly where to look if anything goes wrong or you need to extend some functionality, it'll also guarantee that your whole ISS( your application ) will not entirely fail if one of your modules fails. This of course, also requires certain aspects of
programming styles, most important in this context, to hold module interaction and communication loosely coupled (which I just assume).
So whenever you want to implement new stuff, which does not fit in any other existent code or module, you should create a new, independent module, which is specialized to fulfill a certain task.
Even if I'm not using AngularJS on regular bases, I'm sure the same idea of modularization will fit in there.

How modify objects across scopes in AngularJS?

I am new to AngularJS, the notion of scopes really confuses me. I have a situation where I want to modify a an object or a variable from different scopes. Here is why:
in my application I want to centralize the user notification Controller and notification view.
In the middle top of the page. I separate my code as follow: each view has its controller I think its fair reasonable. I want to inject a service or some common object that when invoking its function with some string parameter on a common place but, I figured out that I can not inject $scope service. So, when

What you want is to communicate between controllers. That is fairly easy to realize whit a service that can broadcast messages (or objects) between controllers.
There is a nice youtube about this:
http://www.youtube.com/watch?v=1OALSkJGsRw

OK here what I have done in my application. I am a java programmer and I used to work with GWT
In GWT ther is a very nice design pattern, to notify widgets across the application, called EventBus. In angular I tried to do something similar. Here is the code link in gist

what actually is sandboxing in JavaScript?

I understand the term sandbox. But my limited skills in JS is unable to help me understand what is sandboxing in JS. So, what actually is sandboxing? Apart from security, why do we need to sandbox JS?

the javascript sandbox does exactly what you've said. It limits the scope of what a script can do. There are also benefits in terms of virtualising the resources the script can call on. This allows the sandbox host to marshal those resources for better performance and say, stop an endlessly looping script bringing the whole browser crashing down.

Sandboxing is the act of creating a scope in which no other part of the application can operate (unless given an opportunity to). More specifically, this is usually a function scope that exposes a limited subset of what's actually going on within it.
One library that's founded on the idea of sandboxes is YUI3. The basic unit of the application is a YUI instance sandbox:
var Y = YUI(); // creates a configurable YUI instance
// Creates a sandbox for one part of your application,
// including the 'node' module.
Y.use('node', function(Z) {
// Z is a YUI instance that's specific to this sandbox.
// Operations inside it are protected from outside code
// unless exposed explicitly. Any modules you request in
// use statement will be separately instanced just for
// this sandbox (in this case, the 'node' module)
//
// That way, if another part of your application decides
// to delete Z.Node (or worse, replace it with a
// malicious proxy of Z.Node) the code you've written
// here won't be affected.
});
The advantages of sandboxes are primarily to reduce application complexity: since sandboxes are immutable, they're much easier to reason about and verify. They also improve runtime security, since a well-designed sandbox should be able to operate as a black box to other scripts running on the page. It does not prevent against all possible attacks, but it protects against many of the simple ones.

Sandboxing creates a limited scope for the script to use. Assuming you're coding for a website, t's worth sandboxing to avoid making edits to a live site when you are uncertain about whether they will work exactly as you expect - and it's impossible to be truly certain without testing. Even if it works properly, if there's a chance of you making a series of alterations to the JS until you've got it tweaked the way you like, you could easily disrupt anyone attempting to use the site while you're updating it.
It's also much easier to tell what's broken when you break things, because of the limited nature of the sandbox.