CODEWITHSUNDEEP
javascriptloadingpackaging
luisgo
luisgo

Reputation: 2475

Javascript dependecy management and packaging

I'm trying to figure out how to best manage Javascript file dependencies and have that drive the packaging of a 100% front-end app. In short, I'm building an application using backbone.js along with some other libraries. I want an organized codebase and would like to be able to declare dependencies within each file. Ideally those declarations would a) drive the order in which files are loaded by the browser (while in development I want the files to load separately) and drive the order in which the packaging scripts load the scripts for concatenation (I'm aiming to serve a single file for the entire app).

I've been reading on requirejs and commonjs but I'm not convinced.

I have a simple shell script right now that uses cat <file> <file> <file> <file> > concatenated.file to do what I want but it's a pain to maintain that list of files up to date and in the right order. It'd be much easier to be able to declare the dependency at the begining of each javascript file and have the packager and loaders be smart about using that information to concatenate/load scripts.

Any suggestions?

Thanks you,

Luis

Upvotes: 1

Views: 1090

Answers (3)

Nayjest
Nayjest

Reputation: 1089

For complex frontend apps Asynchronous Module Definition (AMD) format is best choice. And it's alot of great loaders that supports AMD (curl.js, RequireJS).

I recomend this articles to learn about modern approaches in javascript dependecy management:

Writing Modular JavaScript With AMD, CommonJS & ES Harmony

Why AMD?

For packaging take into account CommonJS specifications, there are few implementations and it's a matter of taste, but in any case I recommend to choose tools, that is compliant with some of that specifications.

Upvotes: 1

PointedEars
PointedEars

Reputation: 14980

It'd be much easier to be able to declare the dependency at the begining of each javascript file and have the packager and loaders be smart about using that information to concatenate/load scripts.

I have had the same idea several months ago and are working on a dependency resolver for my Resource Builder which already makes it easier for me (including the need to distinuish between development and deployed version, with the optional debug parameter).

JsDoc Toolkit (and related efforts), which syntax is supported e. g. by Eclipse JSDT, provides a @requires tag, so you could use that. But resolving dependencies is still not a trivial task (as you can see in ResourceBuilder::resolveDeps()). (The ultimate goal is to use static code analysis to resolve dependencies automatically, without any tags.)

This would reduce the current

<script type="text/javascript" src="builder?src=object,types,dom,dom/css"></script>

to a mere

<script type="text/javascript" src="builder?src=dom/css"></script>

As for asynchronous loaders: The good thing about asynchronous loaders is that they are fast. The bad thing about asynchronous loaders is that – if they work; they are all based on a non-standard approach – they are so fast that you cannot be sure that the features the scripts provide are available in following scripts. So you have to have your code executed by their listeners. I recommend avoiding them unless you really have features in your application that are only needed on demand.

Upvotes: 0

Yacine Filali
Yacine Filali

Reputation: 1772

I am partial to stealjs myself. It's part of JavascriptMVC but no reason why you can't use it with Backbone.js

The nice part about this one is that it builds your app for production including minifying your css and js and neatly packing all of it into 2 files: production.css and production.js.

It can handle loading non JS files too so you can do things like steal('somefile.css').then(function() {...});

For files, its very much like you would do in other languages:

steal(dep1, dep2, dep3).then(function () {
    // code 
});

Upvotes: 2

Related Questions