Feel free to fork this for your own use.

The Commandments

• I will gzip all server responses.

• I will not include any blocking scripts.

• I will use SVGs instead of JPGs, wherever possible.

• I will not include ads, even ones that request users to join groups or lists on Facebook or Twitter.

• I will debounce scroll events.

• I will not include third party JavaScript libraries just to detect if users are part of my “Just Cool Friends” Facebook group, even if it wouldn’t take up that much extra load time.

• I will ignore “the fold” – no matter what the client says.

• I will resist the urge to use window.alert to inform visitors that there’s a Facebook group for cool friends and if they wanna join it, that’s fine, it only takes a few clicks.

• I will not use translate3d as a hack.

• I will not use synchronous XHR to request the list of friends in my Facebook group, and then use the list in order to check to see if the current visitor is on the list, and then show a warning to people who aren’t in the group that says that they have their priorities “messed up” and that “jeeze,” it’s just a stupid group, why can’t you just join it.

• I will use a CDN to serve static content (with no cookies!).

• I will not “waste bytes” in HTML comments to explain that I’d really appreciate it if you joined the Just Cool Friends™ Facebook group. Things haven’t really been the same for me since Linda left, and it’s just so easy to join that it’s actually a little bit rude that you wouldn’t. I don’t post much in there, and I won’t even know if you ‘mute’ the posts from showing up on your feed. But honestly it’s only like one or two posts every day, so it’s not like seeing them in your feed would kill you.

• I mean it’s one crummy group that you join and it makes a guy feel better about himself. The number of people that join goes up and so does my happiness, how does that not make sense? If you have a problem with me or with something I’ve done in the past, you could just bring it up on the group, that’s literally what it’s for. Sometimes I just sit around refreshing the group page, waiting as those numbers tick up. Each number…

• … is another dollar in the bank of my emotional stability. I scratch the pixels into my screen: “10,000,000”. I count in my sleep: “two-hundred-and-six, two-hundred-and-seven” – each time a friend is added my joy grows, my sadness pales, my existence means that much more. I weep as the numbers hit double and then triple digits. So many friends. So many lives touched. How can I be this lucky? How can I be this influential and popular? See Linda?! I’m not a “loner.” I have way more friends in my group than you ever had! Maybe you’re the loner, Linda, or should I call you “Lone-da?!” I hope you can find your own group one day. I hope you can be as meaningful and influential to so many people as I am. And another friend joins. And another friend joins.

• I will minify all of my CSS.

Here at Acme, Inc. we switched to Soy Milk when we rewrote our app, and now it’s 8.3x better than our old Almond Milk app!

I call this a Monty Hall Rewrite.

What’s a Monty Hall?

For those loyal readers who haven’t heard of The Monty Hall Problem, to which I’m alluding, it comes from an old game show, called Let’s Make A Deal. It later became an interesting probability question, and even later a less interesting common interview question.

On Let’s Make A Deal (on which Monty Hall was the original host), contestants were shown three doors and told that behind one of the doors was a brand new car. If they could correctly guess which door hid the car, they could keep it. The guessing happened in two phases.

First the contestant would choose a door that they believed had the car behind it. Then one of Monty Hall’s assistants would walk over to the other two doors (the ones that had not been chosen) and proceed to open one of them, always revealing a bad prize (often a donkey!). Then the contestant, who now had this new information, was allowed to stick with their original answer or they could switch to the remaining closed door. That would be the final allowed guess.

They’d open the final chosen door and their winnings (hopefully a car!) would be displayed.

In 1990, well into the show, advice columnist Ask Marilyn from Parade Magazine was asked whether there was a particular advantage to staying or switching. Much to many folks’ surprise at the time, she answered that the probability of winning was greater if you switched. Thousands of people wrote in to tell her that she was wrong, but most (not all!) were eventually convinced.

My best summarization would be that, initially, each door has 1/3 probability of being correct. Therefore, the door that the contestant first chooses has a 1/3 chance of being correct, and the sum of other 2 choices must be 2/3. When the assistant reveals the donkey behind one of the remaining doors, it does not change these facts. The original choice still has a 1/3 chance of being correct, and the sum of the other doors still has a 2/3 chance of being correct. However, now that the contestant knows that one of the non-chosen doors is a bad door, the 2/3 chance must lie solely in the unchosen, unopened door.

The conclusion is that you have a 2/3 chance of guessing correctly if you switch, and you have a 1/3 chance of being correct if you stay. This has since been mostly proven as well as observed in repeated computer simulated trials. It’s a bad interview question, but remains a popular Probability 101 problem and a decent anecdote.

How is this related to rewrites?

It’s not really, obviously. I don’t think this metaphor goes very deep, but what it hopefully gets across is that in the case of a rewrite, the new framework that you choose doesn’t necessarily have more merit than your original choice. The switch itself is what’s important.

To immediately break down my own metaphor, the switch doesn’t matter as much as the rewrite itself, but people don’t tend to rewrite things on their old stacks.

If you had started with B, and rewrote in A, you’d also likely have better results than in your first pass.

The only fair comparison is a rewrite of your app with your original tools as well as a rewrite of your app with the new tools. This isn’t very practical, and I’m not advocating it. I’m simply advocating awareness of the fallacy.

I’d like us all to be keenly aware of what it really takes to make great software, and to me that involves avoiding false traps. The sexiness of switching to a new, hip library often comes along with a strong confirmation bias, and an even stronger sunk-cost bias. Let us measure only what we are able to measure and leave the rest to the marketing teams and social media experts.

Real Quick For Car People

“This 2015 Hyundai Sonata is way better than our old 1989 Mercedes C Class.”

Please ignore the 2015 Mercedes C Class.

Switching, Rewriting, & Refactoring

Throw away any assumptions or knowledge of tools that you have and purely consider that if you are switching, rewriting, or refactoring, you are now n years better at programming than you were when you initially wrote the software.

Now factor in that you’ve had x years more time to consider the exact problem that you’re trying to solve as well as rid yourself of uninformed assumptions. When going in for the rewrite, you have a much clearer picture of what a successful product looks like, purely because of the initial app. You know to abstract certain parts of the code that need to grow, and to externalize other parts that you know you won’t be able to support indefinitely. For all its negative qualities, second system syndrome is actually somewhat helpful in understanding exactly what needs to be built (even though there isn’t time to build it all).

In your original app, things almost certainly went directions that you weren’t expecting. You had to tack on widgets and endpoints that you never intended, and you ended up with some frankenversion of your original vision. The rewrite allows you to consider all of this stuff from the begining (at least for a bit), which results in things being ‘faster’ or ‘more secure’ or ‘more user friendly’ or whatever metric your new app is better than the old one.

If you’d like another bad metaphor, imagine your original app as The Homer.

Are you talking about any specific rewrite? (aka are you sub-blogging me?)

No. This seems to come up a lot, though. I’m happy to tell you that I think you’re measuring things incorrectly directly to your face. If you must have an example, I’d say that Facebook’s switch from an HTML5 app to a native app would be an ideal candidate for a well-defined Monty Hall Rewrite.

If you weren’t familiar, their old, not-so-great app was written as an HTML5 web app in a native wrapper. It had all sorts of warts (HTML as the data transfer layer, etc) and was indeed not that nice. Mark Zuckerberg famously said that betting on HTML5 was one of their worst mistakes and that the new native app was better, faster, stronger.

So after they had a laundry list of things they didn’t like about their old app, they set out to completely rewrite a new app with new tools. It was better! And faster! But I think it is wrong to attribute a vast majority of these improvements to the fact they were now “native,” but instead to the fact that they were rewritten.

Luckily, at the time, Sencha put out something called Fastbook. A Facebook “rewrite” of sorts to match the new native Facebook app. They made a nice video about how they were able to make a faster/snappier/cooler app than the new native one, all in HTML5 (with Sencha’s tooling, obviously). I don’t necessarily think Facebook should have switched to the Sencha platform or anything along those lines, but it is a good example of people blaming their tools for causing their old problems, and thanking their new tools for solving them.

To Facebook’s credit, @tobie eventually put out a list of things he’d wish the web would fix with things that had actively been a problem for them when building those old web-based apps. I haven’t seen the equivalent list on the problems building cross platform native apps, but the list was quite valid. It’s much more in line with the type of discourse we should be having when we make claims about why our new choices are better than our old ones.

What now?

I don’t mean to discourage rewrites, trying new tools, or any other variant on that theme. I love a good rewrite, and I’m constantly trying new tools. More than anything I wanted to point a thing out that I think muddies a lot of the waters when developers are evaluating new tools.

So when you pick new tools, don’t trash your old ones. And once you decide on one tool instead of another that does something very similar, don’t speak as if you made the obvious or correct choice. Instead, focus on the fact that you made a good choice.

Software is not a zero-sum game. Two tools can be good at the same time, and we all win because of it.

I’d like to take the chance, while we’re still mostly clueless, to write some of my non-scientific theories on cognitive ability and “focus” (the noun) in the context of creating and building things (or “shipping,” as it were).

Motive and Privilege

I see a thin thread woven through everything that I do, and everything that I see my peers do.

Legacy.

We’re all creative, and many of us want to “build things.” I hear it often in interviews, and over beers, that it’s just built into the core of many of us to want to “create something from nothing.” It often takes shape as some other pleasant-sounding turn of phrase, but the “need to create” seems to be innate in all but the most blissful of us. In my experience, this can often be traced back to the desire for someone to ‘make their mark,’ or as I previously alluded, the desire to pursue a legacy.

I’m all for this. This feeling is built in to my DNA as well. And while I would hope to have purely selfless reasons for wanting to create things, I’m certain that my ego, and my human-nature drive me to want to live longer than my bones.

I can’t help but lead with “ego” and “legacy” because the entire ability to create something from nothing (programming) and to get disproportionally rewarded for doing so (programming salaries) comes along with more than a touch of blind privilege. It’s a pretty good spot to be in to be hacking your mental focus levels so you can build bigger and better websites. Blindness to our privilege is mostly to be expected as long as we fight to improve our own awareness and adjust our actions appropriately. Read on now, forewarned of my ego, blindness to privilege, and extreme lack of brevity.

Caffeine is a Zero-Sum Game

Ostensibly, this is a graph of my potential “focus” levels during a day.

I read a fascinating blog post several years ago by Arvind Narayanan called The Calculus of Caffeine Consumption. It was pretty eye-opening for me to see my “focus” levels throughout the day graphed out as a sine wave. Naturally, it’s a massive over-simplification, but in my personal experience, not an entirely incorrect approximation of my energy levels in a day. I am tired, perk up, get hungry and eat and dip down, then hit a stride, rinse and repeat. It’s not a sine wave, but it’s a wave alright.

Like my Uncle Ray always says, “Any wave is sinusoidal with a sufficiently low sampling rate!”, though I think eventually it becomes a straight line. (Which I guess is a wave with an amplitude of zero?)

Our wave of “focus”/energy has all the normal properties of a wave: a wavelength, a period, and an amplitude. The premise of the article is that caffeine, a stimulant, is often consumed during the low points in our day. So we drink coffee when we wake up or when we feel tired after lunch in order to boost our ability to concentrate and sometimes even function. The effect of this decision that is lost on us, is that this reduces the total amplitude of our “focus” wave.

In other words, by consuming caffeine to reduce how low we get during the low points, we inherently reduce our high points as well.

Narayanan states that this type of consumption actually works pretty well for people who are trying keep from falling below a threshold of “focus” or energy. Consider a construction worker, data-entry employee, truck-driver, or similar, where the time put into the task is important, and dipping below a certain level of energy would be dangerous/deadly.

Creative workers, however, don’t have the same limitations. They often need “a moment of clarity” to spark their work, or to break out of “writer’s block.” They would want the absolute highest amplitude of focus, regardless of the consequences on the downside, and to be working while at their highs.

Narayanan, a true hacker spirit (read: CS Ph.D. and Assistant Professor at Princeton), attempts to exploit this relationship to his advantage. Could he use caffeine to increase the amplitude of his “focus?” A conclusive answer here would take quite a few more double blind studies, but in my experience, and seemingly in Dr. Narayanan’s as well, the answer is a resounding “yes.”

Drink a latte 30 minutes before a high point, work as hard as you can, and then use the warmth of your laptop to take a nap a few hours later, because you’ll be spent.

Caffeine is a zero-sum game, but you can use that to your advantage. Consuming caffeine in time for it to affect you at the exact peak of your “focus wave” effectively makes the highs higher, and the lows lower. The rich get richer, while the poor get poorer. It’s like the sad state of our socioeconomic classes, except not awful, and for brain power!

You Require More Vespene Gas

Many people who have read Daniel Kahneman’s Thinking Fast And Slow will remember the chocolate cake experiment.

Photo by Food Thinkers under CC-by-NC-SA

The experiment, led by Baba Shiv at Stanford University, is pretty simple. Half the students are asked to remember a 2 digit number, and half are asked to remember a 7-digit number. They walk down a hall, are told they’re done, and are asked if they want chocolate cake, or fruit salad as a refreshment. The students who were asked to remember the 7-digit number were nearly twice as likely to choose the chocolate cake. Why is this?

Simply put, we have a finite amount of mental energy. The students who spent their energy on remembering 7-digit numbers had no more energy left to spend on avoiding cake.

The prefrontal cortex is primarily responsible for the things that creative people crave, like focus, but also other functions like short-term memory, abstract problem solving, and willpower. The conclusion of the chocolate cake experiment implies that there is a finite amount of resources in the prefrontal cortex, and that one system’s use of those resources could directly affect the available resources of another function.

In the context of our sine-wave, I’m pretty sure I could make a good reference to calculus, because this concept has a lot to do with the area under the curve, but I’ll get it wrong, and I won’t hear the end of it in the comments.

This plays into our first theory quite well. If we use more mental energy in a quick burst (because we have a higher amplitude), we’ll need deeper rest in order to recharge this energy. During our rest periods, the troughs in our sine-wave, we have to refill the energy that we spent during our peaks.

I can’t safely postulate much about how to best do this, except for that studies show that naps are increasingly good for doing such things. Since you’re probably not going to have your big break during a lull in your cognitive ability, why not speed up the process of getting to another high point? Nap away! Refuel the exact part of your brain that will allow you to get in the zone again.

Some folks will recommend a caffeine nap. I don’t have a ton of intentional experience with caffeine naps, but the idea is that if you consume caffeine just prior to taking a nap, you’ll sleep until it kicks in (usually takes at least 30min for caffeine to metabolize), and then it’ll allow you to skip some of the groggier[1] steps on your way back to productivity. It probably works.

[1] Apparently, I can’t write the word ‘grog’ without thinking about Guybrush Threepwood.

Moderation

I would add, finally, that Dr. Narayanan found that the body adjusts to regular caffeine intake in as little as 2 to 3 weeks. That means that if you’re a long-time coffee-drinker, you really do need that cup of coffee to get going in the morning in order to get up to your pre-caffeine addiction baseline.

He notes that it takes 5 days to reach adenosine normality (good) if you’re not consuming caffeine. He retrospectively adds that he initially did not place enough value in these ‘quitting cycles’ (hinting that perhaps you should not repeat his mistakes).

Practical Application

Most of this should be obvious at this point, so I won’t drag on.

• Plan your high points, work during them
• Refuel during low points instead of stretching them out with forced work
• Slingshot your amplitude with caffeine; 3 weeks on and 1 week off
• Avoid non-intentional caffeine, only drink it on schedule
• Don’t ignore the people you love

The Nap Month

I have nothing but my own personal experience to back this up, but I find that my motivation and passion levels work in a similar way on a yearly cycle as they do on a daily cycle. For parts of the year, I’m excited by work, and go out of my way to build things in my free time, and other parts of the year, I just want to come home and binge watch a season of a TV show on Netflix.

For this reason I have to wonder if some of the same energy principles apply. Can I increase the intensity and duration of the productive months? If so, at what cost?

I really struggle (in a not very serious kind of way) during the month or two when I feel like I can’t get anything done, but I think we can use a similar trick to help our productivity pick up again. Specifically, we need to A) simulate caffeine on a macro scale, and B) simulate naps on a macro scale.

Macrocaffeine

I find that an interesting, new passion project gets my creative energy flowing much better than jumping into old work. If I really want to get in the mood to program, I’ll hop off my projects with deadlines and build something that I know probably won’t ever even get finished, but that I’m just excited to build.

Caffeine blocks adenosine (a sleep chemical) receptors in our brain, causing us to avoid sleep longer. If we substitute the current list of things we have to do, with a temporarily more engaging list, it may give us the same slingshot effect that caffeine does for our energy on a micro level.

Macronaps

This one seems a little bit more straight forward to me.

Just stop working so much.

Take a nap from your work. I understand that this is not a viable solution for businesses that intend to make money, but I think there can be some good compromises here. Namely, most hip tech companies have very generous vacation allowances already. Use your vacation during a low point, and in perfect cliché form, “recharge.”

Additionally, companies with large enough teams can have two modes of employment that employees could ideally opt into. “Passion-mode” and “coast-mode.” Someone who is on an upswing should get put on a big project that’s going to take a lot of energy. Someone who is burnt out from the last big project should be given work that will allow them to show up a little late, and leave a little early.

There’s lots of work like this. The support team at your company would probably love it if developers frequently did 6-hour customer support stints. In no way do I imply that the support team doesn’t regularly break its back working very demanding hours/problems and doesn’t deserve their own down-time. There’s also plenty of documentation that I’m happy to churn out during my down month.

The point is to allow employees to be maximally lazy while still maintaining their minimum required value. The more quickly I’m able to get through the less motivated time, the more quickly I’ll be able to jump back into a difficult and challenging project and do it well.

A Final Moment of Clarity

I have very few projects and accomplishments that haven’t come to me in a “moment of clarity.” Naturally, I want to maximize the amount of these moments, and increase the odds that I’ll be working on something that I love when they occur. I have no idea if hacking your body is a good long-term strategy for making this happen, but I find that researching all of this sleep stuff is an excellent tool for procrastinating during my focus droughts.

I can’t guarantee that any of this will resonate with you, or work for you if you try it. But I do think that everyone goes through the motivational recessions, and we should be actively attempting to eliminate or reduce them. What is Quantitative Easing for the Soul?

I simply want my hard work to be spent most efficiently.

Special thanks to Michelle Bu for reading this ahead of time.

The Terminology Play

You mention that it’s prototypal inheritance, not prototypical and pretty much gloss over the rest, comfortable in your superiority in terminology. You may go as far as saying “Objects just come from other Objects because there aren’t any classes.” Then you just link to Crock’s Post on it, and try to seem busy for the next few days.

Many years later you find out that Prototypal and Prototypical are synonyms, but you choose to ignore this.

The Like-Classical-Inheritance-But-Different Play aka the Run-On Sentence Play

“So in Java, like, you have classes or whatever, right? Well so imagine that you don’t have those, but you still want to do that same type of thing or whatever, so then you just take another object instead of a class and you just kind of use it like it’s a class, but it’s not because it can change and it’s just a normal object, and if it changes and you don’t override the object, oh yea, so you can decide to override the parent object class thing, so if you dont do that and the parent changes the link is live…”

And so forth.

The Animal Play

This is a pretty popular one.

So let’s say we want to make an Animal class in our code. As is often necessary in production JavaScript applications.

First we make a “constructor function,” which acts kind of like a constructor method on the inside of a class in a classical language when it’s invoked with the new operator. Except this one is on the outside.

1
2
3
4
5

function Animal (name) {
  this.name = name;
}

var myAnimal = new Animal('Annie');

Then we want to have actions that all animals can do.

1
2
3

Animal.prototype.walk = function () {
  console.log(this.name + ' is walking.');
};

But then you want to define a more specific type of animal. Things start to get weird.

1
2
3
4
5
6
7
8
9
10
11

// I think we need to define a new Animal type and extend from it somehow

function Dog (name) {
  this.name = name;
}

// BUT HOW DO WE EXTEND
// WITHOUT AN INSTANCE TO USE?
Dog.prototype = Animal.prototype; // ?? I HAVE NO IDEA
// Maybe that'll work for some stuff?
// ProHint™: probably not much, once you start modifying one of them :D

Then you remember that Prototypal Inheritance doesn’t really do ‘classes’ so much. So you do something like this:

1
2
3
4
5
6
7
8
9
10

var Dog = new Animal('Annie'); // ??? NO THATS NOT IT >:(

// Maybe we can try Object.create? I hear it's prototypal-y
var Dog = Object.create(Animal);

// Maybe that worked? Let's see...
var myDog = new Dog('Sparky');
// TypeError: object is not a function

// Shucks

And you eventually simply converge on the…

The Father/Son Analogy Play

Here we go. Finally a real world example of ‘instances begetting instances.’ It’ll be a perfect analogy. It’s even an interview question some places. Let’s see how we might implement the relationship of a father and son (or a parent to its child) in JavaScript.

We’ll start out like we did before, with a Human constructor

1
2
3

function Human( name ) {
  this.name = name;
}

Then we’ll add in a common human shared action.

1
2
3

Human.prototype.sayHi = function () {
  console.log("Hello, I'm " + this.name);
};

So we’ll create my dad first.

1
2
3
4
5
6

// Instantiate him
var myDad = new Human('Bill Sexton');

// Greet him
myDad.sayHi();
// "Hello, I'm Bill Sexton"

Score. Now let’s create me.

1
2
3
4

// Let's use ES5 `object.create` in order to be as 'prototypal' as possible.
var me = Object.create(myDad);
me.sayHi();
// "Hello, I'm Bill Sexton"

It’s a start! Seems like I inherited a little too much from my dad, but I inherited, none the less.

Let’s try to smooth things out to make the analogy work better. So we’ll instantiate objects without a name and have a parent name them after they’re created.

1
2
3
4
5
6
7
8
9
10
11

// Wrap it all together
function makeBaby(parent, name) {
  // Instantiate a new object based on the parent
  var baby = Object.create(parent);

  // Set the name of the baby
  baby.name = name;

  // Give the baby away
  return baby;
}

Perfect. Now the baby can sayHi on its own.

1
2
3
4

var alex = makeBaby(myDad, 'Alex Sexton');

alex.sayHi();
// "Hello, I'm Alex Sexton"

Err. yipes. Babies can’t talk. And what’s this deal with a baby being made by one parent. Not to worry, we can fix all of this.

First we’ll probably want to try to take two parents into the makeBaby function (no giggles).

1
2
3

function makeBaby(father, mother, name) {
  var baby = Object.create(...// fuuu
}

Multiple Inheritance! How did you get here? Ugh. Fine. We’ll just simply mock the human chromosome pattern into our little inheritance example.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

// Let's take a set of 4 genes for ease of
// example here. We'll put them in charge
// a few things.
function Human (name, genes_mom, genes_dad) {
  this.name = name;

  // Set the genes
  this.genes = {
    darkHair: this._selectGenes(genes_mom.darkHair, genes_dad.darkHair),
    smart:    this._selectGenes(genes_mom.smart,    genes_dad.smart),
    athletic: this._selectGenes(genes_mom.athletic, genes_dad.athletic),
    tall:     this._selectGenes(genes_mom.tall,     genes_dad.tall)
  };

  // Since genes affect you since birth we can set these as actual attributes
  this.attributes = {
    darkHair: !!(~this.genes.darkHair.indexOf('D')),
    smart: !!(~this.genes.smart.indexOf('D')),
    athletic: !!(~this.genes.athletic.indexOf('D')),
    tall: !!(~this.genes.tall.indexOf('D'))
  };
}

// You don't have access to your own gene selection
// so we'll make this private (but in the javascript way)
Human.prototype._selectGenes = function (gene1, gene2) {
  // Assume that a gene is a 2 length array of the following possibilities
  // DD, Dr, rD, rr -- the latter being the only non "dominant" result

  // Simple random gene selection
  return [ gene1[Math.random() > 0.5 ? 1 : 0], gene2[Math.random() > 0.5 ? 1 : 0] ]
};

Human.prototype.sayHi = function () {
  console.log("Hello, I'm " + this.name);
};

function makeBaby(name, mother, father) {
  // Send in the genes of each parent
  var baby = new Human(name, mother.genes, father.genes);
  return baby;
}

Elementary. My only beef is that we no longer are using real prototypal inheritance. There is no live link between the parents and the child. If there was only one parent, we could use the __proto__ property to set the parent as the prototype after the baby was instantiated. However we have two parents…

So we’ll need to implement runtime getters that do a lookup for each parent via ES Proxies.

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

function makeBaby(name, mother, father) {
  // Send in the genes of each parent
  var baby = new Human(name, mother.genes, father.genes);

  // Proxy the baby
  return new Proxy(baby, {
    get: function (proxy, prop) {
      // shortcut the lookup
      if (baby[prop]) {
        return baby[prop];
      }

      // Default parent
      var parent = father;

      // Spice it up
      if (Math.random() > 0.5) {
        parent = mother;
      }

      // See if they have it
      return parent[prop];
    }
  });
}

So now we support live lookups of parents, and, you know, some simplified genetics.

Isn’t that just a simple, well-defined, example of how straightforward inheritance can be in JavaScript?

Conclusion

Sometimes these analogies get pretty crazy in my head, and I start to think that maybe instead of trying to apply known examples in the outside world in order to help people understand, it’s often better to just let someone know why they might wanna use inheritance in their programs!

I personally find the best Prototypal Inheritance analogy to be:

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

var defaults = {
  zero: 0,
  one: 1
};

var myOptions = Object.create(defaults);
var yourOptions = Object.create(defaults);

// When I want to change *just* my options
myOptions.zero = 1000;

// When you wanna change yours
yourOptions.one = 42;

// When we wanna change the **defaults** even after we've got our options
// even **AFTER** we've already created our instances
defaults.two = 2;

myOptions.two; // 2
yourOptions.two; // 2

So stop making everything so confusing and go program cool stuff, and ignore my old presentations when I used these analogies.

<3z

Much of this comes from my experience deploying applications at Bazaarvoice as a large third party vendor, and should probably be tailored to your specific environment. I’m sure someone does the opposite of me in each step of this with good results.

Also, I fully understand the irony of loading a few MBs of GIFs in a post largely about performance, but I like them. Any specific tools I mention are because I’m familiar with them, not necessarily because there are no good alternatives. Feel free to comment on other good techniques and tools below. Facts appreciated.

You

You work on a large app. You might be a third party, or you might not be. You might be on a team, or you might not be. You want maximum performance, with a high cache rate and extremely high availability.

Dev with builds in mind

Locally, you might run a static server with some AMD modules, or a “precompile server” in front of some sass and coffeescript, or browserify with commonjs modules. Whatever you’re doing in development is your choice and not the topic du jour.

The hope is that you have a way of taking your dev environment files and wrapping them up into concisely built and minified JavaScript and CSS files. Ideally this is an easy step for you, otherwise, you’ll tend to skip it. Optimize for ease of mind here. I tend to disagree with the sentiment that ‘script tags are enough.’ Try to manage your dependencies in a single place, and that place probably isn’t in the order of your script tags in your HTML. Avoiding this step is easy until it isn’t.

Loading what you need is better than byte shaving

One technique at the build-stage that is ideal for performance, is building minimal packages based on likely use. At page load, you’ll want to load, parse, and execute as little JavaScript as possible. Require.js allows you to “exclude” modules from your builds and create separate secondary modules. Rather than shaving bytes in your app files, you can avoid loading entire sections of code. Most sections of an app have predictable entry points that you can listen for before injecting more functionality.

In our current app, only a fraction of the users click on the button that causes a specific flow to popup. Because of this we can save ~20kb of code at page load time, and instead load it as a mouse gets close to the button, or after a few seconds of inactivity (to prime the cache). This technique will go a much longer way than any of your normal byte saving tricks, but is not always the easiest and for that reason is often avoided.

Check your network panel the next time you have Gmail open to see how Google feels about this technique. They take an extra step and bring the code in as text, and don’t bother parsing or executing it until they need to. This is good for low-powered/mobile devices.

In fact, some Googlers released a library, Module Server, that allows you to do some of this dynamically. It works with lots of module formats. And technically you could just use it to see how it decides to break up your files, and then switch over to fully static files after you get that insight. They presented on it at JSConf.eu 2012:

So instead of using a microjs cross-domain communication library that your coworker hacked together, just delay loading EasyXDM until you need to do cross domain form POSTs.

Don’t penalize modern users

I’m all for progressive enhancement, and have to support IE6 in our primary application. However, it pains me when modern browser users have to pay a performance price for the sins of others. It’s a good idea to try to support some level of “conditional builds” or “profile builds.” In the AMD world, you can use the has.js integration, or if you’re feeling especially dirty, a build pragma. However, third-parties have written some pretty nifty tools for doing this as a plugin.

One of the best tools for this that I’ve seen is AMD-feature. It allows you to use a set of known supported features to load the best fitting build for the current user. This can be great on mobile. You can silently switch out jQuery with Zepto (assuming you stick to the shared subset). You can add and remove polyfills for the correct users. If 20% of your JavaScript is loading for %3 of your users, something is backwards.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

define({
    'dropdown': [
        {
            isAvailable: function(){
                // test if we are on iOS
                return iOS ? true: false;
            },

            implementation: 'src/dropdown-ios'
        },
        {
            isAvailable: function(){
                // if we end up here, we're not on iOS,
                // so we can just return true.
                return true;
            },
            // Naturally this is simiplified and doesn't actually
            // imply Android
            implementation: 'src/dropdown-android'
        }
    ]
});

// In your code, you would load your feature like this:

define(['feature!dropdown'], function(dropdown){

    // The variable 'dropdown' now contains
    // the right implementation - no matter
    // what platform the code is executed on,
    // and you can just do this:
    var myDropdown = new dropdown();
});

One less jpeg

Lots of people like repeating this one. I think Paul Irish coined it Adam J Sontag naturally coined it, but the idea is if that if you loaded one less jpeg on your site, you could fit in quite a bit of unshaved JavaScript in its place. Consider this the next time you are sacrificing readability or compatibility for file size.

Requests matter

File size aside, the balance of a fast JS deployment lies somewhere between the number of requests, and the cachability of those requests. It’s often alright to sacrifice the cachability of a small script if you can inline it without causing an additional request. The exact balance is not one that I could possibly nail down, but you can probably think of a file that is dynamic enough and small enough in your application that might make sense to just print it inline in your page.

Package all the pieces together

Fonts and Icons

These days, these two are synonymous. I really like using fonts as icons and have done so with great success. We try to find appropriate unicode characters to map to the icons, but it can sometimes be a stretch. Drew Wilson’s Pictos Server is an incredible way to get going with this technique, though I might suggest buying a font pack in the end for maximum performance (so you can package it with your application).

First, we inline fonts as data URIs for supporting browsers. Then we fallback to referencing separate files (at the cost of a request), and then we fallback to images (as separate requests). This means we end up with different builds of our CSS files. Each CSS build only includes one of the techniques, so no one user is penalized by the way another browser might need fonts. The Filament Group has a tool for this called Grunticon. I’d highly recommend this technique. For every modern browser, you have a single request for all styles and icons, with no additional weight from old IEs that don’t support data-URIs.

CSS Files

It’s typically the case that updates to JavaScript files necessitate changes to CSS as well. So these files usually have the same update times. For that reason it’s pretty safe to package them together.

So, as part of our build step, we first build our necessary CSS for our package into a file (for Bazaarvoice: styles are dependencies of templates, which are dependencies of views, which are dependencies of the separate module packages we’re loading, so this is an automatic step). Then we read this file in, minify it, and inject it as a string in our main JavaScript file. Because we have control over when the templates are rendered, we can just inject the CSS into a style tag before rendering the template. We have to render on the serverside occasionally, as well, and in these cases I would recommend against this technique to avoid a flash of unstyled content.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

var css   = '#generated{css:goes-here;}';
var head  = document.head || document.getElementsByTagName('head')[0],
var style = document.createElement('style');

style.type = 'text/css';

if (style.styleSheet) {
  style.styleSheet.cssText = css;
}
else {
  style.appendChild(document.createTextNode(css));
}

// Only assume you have a <head> if you control
// the outer page.
head.appendChild(style);

Since we inline the fonts and icons into our CSS files, and then inline the CSS into our JS file (of which only 1 is injected on load), we end up with a single packaged app that contains fonts, icons, styles, and application logic. The only other request will be necessary media and the data (we’ll get to those).

You may notice that we now have a couple of combinations of packages. Yep. If we have 3 ways to load fonts/icons multiplied by the number of build profiles that we chose to create (mobile, oldIE, touch, etc), we can get 10-20 combinations fast. I consider this a really good thing. When you generate them, have some consistent way of naming them, and we’ll be able to choose our exact needed app for a user, rather than a lot of extra weight for other users.

Quick Note: Old IEs can be fickle with inlining a lot of CSS. Just test your stuff and if it breaks, just fall back to link tag injection for oldIEs.

The Scout File

This post actually started out as a means to solidify this term. Turns out I am a bit more long-winded than I anticipated.

The Scout File or Scout Script is the portion of JavaScript that decides which package needs to be loaded. It kicks off every process that can happen in parallel, has a low cache time, and is as small as possible.

It gets its name from being a small entity that looks out of the cache from time to time to warn everybody else that things have changed. It’s ‘scouting’ for an app update and gathering data.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

// Simplified example of a scout file
(function () {
  // Feature test some stuff
  var features = {
    svg: Modernizr.svg,
    touch: Modernizr.touch
  };

  // The async script injection fanfare
  var script = document.createElement('script');
  var fScript = document.getElementsByTagName('script')[0];

  var baseUrl = '//cool-cdn.com/bucket/' + __BUILDNUM__ + '/';


  // Build up a file url based on the features of this user
  var featureString = '';
  for (var i in features) {
    if (features.hasOwnProperty(i) && features[i]) {
      featuresString += '-' + i;
    }
  }
  var package = 'build' + featureString + '.js'

  // Set the URL on the script
  script.src = baseUrl + package;

  // Inject the script
  fScript.parentNode.insertBefore(script, fScript);

  // Start loading the data that you know you can grab right away
  // JSONP is small and easy to kick off for this.
  var dataScript = document.createElement('script');

  // Create a JSONP Url based on some info we have.
  // We'll assume localstorage for this example
  // though a cookie or url param might be safer.

  window.appInitData = function (initialData) {
    // Get it to the core application when it eventually
    // loads or if it's already there.
    // A global is used here for ease of example
    window.comeGetMe = initialData;
  };

  // If we're on a static site, the url might tell us
  // the data we need, and the user cookie might customize
  // it. Simplified.
  dataScript.src = '//api.mysite.com' +
                   document.location.pathname +
                   '?userid=' +
                   localStorage.getItem('userid') +
                   '&callback=appInitData;';

  // Inject it
  fScript.parentNode.insertBefore(dataScript, fScript);
})();

If you’re a third party or have little control over the pages you’re injected on, you’ll probably use a file. Otherwise, the code should be small enough and dynamic enough to warrant inlining on a page.

Build apps into self-contained folders

When you build your application, you end up with a set of static files in a folder. Take this folder of files and assign a build number to it. Then upload this to a distributed content delivery network. S3 with CloudFront on top of it is an easy choice. The Grunt S3 Plugin is a good way to do this with the Grunt toolchain. Bazaarvoice has an Akamai contract, so we tend to use them, but the idea is that you are getting your built files onto servers that are geographically close to your users. It’s easy and cheap. Don’t skimp! Latency is king.

Now that you have an app on a static CDN, make sure it gets served gzipped (where appropriate, grunt-s3 can help with this), and then set the cache headers on your built files to forever. Any changes will get pushed as a different set of built files in a totally different folder, these files should be guaranteed to never change. The only exception to this rule is the Scout File, which lives outside of the build folders in the root directory.

The scout file for our third-party app is a very small JS file that contains a build number and a bit of JavaScript to determine the build profile that needs to be loaded. It also contains the minimum amount of code to determine the initial data that we’re going to need for a page. It doesn’t have jQuery, or really any dependencies, it just does exactly what it needs to do. This file is cached for about 5 minutes (should be relatively short, but close to the average session length).

Parallelizing the initial data request

Many people use each of their models to make separate requests for data once the app is loaded. Unfortunately, this is terrible for performance. Not only are there multiple requests, but they can’t be fired off until the BIG app files are loaded and executed. We want to parallelize the loading of our app and our data. This is going to be tough for some folks, but it’s a huuuge performance win.

We use node.js to run our models at build time. We feed in each of the “page types” that we know how to handle. For each of these page types, each model registers its intent to load data, and we build up a hash of data that is needed for each page type and stick that into the scout file.

Then we had our API folk create a batch API so we can make multiple data requests at once. We use this hash of needed data for each page type (we have less than 10 page types, and you probably do too) in order to fire off a single request for the data that all the models will need, before they are loaded. Unfortunately the way to do this changes drastically based on your framework, but it’s worth your time!

Statically generate your container pages and CDN them too

If you aren’t rendering templates on the server, then there’s likely no reason you shouldn’t be statically compiling all of your page shells at their appropriate urls, and uploading them to a static CDN along with your scripts. This is a huge performance improvement.

Distributing the HTML to geographically close servers can have big wins towards getting to your actual content more quickly. In the case that you are uploading your static HTML pages up to the static cdn along with your JS Application, your HTML files can become your Scout File. Put a small cache on each static HTML page and inline the contents that you would have put in a scout file. This serves the same purpose as before, except we’ve saved a request. The only thing that isn’t highly cached on a close-by server is the data, and we’re already loading that in parallel with our app if we’ve followed the previous instructions.

This means the main URL for your site is just a CNAME to a Cloudfront url. Doesn’t that just sound nice? Talk about good uptime! Of course that means the dynamic parts of your site would come from a subdomain like api.mysite.com or similar. The reduced latency of your initial HTML can be a very nice win for performance since you’ve inlined a scout file to immediately load the rest of the app in parallel.

The smart peeps at Nodejitsu put out Blacksmith to help with static site generation a while back, but there are plenty of options. Many apps are single page apps with only an index.html file anyways, so you can skip the static generation all together.

All this together

The goal in all of this is to:

• geographically cache anything that’s static, not just images and jQuery.
• cache your app until it changes, but not much longer.

The folder structure I normally see is something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# Simplified for Ease of Eyes
| S3-Bucket-1
  |- app
     |- b1234
        |- build.js
        |- build-svg.js
        |- build-optional.css
     |- b1235
        |- build.js
        |- build-svg.js
        |- build-optional.css
     |- b1236
        |- build.js
        |- build-svg.js
        |- build-optional.css
  |- index.html # or scout.js

The index.html file is the only thing that changes, everything else is just added. If we’re a third party, it’d be the scout.js file since we’d be included in someone else’s markup. Everything else has a 30yr cache header. We can upload our build into a folder, verify it, and then switch the build number in the scout file.

1
2
3

// Simplification of the above process
var build = '__BUILD__'; // Replaced at build time
injectApp('/app/' + build + '/build.js');

Deploying a new version of the app becomes “updating one variable.” This means that every user on the site will have a fully updated app in the amount of time you cached your scout file for. In our case it’s 5 minutes. It’s a pretty good trade off for us. We get lifetime caching for our big files and media, but have a very quick turn around time for critical fixes and consistent roll-outs. It also means that if we ever need to roll back, it’s a single variable change to get people fully back on the old code. Clean up old builds as you feel is necessary.

Other media requests

Naturally, you’ll have some logo images, or some promo images to load as part of the app. These should probably just be imageOptim’d, and sprited as best as possible. However, there is usually a second class of media on a site. Usually these are thumbnails and previews and avatars and such. For these files, I’d suggest using a mechanism to lazy load these media files. Make sure you’re doing smart things with scroll event handlers (hint: throttling the hell out of them), but you don’t want to load 50 avatars if the user is 1000px away from that part of your app. Just be smart about this stuff. It’s not really my intent to cover this portion of app performance since it’s not entirely related to deployment.

Wrap Up

There’s nothing that surprising about these techniques. Everything that could possibly be statically generated is statically generated, and thrown out on edge-cached servers. Every piece of functionality that isn’t needed on page load, isn’t loaded on page load. Everything that is needed is loaded in parallel right away. Everything is cached forever, save for the scout file and the data request (you can save recent requests in local storage though!).

You aren’t left with much else to optimize. You are always only loading and executing the minimum amount of JavaScript, and saving it for the maximum amount of time. Naturally the more common tips of not going overboard with external libraries, and paying attention to render performance, and serving HTML with the page response are all ways to change the performance (usually for the better), but this architecture fits well with many of today’s more app-like deployments.

There’s something really comforting about exposing a minimal dynamic API that needs to be fast and having everything else served out of memory from nearby static servers. You should totally try it.

The Jed Toolkit is a collection of interoperable tools to help facilitate the full process of internationalizing applications in JavaScript. These tools have a wide range of utility, from small modules to help format messages, dates, and numbers to services that facilitate translation, and code integration. The goal of the project is to bring the experience and quality of internationalizing JavaScript applications up to par with the rest of the current state of JavaScript tooling.

I’m in the process of moving everything over, but you’ll likely want to watch this space: github.com/jedtoolkit and jedtoolkit.org

The Dojo Foundation and Future

I’m excited that The Jed Toolkit has been accepted into the Dojo Foundation so its users can be sure that it will be a safe, unencumbered resource for them into the future. I’m extremely happy to be part of a family that includes require.js, sizzle, and the dojo toolkit.

After being tasked with internationalizing a large application that I was building I quickly realized that there was little available for JavaScript developers. I had been using Gettext in a python application a few weeks prior, and decided it might be nice to implement in JavaScript. So I did. I called it “Jed” (soon to be gettext2.js) after Jed Schmidt, everybody’s favorite “hobbyist” JavaScripter / Japanese translator.

I was drawn to this problem because there were so few people considering its intricacies, but I was shown by some very smart folks that there was a lot more to internationalization than the little library I wrote. So I wrote another library, and ported a few others.

I was quite happy with how these were turning out. They weren’t especially hard to create, because most of them follow well-documented specifications. I really liked how ICU MessageFormat made a lot of decisions based on how translators think, instead of how programmers think. But naturally, they locked away that goodness behind a syntax/grammar that no non-programmer should ever have to deal with. MessageFormat is great for translations but not for translators. Not in the real world at least. That’s when I realized that the problem was not (only) the tools for writing international apps, but even deeper: in the tools and integration with translators.

It’s all about tools

The translation space hasn’t grown much since computers first existed. We can barely encode files correctly in 2012. However, in other spaces, like content authoring, we have a whole system of tools and integrations to map non-technical users’ intent to structured usable data for consumption. If your local tech writer wants to start a blog, they can! They don’t need to know how to set up a server or that HTML even exists.

The process of getting an app translated is cumbersome, and is a blocker to getting good applications out there. FTP zips and crazy XML specs mixed with Word Documents rule the landscape. There are no decent apis, or automatic integrations that anybody is using at scale. I want to set out to change this.

Translators aren’t all to blame. If you were a translator and got the message “fair”, would you translate it as a carnival, or as ‘just’? We set our translators up for failure with our context. We can do better. We can describe messages, and their variables. We can offer examples and photos of the context. We can even translate the app in real time and they can see their translation literally running in the place it will live.

The goal of the Jed I18n Toolkit is to help make the internationalization process much more accurate and enjoyable for all parties. We should be able to write our messages directly in our templates in whatever format we think is best. Our messages should be automatically culled, and deduped and sent into a translation queue. The translator shouldn’t be presented with anything other than things that help them translate. The programmer’s format should be irrelevant. Context is king, and a bunch of crazy sprintf characters and html are just noise. When the translations are done, they should exist as a service or api and be updated in real time. Gone should be the days of the 2 month translation code freeze. You should be able to write a post commit hook that gets your translations through the system as fast as you can find someone to translate them.

There’s a lot to decide on how to bring all of these ideas into the project in a generic, but still usable way, and it will take some time to get everything right. Right now I’m starting by putting in the few open source projects that are already out there as well as showing early beta work on some of the integration tools. Please be patient with me and send me your suggestions and frustrations so we can finally bring internationalization out of the dark ages.

The slides are available (likely in webkit) at: alexsexton.com/talks/thirdparty

I can’t thank Logan enough for doing Austin Tech Videos. It’s a treasure trove of all kinds of talks from around town.

Performance Matters

Our core applications were built nearly 7 years ago, and gained features everyday over that period of time. As you can imagine, performance started to suffer. Since we’re on the product page of major retailers, we knew that this wouldn’t stand. I was tasked with re-thinking our solution with performance at the forefront of our architectural and deployment strategies. I attacked three different types of performance at varying levels of depth.

• Network
• Injection/Rendering
• Application

Bazaarvoice has a developer blog that I sometimes write for, so I wrote an article on Third Party Front-end Performance. Normally I don’t just link across, but I think this information is actually fairly applicable to a large chunk of developers. So check it out. Feel free to comment either place. Part 2 and 3 to come.

Web programming is the science of coming up with increasingly complicated ways of concatenating strings.

I think that there’s a good reason for this.

As we turn to the next chapter of the web and start building more web applications, rather than just web documents, we begin to need to mix language with data. This presents an extremely difficult challenge if you only have to consider a single language. Often times we have to support many.

While the data density in language increases on our sites and apps, we must consider the user who has to read those sentences. The goal is to offer interesting data to the user without just generating a table and without sounding like Borat writes the copy. You can spend as much time as you’d like on the interaction and visual design, but if your app doesn’t have a good flow, you’re leaving the most important cards on the table: the content.

Let’s Focus on English for a Second

Number of Results: 15

in Number of Categories: 3

This is the type of language that we’ve all come to expect out of the web. It gets the point across, but I’d argue that it’s not very personal or natural. That may not matter in this particular example, but consider building anything social. Identity is becoming a huge part of the next wave of apps. If you want to have any chance at personalization or identity, then the following isn’t going to cut it:

Alex added 5 friend(s) to their group on March 19, 2012

This is in stark contrast to some of the more popular social networks.

Not only does this correctly address the correct pluralization for ‘people’, it also takes into consideration the offset from the total count of the 3 people that are listed explicitly. This attention to detail doesn’t stop at decent pluralization, but also gender.

Remember the old days when Facebook used to refer to everyone as a ‘their’? That was weird. Don’t fall into that trap. When it comes to good user experience, you can’t ignore the text. If you can go through your app and find any sentence that you’d write differently if it wasn’t generated by a computer, you are reducing the effectiveness of that text and degrading the overall experience.

Iteration

Assuming you’re sold on the idea of a proper language treatment of your app, let’s try to solve the problem using some of the examples we’ve already seen.

There are X result(s)

In JavaScript, the naïve solution would be to do something like the following:

1
2
3
4
5
6

if ( X === 1 ) {
  return "There is one result";
}
else {
  return "There are " + X + " results";
}

This results in a proper english sentence in all cases. That’s great, but let’s get a touch more complex. Now we want to support another language. The pluralization rules for English are different than the rules for French. If we want to support French, our solution starts looking more like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

if ( lang === "en" ) {
  if ( X === 1 ) {
    return "There is one result";
  }
  else {
    return "There are " + X + " results";
  }
}
else if ( lang === "fr" ) {
  if ( X > 1 ) {
    return "Le, there are " + X + " results";
  }
  else {
    return "Le, there is " + X + " result";
  }
}

This quickly becomes an unscalable solution. You might be thinking “Well, Alex, I never plan on internationalizing my app, so the rest of this article doesn’t apply to me.” – I’d encourage you to consider the original example as a more pleasant English-only sentence:

There are 8 results in 2 categories.

Even when ignoring locale, we still have some combinatoric debts to pay. Let’s check out the code for handling this naïvely:

1
2
3
4
5
6
7
8
9
10
11
12

if ( ResCount !== 1 && CatCount !== 1 ) {
  return "There are " + ResCount + " results in " + CatCount + " categories.";
}
else if ( ResCount === 1 && CatCount !== 1 ) {
  return "There is one result in " + CatCount + " categories.";
}
else if ( ResCount !== 1 && CatCount === 1 ) {
  return "There are " + ResCount + " results in one category.";
}
else if ( ResCount === 1 && CatCount === 1 ) {
  return "There is one result in one category.";
}

This is pretty painstaking even without the chore of translating it into other languages. You cannot split up the halves of the sentences safely (especially if you want multiple languages), because the two halves may not match. You can imagine that when gender is added to this sentence, things explode even further.

Alex searched for an image. He found 5 results in one category.

Now we have to multiply that logic times the number of gender choices. Most specs have 3 gender choices: “male”, “female”, and “other”. “Other” specifically is treated “as if you cannot determine the gender of someone who is far away from you.” In the case of this simple sentence, we’d need twelve copies of the sentence – one for each combination of gender and plural form of the nouns.

Gettext (jed)

I recently released a library, Jed, for using Gettext style messages in JavaScript. Gettext is a GNU spec that’s been around for ages. I had been exposed to a little bit of Gettext from my python days, and considered it to be the most popular solution to many of these problems. The main feature of Gettext is that you can decouple the messages from the plural-forms of a given language.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var pluralForms = {
  "en" : function ( x ) {
    if ( x === 1 ) {
      return 0;
    }
    return 1;
  },
  "fr" : function ( x ) {
    if ( x > 1 ) {
      return 1;
    }
    return 0;
  }
};

We now get back an index of sorts. “Gettext” refers to the lookup/loading/encoding mechanism more than anything, but with these plural forms we could do a lookup for the correct string, stored as data.

1
2
3
4
5
6
7
8
9
10
11

var translations = {
  "en" : {
    "somekey" : [ "There is one result.", "There are %s results." ]
  }
  "fr" : {
    "somekey" : [ "Le, there is %s result.", "Le, there are %s results." ]
  }
}

var lang = "en";
var msg = sprintf( translations[ lang ][ "somekey" ][ pluralForms[ lang ]( X ) ], X );

In this case we’re using sprintf style replacement after we do the key lookup. That tends to be the most common way to do substitution with Gettext. Now we have a solution that relies on data instead of one-off code blocks for each message. Also, if your sprintf supports positional variables, you can now solve the problem that different languages order sentences differently than english does.

Soon after I released Jed it was shared on es-discuss. Immediately Norbert Lindenberg stepped up to tell me that I was making a mistake by choosing Gettext. How right he was. The best example of my oversight is actually one that we’ve already seen:

There are 8 results in 2 categories

How would we represent this in Gettext’s PO format? The plural-form functions can only take a single number to decide the plural form. This sentence would need to be split up again, which won’t work across languages and often won’t work well even in English. Gender can be added in by utlizing Gettext’s context feature, but it only goes one level deep. What if I needed an actual context AND a gender selection?

Norbert was kind enough to point me in the direction of the ICU MessageFormat spec. I could quickly see that some smart people had thought about this a lot longer than I had. Using Jed for Gettext can still be nice if you already have invested in using Gettext in other parts of your stack, but I’d generally suggest against it in favor of MessageFormat.

ICU MessageFormat

MessageFormat is actually just a few specs pasted together, but they look similar. They may seem vaguely familiar to those who have ever used Java’s ChoiceFormat utility. They are different in a few ways, but the important part is that they more or less solve multiple plurals and gender specificity without as much of the combinatorics game.

The MessageFormat spec contains PluralFormat and SelectFormat in the most common cases. Using the syntax in PluralFormat we can address multiple plurals in the same sentence. All the pluralization data is standardized and pulled from CLDR and not needed as user input. There are keywords that come back as a result for any given input number: “zero”, “one”, “two”, “few”, “many”, “other”. All languages can be roughly mapped to these keywords, and it is the basis for some of the keywords in the message.

I won’t go in to much detail about the syntax, as that’s not the point of this post.

PluralFormat

1
2
3
4
5
6
7

There {ResCount, plural,
        one {is one result}
        other {are # results}
      } in {CatCount, plural,
        one {one category}
        other {# categories}
      }.

Using PluralFormat we were able to decouple the pluralization of each of the nouns.

SelectFormat

Gender is usually handled via SelectFormat which works much like a switch statement (except default becomes other).

1
2
3
4
5
6
7
8
9
10
11

{GENDER, select,
  male {He}
  female {She}
  other {They}
} just found {ResCount, plural,
        one {one result}
        other {# results}
      } in {CatCount, plural,
        one {one category}
        other {# categories}
      }.

At the top we are able to determine the gender to use and then reuse most of our code from above to have a multiple plural and gender-specific sentence in as few characters as possible. Exceedingly complex sentences can often still require nesting and combinatorics, but for the majority of cases, you can avoid repeating any logic.

There are also complex ‘plugins’ that can be used. The offset option will help you generate sentences like in the google plus example earlier.

NumberFormat

Technically, I don’t think NumberFormat is part of MessageFormat – but it is usually necessary to pull in. NumberFormat allows you to internationalize things that we haven’t even covered yet. Ever consider that other countries use , characters where the US uses . and visa versa? Number format is how you handle numbers, percentages, and currencies across languages.

1
2
3
4

1234.5       //Decimal number
$1234.50     //U.S. currency
1.234,57€    //German currency
123457%      //Percent

Tools

messageformat.js

Shortly after releasing Jed, I released messageformat.js. It’s a much less sexy name, but perhaps I’ll fix that soon. Google also has an implementation for people using the Google Closure library: http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/i18n/messageformat.js.

While both are likely to be sufficiently fast, I did implement messageformat.js as a compile to JS language. This means that at build time, you can ‘precompile’ your messages and ditch the majority of the library. This creates some great opportunities to be able to include MessageFormat style strings directly inside of your precompilable templates and have it all compile to a series of string concats. The readme on the project page should be quite helpful to learn the syntax as well as the integration and api.

numberformat.js

My co-worker Oliver Wong was able to do a quick port of the Google Closure NumberFormat.js to not need Google Closure (under Apache 2).

EDIT: moment.js

If anyone was wondering how I handle dates in my JS apps, I figured I’d add it here. Moment.js, by Tim Wood is a library that I lean on a lot. There are plenty of additional internationalization libraries that I could start adding (for collation and rtl, etc), but for right now, the built in localization, and friendly ago syntax of moment.js make for a great user experience around dates.

All Together Now

I plan on updating Jed to actually contain this group of tools rather than the Gettext ones. I think these tools better suit the needs of modern applications. I will certainly keep the old Jed (Gettext) code around for those that require that format. It’s not terribly difficult to integrate with these tools separately now, though.

Conclusion

Language is important. It can get complex. A lot of incredibly bright people have been looking into the constraints of same-language message generation, as well as multi-langual message generation (the spec writers, not necessarily the library creators). These tools and/or ideas should be the starting point of any application that desires to have a good UX.

It doesn’t matter how many drop-shadows or rounded-corners you have, the user shouldn’t have to decode your words. The words are often the most valuable experience.

I recently had some in-depth discussions with Tom Dale who wrote a pretty popular article against AMD. Tom is a good friend and I respect all of his opinions. I wouldn’t say that he’s since ‘come around’ on the AMD issue, though I may have worn his desire to fight against it. I’ll take what I can get. His business partner and all-around web-tech badboy Yehuda Katz remains less convinced and sent me a few questions that he wanted answered. I won’t add them here verbatim, but I’ll try and touch on a lot of that stuff as well. I think we more or less agree these days (but he by no means necessarily endorses what I’m writing here). I’ll explain.

I’m going to opt to try and not rehash the great responses to Tom’s concerns by James, Dave, and Miller.

AMD is not a script loader

This misconception is likely propagated by the fact that RequireJS shows up on all of the script loader shootouts. I have written most of my thoughts on this already in my most popular (read: only) Quora answer: What are the use cases for RequireJS vs Yepnope vs LABjs. I’ll mostly just leave it at this: Script loading is a means in which AMD/RequireJS meets their requirements. It’s neither a focus of the project or an integral part to using AMD in production.

AMD makes async loading possible, not required

I often hear that people don’t have an interest in asynchronous modules. This is perfectly fine. There are tons of integrated systems in full stack web frameworks that do a lot of great things for preprocessing that just don’t require asynchronous script loading to be great.

AMD is also so other people can include your module asynchronously.

So if you have your app split up into modules via some preprocessor system, that’s fine, but if you’d like your code to be accessible to people who don’t run the exact same stack as you: AMD works everywhere.

So write all your code how you like it, and right before you release it on github, consider adding this:

1
2
3
4
5
6

if (typeof define === 'function' && define.amd) {
  define(function () {
    return TheModule;
  });
}
// Feel free to also leak the global and/or test for a CJS enironment.

And to take this a step further, I’d encourage the preprocessing systems to just process to AMD.

1
2
3
4
5
6
7

// Node style modules
var x = require('x');
var y = require('y');

var res = doSomething(x, y);

exports.module = res;

Instead of preprocessing this code to work on the web by just concatenating the globals in the correct order, why not just use AMD? It could easily be translated at preprocess time to:

1
2
3
4

define(['x','y'], function(x,y) {
  var res = doSomething(x, y);
  return res;
});

Now you have a module that anyone can pick up (and translate it into their own module format if they’d like).

The problem with using anyone else’s format is that AMD is the only format that is suited well for asynchronous loading. This is not important to one group of people, but it is important to a different group of people, and is a valid concern in web development. In this case, AMD is the inclusive module format.

As for ‘synchronous’ module loading with AMD, the api must use the asynchronous pattern, but if a module is already registered, the result is atomic. Not to mention that it’s perfectly valid to use the require('x'); syntax when you can be sure a module already exists. The syntax allows for asynchronous loading, but it doesn’t require you to load things that way.

If you don’t like parts about AMD, and prefer to preprocess, that’s fine. I would encourage you to process to AMD though. Much like JavaScript is a common compilation target, I’d like to see AMD become that as well, for modules. It won’t help when in 5 years every project handles modules with their own preprocessor format.

AMD requires preprocessing anyways, right?

Yep, but not until build time. Any sane user of RequireJS uses the amazing r.js build tool before pushing to production. So why not just preprocess on request and output “modules” in the correct order and wrap them in a big IIFE?

It would likely work, but in my opinion there is value in being able to develop directly out of a folder, with only static resources. It’s the reason that so many new developers are using LESS.js – just load the file and go. It doesn’t require you to install a watcher, or set up rails, or even learn how to install an additional whole programming language to your highly varied OS landscape. AMD works without all the stuff. It is a developer experience with immediate gratification.

Many people disagree with the sentiment that our tools should all be able to run on the client side in order to facilitate the idea that our web pages can run out of static directories. I definitely agree that there are tons of uses for preprocessors that run outside of the browser, but I don’t fundamentally agree that modules are part of the ‘just nice to have if you can figure out the watchers’ group of tools. Real modules are going into browsers soon, and I think they should be part of the first class citizen group of tools that we run in our browsers. Not to mention, if you do opt-in to using a pre-processor and you want someone else’s preprocessor to be able to understand your modules, you’ll have to agree on a standard compilation target anyways. What better than AMD?

Much of what James writes about in his posts are about how there are a few ‘meh’ things about AMD, but that it meets nearly every requirement of a module system better than any alternative. He doesn’t often mention AMD as a compilation target, but I think it solves everyone’s problems.

It’s not nearly as ‘complex’ as you think it is.

AMD is implemented by attaching a scriptloader to an object. Load something, store it in the object, if someone else asks for it, pull it back out. Much of the size in RequireJS is for other amazing features and developer tooling. You can switch out RequireJS in production with Almond – it is 857 bytes.

The other notion is that it’s a chore to write. If we ignore the fact that most modern code editors could easily store the boilerplate for you, I would argue that it’s actually less characters than not doing it. Also, (nearly) everyone who says this also complains that it forces them to nest their code an extra level, and then they turn around and immediately wrap all of their code in an IIFE.

1
2
3
4
5
6
7
8
9
10
11

// An IIFE for leakage. One level of nesting.
(function(){
  // require statement per dependency
  var x = require('path/x'),
        y = require('path/y'),
        z = require('path/z'),
        a = require('path/a');

  doStuff();
  exports.module = { ... }; // if you're doing more commonjs type stuff, not always
})(this);

Here’s the same AMD module:

1
2
3
4
5
6
7
8
9

require([
    'path/x',
    'path/y',
    'path/z',
    'path/a'
], function ( x, y, z, a ) {
  doStuff();
  return { ... };
});

~36% less to type, by my quick and dirty measure (stripping whitespace and counting chars). It can be even less if you don’t have any dependencies and just include a define at the end of your file like we did in a previous example.

Sure there’s a level of nesting, but it’s one that you’ll need to put there regardless of whether you’re using AMD or not. Sure that can be generated at request time, but so can the AMD callback function boilerplate.

Why not just polyfill ES6 Modules?

Well, first off, they’re not entirely baked. David Herman – the author of the original Module proposal – just posted a pretty delicious update for some ideas for a simpler and sweeter module syntax.

Secondly, I think it’s a great idea. As soon as the syntax settles back down I think we could all consider setting up preprocessors to allow for the syntax in the browser. This would require a request-time preprocessor because of the invalid nature of the syntax. So if you were able to run a preprocessor, then I think you should use the ES Harmony Module syntax. I think it should then compile to AMD, obviously, but you shouldn’t ever have to worry about it.

Quick RequireJS plug

I obviously like AMD a decent amount, but I also think RequireJS is a fantastic tool in my stack. The ‘plugin’ architecture is not incredibly well-documented, but it essentially acts as module middleware. My favorite application of this feature involves templates.

I use the pattern in my require-handlebars-plugin to great effect. Rather than require a precompiled template during dev mode, I simply prefix my module name, and the template compilation occurs before the callback is invoked.

1
2
3
4
5

// In a no template middleware world
require(['handlebars', 'text!someTemplate.hbs'], function ( Handlebars, strTemplate ) {
  var fnTemplate = Handlebars.compile( strTemplate );
  fnTemplate({"some": data});
});

This is also similar to the technique where templates are stored in type="script/tmpl" script tags and pulled in by their id. This means that if you want to compile your templates at build time, you need to fundamentally alter every location that retrieves a template.

With the hbs template plugin, this is handled for you.

1
2
3
4

// With require-handlebars-plugin
require(['hbs!someTemplate'], function ( fnTemplate ) {
  fnTemplate({"some":data});
});

During development, this loads the template in as text and precompiles it for you. At build time it automatically outputs a precompiled module that is concatenated into the build. This ability alone is like magic to me and I just wanted to tell everyone how much I like it.

Conclusion

You don’t have to like AMD more than whatever you use. It would be nice if we had a standard, compatible web module syntax though. I think AMD is the best-suited candidate for that role, and that the preprocessors should use AMD as a compilation target, rather than a direct competitor. Obviously it’s still cool if you just use it straight up, but that doesn’t need to happen for it to succeed.

The talk is pretty short :D

Breaking The Cross Domain Barrier from SlexAxton on Vimeo.

Breaking The Cross Domain Barrier from yayQuery on Vimeo.

The slides are available here: Breaking The Cross Domain Barrier

Sorry for the half-vid, and low quality, but I figured it was worth putting out there, as I’ve had a few requests for it and I’m running out of hard drive space. Perhaps with any pressure, I’d do a screencast.

Also, this was the day that I took two green nyquil pills thinking that GREEN meant DAY (for dayquill). So I may be a little more relaxed than normal. I’m sure the beer didn’t help either. I rather liked it, if I recall.

One of the most common examples of this situation happens with tabbed interfaces, and more specifically the jQuery UI Tab widget. You give it your group of divs and links to turn them into the tabs, but that code doesn’t run until domready. Before the dom is ready, you’re original content all shows on the page, then when the tab code runs, it gets hidden.

Please don’t set them to hidden in your CSS in order to stop this from happening. This hurts accessibility, SEO, and the laws of white-hat web development, because without JavaScrpt, this content can never be seen. Instead, try this little trick:

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

<style type="text/css">
/*
Obviously this is not a real class name, but here you would just
set all the elements you want to hide as display:none.
You should probably make this style whatever the JavaScript ends
up setting them to. That way you don't accidentally add weird styles.
*/
.stuffIDontWantToFlash {
  display:none;
}
</style>

<noscript>
<style type="text/css">
/*
Inside of this noscript block, show the elements, this should behow
you want it to look for people without JS - it could even be styled
totally different for them if you'd like to lay it out differently without
tabs...
*/
.stuffIDontWantToFlash {
  display:block;
}
</style>
</noscript>

So there. Now we’re using the noscript tag to conditionally override our CSS hiding of the elements. You can technically do this with link tags as well, but since you need to put the noscript version in a separate place than the original style (which can be anywhere), it’s probably not worth the extra http request. Just make sure the noscript override version runs after the initial setting. Cascading at it’s finest.

I know what 2 of you are thinking: “OMG Gross. This does not validate, because a style tag can’t be anywhere except in the head element” - well, you could put it in the head element, but that could be weird. In other words, I don’t really care. It works everywhere.

<3z

Alex

A bulleted list of things I learned at the meetup (other than how strong The Moff™ is in real life):

• Here were some slides for the night: http://3.ly/y2dd

• No date on the official release of the store but apparently “Coming soon”

• There will be a free and a pay model, but the pay model is only launching in the US (then other markets to follow)

• There will be a way to do billing monthly/yearly/onetime (paypal (“harder”, not sure of the specifics)/googlecheckout)

• There will be an API to see if the user really bought something

• 5% of your revenue is theirs, rest is yours (yay) (way better than 30% – wowy)

• Apps aren’t chrome specific. They say they’d love to make stuff work cross browser, but they are going a little bit different direction from W3C widget spec…

• Pay to install

• You install apps directly into the browser

• There will be a user-permission popup for (location, notifications, storage, etc)

• Open now… I guess this means you can build stuff that works as a chrome app already (but there’s no store)

————————-Second Half—————————–

• Apps different than websites (even though theyre both web)

• You CAN use flash/silverlight/java if you want, but they don’t auto install, so if the user doesn’t have them, you’re SOL

• Google hosted (if you want)

• If you go Google hosted, they are packaged (let’s get a spec for this going!), if not, just a URL and a manifest

I stopped taking notes at this point to actually build a chrome app. It was insanely easy, so I’m happy about that. Yay chrome apps. I’d love to see how these pan out. I don’t think it can work until they are cross-browser, etc, but half the fun of them is that if it’s a chrome app, it doesn’t have to work in FF, so you can use specific APIs… so it’s a tradeoff.

Aiight. Tried to keep that as informal as possible. Hope someone wanted this info!

Alex

here: On jQuery Large Applications and here: On Rolling Your Own.

Rebecca points out some huge holes in the jQuery-verse when it comes to large-application development, and gives her opinion on why she doesn’t think jQuery is ever a good fit for a large application. I disagree, and she’s successfully convinced me to write a post on why I think what I do, so here we are.

Also, please, no one point out that I prefer Django over Pylons, which is essentially the same argument :D . The difference, though, is that I think Pylons is awesome, and that people should totally be using it for large applications on the backend, as long as they prefer it!

First, I will start by mentioning that I have written several large applications using jQuery, and that I think that from a ‘framework’ perspective, something like Dojo (which Rebecca supports) or YUI3 serves as a much better core to a large application than jQuery. However, arguing that ‘you shouldn’t use jQuery in your large application’ is an entirely different topic. jQuery does not describe or prevent any framework of application development, so you are free to choose your own to suit your needs. I do not advocate the incorrect use of jQuery as the core of your application. I do advocate JavaScript at the core of your application, though.

jQuery is a tool (lolz)

I build large applications that use jQuery. I don’t build large applications on top of jQuery. This incredibly important distinction hasn’t been very well clarified thus far in the conversation. I think it’s a fair ambiguity, however, because while it’s possible to use jQuery in well-structured ways, it’s certainly the road less travelled. The ‘common jquery user’ tends to throw everything onto the jQuery namespace, and pull in everything as plugins, and generally very tightly couple their applications to jQuery. I think the distinction is still important for the argument, because it doesn’t rule out the fact that you can write some really nice applications using jQuery.

It’s not jQuery, it’s you.

I think the thought that people are incapable of using jQuery in this manner stems from quite a few bad consulting experiences with companies using jQuery for no reason other than the fact that it’s the cool thing to do, but using it entirely in an entirely backwards manner. This is also not a good way of making library decisions (at least in the long term). It doesn’t reflect poorly on the code in jQuery so much as it reflects poorly on either the messaging from the jQuery team, or just the general population’s inability to write good code and tendency to do what’s popular. However, if Dojo were the hip-cool-designer library, they would suffer from the exact same problem.

Any library, in the hands of people who don’t know what they’re doing (even FuseJS), will not serve the needs of the application. This is a reality for anything that becomes popular. It’s easy to like Dojo for the quality of code that comes out of it, but that’s because the significantly less amount of people who use it are really good JavaScript Developers. That’s important.

Being a good JavaScript developer before you start writing your application is the key to building good large applications. It’s not what library you use. This is why I write about inheritance in JavaScript for the majority of my large jQuery apps articles. It’s the JS people need to learn. In fact, I’d imagine there’d be some insanely backwards code from people using Dojo who didn’t know what they were doing. You have to remain level-headed, though, and try to evaluate the tools without bringing in your past experiences with other developers. You can certainly choose Dojo to get away from jQuery noobs, but recommending Dojo to jQuery noobs is just bringing your problem along with you.

Roll it.

Aiight, with all that out of the way (yikes), let me give my most objective reasoning possible for why I think it’s ok to use jQuery in a large app. Please keep in mind that I’m not advocating against Dojo or YUI3, I’m advocating against the absolute notion that ‘jQuery should never be used for large applications.’ Use what you prefer, of course.

Rebecca’s core argument against rolling your own jQuery large app is that 1) no one else knows your code-base, so supporting is harder, and 2) the solutions in a library like Dojo are built to work together by smart people who have thought long and hard about the problems, and rolling your own are more fragile and can cause issues with upgrade paths and compatibility, etc. These are valid points, but I think they are painted with a narrow frame of reference for the type of app structure you might use in a large jQuery app.

It’s common knowledge that a separation of concerns is key to any large application. Loose-coupling is something that I’ve blogged extensively about in the past. If you have a problem updating a portion of your application, it’s because you wrote it too coupled. This is not unique to jQuery. Dojo’s API stays about as backwards-compatible as they come (seriously), but that doesn’t mean your old code will just work. In fact one of the few experiences I’ve had with DojoX code is that some of the less popular DojoX modules often need changes to return the correct values, or not throw errors. The core of the library, has been significantly more impressive in regards to this, but we’re talking about code that you write, not the library core.  I am a fan of Dojo’s backwards compatibility efforts over jQuery’s. Changing an API in a point release isn’t always the most friendly change for devs.

Her list of requirements for a large app is well considered. It is a comprehensive list of things that often come in handy when building a large application. All of these things have been answered by smart people, in the JavaScript community. Much like her example with templating, you can decide which pieces to use (except, directly, not with library specific code…). Instead of overriding Dojo.templated you just change out the contents of your template rendering function with the new one. If you correctly loosely-coupled your application, then ‘yay’, you switched out a part of your app in less lines of code!

Here’s the list of things that she’d expect from a framework, along with the appropriate solutions I’d consider:

• DOM manipulation tools - jQuery core
• Ajax tools - jQuery core
• A dependency management and build system - RequireJS
• Clear patterns for code organization, such as namespaced modules - The module pattern and a few object literals
• An inheritance system, preferably one that offers multiple inheritance, for sharing code across modules and staying DRY - modules +$.extend
• A non-DOM-centric, loosely coupled API for communication between modules - pub/sub || custom events
• A widget system that makes use of the inheritance system, with lifecycle management (setup/teardown) and templating - $.fn + mustache/microtemplates
• A system for maintaining templates separate from JavaScript while interning them into the build to eliminate HTTP requests - <script “text/html”> + text!requirejsdependency
• A system for abstracting RESTful server communication - assumes you want REST - but $.ajax usually works anyways…
• For a UI-intensive project, a rich widget system pluggable to arbitrary data sources and designed with an easily-extended API - jQuery UI or ExtJS on jQuery
• For an enterprise project, a11y and i18n provisions, as well as clear patterns for file organization - jQuery UI has many of these, you can also build them in. Require dictates some directory structure.

These requests are pretty obviously skewed to someone who likes working in Dojo. They are all pretty awesome ways to do things, but to say that you needed the module pattern is to entirely overlook other very valid ways of structuring complex code. Of course Dojo offers ways to do things like event-oriented programming over object-oriented. The point here is that, if Dojo has answered every question, and jQuery and friends has also answered every question (perhaps not in the same place), it’s going to be just as hard to pick up the code base and figure out what’s going on. I could structure my Dojo app in a way that Rebecca doesn’t like, and use template overrides for template-languages that she despises, and I could tightly couple my dom elements and their attributes to my data, and it’d all be in beautiful Dojo. That Dojo has answered all the questions does not facilitate that you understood those answers or that you agree with them.

The positives

I somewhat reject the notion that using jQuery, Underscore, Require, Mustache, and the module pattern (as facilitated by Require) is “rolling your own.” Sure you piece them together, by choosing how you use them, but you do the exact same thing when you choose how you use the various parts of Dojo. I think that all of these tools are as strong as the Dojo alternatives. You can argue that you could use any of these tools with Dojo because it’s so flexible that you can put anything in, but then you can’t argue that ‘rolling your own’ is bad, because that’s what you just did. Either use Dojo, or agree that sometimes, it’s not that bad to pull in a different way of thinking, you can’t have it both ways.

jQuery normalizes things across browsers when you need it to, and serves as a mostly-fantastic way of doing dom-manip and ajax. If you use it according to it’s strengths, you still can choose some really strong software alongside it that was specifically designed to be awesome at what it does.

Underscore gives you a very solid utility library, much like you’d find in Dojo, and it’s extensible to boot. You can use it in two of the major paradigms natively, and it falls back to native implementations when it can. It’s hardly fragile, and it’s insanely easy to integrate into your project. It’s no worse or better than Dojo’s offering.

RequireJS is likely going to be used in Dojo 2.0 and James Burke, who wrote Require, also wrote most of the Dojo dependency management system. Require incorporates all the sweet stuff from Dojo, plus some really awesome future stuff coming from the CommonJS peeps. Some apps, though, don’t require a ton of dependency management. Single page apps are likely not going to be terribly dependency heavy, and if you want… you can leave out the dependency management system all-together, and still use your modules, just like you always wanted. You can switch it out for LabJS if you want speed too.

Templating was the example that Rebecca used to show that she could roll her own templating style in Dojo. She used mustache instead of the default Dojo offering. I can’t argue against that. I’m in favor of pulling together the correct tools for the job.

A lot of what is nice about Dojo, is it’s prescribed format for creating modules. There’s quite a bit of flexibility, but anyone who could understand the way that Dojo does this could easily understand some of the basic underlying patterns that it’s enhancing. I can use object.create and the module pattern to my hearts content to structure my app, and that’s not some ‘wild tangent’ that no one will ever be able to unravel. It’s a simple, and common pattern that you’d be required to understand to use the Dojo method. Sure there’s no prescribed way to exactly structure this, but that’s the case with the ‘extremely flexible’ Dojo offering as well.

I’m not advocating creating super complex alternatives to Dojo’s module structure. I think JavaScript offers a simple and flexible interface to creating and manipulating objects. I can choose which ever way I’d like. The module pattern is 2 pages of of text and code examples in The Good Parts. Just go read that.

TL;DR

Dojo is a fantastic library that I would encourage you to pick up and add to your skillset. jQuery can be a fantastic tool to use as well. “Rolling Your Own” application with good tools alongside jQuery is no harder to understand than a Dojo app, nor is it harder to support, and it’s likely more specific to your needs. The fragile part of your code isn’t in the tools you use, it’s in the code that you write around them.

I wish we’d focus less on whether jQuery or LibX was a good or bad choice for large applications, and focus on the fact that people who don’t know JavaScript are never going to write well-structured apps. Anyone who does understand the fundamental concepts behind JavaScript would be able to do it well with or without Dojo. Your language should provide your structure, and your toolkits should dictate your tools on top of that structure.

Learn JavaScript first. Then care about large apps. Then make a smart decision, according to your preferences, on which, if any, library you want to use.

-Slex

I am now a featured author on ScriptJunkie – a new website from Microsoft about front end development. Check out my post “Building and Maintaining Large JavaScript Applications”

I’ll likely cover a few more topics concerning large application structure in the future, both on my blog and on yayQuery and ScriptJunkie.

Also, TXJS happened. I’d suggest going to the totally awesome webpage and catching the slides and the speakerrate pages for all the talks to get caught up on how much awesomeness happened. Also, my fridge is still full of left over beer, so if you’re in town… beer.js at my place.

Superclassy Inheritance with Javascript - Alex Sexton - NCJS 02/20/10 from yayQuery on Vimeo.

<3z

By and large, when using jQuery, developers seem to forget the paradigms they learned for well structured code in other languages. This is likely due to the fact that jQuery is effectively neutral when it comes to your structural methodology or inheritance patterns, and therefore doesn’t push someone in any one direction. Many times in other libraries (See Dojo Declare/Provide/Require, or MooTools Class, etc.), a paradigm is used and exclusively offered, and then code generally ends up more uniform than the oh-so-common-massive-jquery-indented-chains that I’m sure you’ve seen .

I’m not going to necessarily suggest that you use any single inheritance pattern, as there are many options, and each makes sense for different people and different situations. I do however suggest that you know your options. There are a few good reads on the topic of Inheritance in javascript, and I would strongly suggest people read at least a bit of the following:

• Javascript: The Good Parts (Chapter 5) -Douglas Crockford
• Prototypal Inheritance in Javascript) -Douglas Crockford
• Object-Oriented Javascript -Stoyan Stefanov
• Javascript Override Patterns -Andrea Giammarchi
• Simple JavaScript Inheritance -John Resig

Choosing your form of modularity is an important step. If you come from a background of highly-classical inheritance (I learned Java in school, so…I know that world) then perhaps starting with a classical implementation is going to be your best choice. If you are trying to stay slim and do the things a little more in the “JavaScript way” (a term that means essentially nothing), then you might try to use prototypal inheritance. For my examples, any form of inheritance will at least work on most accounts.

I’ll jump straight to a code example of this technique in use, and then describe it’s setup and structure:

1
2

<!-- Just an empty div to begin with -->
<div id="mySpeaker"></div>

Then we’ll run our javascript:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$(function(){
  // Call a custom plugin for your object on a dom element
  $('#mySpeaker').speaker({'name': 'Alex'});

  // Have quick access to the actual speaker object
  var mySpeaker = $('#mySpeaker').data('speaker');

  // The interface of the object that you build can
  // wrap more complex dom manipulations that are
  // separated from actual program logic.
  mySpeaker.speak('I am a speaker.'); // Results in a dom update

  // This shows automatic access to correct element in the dom
});

And the html now looks more like this:

1
2
3
4

<div id="mySpeaker">
  <h1>Alex</h1>
  <p>I am a speaker.</p>
</div>

The key here is that we didn’t have to call something like $elem.append(‘Alex’) nor did we even have to consider what would happen when a speaker object was called with the speak() function. I consider this to be the key to modular development. This level of abstraction helps keep the how and the what separated (or “loosely coupled” – if you like buzzwords). The other thing that was important to note is that after we instantiate the plugin, we have a clear two-way path between our Object and our Dom Element – both have an easy way to immediately access the other. This is important, because we often have different points of entry to jump-start a routine, so being able to access the part that you need quickly and easily is important.

Implementing this technique is pretty simple, and should actually take less brain power to set up than traversing through the dom in your head to figure out a crazy chain.

Let’s start with the Speaker object.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

/**
 * Object Speaker
 * An object representing a person who speaks.
 */
var Speaker = {
  init: function(options, elem) {
    // Mix in the passed in options with the default options
    this.options = $.extend({},this.options,options);

    // Save the element reference, both as a jQuery
    // reference and a normal reference
    this.elem  = elem;
    this.$elem = $(elem);

    // Build the dom initial structure
    this._build();

    // return this so we can chain/use the bridge with less code.
    return this;
  },
  options: {
    name: "No name"
  },
  _build: function(){
    this.$elem.html('<h1>'+this.options.name+'</h1>');
  },
  speak: function(msg){
    // You have direct access to the associated and cached jQuery element
    this.$elem.append('<p>'+msg+'</p>');
  }
};

I use an object literal here which puts me in the Prototypal Inheritance camp, I believe, but this is just an easily digestible pattern.

As you can see, there are easy-to-read, small functions, that have a clear purpose. In our use of this pattern, we call api type methods like speak() but not necessarily an internal method (like _build). You can hide your internal functions either by naming convention (not really hiding them), or by using something like the module pattern. In our simple example, I have just added an underscore to the beginning of the function to indicate that it’s private.

Code that is organized like this is much easier to test and to change/read. This also allows you to change the way things function without changing the way that the Object api is used. For instance, we could change the speak method to alert the string instead of append it to the related element. We would have to change the internals of the speak function, but we could keep our call to it the same.

The bridge that we build is probably the most interesting part of this pattern. It’s a different approach than many of the popular plugins take (slightly different than jquery ui), but it has a few really great benefits.

The most simple way to do this is by hand:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// Make sure Object.create is available in the browser (for our prototypal inheritance)
// Courtesy of Papa Crockford
// Note this is not entirely equal to native Object.create, but compatible with our use-case
if (typeof Object.create !== 'function') {
    Object.create = function (o) {
        function F() {} // optionally move this outside the declaration and into a closure if you need more speed.
        F.prototype = o;
        return new F();
    };
}
(function($){
  // Start a plugin
  $.fn.speaker = function(options) {
    // Don't act on absent elements -via Paul Irish's advice
    if ( this.length ) {
      return this.each(function(){
        // Create a new speaker object via the Prototypal Object.create
        var mySpeaker = Object.create(Speaker);

        // Run the initialization function of the speaker
        mySpeaker.init(options, this); // `this` refers to the element

        // Save the instance of the speaker object in the element's data store
        $.data(this, 'speaker', mySpeaker);
      };
    }
  };
})(jQuery);

And that’s it!

Now you have separated the creation of the plugin from the actual code itself. You are using the plugin to attach objects (with any inheritance patten) to dom elements and visa versa, but the plugin itself is just the connection and initialization code. This means that we could generalize this process further. I first saw this from Scott Gonzalez (of the jQuery UI team) and his code later became the ‘widget factory’ in jQuery UI. I prefer to not pass strings into my plugins in order to call functions, but it’s a valid approach as some people would take issue with having to pull out the object each time they started with a dom element.

Here is some code that might get you started writing/using a ‘bridge’ function (bridge is what’s found now in jQuery UI 1.8) that can help you attach your general code with a given plugin (since writing that same initialization plugin code multiple times would get old and defeat the whole DRY principle that our inheritance model has hopefully provided). This code is mostly courtesy of Scott Gonzalez because I couldn’t think of a more stripped down elegant approach to this. I changed it to accept Objects instead of Constructor Functions because that works a little better with my example (prototypal inheritance). I also force it to call my init function in order to save myself an extra call. (This example shows Scott’s use of this method along with John Resig’s Simple-Inheritance implementation – also very cool.)

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

$.plugin = function(name, object) {
  $.fn[name] = function(options) {
                // optionally, you could test if options was a string
                // and use it to call a method name on the plugin instance.
      return this.each(function() {
          if ( ! $.data(this, name) ) {
              $.data(this, name, Object.create(object).init(options, this));
          }
      });
  };
};

// With the Speaker object, we could essentially do this:
$.plugin('speaker', Speaker);

// At this point we could do the following
$('#myDiv').speaker({name: "Alex"});

That’s about all there is to it. I’d encourage you to pick some pattern for your development that isn’t just inline chaining of jQuery function calls. This way of breaking up and organizing functionality in your code serves as a quick and easy jumping-off point for testing and modularity. It’s much easier to test the individual functions of a modular object than it is to write tests for a single-line chain of jQuery calls.

Also, I do get some feedback along the lines of “well, my code is not a plugin” – “this isn’t applicable to my code” – but I usually tend to disagree. The stigma that a jQuery plugin has to be for general consumption is flawed. I encourage you to use the plugin architecture if you are creating functionality based on a dom element selection. For instance, if you are adding an error notification system, it would be very easy to create a notification object that attaches to a div and has the methods required for notification directly attached to it, rather than having a function that merely hides and shows random dom elements.

I am doing a round up of performance on a lot of this inheritance usage and I should get to writing another entry on that soon, but from my early tests, using reasonable inheritance is generally not that expensive. If you are pushing the limits of CPUs and browser rendering, you might have to make some sacrifices, but for the general case, the instantiation hit of inherited objects is probably well worth your while.

I’d love to hear about the way you approach this problem.