npm and Small Focused Modules

A lot of discussion has been happening around npm and it’s vulnerabilities since one module being unpublished about a week ago caused problems for lots of developers and their teams. Sindre Sorhus, a prominent developer and publisher on npm, wrote about why he thinks we need small reusable modules, like the one that was unpublished last week. You can read his thoughts on this here. You should read the whole post, but here is a snippet that sums it up.

People get way too easily caught up in the LOC (Lines Of Code). LOC is pretty much irrelevant. It doesn’t matter if the module is one line or hundreds. It’s all about containing complexity. Think of node modules as lego blocks. You don’t necessarily care about the details of how it’s made. All you need to know is how to use the lego blocks to build your lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works. Our short term memory is finite. In addition, by having these modules as modules other people can reuse them and when a module is improved or a bug is fixed, every consumer benefits.

Strong versus Loose Typing in JavaScript

Being a long time JavaScript developer, I’m perfectly happy with the fact that JavaScript is loosely typed. I think the reason strong typing in JavaScript is gaining in popularity is because more and more developers are using JavaScript that are used to programming in strongly typed languages. So there’s no reason for me to use something like Typescript that adds static typing to the language. Anyway, I came across this quote from Douglas Crockford in his book, JavaScript: The Good Parts, which explains my feelings on the subject better than I can.

The fashion in most programming languages today demands strong typing. The theory is that strong typing allows a compiler to detect a large class of errors at compile time. The sooner we can detect and repair errors, the less they cost us. JavaScript is a loosely typed language, so JavaScript compilers are unable to detect type errors. This can be alarming to people who are coming to JavaScript from strongly typed languages. But it turns out that strong typing does not eliminate the need for careful testing. And I have found in my work that the sorts of errors that strong type checking finds are not the errors I worry about. On the other hand, I find loose typing to be liberating. I don’t need to form complex class hierarchies. And I never have to cast or wrestle with the type system to get the behavior that I want.

Support for old versions of Internet Explorer to be dropped—in 2016


But all that is set to change under a new support policy announced today that is scheduled to take effect in about 18 months. Starting January 12, 2016, only the newest version of Internet Explorer for any given version of Windows will be supported. Older versions will cease to receive security fixes and other updates.

Once the new policy takes effect, Windows Vista and Server 2008 users must use Internet Explorer 9, and Windows 7 and Server 2008 R2 users must use Internet Explorer 11. Windows Server 2012 users must use Internet Explorer 10, while Windows 8.1 and Windows Server 2012 R2 users must have Internet Explorer 11.

via Support for old versions of Internet Explorer to be dropped—in 2016 | Ars Technica.

Start a dev server to preview your work without Yeoman

I published these notes on GitHub as a Gist recently, but I’ll go ahead and post them here too. It pertains to starting a dev server to preview your work quickly without using Yeoman. Yeoman is nice for doing this, especially using LiveReload, but you may need this and not always have the ability to use Yeoman or may not think it’s worth installing it just for that. Regardless, here’s how to preview your work on a dev server without Yeoman, using Ruby, Python or Node.js.


Mac OS: Ruby and Python are pre-installed. Install Node.js.

Windows: First install Ruby, Python or Node.js


Install the asdf gem.

gem install asdf

Change to the directory you want to host and type asdf from the terminal or command prompt.

Navigate to http://localhost:9292/ in your browser to preview your site.


Change to the directory you want to host and type python -m SimpleHTTPServer 8080 from the terminal or command prompt.

Navigate to http://localhost:8080/ in your browser to preview your site.


From the terminal or command prompt, type npm init and answer the questions from the prompts to create a package.json file.

Type npm install --save express to install express as a dependency and update your package.json file.

Create a JavaScript file called server.js and save it with the following contents.

var express = require('express'),
app = express();

app.use( express.static( __dirname + '/public' ) );

var server = app.listen(3000, function() {
console.log('Listening on port %d', server.address().port);

Put the files you wish to preview in a directory called public, and type node server.js from your parent directory.

Navigate to http://localhost:3000/ in your browser to preview your site.


I love Backbone.js. But it’s not perfect. One of my main problems with it is inline templates. Inline templates are templates that are contained within script tags within an HTML document. Almost every Backbone.js tutorial I’ve seen uses inline templates. But in the real world, this is a horrible way to build your web app.

Yet, it seems no one ever talks about this important piece of building real world web apps. There are some notable exceptions however. Angular.js lets you use external templates. Require.js has a plugin which lets you load templates as external dependencies, and many Backbone.js developers use and recommend this method. But, my opinion is that you shouldn’t be forced to use the entire Require.js library just for one feature.

That’s why I created a small script called TemplateManager. TemplateManager uses jQuery to asynchronously fetch and cache external template files. It also uses Underscore.js to pass the rendered template to a callback. And it uses Promises, actually jQuery’s Deferreds, to handle callbacks.

I like it because you can preload all your templates on initialization and because they are cached you can use them on demand later when you render your views. By preloading them, the requests happen in the background asynchronously so nothing is potentially blocked except whatever is rendered initially. You can also lazy load them and only fetch them when the view is created and rendered.

jQuery and Underscore are required for this, but Backbone is not. This allows you to use it with any application, although it works really well with Backbone since jQuery and Underscore are dependencies. I could have made it a Backbone plugin, but since it’s not a dependency, it can be used anywhere so I didn’t want to force that. I think in the future it would be useful to add support for other templating libraries so Underscore wouldn’t be a dependency in that case.

Check it out in the wizard-mvc project or on GitHub.


I also created a version of this for Marionette.js called Marionette.TemplateManager which is a Marionette plugin. I’ve been trying out Marionette recently, and I thought it would be nice to utilize this here too. One thing about Marionette is that it already has a TemplateCache object that caches inline templates internally. Marionette.TemplateManager takes advantage of this by using the TemplateCache instead of its own internal cache. It doesn’t return the compiled template with the promise however since Marionette also handles that internally. With Marionette, you can also change the default templating library so you don’t have to use Underscore templates.

Check it out in the wizard-mvc project or on GitHub.

Use setTimeout with QUnit and Sinon.js

I am currently using QUnit with Sinon.js in my JavaScript testing setup. However, I ran into a problem attempting to use setTimeout with QUnit along when using Sinon.js. Here is what I found.

QUnit advises using setTimeout when testing asynchronous functionality. But, I found that this did not work when you include Sinon.js. The reason is that Sinon.js provides fake timers and in doing this it overrides the setTimeout method. If you need to use setTimeout, you must change the config in Sinon.js.

sinon.config = {
    useFakeTimers: false

Changing the config above will allow you to use setTimeout with Sinon.js. This isn’t very clear in the documentation unfortunately.

Underscore 1.5 Released

Underscore 1.5 was just released two days ago. The last significant update prior to that was 1.4.4 released on January 30th, 2013. The biggest feature was the unzip method which has now been pulled out of Underscore in the 1.5.1 release today. Underscore is a utility-belt library for JavaScript and also a dependency of Backbone.js.

It seems humorous to pull the biggest feature in a 1.x release 2 days after releasing it. Perhaps creator Jeremy Ashkenas thought so, calling the commit, “remove silly duplicate unzip function. Favor in the docs.” You can read the discussion and the reason for this change here on GitHub.

Now that the unzip method has been pulled there aren’t many significant changes which makes the 1.x release number seem kind of silly. Maybe the source map, plus the number of changes warrant it. Anyway, here’s the changelog which you can also see in the docs.

  • Added a new unzip function, as the inverse of
  • The throttle function now takes an options argument, allowing you to disable execution of the throttled function on either the leading or trailing edge.
  • A source map is now supplied for easier debugging of the minified production build of Underscore.
  • The defaults function now only overrides undefined values, not null ones.
  • Removed the ability to call _.bindAll with no method name arguments. It’s pretty much always wiser to white-list the names of the methods you’d like to bind.
  • Removed the ability to call _.after with an invocation count of zero. The minimum number of calls is (naturally) now 1.

Unit Testing Ajax with Sinon.js and QUnit

I’ve done unit testing with JavaScript using QUnit, but I’ve never tried writing unit tests for Ajax. I recently learned about Sinon.js however, and that has taken unit testing in JavaScript to a whole new level for me. By default, Sinon.js doesn’t work with QUnit, but fortunately you can add another script to make it work.

While attempting to write unit tests for Ajax, I had trouble finding good information. I actually found the solution in the Sinon.js docs. The secret to unit testing Ajax is not spies, stubs or mocks that are available in Sinon.js but the Fake XMLHttpRequest. This allows you to test Ajax calls and callbacks without making actual Ajax requests. The following test passes in QUnit.

test("ajax tests", function () {
    var xhr = sinon.useFakeXMLHttpRequest();
    var requests = sinon.requests = [];

    xhr.onCreate = function (request) {

    var callback = sinon.spy();

    $.ajax('/some/article', { success: callback });

    equal(sinon.requests.length, 1);
    equal(sinon.requests[0].url, "/some/article");

    requests[0].respond(200, { "Content-Type": "application/json" }, 


You can see the code working here in jsfiddle. As you can see, the Ajax request was called with the right url. With the respond method, we were able to make our fake Ajax call return a 200 code so that the callback will be run as well. The trick is calling the respond method every time a request is sent. You just have to increment the number of the array item.

Here I am only returning an empty array because I couldn’t get the code to work in jsfiddle, but you can control what data is returned by the Ajax call, as well.

That’s it. I didn’t go into detail here about how QUnit or Sinon.js work, so you will need to check out their respective documentation if you are wondering about that. Unit testing Ajax is just one of the benefits of Sinon.js. If you aren’t already using it, I recommend that you do.