The two libraries mentioned in the title – $script.js and RequireJS – are not technically classified in the same way because though they do similar things, they have different emphasis. $script.js is a script loader with dependency management, and while RequireJS is the same way, it’s dependency management is much more powerful and more closely resembles what you would use for importing classes in compiled languages such as Java. You’ll see what I mean soon.
This handy library was created by Dustin Diaz and Jacob Thornton and is hosted on Github. That’s where you’ll find the documentation on how to use it, but I’ll still show it off a bit here to give you an idea of how it works. I’ve actually already written an article about this library – which happens to be the first post ever on this blog – but its focus was quite different.
First, we’ll talk about the most basic usage: loading a script.
This loads jquery.js asynchronously onto the page. This is no more useful than just using a normal
script tag though. It’s slightly shorter, but since it is loaded asynchronously, the code right after this line will run before jquery.js is loaded. So, we also give it a callback function that runs after jquery.js is loaded.
Now, once jquery.js is loaded and executed, we’ll be sure that we can access the objects and functions that it defines. There is so much more you can do with $script.js – including named dependencies – but this gives you the gist of how to use it. With this, we’ve successfully defined a dependency and assured the dependency would be loaded and executed before we tried to use it. Using something like this allows us to only need to use 2
script tags in our HTML (one to load $script.js and one to load the main application). The rest of the scripts that we depend on can be managed with $script.js.
RequireJS is a much larger project, with a Github project and a site of its own. You’ll find the documentation for RequireJS at that second link, but if you want to read some history and a more thorough introduction to RequireJS you can read this article on Adobe Developer Connection.
First we’ll just define a module that can pulled in as a dependency.
You can see two different types of modules there. The first one is just defined as an object literal, which will be what is returned to the dependent script, as you’ll see later. The second example has a function, which will be run immediately when the module is loaded as a dependency and the value that is returned from that function will be the value that is given to the dependent script.
Now we’ll create a module that is dependent on the module we just defined. We’ll assume that the module above is saved as person.js. Here’s how we define another module that is dependent on the module we just made, plus another module that was created behind the scenes.
We define the module exactly as we did before, except this time we send in an array as the first parameter. The array lists strings of file names (sans the “.js”) of modules to fetch. Then, when those modules are fully loaded, they are sent in as parameters to the function for the new module you are defining. As stated above, this localizes the modules so they are not accessible globally.
Now we’ll write a bit of code that is dependent on the latest module and the
person module, but isn’t creating a new module. We’ll assume that the latest created module is saved as default-person-list.js.
This is almost exactly the same as creating a module that is dependent on another module except for a couple important things:
- We no longer use the
definefunction; instead we use
require(finally we know where the name of the library comes from!).
- There’s no need to return anything from the function. Since this is not being defined as a module, it is just run as is and therefore has no need to return anything.
If you are a very modular programmer and you enjoy the idea of keeping the modules localized, then taking the RequireJS route is probably a really good idea for you. If your application is relatively simple or you just don’t like the idea of converting everything into individual module files, then something like $script.js would probably be a great fit. Ultimately it’s up to you, as they are both great tools. Anyway, that’s all for today; Happy coding and God Bless!