Nerdworks Blogorama - Nerdspeak

IE9 web cast / Chennai Web Camps / OSI Days 2011

2011-11-24T04:09:03Z

It has been a somewhat hectic two weeks shuttling between Chennai and Bangalore for a bunch of stuff. As usual, I’ve been happily handing out promises about posting resources for my talks on my blog. Like candy. Turns out you’ve got to come good on them eventually. So here goes:

IE9 Web Cast on ECMAScript 5

Get the deck (there isn’t much in the deck but there it is for what its worth).
Get the JavaScript eval console I was showing off in the session.

Chennai Web Camps

All the resources for the web camps sessions are available here.

OSI Days 2011

Session on WebMatrix: Building a complete website within an hour
- Get the deck
- Get WebMatrix
Session on building cross browser HTML5 web apps
- Get the deck
- Get the demos

That’s all folks. Hope the sessions were useful. If you’ve got feedback on any of these, please feel free to leave a comment. If you want to be nasty and use dirty words, please email them to me.

Partial function application in JavaScript

2011-11-07T09:32:22Z

Partial function application is a functional programming technique that allows you to transform functions that take N parameters into functions that take a subset of N parameters. For example, say you have this fairly useless function:

function add(a, b) {
    return a + b;
}

Let’s say that for some reason we need a version of "add" that will always have the value 5 for the parameter "a". One way we might do it is like so:

function add5(b) {
    return add(5, b);
}

No black magic there. I was wondering if there might be some way that we can automate the process of generating functions with part of their arguments pre-bound. Here’s what I came up with:

function partialBind(f, context) {
    // arguments length MUST be greater than 2
    if(arguments.length <= 2) {
        // coz. what're you "partial binding" otherwise?!
        return null;
    }

    // convert args to array excluding param "f" and "context"
    var arrayProto = Array.prototype;
    var params = arrayProto.slice.call(arguments, 2, arguments.length);
    return function () {
        // append params passed to this function to "params"
        var args = params.slice(0, params.length);
        if (arguments.length > 0) {
            arrayProto.forEach.call(arguments, function (p) {
                args.push(p);
            });
        }

        // call the original function
        return f.apply(context, args);
    }
}

This function allows me to transform pretty much any function that takes at least 1 argument into a new function that takes a subset of the arguments. Transforming our "add" function into a single parameter version with "a" bound to 5 for instance, would now look like this:

var add5 = partialBind(add, null, 5);
var val = add5(10);
assert(val === 15);

Interestingly, "partialBind" allows us to compose argument binding to multiple levels. If we wanted to take our "add5" function and create another version that binds the second parameter to, say 20, then we can do this:

var add5_20 = partialBind(add5, null, 20);
var val = add5_20();
assert(val === 25);

Note that we are doing a partial bind of a function that is already a partial bind of another function. Turns out we can take this to as many levels as we want. The example given above is of course somewhat concocted because we could have achieved the same result with a single partial bind instead of doing it in two levels:

var add5_20 = partialBind(add, null, 5, 20);
var val = add5_20();
assert(val === 25);

All of this works because JavaScript supports closures. Pretty nifty don’t you think?

Web Camps, Virtual Tech Days and jsFoo

2011-10-17T05:28:01Z

So I’ve had a busy few weeks recently doing a bunch of sessions at Web Camps (in Delhi and Hyderabad), Virtual Tech Days and jsFoo. At each of those events I promised attendees that I’d put up the demos and the decks on my blog “soon”. Well, truth be told I’ve not been exactly conscientious about doing this quickly and I apologize for that. At any rate here’s the material for folks who came by for these sessions:

Web Camps

Bold and Beautiful with CSS3 – deck / demo
Spice it up - Advanced HTML5 – deck / demo

Folks who attended the Hyderabad event might remember that I used a HTML5/CSS3 version of the decks during the session. If you’d like a copy of that code then hang tight because I hope to put up a post here on how I built it and intend to share the source with that post.

Virtual Tech Days

Socket programming on the web – deck / demo
Threading and async programming on the web – deck / demo
Baking some HTML5 goodness into your ASP.NET apps – deck / demo

jsFoo

A primer on ECMAScript 5 – deck
Advanced JavaScript Techniques – deck
Best practices for building async apps with JavaScript – deck / demo

A number of jsFoo attendees requested that I share the “eval” console that I used to geek out on many of the advanced JS and ES5 samples during the session. I already have a post on that here:

http://bit.ly/js-eval

You should be able to download a copy for your own use from that post or use the online version if you prefer that.

On the HTML5 Indexed DB API - Part 4 of n

2011-09-08T03:51:02Z

So far we have looked at creating databases and adding data to them. Let's next take a look at retrieving records from the database. Surprisingly, this turns out to be a bit complex. The indexed DB way of enumerating records from an object store is to use a “cursor” object. A cursor can iterate over records from an underlying object store or an index. A cursor has the following key properties:

A range of records in either an index or an object store.
A source that references the index or object store that the cursor is iterating over.
A position indicating the current position of the cursor in the given range of records.

While the concept of a cursor is fairly straightforward, writing the code to actually iterate over an object store turns out to be somewhat tricky given the asynchronous nature of all the API calls. Let’s implement the listNotes method of our NotesStore object and see what the code looks like.

...
listNotes: function (callback) {
    var self = this,
        txn = self.db.transaction(null, TransactionMode.ReadOnly),
        notes = [],
        store = txn.objectStore(self.store_name);

    Utils.request(store.openCursor(), function (e) {
        var cursor = e.result,
            iterate = function () {
                Utils.request(cursor.move(), function (e2) {
                    // if "result" is true then we have data else
                    // we have reached end of line
                    if (e2.result) {
                        notes.push(cursor.value);

                        // recursively get next record
                        iterate();
                    }
                    else {
                        // we are done retrieving rows; invoke callback
                        txn.commit();
                        callback(notes);
                    }
                });
            };

        // set the ball rolling by calling iterate for the first row
        iterate();
    });
},
...

Let’s break this implementation down:

First we acquire a transaction object by calling the database object’s transaction method. Note that this time we are indicating that we require a “read-only” transaction.
Next we retrieve a reference to the object store via the objectStore method of the transaction object.
Then we issue an async call to the openCursor API on the object store. The tricky part here is that every single iteration over a record in the cursor is itself an async operation! To prevent the code from drowning in a sea of callbacks we define a local function called iterate to encapsulate the logic of iterating over every record in the cursor.
This iterate function makes an async call to the cursor object’s move method and recursively invokes itself again in the callback if it detects that there are more rows to be retrieved. Once all the rows in the cursor have been retrieved we finally invoke the callback method passed by the caller handing in the retrieved data as a parameter.

That’s it for today’s post. I’ll let you mull over this for a bit till the next post when we’ll cover some more scenarios.

On the HTML5 Indexed DB API - Part 3 of n

2011-09-06T00:43:56Z

In the previous post we covered some more background on working with the Indexed DB API and briefly reviewed the mechanics of creating a new database. In this post we take a look at some important Indexed DB constructs that one must be familiar with while working with the core APIs.

Object stores

Object stores are the indexed DB equivalent of "tables" from the relational database world. All data is stored inside object stores and serves as the primary unit of storage. A database can contain multiple object stores and each store is a collection of records. Each record is a simple key/value pair. Keys must uniquely identify a particular record and can be auto-generated. The records in an object store are automatically sorted in ascending order by keys. And finally, object stores can be created and deleted only under the context of "version change" transactions. We’ll see what a "version change" transaction is when we review transactions later on in this post.

Keys and Values

Each record in the object store is uniquely identified by a "key". Keys can be arrays, strings, dates or numbers. For the purpose of comparison, arrays are considered to be greater than strings which are greater than dates which in turn are considered to be greater than numbers. Keys can be "in-line" keys or not. By "in-line" we indicate to indexed DB that the key for a particular record is actually a part of the value object itself. In our notes store sample for instance, each note object has an id property which contains the unique identifier for a particular note. This is an example of an "in-line" key, i.e., the key is a part of the value object.

Whenever keys are "in-line", we must also specify a "key path", i.e. a string that signifies how the key value can be extracted from the value object. The key path for "note" objects for instance is the string "id" since the key can be extracted from note instances by accessing the "id" property. But this scheme allows for the key value to be stored at an arbitrary depth in the value object’s member hierarchy. Consider the following sample value object:

var product = {
  info: {
    name: "Towel",
    type: "Indispensable hitchhiker item",
  },
  identity: {
    server: {
      value: "T01"
    },
    client: {
      value: "TC01"
    },
  },
  price: "Priceless"
};

Here, the following key path might be used:

identity.client.value

Database versioning

Indexed DB databases have a version string associated with them. This can be used by web applications to determine whether the database on a particular client has the latest structure or not. This is useful when you make changes to your database’s data model and want to propagate those changes to existing clients who are on the previous version of your data model. You can simply change the version number for the new structure and check for it the next time the user runs your app and do the needful to upgrade the structure and migrate the data.

Version number changes must be performed under the context of a "version change" transaction. Before we talk about that though let’s quickly review what "transactions" are.

Transactions

Like relational databases, indexed DB also performs all of its I/O operations under the context of transactions. Transactions are created through connection objects and enable atomic, durable data access and mutation. There are two key attributes for transaction objects:

Scope

The scope determines which parts of the database can be affected through the transaction. This basically helps the indexed DB implementation determine what kind of isolation level to apply to objects during the lifetime of the transaction. You can think of the scope as simply being a list of object stores that will form a part of the transaction.
Mode

The transaction mode determines what kind of I/O operation is permitted in the transaction. The mode can be:
1. Read only
  
  Allows only "read" operations on the objects that are a part of the transaction’s scope.
2. Read/write
  
  Allows "read" and "write" operations on the objects that are a part of the transaction’s scope.
3. Version change
  
  The "version change" mode allows "read" and "write" operations and also allows the creation and deletion of object stores and indexes, i.e., the structure of the database can be modified only under the context of a "version change" transaction.
Transaction objects auto-commit themselves unless they have been explicitly aborted. Transaction objects expose events to notify clients of:
- when they complete
- when they abort and
- when they timeout

Creating the object store

Our notes store database will contain only a single object store to record the list of notes. As discussed earlier, object stores must be created under the context of a "version change" transaction. Let’s go ahead and extend the init method of the NotesStore object to include the creation of the object store. I’ve highlighted the changed bits in bold.

var NotesStore = {
    name: "notes-db",
    store_name: "notes-store",
    store_key_path: "id",
    db: null,
    ver: "1.0",
    init: function (callback) {
        var self = this;
        callback = callback || function () { };
        Utils.request(window.indexedDB.open("open", this.name), function (e) {
            self.db = e.result;

            // if the version of this db is not equal to
            // self.version then change the version
            if (self.db.version !== self.version) {
                Utils.request(self.db.setVersion(self.ver), function (e2) {
                    var txn = e2.result;

                    // create object store
                    self.db.createObjectStore(self.store_name,
                                              self.store_key_path,
                                              true);
                    txn.commit();
                    callback();
                });
            } else {
                callback();
            }
        });
    },
    …

Object stores are created by calling the createObjectStore method on the database object. The first parameter is the name of the object store. This is followed by the string identifying the key path and finally a Boolean flag indicating whether the key value should be auto-generated by the database when new records are added.

Adding data to object stores

New records can be added to an object store by calling the put method on the object store object. A reference to the object store instance can be retrieved through the transaction object. Let’s implement the addNote method of our NotesStore object and see how we can go about adding a new record:

    …
    addNote: function (text, tags, callback) {
        var self = this;
        callback = callback || function () { };
        var txn = self.db.transaction(null, TransactionMode.ReadWrite);
        var store = txn.objectStore(self.store_name);
        Utils.request(store.put({
            text: text,
            tags: tags
        }), function (e) {
            txn.commit();
            callback();
        });
    },

    …

This method can be broken down into the following steps:

Invoke the transaction method on the database object to start off a new transaction. The first parameter is the list of names of the object stores which are going to be a part of the transaction. Passing null causes all the object stores in the database to be a part of the scope. The second parameter indicates the transaction mode. This is basically a numeric constant which we have declared like so:
```
// IndexedDB transaction mode constants
var TransactionMode = {
    ReadWrite: 0,
    ReadOnly: 1,
    VersionChange: 2
};
```
Once the transaction has been created we acquire a reference to the object store in question through the transaction object’s objectStore method.
Once we have the object store handy, adding a new record is just a matter of issuing an asynchronous API call to the object store’s put method passing in the new object to be added to the store. Note that we do not pass a value for the id field of the new note object. Since we passed true for the auto-generate parameter while creating the object store, the indexed DB implementation should take care of automatically assigning a unique identifier for the new record.
Once the asynchronous put call completes successfully, we commit the transaction.

Coming up

In the next post, we’ll take a look at retrieving records from an indexed DB. Surprisingly, this turns out to be slightly trickier than what one might expect.

On the HTML5 Indexed DB API - Part 2 of n

2011-09-04T23:48:03Z

In the previous post in this series we covered the fundamentals of the Indexed DB specification. We continue the journey in this post and take a look at the API itself.

Building an offline note taking app

For the rest of this series of posts, we’ll try and build the client side data layer for a fictitious note taking web app. From a data model point of view it’s about as simple as it can get. The app allows users to write text notes and tag them with specific key words. Each note will have a unique identifier which will serve as its key and apart from the note text, it will be associated with a collection of tag strings. Here’s a sample note object represented in JavaScript object literal notation:

var note = {
      id: 1,
      text: "Note text.",
      tags: ["sample", "test"]
    };

We’ll build a NotesStore object that has the following interface:

var NotesStore = {
        init: function(callback) {
        },

        addNote: function(text, tags, callback) {
        },
    
        listNotes: function(callback) {
        }
    };

It should be fairly self-evident as to what each method does. All method calls execute asynchronously and where a result is to be returned to the caller, the interface accepts a reference to a callback that is to be invoked with the result. Let’s see what it takes to efficiently implement this object using an indexed database.

Testing for Indexed DB

The root object that you deal with when talking to the indexed DB API is called indexedDB. In fact you can check for the presence of this object to see whether the current browser supports indexed DB or not. Like so:

if(window[“indexedDB”] === undefined) {
      // nope, no indexed DB!
    } else {
      // yep, we’re good to go!
    }

Alternatively, you can use the Modernizr JavaScript library to test for support for indexed DB like so:

if(Modernizr.indexeddb) {
        // yep, go indexeddb!
    } else {
        // bleh! No joy!
    }

Asynchronous requests

The asynchronous API calls work through what are known as “request” objects. When an asynchronous API call is made, it would return a reference to a “request” object which exposes two events – onsuccess and onerror. The former is raised when the API executes successfully and the latter is raised when it errors out. Here’s what a typical call looks like:

var req = someAsyncCall();
    req.onsuccess = function() {
        // handle success case
    };
    req.onerror = function() {
        // handle error
    };

As you work with the indexedDB API you eventually get to a point where it becomes somewhat hard to keep track of all the callbacks. In a future post I’ll explore some ideas I am currently playing with on how we can simplify this further. For now though, to make our exploration of the API somewhat simpler I’ll define and use a small utility routine that abstracts the “request” pattern away:

var Utils = {
        errorHandler: function(cb) {
            return function(e) {
                if(cb) {
                    cb(e);
                } else {
                    throw e;
                }
            };
        },
    
        request: function (req, callback, err_callback) {
            if (callback) {
                req.onsuccess = function (e) {
                    callback(e);
                };
            }
            req.onerror = errorHandler(err_callback);
        }
    };

Now, I can write my async calls like so:

Utils.request(someAsyncCall(), function(e) {
        // handle completion of call
    });

Creating and opening the database

Creating/opening a database is done by calling the open method of the indexedDB object. Here’s an implementation of the NotesStore object’s init method:

var NotesStore = {
    name: “notes-db”,
    db: null,
    ver: “1.0”,
    init: function(callback) {
        var self = this;
        callback = callback || function () { };
        Utils.request(window.indexedDB.open(“open”, this.name), function(e) {
            self.db = e.result;
            callback();
        });
    },

    …

The open method opens the database if it already exists or creates a new one if not. The success callback of the request object returned by open receives an event object as a parameter whose result property is a reference to the newly opened database. You can think of this as the object that represents the connection to the database. When this object is destroyed (or if you called its close method) the connection to the database is terminated.

Coming up

Now that we have the database created, in the next post, we’ll go ahead and create the rest of the database objects.

On the HTML5 Indexed DB API – Part 1 of n

2011-09-03T21:40:34Z

Over the years the web has increasingly transformed from being just a repository of content to a marketplace of full-fledged functional applications. The suite of technologies that are bandied about these days under the “HTML5” banner have as a fundamental goal, the enablement of the building of this new breed of software. In this post (and over the next post or two) we review a technology that solves an important piece of the application puzzle – that of managing storage and retrieval of user specific data on the client side, called “Indexed DB”. For almost as long as the web has been around, there has been a need for web sites to track visitor specific information in one form or another. Using HTTP cookies has so far been pretty much the only standards based option available to web developers. While plug-in based alternatives in the form of Silverlight and Flash do exist, the typical challenges imposed on end users who either do not have the plug-in in question installed or are using the wrong version serves to complicate matters significantly. Let’s first briefly review what the available alternatives are for a web developer seeking to solve the problem of managing client side storage today:

HTTP Cookies

HTTP cookies allow web applications to store small amounts of textual data on the client side using specially crafted HTTP headers. Access to this data is provided via the browser DOM. JavaScript code must be used to parse and make sense of the data. While this works, there are significant challenges in working with cookies:

Cookies are not allowed to be greater than 4 KB in size.

Cookies are transmitted with every request that the browser makes – even when it is requesting for things like images, script files or style sheets.

The programming model is not straightforward in that it is basically just text and you need to write code to parse and crack data stored in cookies.

Only textual data can be stored and retrieved.

Plug-ins

Plug-ins have historically been the natural (if not the only) choice for web developers who have needs that are not catered to sufficiently by cookies. Technologies such as Silverlight, Flash and Google Gears come with their own brand of local storage options. While they are a better option as compared to cookies they do however present some unique challenges of their own:

As stated earlier, the primary issue is that user experience is less than stellar when you encounter cases where the user either does not have the plug-in in question installed or has the wrong version installed and must therefore upgrade. Often users are logged in to their computers with user accounts that do not have the required permission to install new software and hence are simply locked out of the web application or functionality completely.

Web developers must familiarize themselves with the specific tool stack associated with the plug-in.

DOM Storage

DOM storage is a part of the HTML5 suite of specifications and is meant to be a replacement for HTTP cookies. This is actually a viable client side storage option. The idea is to basically provide a key/value based storage API that allows web applications to store user specific data in a persistent manner. The API is simple to use and it just works! However, there are some limitations to how it can be put to use which are to a large extent deliberate and by design:

You can only store strings in DOM storage, i.e., both key and value must be JavaScript strings. You can however use JSON serialization to manage the storage and retrieval of objects.

Data stored in DOM storage is scoped by the domain, i.e., it will not be possible for code running in one domain to access DOM storage data stored under the context of a different domain. While this is a good thing, the limitation however is that it is not possible to scope this with a greater level of granularity – say by specific URLs within a domain.

There is no mechanism to iterate through all the data stored in DOM storage. You can only request the value for a specific key that you already know.

With that brief overview of the alternatives let us move on to the topic of this post – the Indexed Database API.

What is Indexed DB?

An Indexed DB is basically a persistent data store in the browser – a database on the client side. It defines an API that allows the storage and retrieval of key/value data. Like regular relational databases, it maintains indexes over the records it stores and developers use the Indexed DB JavaScript API to locate records by key or by looking up an index. Each database is scoped by “origin”, i.e. the domain of the site that creates the database. The database is transactional and provides a means for traversing the data in a deterministic order.

The Indexed DB API includes a synchronous and an asynchronous version of pretty much all the interfaces. The asynchronous API is meant to be used from web apps when you are interacting with the database directly from the UI thread where having an API call block on an I/O operation is not acceptable. All blocking calls work asynchronously and results are reported via callbacks. The synchronous API counterparts are identical to the asynchronous versions except for the fact that there are no callbacks and results are returned directly.

A word on the status of the spec

The Indexed DB specification is currently (i.e., when this post was written) in draft status and should not be considered as being production ready. The specification itself is under active development and developers are encouraged to review it only with the objective of familiarizing themselves with an up and coming standard. Do not use it in production sites yet!

Setting your development environment up

Before we proceed with the API itself, you might want to spend some time setting up your development environment up. For Internet Explorer (IE), an experimental implementation of the specification is available for download from Microsoft’s HTML5 Labs site. “HTML5 Labs” is an initiative from Microsoft for publishing prototype implementations of various key HTML5 specifications so that developers are able to experiment with them and provide feedback. The prototype implementation for Indexed DB works on Internet Explorer versions 8 and up and installing it is fairly straightforward.

Download the prototype by clicking on the link “Download the Protoype now!” from here.
Unzip the downloaded file.
If you are running a 32-bit version of Windows then run vcredist_x86.exe.
Register “sqlcejse40.dll” by running the following command from an elevated command prompt:

regsvr32 sqlcejse40.dll

If everything goes well, then you should see a screen such as the following:

Alternatively, get a recent version of Google Chrome or Firefox and you should be all set.

Coming up…

Now that we have the fundamentals covered, we’ll go ahead and get started with the API itself from the next post. Stay tuned!

On JavaScript code blocks, variable scope and variable hoisting

2011-09-02T22:50:07Z

I am currently reading the book JavaScript Patterns, by Stoyan Stefanov and I came across this interesting tidbit of information regarding variable scopes in JavaScript. Consider the following C++ code:

#include <iostream>

int main() {
  if(true) {
    int foo = 10;
  }

  std::cout<<foo;
  return 0;
}

Compiling this produces the following error:

scope.cpp(8) : error C2065: 'foo' : undeclared identifier

This is only to be expected. In C++, code blocks automatically define a variable scope, i.e., variables defined inside the code block are not visible outside of it. The same behavior can be observed in many of the other popular programming languages in use today such as C# and Java with one notable exception – JavaScript! Consider the following JavaScript snippet:

function scope() {
    if(true) {
        var foo = 10;
    }
    print(foo);
}

scope();

Interestingly, this prints the value “10”! What’s going on here? The first thing one needs to understand about JavaScript is the notion of “variable hoisting”. Regardless of where you have declared a variable, the runtime treats it as though it has been declared at the start of the scope. Here’s an example:

function hoist() {
    try {
        print(undeclaredVariable === undefined);
        print("Yep, was able to refer to 'undeclaredVariable'.");
    }
    catch(e) {
        print("Could not use 'undeclaredVariable'.");
    }
    
    try {
        print(declaredLater === undefined);
        print("Yep, was able to refer to 'declaredLater'.");
    }
    catch(e) {
        print("Could not use 'declaredLater'.");
    }
    
    var declaredLater = 10;
}

hoist();

Running this snippet produces the following output:

Could not use 'undeclaredVariable'.
true
Yep, was able to refer to 'declaredLater'.

In the function “hoist” we have declared a variable named “declaredLater” right at the end of the function body. Interestingly, while we were unable to refer to an undeclared variable (evidenced by the fact that the “print” statement inside the first “catch” block got executed) we seem to have no problems referring to “declaredLater” even before it is actually declared. This is so because the JavaScript runtime “hoists” all the local variables declared in the function to the top of the function. It is as though the function had been defined like so:

function hoist() {
    var declaredLater;

    // stuff here
    
    declaredLater = 10;
}

hoist();

Note that though the variable itself gets declared at the top of the function, the initialization still happens only on the line where it occurred in the original function - which explains why the statement print(undeclaredVariable === undefined) ends up printing true.

Now, why did our “scope” function work the way it did? Turns out that in JavaScript curly braces do not introduce a variable scope. Only functions do. This means that variables declared inside of “if”, “for”, “while” etc. behave as though they have been declared at the top of the function. The aforementioned book therefore recommends moving all variable declarations to the top of the function. So, instead of doing the following:

function foo() {
    var a = [1, 2, 3, 4];
    if(someCondition() === true) {
        var b, c, d;
        // do something with b, c, d
    }
    for(var i = 0; i < a.length ; ++i) {
        // do something with "a"
    }
}

Do something like the following:

function foo() {
    var a = [1, 2, 3, 4], b, c, d, i, len = a.length;

    if(someCondition() === true) {
        // do something with b, c, d
    }
    for(i = 0; i < len ; ++i) {
        // do something with "a"
    }
}

This makes it clear that the scope of the variables in question is the function “foo”.

The key takeaways therefore are the following:

Code blocks do not determine variable scope in JavaScript. Functions are the only construct that can be used to limit scope of variables.
Regardless of where variables are declared, the runtime always treats them as though they have been declared at the beginning of the function in question.
If you need some global code to be executed, then use an immediate function (also known as a “self-executing” function) to limit the scope of the local variables you use in that code. So instead of doing the following:
```
<script>
  var v1, v2;
  // some code here that uses v1 and v2
</script>
```
Use code like this:
```
<script>
  (function() {
      var v1, v2;
      // some code here that uses v1 and v2
  })();
</script>
```

JavaScript strict mode restrictions

2011-09-19T08:30:38Z

In the previous post we took a look at what strict mode was all about. Today we review some of the key restrictions that become applicable when strict mode is active.

Identifiers must be declared before they can be assigned to

This aspect in my opinion makes strict mode worthwhile all on its own even if there was nothing more to it. Undeclared variable assignments do not automatically get added as expando properties on the global object.
```
"use strict";
foo = 10; // ReferenceError: Variable undefined in strict mode
```
With this in place, the following snippet that I’d given in the first post under the “What is strict mode?” section will fail to run and throw a “ReferenceError” instead because of the typo in the variable name “product” in the assignment inside the “for” loop.
```
function findProduct(numbers) {
    "use strict";
    var product = 0,
        len = numbers.length;
    for(var i = 0; i < len; ++i) {
        prodct = product * numbers[i]; // ReferenceError: Variable undefined in strict mode
    }
    return product;
}
```
No automatic context for context-less function calls

Functions that are called without setting an explicit context do not automatically get the “global object” in “this”. Consider the following snippet:
```
function foo() {
    // prints “true”
    print(this === window);
}
foo();
```
Here, “foo” is being invoked without setting an explicit context object, i.e., we are not calling it like so:
```
foo.call({foo: "bar"});
```
In unrestricted mode this causes the context to be automatically initialized to the “global” object, which in browsers is the “window” object. Since the snippet above was running in unrestricted mode, the expression “this === window” evaluates to true. If we modify the function like so however, we see that “this” is no longer equal to “window”:
```
function foo() {
    "use strict";
    // prints “false”
    print(this === window);
}
foo();
```
Reserved keywords cannot be identifier names

Naming variables and functions as eval, arguments, implements, let, private, public, yield, interface, package, protected and static will cause errors.
```
"use strict";
var yield; // SyntaxError: Expected identifier
```
Violations of ES5 property configuration cause errors

Violations of the configuration as specified in the property descriptor for ES5 properties will cause errors to be thrown in strict mode instead of them being silently ignored. Here are some examples:
1. Writing to a non-writable property:
```
"use strict";
var person = Object.create({}, {
    name: {
        value: "foo",
        writable: false,
        configurable: true,
        enumerable: true
    }
});

// TypeError: Assignment to read only properties not allowed in 
// strict mode
person.name = "bar";
```
  Note the line highlighted in bold. Setting the “writable” property descriptor to “false” makes the “name” property of the “person” object read-only. Attempts to assign to this property will be silently ignored in unrestricted mode but causes a “TypeError” to be thrown in strict mode.
2. Changing configuration of a non-configurable property:
```
"use strict";
var person = Object.create({}, {
    name: {
        value: "foo",
        writable: false,
        configurable: false,
        enumerable: true
    }
});

// TypeError: Cannot redefine non-configurable property 'name'
Object.defineProperty(person, "name", {
    value: "bar",
    writable: true,
    configurable: true,
    enumerable: true
});
```
  Here we attempted to change the property descriptor on a non-configurable object. Again, an error that would have gone unnoticed in unrestricted mode results in a “TypeError” being thrown in strict mode.
Writing to read-only accessor properties

Writing to accessor properties that do not have a “setter” defined causes errors to be thrown instead of being silently ignored:
```
"use strict";
var person = Object.create({}, {
    name: {
        get: function() {
            return "foo";
        },
        configurable: false,
        enumerable: true
    }
});

// TypeError
person.name = "bar";
```
Here, “name” is an accessor property that does not have a “setter” method defined. Attempts to assign a value to this property results in an error in strict mode while being quietly ignored in unrestricted mode.

Cannot extend non-extensible objects

Extending a non-extensible object throws an error in strict mode instead of being silently ignored:

"use strict";
var person = {
    name: "foo"
};
Object.preventExtensions(person);

// TypeError: Cannot create property for a non-extensible object
person.age = 10;

Other sundry restrictions

There are a few other sundry restrictions for strict mode code which are perhaps somewhat less frequently used. I have briefly reviewed them below:
1. Numeric constants are no longer interpreted as having an octal base if you put a leading zero.
2. Variable/function instantiations in strict mode “eval” code occur in an environment that is local to the “eval” code and not in the environment of the calling code. This means that “eval” code cannot introduce new identifiers in the caller’s execution context/scope.
3. “arguments” is immutable, i.e., you cannot arbitrarily extend the “arguments” object by tacking on your own properties to it. Now why anyone would even want to do this is puzzling to me but it must have been happening often enough for Ecma to take the effort to specify that you can no longer do it in strict mode!
4. “arguments.callee” and “arguments.caller” are not available in strict functions. I cannot say that I am completely happy with this particular restriction!
5. Creating duplicate property definitions on an object is not allowed in strict mode code. The following snippet for instance, produces an error in strict mode:
```
"use strict";
var o = Object.create({}, {
    name: {
        value: "foo"
    },
    name: {
        value: "bar"
    }
});
```
  This code throws up a “SyntaxError” with the message, “Multiple definitions of a property not allowed in strict mode”. In unrestricted mode, “o.name” would have the value “bar”.
6. Calling “delete” on an ES5 property which has its “configurable” property set to “false” results in an error being thrown in strict mode. This is a variation on the restriction discussed in point 4 above.
7. The JavaScript “with” statement is not allowed in strict mode code.
8. It is not allowed to create functions with duplicate parameter names in strict mode. Again, it defies logic as to why anyone would want to do this but there it is!

Some best practices

Here are some things that you should perhaps consider while writing code that uses strict mode:

Given that “strict mode” is a fairly recent phenomenon, unless all your users have been conscientiously updating their favorite browser to a new version, chances are high that you will have some percentage of visitors to your web app who are running a JS engine that does not understand “strict mode”. This means that basically all of your code is going to run in unrestricted mode regardless of whether or not you’ve used the strict mode directive. It becomes important therefore to always test your code in unrestricted mode and make sure that everything is still peachy.
Now, even if a major chunk of your end users are on browsers that don’t support strict mode it still makes sense to use strict mode in your development environment because a large part of strict mode is about enforcing JavaScript development best practices and you can benefit from automated enforcement at least during development. Just make sure that you test everything in unrestricted mode before going live!
Enable strict mode in small increments instead of a one-shot quick fix. If you have a 3000 line JS file for instance, it is probably not wise to simply add the "use strict"; directive at the top of the file as the semantic differences between the two modes can potentially result in subtle unforeseen bugs. Do it in smaller chunks at a function level and certainly use it with abandon for new code that you write.

I’d encourage you to experiment and read up on strict mode. In my opinion, this is one of the best features introduced as part of ES5. Here are some resources that you are likely to find useful:

IE10 Platform Preview developer guide documentation on strict mode
Strict mode demo on IE test drive
Article on ES5 strict mode in Firefox 4 – has good information about strict mode in general
The venerable ES5 spec – doesn’t exactly make for exhilarating reading but nothing like quoting the spec to nail an argument!

With that we come to a close of the two part series on JavaScript strict mode. What do you folks think about this feature? Feel free to let me know what you think by leaving a comment.

On JavaScript strict mode

2011-09-19T08:26:37Z

ECMAScript version 5 is the latest revision of the ECMAScript programming language ratified for widespread adoption by Ecma International – the standards body responsible for figuring out what goes into the language. If you’re wondering what exactly ECMAScript is and why you should be interested, it turns out that ECMAScript is standardese for a language that the rest of the world knows as JavaScript. Strictly speaking (no pun on title intended) JavaScript and ECMAScript aren’t identical. JavaScript is a dialect of ECMAScript but the differences are mostly negligible and are largely there for historical backward compatibility reasons. ECMAScript 5 (henceforth referred to as ES5) brings a suite of interesting features to the table, many of which have as their goal, the introduction of greater programming discipline to the language.

In this post (and over the next few posts), we review one such feature which directly addresses some of the more notorious parts of the language. This new feature is known as “strict mode”, which briefly, is a whole new execution mode for JavaScript that causes the execution engine to run code with slightly different semantics.

What is strict mode?

“Strict mode” is a way of causing the runtime engine to interpret and execute JavaScript with different semantics than what one sees with unrestricted code. Code running in strict mode has the following characteristics:

Excludes some syntactic and semantic features, i.e., you can’t do some things that you are allowed to do otherwise
Modifies semantics of some features, i.e., same code runs differently in strict mode compared to what happens in unrestricted mode
An expanded list of scenarios that cause errors to be raised instead of them being silently ignored or running with assumed intent
Applies to specific code units – i.e., you cannot have strict mode apply to all your .js files at one shot (unless you concatenate all of them of course, in which case its one code unit as far as the runtime is concerned)

The basic rationale behind strict mode is the introduction of some runtime enforced discipline to JavaScript development. I have always felt that JavaScript is far too dynamic for its own good and in my opinion, strict mode tries to address some of that excessive dynamism. Many of the tricky parts of the language that required programmer discipline are now enforced by the engine when you mark a particular code segment as “strict”. Can you spot the bug in the following snippet? With “strict mode” turned on, the runtime will!

function findProduct(numbers) {
    var product = 0,
        len = numbers.length;
    for(var i = 0; i < len; ++i) {
        prodct = product * numbers[i];
    }
    return product;
}

Browser support

Pretty much all modern browsers support strict mode in their respective JavaScript engines. On Internet Explorer (IE) strict mode is available from version 10 onwards. You can download the latest platform preview of IE10 from the IE test drive site. All the samples in this article have been tested on IE10 platform preview 2 (IE10 PP2) using a JavaScript eval console I had put together sometime back. Selected samples have been tested on Google Chrome 14 and Firefox 7 beta as well.

Strict mode contexts

Running a piece of JavaScript under strict mode is simplicity itself. Here’s an example:

"use strict";
alert("Look ma! Strict mode!");

The nice thing here is that this is perfectly valid ECMAScript 3 code as well (ES3 is the previous edition of ECMAScript. What happened to ES4? It went the way of the dodo!). An ES3 JavaScript engine will simply ignore the noop line and proceed with running the rest of the script. In fact, this sort of syntactic backward compatibility with ES3 has been a key design goal for ES5 and a surprisingly large part of the ES5 specification can be implemented completely in ES3 JavaScript. Strict mode however, is an example of an ES5 feature that perhaps cannot be implemented purely in ES3 JavaScript without additional support from the runtime.

The following kinds of JavaScript code can be made to run under strict mode:

Global code

This is basically executable code that you enter inside a script tag. For example:
```
<script>
  "use strict";
  // global strict mode code here
</script>
```
Note that with HTML5, there is no longer a need to add the type attribute for script tags.
Eval code

Eval code that has the strict mode directive prefix:
```
eval("'use strict'; // strict code here");
```
Or is invoked from strict mode code:
```
"use strict";
eval("// strict code here");
```
Function code

Functions that have the strict mode directive prefixed before the rest of the code (putting the directive anywhere else doesn’t count):
```
function foo() {
    "use strict";
    // strict code here
}
```
Functions declared in strict mode code inherit the strictness:
```
function foo() {
    "use strict";
    var bar = function () {
        // strict code here
    };
    bar();
}
```
Note that the latter case is particularly relevant when you are defining callbacks for various event handlers. Also, note that strictness does not extend across call stacks. Here’s an example:
```
function foo() {
    // not strict mode even though
    // foo is being invoked from a
    // "strict" function
}

function bar() {
    "use strict";
    foo();
}

bar();
```

In the next post we’ll start taking a look at some of the restrictions that ES5 strict mode imposes on the language and how they help you write better JavaScript.

Nerdworks Blogorama - Nerdspeak

IE9 web cast / Chennai Web Camps / OSI Days 2011

IE9 Web Cast on ECMAScript 5

Chennai Web Camps

OSI Days 2011

Partial function application in JavaScript

Web Camps, Virtual Tech Days and jsFoo

Web Camps

Virtual Tech Days

jsFoo

On the HTML5 Indexed DB API - Part 4 of n

On the HTML5 Indexed DB API - Part 3 of n

Object stores

Keys and Values

Database versioning

Transactions

Scope

Mode

Read only

Read/write

Version change

Creating the object store

Adding data to object stores

Coming up

On the HTML5 Indexed DB API - Part 2 of n

Building an offline note taking app

Testing for Indexed DB

Asynchronous requests

Creating and opening the database

Coming up

On the HTML5 Indexed DB API – Part 1 of n

HTTP Cookies

Plug-ins

DOM Storage

What is Indexed DB?

A word on the status of the spec

Setting your development environment up

Coming up…

On JavaScript code blocks, variable scope and variable hoisting

JavaScript strict mode restrictions

Identifiers must be declared before they can be assigned to

No automatic context for context-less function calls

Reserved keywords cannot be identifier names

Violations of ES5 property configuration cause errors

Writing to read-only accessor properties

Cannot extend non-extensible objects

Other sundry restrictions

Some best practices

On JavaScript strict mode

What is strict mode?

Browser support

Strict mode contexts

Global code

Eval code

Function code