Now that it’s 2014 and I’ve read that blog post about everyone being scared of moving to 1.0.0, I’m excited to announce a JavaScript project of mine that will help RequireJS users feel a little more comfortable with the browserify ecosystem.

On demand async loading of modules in the browser

Promethify is a browserify transform that allows for the async module loading that RequireJS solves for out of the box. It’s intended to be used to only load what you need.

It allows you to specify what modules are needed to be loaded dyanmically just like RequireJS. Pass as it’s first parameter, an array of dependencies instead of strings, and boom, everything else just works.

You can use it to write code like this in browserify:

1
2
3
4
5
6
7
8
9

//main.js
var $ = require('jquery');

$('.buy-product').click(function(){
  require(['/shopping-cart'], function(shoppingCart) {
    // only downloaded shopping cart code including jqueryui when necessary
    shoppingCart.open();
  });
});

1
2
3
4
5
6
7
8
9

//shopping-cart.js
var $ = require('jquery');
require('jqueryui');

module.exports = {
  open: function(){
    // open modal with jquery ui
  }
}

There are a few exising alternative approaches out there to achieve lazy loading with browserify, but they all have the same large con for me. They all require significant build/configuration changes for each module that needs to be asynchronously loaded.

The few goals for this project in relation to the other solutions were to

1. Have RequireJS-like simplicity in how to define what modules are loaded asynchronously. Just add it to the dependency array, and all of the hard work is taken care of for you.
2. Have a completely opaque mechanism for fetching and generating the JavaScript file for the module. I don’t want a user to think about jQuery.getScript.
3. The interface should be a regular browserify transform that takes configuration from package.json so this could be used from the browserify CLI as well as a custom bundling script.

I am hopeful that this will open up a whole new world of possibilities for browserify. As a huge RequireJS fan, this is something that I’ve sorely missed as I’ve used browserify on larger applications.

Please let me know your thoughts in the comments or on twitter. I’d love to hear why this is a great/horrible idea, or how I can make it better.

Tweet

I came across some code recently that looked like this:

1
2
3
4
5
6

function clearPhoto(photo) {
   photo._id = void 0;
   photo.name = void 0;
   photo.caption = void 0;
   photo.renditions = void 0;
}

While it’s definitely worthwhile to know what void 0 does, in JavaScript, just use undefined instead of void 0. There are a few reasons why some might consider using this in your codebase, and I’d like to address a few of them here.

1. Defensiveness

A very old version of JavaScript does allow for assigning to the identifier undefined and that’s potentially an argument for why void 0 should be used instead of undefined. Formally, the undefined that we use in JavaScript is a property on the global object. In the browser, window.undefined is similar to window.setTimeout It is assignable in ES3, so you can change the value of undefined in old browsers. Understandably, everyone is worried about what happens if someone sneaks undefined = true somewhere into your codebase, but there are other ways to deal with this problem.

Why not worry about the assignment problem?

1. All modern browsers provide ES5, the version of JavaScript that fixes the assigning undefined problem, by making sure that trying to assign undefined is a no-op.
2. Ideally, your entire codebase should be in Strict Mode, and ES5 strict mode does not allow assigning to non-writeable properties, which will mean that an error is thrown if someone accidently assigns to undefined.
3. Whatever linting tool that you use should have an option to flag accidental things like this with nice early error messages.

2. Expressiveness

Depending on the developer’s programming language background, some devs feel like using void 0 expresses their intent clearer. They want to ‘void out’ a certain property in a similar way to how programming languages like C have a void return type if they don’t return anything. Personally, I have a hard time understanding how the word “undefined” can be better expressed considering there’s only one actual regular dictionary definition of the word, but everyone has different tastes when it comes to these things.

With respect to this argument, I always err on the side of idiom and convention. JavaScript uses the identifier “undefined” for this meaning, void 0 and I think that it only sounds better if you’re coming from C/C++.

3. The tendency to show off

I know that I’m veering into difficult territory here, but I think that a part of this is showing off. We all have the urge to use everything new that we learn in a programming language and we all have egos. This particular case is even better because many JavaScript developers don’t know what void 0 does, or even that there is a void operator in JavaScript.

There’s also a tendency to think “Well, it’s part of JavaScript and if developers don’t know JavaScript, then why are they working here?” I understand that argument too, but I don’t think that it is always correct. I very unscientifically polled my twitter followers and the people who saw their retweets to figure out how many people actually knew what void 0 actually did. Only 65% of responses were correct, and taking into account cheating and the already JS-loving skew of my follwers, the actual percentage of JavaScript developers that know what void 0 does is much lower.

I know that thinking about what most JavaScript developers already understand can be a slippery slope, but here’s a litmus test for when this should matter. If there is a straightforward and semantically equivalent alternative to sprinkling your codebase with little known constructs/features, don’t use it. undefined is that alternative whenever you think you need to use void 0. Please don’t think that I’m telling you not to use anything that’s not known by most JS devs. Getters and setters, for example, are fine because those are incredibly powerful and have no more widely known alternative.

Alternatives for the concerned

In case you are very worried about older browsers and malicious code, the way to deal with this is silo away somewhere in your code an actual unchangeable version of the value undefined and use that where you need it. Define it once and use it everywhere instead of void 0 everwyhere.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

(function(){
'use strict';

var undefined = void 0;
// OR
var undefined = (function(){}).call();
// OR if jQuery's around
var undefined = jQuery.noop();
// OR if in node/browserify
var undefined = require('undefined');

// ...

function clearPhoto(photo) {
   photo._id = undefined;
   photo.name = undefined;
   photo.caption = undefined;
   photo.renditions = undefined;
}

})();

Summary

Please don’t use void 0 in code that other people need to read. If you’re worried about malicious code changing the value, there are alternatives. When trying to decide about what to include in your codebase, consider what percentage of people that work with you will understand what you’re doing and apply the litmus test of ‘Is there an equivalent alternative?’.

See you in the comments or on twitter!

Tweet

In case you saw my twitter poll, here’s the result breakdown:

A HUGE thanks to Michael Benin for recording, editing, and turning this around in less than a day.

Coding at Scale, Angular State of Mind, CSS Animations and CucumberJS from John K. Paul on Vimeo.

Another month, even more awesome talks. This time, one main talk and three lightning talks. I'm very encouraged by seeing how many people out there want to come and share knowledge of what they know. As always, get in touch with me if you want to present either lightning talks, or main talks.

Coding at Scale: Tactics for Large-Scale Web Development by Mike Petrovich
Web applications and their development teams are becoming larger and more complex, which introduces a new set of challenges relating to developer communication and collaboration. How do large teams—sometimes in different parts of the world—coordinate effectively to build complex web applications?


In this talk, we'll examine many of the technical and logistical challenges faced by large and small-but-growing development teams alike, and we'll identify high-level patterns and implementation tactics successfully employed by development organizations.
Angular State of Mind: Intro to Angular.js by Rushaine McBean
Using a JavaScript framework or library today is a no brainer, the hard part is figuring out which to learn. In this talk, I’ll guide you through the key Angular concepts so your eventual mastery of AngularJS will lead to building scalable JS applications.
CSS Animations by Chris Sanders
The goal of my presentation is to discuss animations in CSS and why they are the preferred way to handle animations for your application. Firstly, I will give an overview of the syntax for creating animations. Then I will be presenting some common things people like to create with javascript and instead create them with CSS3 and CSS4.
CucumberJS by David Souther

David Souther shows how to write and run behavioral tests using Grunt, CucumberJS, and WebdriverJS. In a TDD fashion, we will go from an empty directory to a complete green functional test. Bring your Github, and look at each commit as we show how easy testing the full stack can be.