Posts about Javascript

Node Knockout 2011 and Twends

toby ho — Mon, 29 Aug 2011 22:19:07 +0000

This past weekend I participated in the Node Knockout - a programming competition where teams of 1 - 4 members build something using node.js in 48 hours. I was very fortunate to have worked with @robfaraj on this, it was a fun couple of days! The end result is what we call ~~Twends~~ Twends: new location is now twends.us. Twends is a real-time Twitter trend visualization...app. It looks like this

First, you either select a trending topic or type in a term of your own, then you will see this word visualization based on a series of packed circles. The larger the circle and the redder it is, the more frequently the word is being said at the moment. All the while, birds are fly across the screen. Each bird on the screen represents a tweet that's been written, now...ish. Just sit back, relax and watch the pretty circles changing shape and the birds flying across your screen. By reading the words you can often learn interesting things. For example, I learned while reading Twends that Justin Beiber fans are called beliebers, while Taylor Swift fans are called swifies.

Oh! And here's a video of it in action

The Tech

Twends was built using client-side Javascript with the help of some great libraries and the Twitter REST API. d3.js is without a doubt the most valuable library(MVL). We used it to layout the circles as well as animate them from their old positions to the new positions each time new data comes in. We also used HTML5 Boilerplate and jQuery. On the server side, we used express and the jade templating language.

Graphics is done using SVG, which d3.js works very well with - although is independent of. IE8 and below do no support SVG so Twends do not work there. Twends could have worked on IE9 but it doesn't. IE9 supports SVG, so that was not the problem. The problem was that IE9 was blocking the JSONP requests I was making to the Twitter API due to this problem, of which the blame is half on Microsoft and half on Twitter. So, if you go to the site with IE, it will greet you with a friendly(?) message and prompt you to install Google Chrome Frame, yea!

The Aftermath

~~The competition is still being judged at the moment, so I don't know what's the aftermath just yet. I guess I'll update this part of the post another time.~~

Node knockout came to an end and the winners were victorious! Congrats to them. I am a little disappointed/surprised that one of my favorite entries: Pitchography didn't win anything, here's a demo of their awesome presentation tool. As for Twends, well we were decidedly better than half of the entries out there :) We also presented it at the Atlanta Javascript Users Group and got some good feedback. I've made the source code public on github as well.

Node Knockout was a great experience. The organizers did a superb job of allowing the contestants to focus on writing code rather than dealing with setting up servers or administrative stuff. I enjoyed everything from the planning stages where we threw around random ideas, to the actually coding and then to the showing it off to people and seeing their reactions and comments. If you love code, then I highly recommend that you try a hackathon like this one.

My JSConf Talk in Video

toby ho — Fri, 19 Aug 2011 15:51:16 +0000

The awesome folks behind JSConf just released a whole bunch of great talks in video form from the Portland event. Great chance to catch up on the talks whether you were there or not! They even put mine up there, which since this is my website, I am obliged to embed here. Wow I sound so very Chinese.

Embedded Content

The Javascript Stacktrace Blog Post

toby ho — Wed, 08 Jun 2011 21:44:11 +0000

For the past week or so I did some research on how best to include scripts in Tutti's sandbox environment and still get the best stacktraces possible. I got sucked in deeper and deeper and it just got uglier and uglier. This post will attempt to summarize all the knowledge that I've uncovered.

What's a Stacktrace?

When I say stacktrace, I mean it in the context an exception being thrown in your code, and getting the information about where exactly in your code the exception was thrown. This is what a exception might look like

Error: Buck stops here.
at failInlined (http://localhost:8000/error_object/:16:11)
at catchError (http://localhost:8000/util.js:77:26)
at http://localhost:8000/error_object/:49:1

First, there is an error message. Then, the stacktrace. The stacktrace basically represents the state of the program's call stack at the point when the exception was thrown. The stacktrace also contains the location(file URL and line number) of each call in the stack, which is extremely useful for debugging.

So What's the Problem?

The problem, is that not all browsers give you informative stacktraces. Not only that, different browsers give you the information in different ways.

Most browsers today give you the stacktrace information in the Error object that was thrown. In Firefox, Chrome and Opera, for example, the Error object contains a stack property which is a string representation of the stacktrace, much like the example shown above.

// Get stacktrace on Firefox, Chrome and Opera

try{

   throw new Error('Buck stops here')

}catch(e){

   console.log(e.stack) // Yea!

In Safari, however, the stack property is non-existent: it does not give you the full stacktrace. Instead it gives you the location for the top stack frame only. This is gotten from the properties sourceURL and line.

// Get 1-level stacktrace on Safari

try{

  throw new Error('Buck stops here')

}catch(e){

  console.log(e.sourceURL + ': ' + e.line) // Meh

On IE, you are out of luck. There is no stacktrace information available on the Error object.

Going Deeper

Javascript can be executed in various different ways/techniques, and not all of them yield good stacktraces. My next objective was to see what the stacktraces look like for the different techniques

Technique 1: Script Tag Includes

The script tag include is probably the most common way to execute Javascript on a webpage.

<script src="myscript.js"></script>

Technique 2: Inlined Script Tag

Alternatively you can inlined Javascript code inside of the script tag.

<script>

console.log('Hello world')

</script>

Technique 3: Dynamically Inserted Script Tag

You can also create a script element dynamically in Javascript and load some Javascript into it.

var script = document.createElement('script')

if (<IE sucks and you are it>)

  script.text = jsCode

else

  script.appendChild(document.createTextNode(jsCode))

document.body.appendChild(script)

document.body.removeChild(script)

Technique 4: Eval

Use eval to execute the Javascript in Javascript. You probably want to global eval it.

// This code for global eval stolen from jQuery 1.6.1

(window.execScript || function(jsCode) {
	window["eval"].call(window, jsCode);
} )(data);

Technique 5: Data URL in the Script Tag

Using a data URL in a script tag is...I am not sure if anyone actually does this, and I am not entirely sure it's useful, but what the heck.

<script url="data:application/javascript,console.log('hello%20world')"></script>

Summary: Stacktrace Information From Error Object

Long story short, I tested the stacktrace output for each of these five techniques in different browsers. I summarized the results in this here table (that's right, geek out!)

Browser	Include				Inlined				Dynamic				Eval'ed				Data URL
Browser	LN	SR	ST	AG	LN	SR	ST	AG	LN	SR	ST	AG	LN	SR	ST	AG	LN	SR	ST	AG
IE 6 - 8																	Unsupported
IE 9
Safari 5	Y	Y			Y	Y			Y*	Y			Y				Y*	Y
Chrome 11	Y	Y	Y		Y	Y	Y		Y*	Y	Y		Y*	Y	Y		Y*	Y	Y
Firefox 3.6 - 4	Y	Y	Y	Y	Y	Y	Y	Y	Y*	Y	Y	Y	Y*	Y	Y	Y	Y*	Y	Y	Y
Opera 11	Y	Y	Y		Y*	Y	Y		Y*	Y	Y				Y		Y*	Y	Y

*: Line number may not be helpful
LN: Line numbers
SR: Source file URL
ST: Full stacktrace
AG: Call arguments in stacktrace
Include: Script tag with src set to a Javasrcipt file URL
Inlined: Script tag with inlined Javascript
Dynamic: Dynamically inserted script tag with inlined Javascript
Eval'ed: Global eval'ed Javascript
Data URL: Script tag with src set to a Data URL containing Javascript

A straightforward script tag include yields the best stacktrace information. As the asterisk(*) indicates, the dynamic script element, global eval, and data URL techniques can yield stacktraces with non-helpful line numbers. The data URL technique actually gives correct line numbers, it's just that all the newlines have been encoded and the entire source jammed onto a single line - so, I can't really say the line numbers are all that helpful. Strangly, Opera yields non-helpful line numbers even with the Javascript-inline-in-a-script tag technique.

So That's it? No IE?

There's no way to get stack information on IE, not unless you want to do the other thing, but you don't want to know about that.

What's that? You do want to know? No you do not! Just forget I said anything.

Okay! I'll tell you, but you are going to regret it.

window.onerror

On IE - and as it happens on Firefox and Chrome as well - you can register an onerror handler on the window object, like so

window.onerror = function(message, fileURL, lineNumber){

  log(message + ': ' + fileURL + ': ' + lineNumber)

The handler will be called anytime a thrown exception is uncaught: propagates all the way to the bottom of the call stack with no catchers. Catching the exception will cause the handler not to be called, unless you rethrow it, but even then, there are other complications. When the handler is called, there is no error object, only the error message, file URL, and the line number.

Bad News: IE

Because of various IE bugs, the fileURL and line number passed into the onerror handler isn't always accurate or helpful. After some research, I've isolated these bugs:

In IE 7 and below, if an exception is thrown from within the code of an included script, fileURL will erroneously be set to the URL of the current HTML document even though the lineNumber will be set to the correct line number from within the script.
In IE 8 and below, if an exception is thrown using the throw statement, (i.e. throw new Error() ) and is caught, and then re-thrown, and then propagates all the way up, the line number reported will be the the place it was re-thrown, rather than the place it was first thrown. This bug does not surface when the error is triggered otherwise, such as with type and reference errors.

IE 9 has both of these bugs fixed, even when it emulates older versions of the browser.

What Can You Throw

The "throw" statement lets you throw just about any old value - even numbers and strings! But this is not recommended as you won't be able to get any line numbers or stacktraces if the value thrown isn't an object - except for in IE, where you can get line numbers using onerror. In IE, throwing anything other than a pre-defined error object(Error, TypeError, etc) will result in the loss of a meaningful message in both the caught error object and in the onerror handler - where it will just say "Exception thrown and not caught".

So, the simplest recommendation here is to only throw the pre-defined Error object when you want to explicitly throw an error using the "throw" statement.

throw new Error('Buck stops here.')

or better yet, don't use the throw statement at all(this avoids the second IE bug mentioned earlier).

The DIY Stacktrace

The DIY stacktrace was pioneered by Eric Wendelin among others. It first looks up argument.callee to get the current function being executed, then it walks the call stack by accessing the function's caller attribute recursively. For example:

> function f(){

g()

> function g(){

h()

> function h(){

    console.log(arguments.callee.caller.caller)

> f()

function f(){

g()

In the example, we are able to access the function f from with the body of h's execution by walking two levels up the call stack using the caller attribute.

Pros and Cons of the DIY Stacktrace

The advantage of the DIY stacktrace is that it will work in any browser.

The disadvantages are

It will not get you file locations/line numbers.
It does not work with thrown errors - either implicitly or explicitly - because the building of the stacktrace needs to be explicited done as its own statement, say, printStackTrace, for example. So, you cannot have a stacktrace and an error thrown - you cannot have your cake and eat it too.

Conclusion

Sorry I don't have a better conclusion than: It's a great big mess. However, with the knowledge covered here, I think it is possible to employ some sophisticated hackery to recover at least some stacktrace info for each browser - the hardest case being IE. Such a technique - if made practical - would be useful for unit test frameworks and crash reporting.

References

Eric Wendelin's Javascript Stacktrace ( GitHub repo )
DIY Stacktrace - Helen Emerson
3 painful ways to obtain a stacktrace from Your Sway/CrashKit

Try Traceur

toby ho — Thu, 19 May 2011 15:12:51 +0000

I screwed around with Traceur last night and this morning. Then I built this thing called Try Traceur to make it easy for folk to screw around with it too. Try it! You know you want to.

JSConf Summary and My Codez

toby ho — Fri, 06 May 2011 22:25:03 +0000

JSConf 2011 Portland was truly amazing experience for me, personally. Not only did I meet some fantastic people in the community - some of whom I've long wanted to meet, I also got to show off my stuff, and it didn't totally suck. Also, add to that, Portland is a fantastic city! I want to thank Chris Williams again for motivating me, and everybody involved for such a great event!

My talk was on Tutti and most of its time was occupied by demos, so rather than posting the slides I thought I would just post the example code for the demos. I hope this is helpful to people!

Tuttiterm - Tutti for your Terminal

toby ho — Fri, 04 Mar 2011 07:23:16 +0000

I've created Tuttiterm - which allows you to control browsers via Tutti. See the project README. Here's a screenshot:

Testing Tip: The Dummy Function

toby ho — Fri, 25 Feb 2011 11:37:29 +0000

Sometimes when you are writing tests, you find yourself testing whether a particular callback has been called. For example, you might write a test like this

var lastCalledWith
function callback(e){
    lastCalledWith = e
}
obj.bind('someevent', callback)
obj.doSomethingThatShouldTriggerEvent()
expect(lastCalledWith.type).toBe('someevent') // check that callback was called

This is slightly tedious and the code ungainly because you need to introduce a variable in your test, and store the arguments to it so that you can check the result. We can do better

function $dummy(){

    arguments.callee.lastCalledWith = arguments

obj.bind('someevent', $dummy)

obj.doSomethingThatShouldTriggerEvent()

expect($dummy.lastCalledWith[0].type).toBe('someevent')

This is a nice and generic, but we have to reset the lastCalledWith attribute before each test, something like

delete $dummy.lastCalledWith

But let's make it more painless

$dummy.reset()

By adding this reset function

$dummy.reset = function(){
    delete this.lastCalledWith
    return this
}

Moreover, reset returns back the dummy function itself, so, now you can write the test like so

obj.bind('someevent', $dummy.reset())
obj.doSomethingThatShouldTriggerEvent()
expect($dummy.lastCalledWith[0].type).toBe('someevent')

Very nice. I like.

Playing With Self

toby ho — Fri, 18 Feb 2011 21:21:54 +0000

The Self Language is a descendant of Smalltalk, and is the language that introduced the concept of prototype inheritance. To get a historical perspective, I wanted to try it out, and luckily, it is still available online despite Sun killing the project in '95.

Install

To install Self, go to its download page and follow the instructions. In short, first, you need to install the VM by running the installer. Next, you need to download a snapshot image. There are two to choose from: the clean(spic 'n span) and the demo(kitchen sink). Next, double click on the image that you downloaded, and you should be good to go.

I am going to do a walkthrough using the clean image because I just want to try out some basic language features. When the environment - or "world" - finishes launching, you are greeted with a large gray space with a shell window on the top left, and a trash can on the top right.

So, let's play around and see how prototype inheritance works in Self. To create a new empty object, type

()

into the shell window and then click the "Get it" button. You should see a new expandable window that says "a slots object". If you expand it, it should look like

This is an empty object, the equivalent of {} in Javascript.

Slots

Now let's add some attributes to it, except in Self, we call them slots. Right-click on the header of this window and select "Add Slot". You should see this

This textarea is where you would write the code for either a value slot or a method slot. The textarea preloads with some examples of what you can write here.

We are going to just add a read-only slot

Just so you know, a read/write value slot would be written as

name <- 'Thelonious'

When you are done, click on the thin green vertical bar on the left side of the window, and it should except the code. If your code has a syntax error, it will complain, and you'll need to try again. If you got it right, you should see this

For fun, let's make a few more slots. Repeat the "Add Slot" procedure, but this time add a hair slot and set it to 'dark and curly', add a plays slot and set it to 'piano'. If things go right you should see

Now, click on the "E" button to get an evaluation console. If you type

plays

into it and click "Get it", you should get the string 'piano' to come out

Okay, so it gets the value correctly.

Inheritance

Cool. Next we are going to create the inheritance link. First, we create an empty object again to represent the child.

Now, we add a special slot and call it parent*.

We don't set it to a value so that it defaults to nil

Next, we need to link it to Thelonious. First click on the little button with two small dots just to the right of the nil. The nil object will come out and you'll see a link from your parent* slot to it.

In Self, any slot that ends in * is a parent link. So, in fact, it supports multiple inheritance! Anyway, we are close to completing the inheritance. Now just drag the link to Thelonious. If you got it, you'll see this

Now, to test that it worked, click on "E" in the child object and type

hair

Sweet! Now, we can override slots in the child, right?

Yup. While we are at it, we'll change the name to 'Thelonious Jr.' too.

Methods

Next, let's create a method. Let's create a greet method on the parent. The greet method will simply popup an alert dialog with the message. It does this using the report: method of userQuery.

userQuery report: 'Hi, I am ', name, ', I have ', hair, 
   ' hair and I play the ', plays, '.'

But, this won't work. Try running it - by clicking "Do it" will give you

It couldn't find the userQuery object within its slots. In Self, the normal convention is to have your object inherit the lobby object in order to have access to all the global variables(this is like the global object in Javascript, aka the public restroom). So okay, we have 'Thelonious' inherit lobby using a link called lobby*. To do this, we first get hold of the lobby object by typing in the shell

lobby

and clicking "Get it". Then, create a slot on 'Thelonious' called lobby* and like to it. You should end up with this

Now, if you try "Do it" on greet it should give you

And 'Thelonious Jr.' should also be able to do this

Sweet!

Comparison With Javascript

With a cursory look at the language Self, here are some of the differences between it and Javascript:

It supports multiple inheritance, name clashes will result in a runtime error.
Implicit self. No need to write "this." within the method body like Javascript.
It differentiates between methods and blocks(in Javascript they are both functions). For this reason, you won't have the ugly Javascript problem of having to manually store a reference to this when you want to use it in inner blocks within a method.
There's no constructor. You construct object using literals or by cloning another object.
Reflection is done with a special mirror object attached each object's _Mirror slot.
There is support for referencing a super method using a special resend syntax.

Checking Types in Javascript

toby ho — Fri, 28 Jan 2011 12:51:45 +0000

Have you ever wondered: what is the correct way to check if a Javascript variable is an Array?

Do a Google search and you will get a great variety of answers. And, unfortunately, there's is no correct answer. This is one of the sad things about Javascript, not only are there many varying implementations of the language, there are also many varying opinions about how things should be done.

Enough philosophizing and feeling sorry about the state of things. With this article, I will trying to give a comprehensive overview of the different techniques of checking-types in Javascript, the pros and cons of each and why they exist.

typeof operator

In the beginning, there was typeof. This handy operator gives you the "type" of a Javascript value:

typeof 3 // "number"

typeof "abc" // "string"

typeof {} // "object"

typeof true // "boolean"

typeof undefined // "undefined"

typeof function(){} // "function"

All is fine 'n dandy until

typeof [] // "object"

Huh? An array's type is object? I guess it is, if you want to get technical about it, but still, what the...

typeof null // "object"

Okay, now that's just wrong!

Also, typeof will return "object" for Dates, RegExp, user defined objects, DOM elements, and pretty much anything else. So, typeof is pretty good at distinguishing between different kind of primitive values, and distinguish between them and objects, but is completely useless when it comes to distinguishing between different kinds of objects - which includes arrays and nulls(WTF?!).

instanceof operator

The instanceof operator tells you whether a object is an instance of a certain type. The so-called "type" is a constructor. For example

function Animal(){}

var a = new Animal()

a instanceof Animal // true

Alternatively, you could make this check using the constructor property of an object

a.constructor === Animal // true

However, the constructor check has two problems. First, it does not walk up the prototype chain

function Cat(){}

Cat.prototype = new Animal

Cat.prototype.constructor = Cat

var felix = new Cat

felix instanceof Cat // true

felix instanceof Animal // true

felix.constructor === Cat // true

felix.constructor === Animal // false

The second problem is that it will bomb out if the object in question is null or undefined.

felix = null

felix instanceof Animal // true

felix.constructor === Animal // throws TypeError

instanceof works for all native types!

[1, 2, 3] instanceof Array // true

/abc/ instanceof RegExp // true

({}) instanceof Object // true

(function(){}) instanceof Function // true

or does it?

3 instanceof Number // false

true instanceof Boolean // false

'abc' instanceof String // false

Okay, what is going on here? It turns out that instanceof does not work with primitive values. The primitive types in Javascript are: strings, numbers, booleans, null, and undefined - (Oh good! You can count them all on one hand!) Well actually, I should have said it does not work with primitives with the exception of null and undefined, because they are not an instance of anything, and so instanceof correctly returns false when either is used on the left hand side.

null instanceof Boolean // false

undefined instanceof Array // false

To top that off though, checking for the constructor property will work for the primitive types number, string and boolean.

(3).constructor === Number // true

true.constructor === Boolean // true

'abc'.constructor === String // true

This works because whenever you reference a property on a primitive value, Javascript will automatically wrap the value with an object wrapper, like so

var wrapper = new Number(3)

except you don't see this - it happens behind the scenes. The wrapper then will be an instance of - in this case Number - or a Boolean or a String depending on the type of the primitive value, at which point it can walk up the prototype-chain and get at the properties of the Number prototype, etc. So, for example, creating a wrapper manually will make the instanceof operator work

new Number(3) instanceof Number // true

new Boolean(true) instanceof Boolean // true

new String('abc') instanceof String // true

But doing that would be pointless because it requires you to already know the type of the value of which you are asking whether or not it is of the type that you already know it is.

Cross-window Issues of instanceof

It turns out that instanceof has another problem. It breaks down when you try to test an object coming from another window. You know? The ones that are created for each <iframe>, <frame> or popup window that you create.

var iframe = document.createElement('iframe')

document.body.appendChild(iframe)

var iWindow = iframe.contentWindow // get a reference to the window object of the iframe

iWindow.document.write('<script>var arr = [1, 2, 3]</script>') // create an array var in iframe's window

iWindow.arr // [1, 2, 3]

iWindow.arr instanceof Array // false

Above, we created a variable arr inside the context of the iframe and set it to the array [1, 2, 3]. However, we get false when we ask whether it is a instance of Array. What is happening?!! Behold.

Array === iWindow.Array // false

The Array in the iframe is not the same Array as our Array! This is true for all built-in objects: there are two versions of all of them! Basically, we have parallel universes! OMG!

What this means is that an array created within the iframe is only an instance of the Array constructor within the iframe

iWindow.arr instanceof iWindow.Array // true

The same phenomenon happens with windows created using the open() function. It is because of this cross-window problem that the use of instanceof is somewhat limited and discouraged within the Javascript community.

Duck-Typing

Because neither typeof or instanceof are satisfactory, many resort to duck-typing. This means checking the behavior: if it looks like a duck and quacks like a duck, then it is a duck as far as I am concerned. Pretty sure I misquoted that...oh well.

So, using duck-typing, an isArray check might look like

// source: http://forums.devshed.com/javascript-development-115/javascript-test-whether-a-variable-is-array-or-not-33051.html

function isArray(obj){
    return (typeof(obj.length)=="undefined") ?
        false:true;
}

// source: http://www.hunlock.com/blogs/Ten_Javascript_Tools_Everyone_Should_Have

function isArray(testObject) {
    return testObject &&

	!(testObject.propertyIsEnumerable('length')) &&

	typeof testObject === 'object' &&

	typeof testObject.length === 'number';
}

in jQuery, the function to check whether an object is a window is

isWindow: function( obj ) {
    return obj && typeof obj === "object" && "setInterval" in obj;
}

You could easily trick this function into returning true

$.isWindow({setInterval: 'bah!'}) // true

Clearly, the problem with this approach is that

it is inexact and can have false positives
the set of properties of the object to test is arbitrary, and so it's unlikely for different people to agree on one way of doing it

For the record, I don't like this approach.

Object.prototype.toString method

It turns out that, you can get type information about an object by using the Object.prototype.toString method.

Object.prototype.toString.call(3) // "[object Number]"

Object.prototype.toString.call([1, 2, 3]) // "[object Array]"

Object.prototype.toString.call({}) // "[object Object]"

This native method is rarely encountered normally because it's usually shadowed by another toString method lower down in the prototype chain(Array.prototype.toString, Number.prototype.toString, etc.). This method reliably differentiates between native types, however, will return "[object Object]" for all user-defined types

Object.prototype.toString.call(new Animal) // "[object Object]"

It does, however, work across different window contexts

Object.prototype.toString.call(iWindow.arr) === "[object Array]" // true

with one exception: different windows(as in popup window) in IE.

var pWindow = open("")

pWindow.document.write('<script>var arr = [1, 2, 3]</script>')

Object.prototype.toString.call(pWindow.arr) // you get "[object Object]" in IE; "[object Array]" else where.

This is strange because for iframes it works just fine, bummer! This method has become somewhat of a preferred way to differentiate native types despite the IE bug. Ehh, nobody uses popup windows anymore anyway.

Function.prototype.toString method

Yet another way to test for type information is by using the Function.prototype.toString method.

Function.prototype.toString.call((3).constructor)

// "function Number() {
//    [native code]
// }"

The method gives you the complete source of a function. In the case of native functions, it just says "[native code]" in the body. One could easily parse out the name of the function to figure out type of the object using this helper function

function type(obj){
	var text = Function.prototype.toString.call(obj.constructor)
	return text.match(/function (.*)\(/)[1]
}

type("abc") // "String"

This one will work for user-defined types too

type(new Animal) // "Animal"

this code has a problem wrt popup windows in IE just like instanceof. It's because when Function.prototype.toString is called with a constructor from another parallel universe, it can only discern the constructor as an object("[object Object]"), and thus rejects the argument and throws a "Function expected" error. This problem can actually be worked around by referencing the toString method indirectly

function type(obj){
	var text = obj.constructor.toString()
	return text.match(/function (.*)\(/)[1]
}

Now, it works for popup windows in IE too! This fix makes it susceptible to shadowing

Array.toString = function(){ return "function NotArray(){ }" }

type([1,2,3]) // "NotArray"

but still, I'd say this is pretty cool.

Now, let's return to user-defined types for a minute. With this approach, there's no way to distinguish between two different user-defined types with the same name

var f = function Animal(){ "something" }

var g = function Animal(){ "something entirely different" }

type(new f) // "Animal"

type(new g) // "Animal"

For this reason, this method is inferior to instanceof for user-defined types. Another seemingly obvious problem with this approach is performance, but I'd have to benchmark it(jsperf!) to make a real claim.

DOM Elements and Host Objects

So far, I have not mentioned type checking for DOM elements and host objects. That's because it's hard. With the exception of duck-typing, none of the methods mentioned above will work for all browsers. If you drop IE7 and below, however, you can actually get some of the things to work. The output below were created using Tutti

> var div = document.createElement('div')
> typeof div
Safari 5.0 => object
Firefox 3.6 => object
IE 7.0 => object
IE 8.0 => object
Opera 11.01 => object
> div instanceof Element
Safari 5.0 => true
Firefox 3.6 => true
IE 7.0 => Error: 'Element' is undefined
IE 8.0 => true
Opera 11.01 => true
> div instanceof HTMLDivElement
Safari 5.0 => true
Firefox 3.6 => true
IE 8.0 => true
IE 7.0 => Error: 'HTMLDivElement' is undefined
Opera 11.01 => true

First up, typeof is useless, that was expected. Next, everyone but IE 7 recognizes that a div is an instance of Element as well as an HTMLDivElement. In IE7, those constructors aren't even present. Next,

> Object.prototype.toString.call(div)
Safari 5.0 => [object HTMLDivElement]
Firefox 3.6 => [object HTMLDivElement]
IE 7.0 => [object Object]
IE 8.0 => [object Object]
Opera 11.01 => [object HTMLDivElement]

The result of Object.prototype.toString in IE - even IE 8 - is particularly unhelpful. What about

> div.constructor.toString()
Safari 5.0 => [object HTMLDivElementConstructor]
Firefox 3.6 => [object HTMLDivElement]
IE 7.0 => Error: 'div.constructor' is null or not an object
IE 8.0 => [object HTMLDivElement]
Opera 11.01 => function HTMLDivElement() { [native code] }

Function.prototype.toString: it gives us something useful for IE8, but every browser has a slightly different output.

Fun! Try another one? Allllllllllllllllrrrighty then!

> typeof window
Safari 5.0 => object
Firefox 3.6 => object
IE 8.0 => object
IE 7.0 => object
Opera 11.01 => object
> window instanceof Window
Safari 5.0 => ReferenceError: Can't find variable: Window
Firefox 3.6 => true
IE 8.0 => true
IE 7.0 => Error: 'Window' is undefined
Opera 11.01 => ReferenceError: Undefined variable: Window
> Object.prototype.toString.call(window)
Safari 5.0 => [object DOMWindow]
Firefox 3.6 => [object Object]
IE 8.0 => [object Object]
IE 7.0 => [object Object]
Opera 11.01 => [object Window]
> window.constructor
Safari 5.0 => function Object() {
    [native code]
}
Firefox 3.6 => function Object() {
    [native code]
}
IE 8.0 => [object Window]
IE 7.0 => undefined
Opera 11.01 => function Object() { [native code] }

With window it is just all over the place, none of these methods worked for all browsers. You can try testing out some other host objects if you want, but in general it doesn't look doable. However, in my testing, the XMLHttpRequest object and DOM and Text elements look doable using instanceof, if you can drop support for IE7 and below.

What We've Learned

Checking types in Javascript is a big mess. Although it's really not that hard to check for any one particular type, it is definitely not consistent across types, and you probably have had to make a lot of choices along the way. So it helps to know about all the different options. In an upcoming post, I will try to make all of this easier with a small piece of code. Stay tuned.

Sources

Trampolines in Javascript and the Quest for Fewer Nested Callbacks

toby ho — Fri, 10 Dec 2010 14:32:43 +0000

The problem of Javascript coders often having to deal with more than the desired number of nested callback functions have never really went away. My complaint has been stated not long ago. Lately, with the raise of node.js, the complaints seemed to have gotten louder, or just more numerous. At JSConf EU 2010, there were no fewer than 5 talks addressing this issue, each in their own unique way.

Crockford himself, for example, thinks that this is just the way it should be, and people who don't like it are just grumpy (Waa!)
Ryan Dahl glossed over the problem of losing the stack, and suggested that you just roll your own solution for remembering state across your series of function contexts.
Jed Schmidt revealed his fantastic hack: program in continuables/streams. The solution is actually very close to Haskell's I/O Monad, and is both clever and beautiful, but it requires you to change your mind-set completely and therefore is unlikely to gain a lot of mindshare.
Tim Caswell introduced a helper library called Step which allows you to chain your functions rather than nest them.
Tom Hughes-Croucher recommended using named functions, for the stacktraces will display them names and therefore be more helpful.

More recently, Kyle Simpson(Getify) started a twitter thread and blog post with his own proposed addition to the language, which boils down to an @ operator that cooperates with dojo-style promises.

Clearly, we are far from reaching consensus.

Generators

One thing that was brought up over and over again in Kyle's thread is generators. My take is this: generators have existed in Spidermonkey ever since Firefox 2, so if you are open to new language features, generators have already been around the block, we just have to get it into the standard, at which point I believe node.js - and just Javascript programmers in general - can really benefit. I have long been using generators in Python, so I know that they are very powerful. All of this motivated me to go deeper and see how far it can go in the Quest for Fewer Nested Callbacks.

First, the Punchline!

Let's see the punchline now because it may take a while before we can get through all the steps necessary to arrive at it: with the help of generators and a bit of support code, this(code taken directly from Kyle's post)

setTimeout(function(){
   xhr("/something.ajax?greeting", function(greeting) {
      xhr("/else.ajax?who&greeting="+greeting, function(who) {
         console.log(greeting+" "+who);
      });
   });
}, 1000);

can be written as

yield sleep(1000)
var greeting = yield xhr('/something.ajax?greeting')
var who = yield xhr('/else.ajax?who&greeting=' + greeting)
console.log(greeting + ' ' + who)

The supporting function

function xhr(url, callback) {
   var x = new XMLHttpRequest();
   x.onreadystatechange = function(){
      if (x.readyState == 4) {
         callback(x.responseText);
      }
   };
   x.open("GET",url);
   x.send();
}

almost remains unchanged, all it needs is to be wrapped like so

function _xhr(url, callback) {
   var x = new XMLHttpRequest();
   x.onreadystatechange = function(){
      if (x.readyState == 4) {
         callback(x.responseText);
      }
   };
   x.open("GET",url);
   x.send();
}
function xhr(url){
   _xhr(url, (yield Continuation))
   yield Suspend
}

and, sleep() is implemented as

function sleep(ms){
    setTimeout((yield Continuation), ms)
    yield Suspend
}

Are you intrigued? Read on, then.

Gentle Introduction to Generators

What are generators? How do they work? How can I use them?

Let's start with "How can I use them?". You have to be running Firefox 2 or above, or alternatively you can download Spidermonkey by itself.

For my code samples I'll assume you are using Firefox.

Next, you have to use type="application/javascript;version=1.7" in your script tag. I guess Mozilla was sheepish about this feature when they released it, given that it introduced a new keyword.

So, a hello world example for generators would be:

<script type="application/javascript;version=1.7">
// This is a generator function
function naturalNumbers(){
    var i = 0
    while (true){
        yield i++
    }
}
var N = naturalNumbers() // N is now a generator
console.log(N.next()) // prints 0
console.log(N.next()) // prints 1
console.log(N.next()) // prints 2
// and so forth
</script>

First things first, a generator function is not the same as a function. Repeat after me: a generator function is not a function. Within a generator function, you have yield statements; within a function, you have return statements - you cannot have both.

The generator object has a few methods, here we are only demonstrating next() - which executes the code within the generator function until a yield statement is reached, and returns the value being yielded. If you call next() on it again, it will continue from where it left off, and once again execute till the next yield is reached. In our natural numbers example, since we are yielding the counter within an infinite loop, we can keep calling next() on the generator object to get the next number forever...

Receiving Values

It turns out that in addition to yielding values, the yield statement can also receive values(proud of myself that I avoided using the word "return" in this sentence).

For a yield statement to receive a value, the holder of the generator must call the send() method with a value instead of the next() function

function makePrinter(){
    while(true){
        var message = (yield)
        console.log(message)
    }
}
var printer = makePrinter()
printer.next() // You may not send a value to a newly created generator
printer.send('Hello')
printer.send('I am sending this message')
printer.send('into the generator')
printer.send('and it be received and get printed')

Here we created a printer generator whose job is only to print the objects that it receives from the yields. You can't send in a value for the first invocation of the generator because it hasn't had a chance to yield yet, but after that, you can send as many as you want, since it yields infinite times.

As you can see, we are switching back and forth between two separate threads of execution(but not Threads ;).

Trampolining

Now that you understand generators, the next step is to put it together to get rid of our nested callbacks. To do that, we need to know a technique called trampolining. Neil Mix's article has some brilliant code that shows you how to do it in Javascript, but it was David Beazley's gentle example in Python that helped me understand what's going on.

Let me translate his code to Javascript, and put in some comments for ya

function add(x,y){
    yield x + y             // yield the result of addition
}
function main(){
    var r = yield add(2,2)      // yield the result of add(2,2): a generator
    console.log(r)

    yield
}
function run(){
    var m = main()

    var sub = m.next()      // start the code execution in main()

                             // sub is now generator from calling add()

    var result = sub.next() // start execution of sub

                             // result now has the value of 2 + 2: 4
    m.send(result)           // send back to generator
}
run()

The main feature of trampolining is that a value yielded by a generator is yet another generator, such is the case on this line

var r = yield add(2,2)      // yield the result of add(2,2): a generator

In this example the thread of execution is bouncing between 3 different contexts, namely the run() function and the add() and main() generator functions. We started within run(), bounced to main(), then back to run(), then to add(), then back to run(), then back to main() again, and then finally exiting in run() again.

Here's a picture so we can visualize what's happening

But, right now the run() function is inflexible. We can generalize it to handle arbitrary levels of nested generator execution - with a stack

function run(gen){
    // is object a generator?
    function isGenerator(obj){
        return String(obj) === '[object Generator]'
    }
    // last element of array
    function last(arr){
        return arr[arr.length - 1]
    }
    var stack = []
    var retval = gen
    try{
        while (true){
            if (isGenerator(retval)){   // if a generator
                stack.push(retval)      // push it onto the stack
                retval = undefined
            }else{
                stack.pop().close()     // if we got a normal value
                                        // pop the stack and
            }
            gen = last(stack)           // get the generator at top of the stack
            if (!gen) break
            retval = gen.send(retval)   // send retval to the generator
                                        // if retval is undefined, it acts just
                                        // like next()
        }
    }catch(e if e === StopIteration){
        console.log('Program ended.')
    }
}

We have a stack which starts out containing the generator from which we are starting execution - gen. Then, we keep on executing the generator at the top of the stack. If the received value is also a generator, we push it onto the stack and keep going; if we receive a normal value, then we pop the generator off the stack and, on the next iteration of the loop - send the value to previous generator one level down in the stack.

To call the new and improved the run() function you pass it the entry level generator like so

run(main())

Let's take the same example again, but executing with the generic run() function instead. This time, let's visualize it as a stack. First we start with main() at the bottom

next,

var r = yield add(2,2)

add(2, 2) is pushed onto the stack, because it is a generator. The parameters x and y are both assigned to 2 inside the scope and also go on the stack.

add() then executes and

yield x + y

yields a numerical value: 4. Because, this is not a generator, we pop() the stack, then send the 4 back to main()

var r = yield add(2,2)

where 4 is assigned to r.

main() then prints the value via console.log and then

yield

again, which ends the execution.

Wait, I've Seen That Before!

This... stack, it looks almost like... an execution stack! The interpreter maintains a stack when it's executing code and handling the execution of function calls - and we've just reimplemented it using generators.

To see it another way, the only difference between the trampoline style code and normal functional code is the use of the yield statements. If you take out the yields - and substitute return when appropriate, you'd have

function add(x,y){
    return x + y
}
function main(){
    var r = add(2,2)      // yield the result of add(2,2): a generator
    console.log(r)
    return
}

Now that we have a generalized run() function that handles the stack generically, we can handle recursion

// the Fibonacci sequence using recursion - don't try this at home!

function fib(n){
    if (n == 1 || n == 2)
        yield 1
    else
        yield (yield fib(n-1)) + (yield fib(n-2))
}

function main(){
    console.log(yield fib(10))
}

This actually works!

Wrapping Asynchronous Execution

Okay, that's all fine and good, but we still haven't address the problem of making asynchronous code less onerous. In order to tackle that problem, we need to do a little bit more.

By keeping a stack of all of the generators we have in progress, we can restart them back at any time. However, we need to be able to suspend the execution of a generator if we are waiting for an asynchronous response. We also need to pass a function as the callback handler for the async function call, only by which can we know when to resume execution of the thread.

The solution is demonstrated by the implementation of sleep()

function sleep(millis) {
    setTimeout((yield Continuation), millis)
    yield Suspend
}

Continuation and Suspend are special constants - that we created - used as signals to run().

Here's how this works:

(yield Continuation)

will receive a function as a callback handler to setTimeout. Let's call this function the continuation.

yield Suspend

will suspend the execution of this generator, and therefore also suspending this thread of execution until the continuation has been called by setTimeout(). When the continuation eventually gets called, it will resume execution of this generator, which starts back up again after the line

yield Suspend

Our new run() function that handles all of this looks like

function run(gen){
    function isGenerator(obj){
        return String(obj) === '[object Generator]'
    }
    function last(arr){
        return arr[arr.length - 1]
    }
    function startBouncing(retval){
        try{
            while (true){
                if (isGenerator(retval)){
                    stack.push(retval)
                    retval = undefined
                }else if (retval === Suspend){
                    break                       // to suspend execution:
                                                // just break out of this
                                                // while-loop.
                                                // we can later resume
                                                // by re-starting another
                                                // while-loop by calling
                                                // startBouncing() again
                }else if (retval === Continuation){
                    retval = startBouncing      // send startBouncing
                                                // back as the callback
                                                // handler to the async
                                                // function call
                }else{
                    stack.pop().close()
                }
                gen = last(stack)
                if (!gen) break
                retval = gen.send(retval)
            }
        }catch(e if e === StopIteration){
            console.log('Program ended.')
        }
    }    
    var stack = []
    var retval
    startBouncing(gen)
}

We've refactored the while-loop inside of a function: startBouncing(). When we need to suspend, we just break out of the while-loop. When we need to resume, we just call startBouncing() to start the while-loop all over again. All the while we still have the stack in tact. The callback handler we send as the continuation is none other than the startBouncing() function. Notice that startBouncing() also takes a retval as argument. This enables us to send the first argument of the callback back to the generator, as the XHR example shows

function _xhr(url, callback){
    var xhr = new XMLHttpRequest()
    xhr.open('GET', url)
    xhr.onreadystatechange = function(){
        if (this.readyState == 4){

            // send the responseText as the first arg of the continuation
            callback(this.responseText)
        }
    }
    xhr.send()
}
function xhr(url){
    _xhr(url, (yield Continuation))
    yield Suspend
}

Because we are passing the responseText as the first argument to the callback(the continuation) - by our made up convention - it will be the value that's sent back to the caller of this generator function. So

var responseText = yield xhr('/something.ajax')

Just works!

Adding Back Exceptions

Async-style calls don't really throw any exceptions. That's because if there were problems with the request, you could only be notified asynchronously - the original execution has already past! However, now that we have something that looks like synchronous code again, we can put exceptions back into play. We will use the convention that if an instance of Error is passed as the first argument of the continuation, then we will throw it. Thus for our xhr function

function _xhr(url, callback){
    var xhr = new XMLHttpRequest()
    xhr.open('GET', url)
    xhr.onreadystatechange = function(){
        if (this.readyState == 4){
            if (this.status === 200)
                callback(this.responseText)
            else{
                var ex = new Error("XMLHttpRequest Error: " + 
                    this.statusText + ': ' + this.status)

                // pass in an error object to the continuable to throw it
                callback(ex)
            }
        }
    }
    xhr.send()
}

To throw an exception from within a generator you actually have to call the throw() method on the generator object. We just need to add an extra else-if inside of our big if statement inside of the while-loop in run()

else if (retval instanceof Error){
    stack.pop().close()
    last(stack).throw(retval)

Now we can get exceptions throw from the xhr() generator function

function main(){
    try{
        var result = yield xhr('/doesnotexist.ajax')
        console.log('blah')
    }catch(e){
        console.log('exception caught: ' + e)
    }
}

Conclusion

I think the trampolining technique is very compelling, perhaps even more compelling than the continuables in fab.js. The only thing we need is support for generators in more engines. As far as I know, Spidermonkey and Rhino are the only 2 that support it right now.

Source Code

You can download all of the code examples shown in this post.

References

A Curious Course on Coroutines and Concurrency brilliant tutorial on generators by David Beazley
Introduction to Generators and Iterators in JavaScript 1.7 - from MDN
Threading in JavaScript 1.7 by Neil Mix

Tutti - Multiple Browser Interactive Javascript Shell

toby ho — Thu, 09 Dec 2010 14:42:43 +0000

Cough, cough...

Have you ever wished that the Firebug console or <insert your favorite Javascript Shell> could execute the piece of Javascript you typed in on IE, or maybe some other browsers as well - at the same time?

Well, now you can!

Now there's Tutti - a Javascript Shell that will lets you execute Javascript on multiple browsers - all at the same time!

Here's how it works: to get started,

Open tuttijs.com in your browser
Create a new room (click).
Copy-n-paste the URL from your current browser window to another browser of your choice, say, IE 8.
Repeat step two for each browser you you want to test.
Type in some Javascript, hit ENTER, and see them results from all your browsers!

Tutti uses Socket.IO, node.js, and WebSocket technology - it's so just cloud™!

Tutti supports on all major browsers, including

Firefox 3.6 and 4
Chrome 8.0
Safari 5.0
Safari 4 Mobile for iPad
Opera 10
Internet Explorer 6, 7, and 8

Tutti is open source, but that's not all, it's also hosted on GitHub so you can download it and run it on your own machine, or better yet: fork it and hack on it to your heart's content!

Try it now!

To try it go to tuttijs.com, or get the source at http://github.com/airportyh/tutti. Remember dependencies such as Socket.IO-node, ExpressJS, node.js are installed separately.

Update: I've changed the domain to tuttijs.com. The old domain is still accessible though.

Two Strategies for Avoiding Tedious Null-Checks

toby ho — Tue, 30 Nov 2010 13:48:14 +0000

Programmers have been plagued by having to write numerous checks for null values ever since the dawn of time. Consider this example,

var customer = database.get(id)
var customerLastName = customer.name.last

What if I told you that, any of customer, customer.name, and customer.name.last could be null at runtime? And if any of them are null just set customerLastName to "Unknown". You’d probably do something like

var customerLastName = "Unknown"
var customer = database.get(id)
if (customer && customer.name && customer.name.last){
    customerLastName = customer.name.last
}

This is an awful lot of repetitive code, and you really don’t want to be writing it over and over again. But, what’s worse than having to write it, is actually having to read it later on.

To see the amount of repetition in the above code, let’s break down the word frequency. The top repeated words are

customer: 5
name: 3
last: 2
customerLastName: 2

If you count phrases too,

customer.name: 3
customer.name.last: 2

There are actually numerous hacks out there already dedicated to solving this problem for ruby, groovy, and other various programming languages.

In this post, I am going to investigate two approaches to tackling this in Javascript.

Approach 1

Because null isn’t an object in Javascript, approaches like andand won’t work. So, what do we do when we want to extend something but can’t modify it? Right! We wrap it! This approach is called NullSafe. Basically, like jQuery, you wrap the object you want to query, and then chain method calls to it until you get the result you are looking for. At the end, you have to unwrap it to get the computed value. What I came up with is this:

var customer = database.get(id)
var customerLastName = NullSafe(customer)._('name')._('last').val() || "Unknown"

Actually, I made it a little more powerful than that, even. In addition to getting an object’s properties, you can also call methods:

var customerLastName = NullSafe(database).$('get', id)._('name')._('last').val() || "Unknown"

Then I added just a bit more convenience with the variable length arguments for getting a chain of properties:

var customerLastName = NullSafe(database).$('get', id)._('name', 'last').val() || "Unknown"

How is this? Is this good? The syntax takes a little getting used to, but the advantage is that you only have write each thing just once, rather than the big repetitive mess you saw above. Also, chaining allows you to write everything in one line.

The implementation of NullSafe is pretty simple too, all but 30-plus LOC,

function NullSafe(obj){
    function NullSafe(obj){
        this.obj = obj
    }
    Wrapper = NullSafe
    var proto = Wrapper.prototype
    proto.call = proto.$ = function(){
        var name = arguments[0]
        var args = Array.prototype.slice.call(arguments, 1)
        var obj = null
        if (this.obj){
            var func = this.obj[name]
            if (this.obj && func){
                obj = func.apply(this.obj, args)
            }
        }
        return new Wrapper(obj)
    }
    proto.get = proto._ = function(){
        var curr = this.obj
        for (var i = 0; i < arguments.length; i++){
            if (curr != null){
                curr = curr[arguments[i]]
            }
        }
        return new Wrapper(curr)
    }
    proto.val = function(){
        return this.obj
    }
    proto.toString = function(){
        return String(this.obj)
    }
    return new Wrapper(obj || this)
}

But then you might wonder why in the world I didn’t just use a try-catch block?

var customerLastName = "Unknown"
try{
    customerLastName = database.get(id).name.last
}catch(e){}

Approach 2

As you saw, the try-catch approach isn’t so bad. It is a bit verbose, and spans multiple lines, but we can fix that.

var customerLastName = $try(function(){return database.get(id).name.last}) || "Unknown"

Pretty nice! Although the actually code is slightly longer than NullSafe, this is easier to understand because within the inline function you are just writing what you would have normally written anyway if you hadn’t had to do the null checks.

The implementation is even simpler,

function $try(func){
    try{
        return func()
    }catch(e){
        return null
    }
}

Performance

I normally don't prematurely optimize, but with jsperf.com, I thought I’d be fun to compare. Intuitively, $try should be faster because it’s doing less, but then again, exception handling can be slow.

I created two separate tests, one in which the chain would have values all the way through to the end, and another in which it would null-out early.

Results

The results were - drum roll please - $try was significantly faster in almost all browsers, the only exceptions where is the null-out early case for Chrome and Firefox, where it was only slightly slower - 20% - 40%. But in all the other cases, $try was faster, in some cases, much faster - almost 7 times in Safari.

Conclusion

With that, I will conclude that $try is my preferred approach, given that it is easier to implement, produces easier to understand code, and executes faster that NullSafe.