Saturday, October 20, 2012

The 21st century belongs to JavaScript

This century is going to belong to the Chinese and to JavaScript. You should learn one or the other. In this post, I look at a good way to get started with JavaScript.

Let's face it, you probably need to give the chaos called your app's JavaScript code some order. If your app is in an entropic state, in a state of high disorder, you need to stabilise it. How can you possibly do that if you don't know any decent JavaScript patterns? You probably want to start using namespacing and modules, for a start. But how can you can do that if you don't know the basics of JavaScript functions?

Reading 'JavaScript Patterns' by Stoyan Stefanov, I realised there's too much stuff in here to remember. Too much. You have to write it down, blog it, or otherwise come up with some way of memorizing the information so that the book is actually useful to you. Obviously, using the patterns themselves in your code is the best way to learn something like this, but unless you have some functions that badly need currying and so on, it can be impractical to just start baking ideas from a book like this into your working code. So where do you start then?

Flickr photo
"DMP-FF005 CHINESE ARMY", by damopabe. The Chinese are going to rock the party hard in the 21st century, everyone knows this.


The chapter on functions is a good place. Javascript is object-oriented, but without classes, which seems a paradox if you mainly work in C# like I do. So, forget classes, and learn your functions if you want to learn Javascript.
In general, when you think of a function in JavaScript, think of an object, with the only special feature that this object is invokable, meaning it can be executed.
Reading this chapter, I was struck by how many different, but only slightly different, ways there were of doing the same thing: making a function. So how well do you know your Javascript terminology? What's this?
    alert("Who am I?");
That's right, it's a plain ol' function declaration. Specifically, an anonymous function declaration. If you had named it (because, let's face it, it's going to be difficult to use that declaration as it stands) by making the first line function MyFunction(){ then it would be a named function declaration. If you assign the function to a variable,
var myFunction = function(){
    alert("Who am I?");
then the whole thing forms a function expression, complete with semi-colon at the end. Since it's still unnamed, you probably know it better as an anonymous function. Now, going back to the first example, the "Who am I?" anonymous function declaration (see how I'm cunningly using repetition to drill the names of these functions, both function declarations and function expressions, into our memories?) seems to be inert and useless, except if you wrap it in () and put a () after it, in which case it stops being useless. In fact, in that case it takes immediate effect because - it should come as no surprise to find out - it becomes an immediate function.
    alert("I happen immediately");
What prompted me to pick up 'JavaScript Patterns' (it's actually an ebook but I feel in my heart that you can pick them up just the same) in the first place was the befuddlement I felt on my current project at the absolute effin' proliferation of JavaScript files: 3rd-party behemoths like jQuery and Modernizr, minnows like jQuery File Upload, and our own proprietary code. Cracking open some of the JS that the other guys in my team had written, I realised I had little idea what I was looking at much of the time. Like dark matter and dark energy, there's dark code. Bad neighbourhoods, I call them. Parts of the app you don't want to find yourself in. I mean I could see that there were a bunch of functions in a DateHelper file, for example, all doing sterling work like converting a day to a date and so on, but why they sometimes were created in an object literal, and sometimes using a constructor function I couldn't tell. What's that? Constructor function, you say?
var Thing = function(message){
    this.message = message;
    this.displayMessage = function(){
var myThing = new Thing("Note the *new* keyword");
Now, I'm not so artless as to believe that there's always great thought behind every piece of production code, especially - like I say - given that this is after all JavaScript we're talking about. But not knowing, at a high level (is this function part of another object? When does it run?) what you're dealing with puts you at a severe disadvantage. And so I decided on a top-down approach to start with - simply to learn what things looked like. Yes, you should learn everything, but you can't because you don't have enough time. So you have to start somewhere. I have any number of free ebooks available to me nowadays - I suppose most devs do too - but I'm realising that they're all useless unless I read them. And I can't read them all if I read them all.

In this post, I'm avoiding talking about how or why you'd use one type of function over another. Obviously, you can read 'JavaScript Patterns', or any number of books, sites, or posts to learn about that. That skill comes with experience, with recognising patterns, and knowing how and where to apply them. I'm talking about doing what you might do when learning astronomy, chess, or bird-watching. You start off by simply being able to identify the things you're looking at.

Now obviously, when it comes to programming, you're supposed to go deeper than crudely identifying objects based on a superficial recognition of coarse features. But this is Javascript we're talking about, people. No-one learns this stuff. Most "senior" developers I've met in the last few years, people who pride themselves on knowing arcane facts about C# and SQL Server, are just blue-arsed ignorance monkeys when it comes to the natural language of the browser, JavaScript. Why is that? No idea, it just is. They must think it's a "junior" language, beneath their dignity to learn. Who cares? And the usual disclaimer in these cases about including myself in that list applies here too, it should go without saying.

So, it might seem like there's not a lot to learn here - immediate functions, custom constructors vs object literals, a few other slight variations - and indeed there isn't. But without knowing those building blocks, the important patterns that you're going to need to learn soon like callback patterns or using Modules to structure your JS are going to expand away from you quicker than your ability to reign them in, until in the not-too-distant future their light will never be able to reach you, leaving you surrounded by an expanding sphere of obscurity. Much like the fate of this galaxy in fact.


  1. Using node.js forces you to learn some of these constructs properly, or some of your things just won't run when (or how) you think they will. Manning has an EAP book on it, definitely worth a read!

  2. Mehdi recommended this one to me:

    1. Yeah, that's on my list Craigles, behind the current one, Wrox ASP.NET MVC4 and stuff by Addy Osmani ... not enough hours!