Category Archives: Javascript

Modern Javascript Development:The arguments object, overloads and optional parameters

Reassign JavaScript Function Parameters In Reverse Order, Or Lose Your Params – In which Derek discovers that arguments object is a data structure with an identity crisis. πŸ˜‰

That’s just bad, and it’s not specific to node.js. You should use the short circuit in the || operator to assign default values to your parameters instead of relying on ordinal indexes in the args pseudo-array in my opinion.

Modern Javascript Development: constructors and objects

The premise that someone would pass in b and c but not a is also weird. But, whatever. It does cause a problem due to the weird nature of the arguments object The big gotcha here is that JavaScript doesn’t support overloads.

In most languages that do support overloads, you would just define two different functions. One that takes three arguments and one that takes two arguments. But that won’t work since JavaScript is interpreted top-down. The last function definition clobbers the previous definition. So in the Fiddle posted above, the two argument function is the only one that exists.

Derek is correct that the arguments object is funky. It’s an array, but not really an array. It only has a “length” property. But it doesn’t have any really useful methods like pop or push. So assigning the variables in reverse order does work, for the reason you would expect knowing that JavaScript is interpreted top-down. I think a better way would be to convert the arguments objec to a REAL LIVE BOY ARRAY and access the values from that.

It has the same effect, but in my opinion it’s a little easier to understand.

How do you start a new project with TDD?

Bobby Johnson (@NotMyself on Twitter) wrote a post detailing how and why he “tests reality” when he starts a new project and gives two examples of what he means.


'use strict';

var assert = require('assert');

exports.test_reality = function(test) {
    test.equals(true, true, 'true should still be true');


using NUnit.Framework;

namespace Simple.Data.SqliteTests
    public class RealityTests
        public void true_should_be_true()

At first glance, you look at those and think they are silly because all they are doing is testing that the test framework is working correctly. But Bobby has a different reason for including them.

So when I am setting up my basic project structure and automation, I like to have at least one unit test ready to run. This allows me to test the automation script and ensure failures in tests cause failures in builds. In .NET I want to confirm that the compilation step fails properly and the unit tests fail properly. In node.js, I want to ensure that linting errors fail as well as unit tests.

That’s a valid point, however this is more of a configuration test of your infrastructure. I personally wouldn’t write a test like this, I’d want the test to have some value before I committed it to the main repository or build/CI server. I strongly feel that developers should use the same build procedure on their desktops to build the application as they do on their CI server. IDE’s like Visual Studio abstract away the building of the application, so we often have to write scripts, rakefiles, psake files, whatever to do all the things that Visual Studio doesn’t do when it builds your application. Things like running the tests and reporting the results, building an installers or setting test/staging/production values in config files. I like to have a repeatable build system setup for projects I’m working on so I tend to re-use scripts or keep it really simple. Which means that I have confidence that I have configured the build script correctly so that it will work properly when I put it in my CI server. Which allows me to start focusing on the design of my application sooner.

Adding type annotations to JavaScript

A few people have mentioned that there is value in TypeScript for the developer to express his/her intent while writing code. e.g. “I want you to pass a string as the first parameter”. TypeScript, and ES6, do this by adding in an optional type annotation.

function foo (bar:string)

Given my assertion that the only way you gain any benefit from type checking is by writing ALL of your client code in TypeScript, what’s to stop us from adding that type annotation now? Take the TypeScript code from before and specify the type like so:

function foo(bar/*string*/) 

Ugly? Yes. But it has the benefit of being stripped out if you minify your JS before deployment while not requiring you to use a compiler and still communicates the intent.

Because really, isn’t type checking in JavaScript really just typO checking? πŸ˜‰

Review of Building Android apps using HTML, CSS, and JavaScript

This book is the Android counterpart of β€œBuilding iPhone apps using HTML, CSS, and JavaScript” and covers much of the same material. It explains how to mark up your HTML page to support the Android mobile browser, as well as covering some basic JavaScript, HTML, and CSS. It shows how to build and submit a native Android app using the Phonegap too.

One of the the aspects that I appreciated about this book was the focus on incorporating lttle touches in your web application that make the application feel more like an Android application. Chapter 2: Basic Styling includes a section on adding the Android look and feel and the chapter on Animation adds extra features. Noting that when Android users drill down into a list, the page slides off to the left. The book also includes sections on using client-side storage to allow your application to be used offline.

Building Android Apps with HTML, CSS, and JavaScript at O’Reilly.

Announcing Bootstrap – a simple JS library for loading scripts

I ran into a problem, more than once. The problem was, I needed to use a JavaScript library on only a few pages in a site. It didn’t make any sense to load the library on pages where it wasn’t being used, it just added to the page load time. So I had two options:

  1. Make sure that I only included the library on the pages that needed it. – This wouldn’t work very well because my users could create new pages based on my template. Some would need the library and some would not.
  2. Dynamically inject the script into the DOM only when I needed it from my JavaScript

Script tag injection is nothing new, it’s been around for a long time. Neither are dynamic script loaders. YUI has had one for years, renamed to “get” in YUI3, that I’ve used quite a few times. LabJS and Require.JS are both full featured, well supported script loaders and work great in a wider variety of use cases. NBL was recently updated.

So why did I bother making this one?

Well, it’s really not that hard to do for one thing. I love making micro-libraries like this. It has no external dependencies and the list of possible features I’d like to add is very short.

What I really wanted to do was be able to modify and existing script to dynamically load a script it was dependent on. I could see doing this in several different pages, so I put it in a library.

bootstrap("myLibrary.js", "ScriptTagId");



The road map looks a little bit like this.

  • Add a “script loaded” event or , more likely, allow a callback to be passed in and executed once the script has loaded.
  • Add the ability to dynamically load CSS files
  • make the “script tag id” parameter an optional parameter and auto-generate an ID if none is provided
  • Make a cool icon for the project

So, to summarize, this library is really simple. The code is easy to understand right now. I believe is releasing early and releasing often. I didn’t want the lack of features to stop me from releasing. πŸ˜‰

The code is licensed under the Apache 2.0 license.

Bootstrap on

How simple could it be? Lemme post the source code for you.

Copyright 2010 Scott Koon

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   See the License for the specific language governing permissions and
   limitations under the License.

var bootstrap = (function() {
        var bootstrap = function(scriptSrc, id) {
            var scriptTag = document.createElement("script");
            scriptTag.setAttribute("type", "text/javascript");
            scriptTag.setAttribute("charset", "utf-8");
            scriptTag.setAttribute("src", scriptSrc);
            scriptTag.setAttribute("id", id);
            var head = document.getElementsByTagName("head").item(0).appendChild(scriptTag);

        return (window.bootstrap = window.$b = bootstrap);

A third option for using jQuery templates

Dave Ward has a great post about defining jQuery templates. There’s a third method that he doesn’t mention in his post. The “embedd-and-grab/clone” method. I’ve used this method before for simple element cloning of templates.

<div id="templates">
    <div id="hello">
        <p>Hello, ${name}.</p>

We can create a div, or really any element you want, to hold our templates. What does this gain us? Well if we are using a design tool, we can see what the template will look like before we have to render it. That may make it easier for a designer on your project. We don’t have to make an AJAX call out to retrieve the external template, although Dave talks about how this really isn’t an issue if you have caching set up correctly on your server. And frankly, for the amount of bytes that are in a typical template I can’t imagine any successful AJAX request taking very long.

To use them, you simply grab the templates div and detach it from the DOM. If you assign the detached elements to a var, you can just use jQuery selectors to find the one you want to use. Because, remember most of the jQuery methods return the jQuery object itself.

var templates = ​$("#templates")​​​​​​​​​.detach();
$.tmpl(templates.find("#hello").text(), person);​​​

Why do you want to use the detach method rather than the remove method? The detach method removes the elements from the DOM but keeps any jQuery data associated with them intact. Meaning you can use the $.data() method to add data to your templates and access the data before you compile your templates.
Dave Ward points out that I need to use “tempates.find()” rather than the default selector method on the jQuery object. Noted and updated