Develop Reference

AngularJs SPA Javascript file

Do i have to include all my javascript file while loading main index page?
In single page application when we are not logged in, we include all of our .js file in main index file. This contains js file that is only needed when users are logged in.
What is better approach of managing angular app in this context?

Simple answer: yes.
Your application is a single-page one, so you can combine all JS files into one and load it at one request. It saves time for processing in the future.
Alternatively, create two pages login.html and others.html, then load two different sets of JS files accordingly.
Normally, nowadays the bandwidth is not the bottleneck, loading a larger JS file does not make trouble (usually).

You can split your code into multiple modules and then just load the js needed for that module.
I suggest using Gulp with packages to inject HTML when appropriate. You then have single lines of code as place holders for your Javascript and you run the Gulp task to inject the Javascript into the areas where it is needed.
You could also run gulp tasks to minify your js into just a few minified files. You will need to be sure your js in min safe (gulp can do this too).

If you make AMD - most often using RequireJS - then you won't need to include all from the very beginning.
A while ago we did a similar project, although without AngularJS, and by using RequireJS we made the different pages, which use different files. And this way people's browsers will never download certain files if they never go to certain pages.
(Of course, we had many pages inside the app, not just 2 or 3, where this wouldn't make any difference.)

Why use requireJS instead of an ordered include list?

I've been using a grunt file to concatenate all my JS into a single file which is then sent to the client. What advantage do I have in using require calls then? The dependencies are inherent from the concatenation order and I don't have to muddy all my JS with extra code and another third-party library.
Further, backbone models (for example) clearly state their inheritance in their definitions. Not to mention that they simply wouldn't work if their dependencies weren't included anyway.
Also, wouldn't maintenance be easier if all comments related to dependencies were in one place (the grunt file) to prevent human error and having to open every JS file to understand its dependencies?
EDIT
My (ordered) file list looks something like:
....
files: [
"js/somelib.js",
"js/somelib2.js",
"js/somelib3.js",
"js/models.js",
"js/views.js",
"js/controllers.js",
"js/main.js"
], ...
So perhaps requireJS isn't worth it for small projects anyway.

Using require.js allow you to break down each part of your application into reusable modules (AMD) and to manage those dependencies easily. It is not easy to manage dependencies in a javascript application with 100 classes, for example.
Also, if you don't want all the overhead of require, check this out (developed by the same guy who created require.js): https://github.com/jrburke/almond

The answer depends on the size of your app and the end use case..
A single site.min.js payload for the front end (client) generally aims for small file sizes and simple architectures (1 single file generated from maybe 10).
back end based (server) apps are usually much bigger and complicated and therefore may warrant the use of another tool to help with managing large code libraries and dependencies (50 files for example).
In general, RequireJS is worthwhile but only if you have many files and dependencies. An alternative for use in the client would be almond. Again, using a tool like this must warrant the need (many files and dependencies).
The answer from orourkedd is also worth reading.

Using Karma to test javascript in a play 2.2.x application

I've got a Play 2 application where my angular js dependencies (and possibly others) are declared using WebJars. When I serve up a page, I use the routing helper to fetch these javascript files.
If I want to test my javascript with Karma I need to specify the path to angular javascript files in order to run my angular dependent code. The examples I've seen on the web don't use web jars and just specify the path as ../app/assets/javascripts/lib/angular.js (or whatever). Is there a better way to do this?

I am not familiar with playframework and therefore I am not entirely understanding the restrictions it is bring to your JS Files but if this helps you can also do something like this in karma.cofig
files: [
'http://localhost:91/sample.js'
],
I performed some quick tests and it worked fine.

Javascript library: load only those files you need

We are developing a javascript component to be used in a JSF app and we're using Dojo.
The thing is we only need specific parts of the library and we'd like to only insert into our webapp the files/folders we use to accomplish our goal.
We could do this 'by hand' but in the future we might need to add other functionality from Dojo and then we will not know what resources we need -> I guess by this moment you realised we are no Dojo/js gurus.
Basically we are looking for a way to automate this process. We were thinking of getting a list of the dependencies and then create a small script to 'filter' the files.
Is this possible ? Have anyone tried this before ?
Thanks.

I may be misinterpreting your request, but I think dojo does what you want out of the box. Since the latest versions of dojo follow the Asynchronous Module Definition (AMD) format, you use a global require function to describe what dependencies a specific block of code have, and only those modules are loaded. An example from the sitepen dojo intro:
require(["dojo/dom", "dojo/domReady!"], function(dom){
var greeting = dom.byId("greeting");
greeting.innerHTML += " from Dojo!";
});
If you only want to have to to load a single <script/> tag, you'll want to look into the dojo builder. Using the online build tool You can select what packages you want included into the dojo.js layer and it will bundle everything up into a zip file that includes dojo.js/dojo.js.uncompressed.js which contains dojo core in addition to the modules you selected.

Ok, we did this by doing the following (just in case anyone will need this):
* declare a JSF filter and map it to /js/* (all dojo resources are under /js folder, this may need to be modified to fit your folder structure); this way, all requests for a dojo resource will be filtered.
* in the filter class, get all the requested files: (HttpServletRequest) request).getRequestURI() and write it line by line in a file: now you have all the needed resources.
* parse that file with a script, line by line, and copy the files to another location -> build the folder structure.
* use the created files in your WebContent folder (or wherever you need it), you have a clean library -> you only deploy what you use.

The web is littered with full-blown JavaScript libraries who say they will save your day and make your web development life much easier. You get encouraged to include these “mere 80 kb” libraries that is supposed to be the solution to all your needs, and practically make the web site work by itself. Needless to say, I’m not a big follower of JavaScript libraries,, especially since they almost always include lots of superfluous code, so I thought I’d put together a tiny library with only essential JavaScript functions.
The result of that is EJ – Essential JavaScript.
EJ consists of functions that I use all the time and they make writing JavaScript go faster and the result is being able to do work more efficiently. It is also about having the things you would write again and again for every web site you produce in one neat and tiny file instead, to be able to focus on the new things you need to address

Modularization & reuse of code written using Ext JS

I need clarity into being able to modularize my JavaScript code that leverages Ext JS. My objective is to create custom classes that extend Ext JS widgets, distribute code among several JavaScript files (.js files).
I have looked into documentation on Ext.Loader but I didn't quite follow the approach to ensure class dependency resolution. My code in a single JavaScript file is working as desired, given that the code sequentialization is as per dependency. But once I break the code in several JavaScript files and want to use in multiple pages, my dependency is in a disarray as all my pages require different classes with varied dependencies.
Considering that I easily achieve code separation and reuse quite easily in regular backend coding, this has baffled me. Please help with inputs. I'm using Ext JS 4.1.1

To enable dependency resolution when creating custom components, use the requires param of Ext.define. It looks like this:
Ext.define("My.custom.Widget", {
alias: "widget.mywidget",
requires: [
"My.custom.TextField",
"My.custom.ComboBox",
"My.custom.Store"
],
constructor: function(config){}
/* ... */
});
For more information, you should read Dynamic Loading and New Class System from the Sencha website. It goes into more detail about how dynamic loading works. It's actually really cool once you get the hang of it.
Almost forgot. You can explicitly call Ext.require to load certain files when you need them. It supports wildcards, aliases and such. There's also Ext.exclude to prevent certain files from loading.

Sencha has some really great guides to help you master the framework.
http://docs.sencha.com/ext-js/4-1/#!/guide
A good one to start with is this one: http://docs.sencha.com/ext-js/4-1/#!/guide/application_architecture Application Architecture. This guide clearly shwos you how to modularize you code and the folder structure the Loader is expecting.
Please have a look at it.