CODEWITHSUNDEEP
javascriptweb-applicationsdeployment
Daniel Fone
Daniel Fone

Reputation: 2905

Best practices for managing and deploying large JavaScript apps

What are some standard practices for managing a medium-large JavaScript application? My concerns are both speed for browser download and ease and maintainability of development.

Our JavaScript code is roughly "namespaced" as:

var Client = {
   var1: '',
   var2: '',

   accounts: {
      /* 100's of functions and variables */
   },

   orders: {
      /* 100's of functions and variables and subsections */
   }

   /* etc, etc  for a couple hundred kb */
}

At the moment, we have one (unpacked, unstripped, highly readable) JavaScript file to handle all the business logic on the web application. In addition, there is jQuery and several jQuery extensions. The problem we face is that it takes forever to find anything in the JavaScript code and the browser still has a dozen files to download.

Is it common to have a handful of "source" JavaScript files that gets "compiled" into one final, compressed JavaScript file? Any other handy hints or best practices?

Upvotes: 31

Views: 10494

Answers (7)

martyglaubitz
martyglaubitz

Reputation: 1002

My strategy consist of 2 major techniques: AMD modules (to avoid dozens of script tags) and the Module pattern (to avoid tightly coupling of the parts of your application)

AMD Modules: very straight forward, see here: http://requirejs.org/docs/api.html also it's able to package all the parts of your app into one minified JS file: http://requirejs.org/docs/optimization.html

Module Pattern: i used this Library: https://github.com/flosse/scaleApp you asking now what is this ? more infos here: http://www.youtube.com/watch?v=7BGvy-S-Iag

Upvotes: 1

paulgreg
paulgreg

Reputation: 18903

Also, I suggest you to use Google's AJAX Libraries API in order to load external libraries.

It's a Google developer tool which bundle majors JavaScript libraries and make it easier to deploy, upgrade and make them lighter by always using compressed versions.

Also, it make your project simpler and lighter because you don't need to download, copy and maintain theses libraries files in your project.

Use it this way :

google.load("jquery", "1.2.3");
google.load("jqueryui", "1.5.2");
google.load("prototype", "1.6");
google.load("scriptaculous", "1.8.1");
google.load("mootools", "1.11");
google.load("dojo", "1.1.1");

Upvotes: 8

gregh
gregh

Reputation: 37347

Read the code of other (good) javascript apps and see how they handle things. But I start out with a file per class. But once its ready for production, I would combine the files into one large file and minify.

The only reason, I would not combine the files, is if I didn't need all the files on all the pages.

Upvotes: 1

Kieron
Kieron

Reputation: 11824

In our big javascript applications, we write all our code in small separate files - one file per 'class' or functional group, using a kind-of-like-Java namespacing/directory structure. We then have:

  • A compile-time step that takes all our code and minifies it (using a variant of JSMin) to reduce download size
  • A compile-time step that takes the classes that are always or almost always needed and concatenates them into a large bundle to reduce round trips to the server
  • A 'classloader' that loads the remaining classes at runtime on demand.

Upvotes: 3

Mo.
Mo.

Reputation: 15343

Just a sidenode - Steve already pointed out, you should really "minify" your JS files. In JS, whitespaces actually matter. If you have thousand lines of JS and you strip only the unrequired newlines you have already saved about 1K. I think you get the point.

There are tools, for this job. And you should never modify the "minified"/stripped/obfuscated JS by hand! Never!

Upvotes: 4

Dan Herbert
Dan Herbert

Reputation: 103417

For server efficiency's sake, it is best to combine all of your javascript into one minified file.

Determine the order in which code is required and then place the minified code in the order it is required in a single file.

The key is to reduce the number of requests required to load your page, which is why you should have all javascript in a single file for production.

I'd recommend keeping files split up for development and then create a build script to combine/compile everything.

Also, as a good rule of thumb, make sure you include your JavaScript toward the end of your page. If JavaScript is included in the header (or anywhere early in the page), it will stop all other requests from being made until it is loaded, even if pipelining is turned on. If it is at the end of the page, you won't have this problem.

Upvotes: 2

Steve M
Steve M

Reputation: 10573

The approach that I've found works for me is having seperate JS files for each class (just as you would in Java, C# and others). Alternatively you can group your JS into application functional areas if that's easier for you to navigate.

If you put all your JS files into one directory, you can have your server-side environment (PHP for instance) loop through each file in that directory and output a <script src='/path/to/js/$file.js' type='text/javascript'> in some header file that is included by all your UI pages. You'll find this auto-loading especially handy if you're regularly creating and removing JS files.

When deploying to production, you should have a script that combines them all into one JS file and "minifies" it to keep the size down.

Upvotes: 12

Related Questions