This Week in JavaScript - 05 May 2014

Welcome to your weekly update of JavaScript news and goodies.

Programming (not strictly JavaScript related)
TDD is dead. Long live testing.
Monogamous TDD
Programming Sucks
7 simple steps to implementing a programming language
On Pull Requests

Functional JavaScript
Functional JavaScript, Part 1: Introduction
Understanding recursion in functional JavaScript programming
var functionName = function() {} vs function functionName() {}
Functional Programming in Javascript === Garbage
A lazy, functional Javascript library

Things that compile to JavaScript
TypeScript 1.0 Released and Open for Contributions
js2js - a revolutionary open-source compiler from JavaScript to JavaScript
.NET to TypeScript and JavaScript compiler
Elm - a functional language that compiles to HTML, CSS, and JavaScript.
A small strongly, statically typed language which compiles to Javascript

Learn stuff
JavaScript Promises … In Wicked Detail
Embular Part 1 - Comparing Ember and Angular
Creating defensive objects with ES6 proxies
Creating type-safe properties with ECMAScript 6 proxies
HTML5 apps can be just as speedy as native apps with the new Famo.us Javascript framework

Libraries, tools and resources
A javascript library for loading and unloading behavior based on environment conditions
A tidy repository of jQuery plugins
16 Best Online Tools for Testing Code Snippets
Free ebook: Programming Windows Store Apps with HTML, CSS, and JavaScript, Second Edition
Learn JavaScript in 60 minutes - thanks @John_Betong;

So what are your thoughts on the latest going-ons in the world of JavaScript? I’d be particularly interested to hear your thoughts on testing and the debate kicked off by DHH with his “TDD is dead” post. I mean, we’re all testing our code, right?

Please PM us if you have anything of interest for the next issue, and happy reading! - Paul & [URL=“http://www.sitepoint.com/forums/private.php?do=newpm&u=184222”]Pullo

I couldn’t find in var functionName = function() {} vs function functionName() {} where it covered the main reason for using ar functionName = function() {} (which I’d have expected to see near the top so I didn’t read all the way to the end).

Using var functionName = function() {} allows you to redefine the function - this is particularly useful when done from within the function itself.

There are a number of situations where you need to use feature sensing to detect which of two or more commands that the browser currently in use supports for providing particular functionality. Typically these will get run multiple times by a given visitor. Wrapping these tests inside a function and having the function rewrite itself means that you only need to test which variant the browser supports once. The function then rewrites itself to always use that variant for the subsequent calls without rerunning the test.

For example the following defines an addEvent function that will work in both JavaScript and JScript. The first time the function is called the function works out which of addEventListener (JavaScript) and attachEvent (JScript) that the browser supports and it rewrites the addEvent function so that it will always use the one that the browser supports without needing to restest which is supported. The code defines the addEvent function three times with different code for each. This is something that you can’t do using function functionName() {} and so if you want to use just one way consistently then you need to use var functionName = function() {} so that you can handle situations like this one.

var addEvent = function(ob, type, fn) {
if (window.addEventListener)
  addEvent = function(ob, type, fn ) {
    ob.addEventListener(type, fn, false );
  };
  else if (document.attachEvent)
    addEvent = function(ob, type, fn ) {
      var eProp = type + fn;
      ob['e'+eProp] = fn;
      ob[eProp] = function(){ob['e'+eProp]( window.event );};
      ob.attachEvent( 'on'+type, ob[eProp]);
    };
  else return;
addEvent(ob, type, fn);
};

addEvent(document.getElementById('myid'),
  'click',
  myfunction);
addEvent(document.getElementById('myid2'),
  'click',
  myfunction2);

I figured I’d paste the code in and give it a quick try, and it seemed to work fine for me.

function addEvent(ob, type, fn) {
    if (window.addEventListener) {
      addEvent = function(ob, type, fn) {
        console.log('addEventListener');
      };
    }
    else if (document.attachEvent) {
      addEvent = function(ob, type, fn) {
        console.log('attachEvent');
      };
    }
    else {
        // Exception?
        return;
    }

    addEvent(ob, type, fn);
};

addEvent();
addEvent();

Not that I’m a fan of a function rewriting itself to begin with.

So you now have one function functionName() {} but the other two are still functionName = function() {}

So where my code used one of the two ways consistently, yours uses one way for one call and the other way for the other two calls and so is jumbling the two ways together in the same code.

As I said - if you want to use one of the two approaches for all calls then var functionName = function() {} is the only one that can be used for all function definitions.

There are THREE definitions of the addEvent function in that code - not one.

Ahh. I suppose I misunderstood your post. I thought you were saying that a function declaration couldn’t be overwritten. But you were actually saying that you need a function expression to do the overwriting.

Although, turns out it’s nonetheless still possible to use only function declarations.

function addEvent(ob, type, fn) {
    function addEventListener(ob, type, fn) {
      console.log('addEventListener');
    };

    function attachEvent(ob, type, fn) {
      console.log('attachEvent');
    };

    if (window.addEventListener) {
        addEvent = addEventListener;
    }
    else if (document.attachEvent) {
        addEvent = attachEvent;
    }
    else {
        // Exception?
        return;
    }

    addEvent(ob, type, fn);
};

addEvent();
addEvent();

Not to say that there would ever be a real scenario where we had to choose between only expressions or only declarations.

That approach is still effectively using both ways of defining a function since addEvent = addEventListener; is still defining a function using an assignment.

Also that approach uses five statements that define functions instead of three.

I agree that there is no reason that you can’t use both ways in your code - as both of your examples show - my point was that if you want to use just one way consistently in your code then only one of the two allows you to do it.

Well… not really. It’s not defining a function. It’s assigning the reference of an already existing function.

I thought this was about what’s possible and what’s not. But nonetheless, you’re right.

So is - var functionName = function() {}

The function() {} part defines the function (anonymously) and then it is assigned to a variable.

addEvent = addEventListener; - does the same thing except that the function is defined separately from the assignment.

So I suppose both versions are just defining three functions just that last variant has an extra two local references in order to do the assignments.