Who the Hell Would Ever Use this F@#ing Language Anyway?

The title of this section is dedicated to a one-time Club AJAX attendee who looked at the next example and was so frustrated at how little he understood it, he started blurting out obscenities. Needless to say, he is now sentenced to life, doing Java.

So, to paraphrase Jack Nicholson… wait until you get a load of this:

“Waitaminute!” I hear you say. “I applied the context to the function, and onTimeout fired — why didn’t this.x resolve? And who the hell would ever use this language, anyway?”

I empathize, really. But remember, you don’t know how to paint without knowing about the color red, and you can’t really say you know JavaScript unless you know about context and all of its pitfalls. When you are able to understand this concept, it will elevate you from just a guy who writes some JavaScript to outright NINJA!

Before we can decipher why the previous example doesn’t work, let’s change it up so we can better break down the issues.

Example #2 basically substitutes otherMethod for setTimeout, so we can side step that particular nuance for now. This example shows a similar situation: we are passing a method to another method and trying to invoke it. However, this.x is still undefined. The reason for this is kind of tricky.

Yes, we used this with onTimeout. But we only used this in order to find onTimeout, we didn’t use it to invoke onTimeout. If we didn’t use this, we would get an error saying the function onTimeout is not found, which makes sense, because that would indicate we want a function (as in, var onTimeout();), but what we really want is a method. So we use this, to get the method, and pass it to this.otherMethod.

The Reason

Ironically, if m() or otherMethod() invoked this.onTimeout, it would work. But when we retrieved the method we sort of “extracted it” from the object, and passed it as a variable, of a function if you will. It’s no longer a method, it’s just a function with no call object bound to it. So we need to re-bind this, which we can do with the call() method:

Is “this” Broken?

We fixed it, but I sense dissatisfaction in you, young Skywalker. “Why should I jump through these hoops? This language is broken!” I agree that this aspect is at the least confusing and seems just plain wrong. But there is a reason for this behavior, believe it or not. Remember, JavaScript functions are just data and can be passed around as such.

Okay, if you don’t believe me, perhaps you’ll believe Brendan Eich from this Talk:

[The reason for the keyword "this"] is I wanted functions, which are the main idea in JavaScript, to also be methods; and for them to be methods, they had to have a receiving object who’s property was the value of that function.

That explanation was a bit… recursive. Perhaps a simple exercise will help. In Example #4, one object copies a method from another. What should be logged, 10 or 20?

If you answered 20, you’d be correct. Even though o.m was copied as data, it was still invoked on the last line with the o2 object, which set its context. But you may see what the issue would be if a copied method carried its context around. Then the answer would be 10, derived from the original object. That would make JavaScript look even more broken.

The following is another example of the use of call(). You can borrow a method from one object and apply it to another object temporarily:

In Example #5, o.changeProps(1); invokes as normal, but the last line, o.changeProps.call(o2, 1); calls that same method, yet invokes it within a different object. Admittedly, this example is a bit contrived and is probably making you squirm from all the best practices it violates. But it does show the versatility of the language and exactly how call works.

Now that we have a better understanding of context and how to fix it, we can readdress the problem in Example #1. However, we can’t use call() to fix the context, because that would have to happen within the setTimeout function and we can’t change native code. Well, we could, but that would be like trying to waterproof a screen with a toothpick. Because the same problem will arise again and again, in callbacks, connections, and myriad other places. We have a better way.

Bind

The problem can be fixed with the new bind method in JavaScript.1.8.5. And in spite of the complexity of the problem, the solution is really quite simple:

Now that this is bound this.setTimeout, we can pass it around and it won’t lose its context. And that’s it! Fixed! Good night nurse!

What’s that? Does this work in what other browser? Hm, I promised some sort of ninja status, didn’t I? That would necessitate some sort of explanation.

Bind Under the Hood

First of all, no, this does not work in that browser, but we can home brew a utility method that does, which we will add it to the prototype object of the Function constructor. Ever added the forEach method to Arrays? We’re doing the same thing here except with the Function’s prototype.

What we need to do is take our existing function and the context passed, and create a newly bound function. We are not going to return the bound function directly because if we did, it would fire immediately, which we don’t want. We are passing the bound function as data to be invoked later. Therefore we need to return another function that has the bound function inside it.

You’ll notice that the function is bound with apply() instead of call(). This is because our utility code has no idea how many arguments may be passed, and apply() handles a variable amount… of variables.

Include the Simple Bind Prototype early within your code, and Example #6 will work — in all browsers.

But Extending Native Objects is Bad

Oh, so you’re one of those purists who believes you shouldn’t mess with native objects eh? That’s okay, I’m concerned about that too. The tide is shifting a bit in the JavaScript library developers community that it’s okay to extend native objects (not host objects) — as long as those extensions are to fix gaps in weaker browsers with standardized functionality. And of course if it’s your code, you can do whatever you want!

And… what you want is to not extend the native object? That’s actually a good thing here, because the wrapper-implementation is a little more clear in how it works as there isn’t the confusion of what “this” is, as in Example #7.

If using the wrapper implementation, you would change the code from setTimeout(this.onTimeout.bind(this), 1);
to:
setTimeout(bind(this.onTimeout, this), 1);

The bind method passes the argument object, which is quite handy on callbacks. The following example is a recreation of a callback mechanism, which demonstrates how variables are passed:

The Mozilla Implementation

You may have taken a peak at the Mozilla bind page, which would be only natural since I linked to it. I didn’t recreate their functionality because it’s a bit complex. Our solution handles 95% of what you would ever do with bind(), while theirs handles new concepts like binding to instance constructors and Arrays. But feel free to experiment!

Conclusion

Congratulations. If you made it this far into the blog and haven’t reached for a bottle of aspirin, bottle of alcohol, or a noose, that means you’ve managed to absorb one of the hardest concepts in JavaScript. Context is the key differentiator between JavaScript and all the other major languages.

Scope

The following shows a very simple example of the use of scope. funcA has access to var a, and funcB has access to var b and var a:

The second log in Example #1 fails because a function captures its scope, and keeps it all to itself. Nobody else has access to funcB‘s scope, not even funcA. However, when funcA captured its scope, it included funcB and therefore funcB has access to all of funcA‘s goodies.

Confused? Try looking at scope as a box made with one-way mirrors. Nothing can see inside the box, but the contents can see out.

Closures

A closure is when you then pass funcB to another function somewhere. The scope of funcB is then captured, or, “enclosed” and passed along with it. An in-depth look at closures is beyond the “scope” (heh heh) of this article, but you can learn more than you ever wanted to know about them from Jibbering.

Context

When learning the JavaScript language, scope gets all of the attention, but the concept that is most difficult to grasp is context. Not knowing what context is and how it works is like trying to learn to paint and not being aware of the color red. The term context can loosely be related to usage of the keyword “this”. Hopefully the following example is obvious:

Both x’s are able to be accessed because this.x is a property within the m() method’s context and var x is a variable within its scope. They do not clobber each other.

That was simple enough, but things start to get tricky when functions are used within methods. Take the following modification to the example:

Example #3 logs 1, undefined. What happened is that the f() function was treated as a method. In the previous example, this worked because m() was a method and had the context of o. Note the difference between writing o.m = function() and var f = function(): m() has a receiving object while f() has no such object.

One solution to work around the previous nuance is by accessing x through the global object. Instead of this.x, o.x could be used and that would work.

But if the solution is so simple, then what is the need for the keyword this? The reason is you don’t always know what object you’re in, especially with the use of object instances.

Now this.x is part of an instance object, and there can be several, or even hundreds or thousands of object instances. So it becomes impossible or at least unrealistic to try and access the properties via the object name.

So perhaps we should just make f() a method, and then it will have access to this.x?

Oops. That was definitely not the right thing if you need access to both var x and this.x.

Using Context to fix Scope

So how to fix… this… example? One possible solution is to create f() with this context, within the m() method:

Now calling this.f(), works pretty well because now not only does f() has the context of the instance1, but it was created within m(), and so it captures that scope, which includes var x.

Using Scope to Fix Context

We’ve probably all run into the following scenario at one time or another.

When I first encountered this situation several years ago, I was perplexed for days. It’s a hard problem to resolve because you don’t really know what’s wrong and what keywords to use to search for solutions.

The problem is the context is broken. The way JavaScript currently works is if a function doesn’t have context, or is not a method associated with an object, it executes in the global space. That should help identify the issue: setTimeout contains an anonymous function that is not associated with this, therefore, this.onTimeout does not resolve correctly.

We can fix this, literally, by assigning it to a variable:

this is nothing more than a keyword that is is used to refer to an object. In this case the object is o, and previously it was the C object instance. Since it is just an object, we can assign it to a variable. By convention, the most popular variable name is self since we are referring to our “self” in a sense. Now when onTimeout is invoked, it is done so with the proper context and the code works correctly.

Conclusion

Knowing the difference between scope and context will not only help you understand the JavaScript language better, but you’ll be better able to communicate with other developers and ask the proper questions. Likewise, knowing the difference between methods and functions, and properties and variables is important to communicate exactly what it is you’re referring to. Remember, var x and this.x are not the same thing!

Understanding this dynamic helps build better communication with the client. If the client asks that the button be moved to the left, and you respond it’s better on the right, you may insult them and their process. Their process may have been:

• Recommendations from usability studies.
• Consulting with expert button location professionals
• Several all night meetings among team members who sweated over the button location

It’s likely none of these, and was probably that the client thought about it in his car on the way to work. But either way, the client had a process which incidentally left you out. How do you resolve this? Ask questions.

When presented with only a solution it becomes a riddle. This may put you in the position of having to reverse engineer their decision to get to the problem. Why do you want the button there? Is it because users aren’t clicking on it? Did a customer complain? Is it because your daughter is left handed?

For the most part, moving a button is easy and is probably the best solution to make the client happy. But what if it’s a complex solution like asking you to increase the buffer time on the video player? If I don’t ask questions, it may go down like this:

I spend a few hours increasing the buffer time from 2 seconds to 5 seconds (this took a long time because it auto-buffered before and there was no code to have a custom setting). The changes are tested and pushed to production. The client now asks for a 10 second buffer. The changes are pushed. The client then says this isn’t working, now customers are complaining that the video takes to long to load, and the buffer time isn’t even helping… on mobile phones. You reply, “Oh, well this code doesn’t affect mobile phones.” The customer replies “Oh, well, I need the videos to load faster on mobile phones.”

Getting the problem at the end of the process is obviously unproductive. All those changes were made was a waste of time and money, and it turns out they hurt the product while the real problem wasn’t addressed — which in this case may not have something completely different, like a video encoding problem.

Unfortunately we developers are often not the ones interfacing with the client. When a project manager tells me he needs a change, I get real frustrated when he can’t answer my questions. “But the client made the request, so I didn’t question it.” The truth is: we are not in the business of doing as we are told. We are in the business of making the client successful. Which may at times even be in spite of the client’s wishes. I’m not saying to be defiant, because sometimes the client may need to go through a learning process himself. Just make sure you have your change order prepared.

The Rookie Dilemma

What do you do if you are so low on the developer food chain that you simply are not allowed in the process and have to just do what you are told? Same thing — ask questions. If you’re not asking questions you’re not learning. But note there is a fine line between asking questions and questioning authority. “Moving the button to the left destroys the flow of the page — it looks stupid there!” is more professionally phrased as “Okay, although that would upset the flow of the page. Just so I know, why are we moving it?” If your questions are intelligent enough, you may trigger a new discussion with the client — and you may even be invited to the party. We’ve all started low on the totem pole at one or multiple times in our career. Asking good questions is just one way of making the climb.

Conclusion

Don’t give the client what they ask for — give them what they need. I’m not going Zen on you. It’s a simple matter that most of the time they don’t really know what they need, so they ask for the wrong thing. The most successful man I ever worked for once said “It’s easy to make the smart clients look smart. But the real money is in making stupid clients look smart.”

Max Motovilov gave a presentation on MDV which was enlightening and thought provoking. He showed how he leveraged The Dojo Toolkit to create behaviors and data stores which update his views through his custom-built template system.

Max’s detailed presentation can be seen here, and you can also see the examples he used on GitHub.

Precedence

You already can run other languages in a browser. There is a TCL plugin; IE has VB Script; and there is also C# in the form of Silverlight. And who can forget the most popular plugin and language on the web today…. Java FX!?

Flash is the obvious precedent, since at one time in the early 2000′s it actually did replace JavaScript. However, since then we’ve had HTML5 with new language APIs, a new and improved browser war with faster engines, and Harmony with buy-in from all the browser vendors.

Flash is also a good example of how you can reach too far. Flash has and has had many impressive features, but a lot of these were later hindered by internet security issues. So we can, for example, wish for a browser language with access to the local file system, but that’s not going to happen. So what then can we wish for?

What is not the problem

One thing I don’t want to see is strict typing. Okay, maybe a little bit of optionally typed variables, preferably in vectors or typed arrays for speeding up Canvas and 3D. Otherwise, loose typing is what makes JavaScript so versatile. AS3 went to a rigid, Java-like syntax, and it’s not very fun to code.

As we all know, JavaScript is not the problem nor bottleneck in web page performance. It’s the DOM, browser compatibility, and server requests. This narrows down the situation to pure language features. HTML5 has added features that make JavaScript more robust than ever. Workers are a simple API (though more difficult in practice) that allow multiple threads for unprecedented scripting power. They also added Storage, so now we don’t have to suffer at the hands of a 4K cookie. Once Web Sockets security is figured out, giving us faster and more consistent server connections, what more do we need?

Structure

I love the lack of structure and wild west nature of developing in JavaScript. But realistically, it’s very difficult for devs to jump between different libraries like jQuery, MooTools or Dojo. This is a delicate balancing act however, because JavaScript is already a great language and the task is to make it better, not more restrictive. Any structural code changes need to be optional.

Modules

It’s flabbergasting to me that CSS has @import and JavaScript doesn’t. I think that can only be explain with “What the Hell?” Dojo’s bread and butter is its script loader — solving a problem that shouldn’t be there in the first place.

Packages

The unique thing about a Flash movie SWF is that it is a self contained file that can include all the necessary resources, minimizing or eliminating multiple server requests. JavaScript has no such ability, save some real kludgy experiments. Mozilla is addressing this issue with their Resource Packages Proposal.

Classes

Yes, JavaScript has prototypes and we have our syntactic sugar to give us inheritance, but again, it’s hard to write standardized code. jQuery, MooTools and Dojo all address this limitation is vastly different ways, fracturing web development.

Fix this!

It would be nice if ‘this’ were optional. Object oriented code is a bit discouraging in JavaScript because you are punished with tens of hundreds of ‘this’ keywords peppered throughout your code, which bloats it and doesn’t help readability. It also hampers newbie developers who have trouble grokking the concept of context invoked functions (like say, calling an object method from a setTimeout). Adobe claims to have fixed ‘this’ in ActionScript 3.0… but not really. ActionScript is essentially Java with JavaScript mashed on top of it. When you write actual ECMAScript in an ActionScript file, you need to use ‘this’ or the compiler gets confused.

What I’m suggesting would require the co-mingling of context and scope. The variable search would start with the initially scoped function, then the object and prototype chain, then the remainder of the scope chain. Would this implementation affect performance? When I write a JavaScript engine I’ll let you know! Until then, I’m punting to the browser vendors!

Protected Variables

Yes, everyone wants their precious private variables, but I’m on record for not being a fan, as I feel they are over used and abused. Protected variables on the other hand, give you the best of both worlds: the public API can be exposed as the clear intent, and the protected variables and methods can only be accessed or changed if the class is extended to explicitly override them. If you want to change my library code you need to work for it, yo!

Maff

Yes, I’m referring to the fact that .1 + .2 = 0.30000000000000004. I understand that it’s common problem in floating point numbers using binary digits. I also concede that this situation rarely is an issue for me, because I do largely graphical work, not work that requires extreme numerical accuracy like accounting. Regardless, a new Math namespace would be a welcome addition, and even better, it could be a strictly typed namespace that allows only floating point numbers.

Tooling

The Google memo says that one major problem with JavaScript is the lack of ability to “tool it”. Not being a server side programmer (and when I play one on TV, I use PHP), I’m not familiar with these tools, or lack thereof. But I’m guessing they are referring to the loose and dynamic nature of JavaScript not allowing an IDE like Eclipse to track objects and report broken code. I’m going to punt a little bit here, and claim: the lack of tools forces you to write better, loosely coupled, encapsulated code. Tools make you lazy! I can hammer in nails with my forehead and drive screws with my teeth! Raaawarr!

Standards Politics

At first glance it may seem to be a great benefit to develop a language outside of the W3C and their sometimes draconian politics, their self centered policies, and their ability to take a great idea and turn it into a shitty one. Lots of languages are written, but only a few catch on. For every great language like Python, you get several like DOS, LotusScript, Authorware, Lingo, or Cold Fusion — or any other Macromedia derived language. Speaking of Macromedia, the early Flash scripting language was proprietary, cumbersome, and unusable. They switched to an ECMAScript-based syntax, and ActionScript exploded with success.

Believe me, I’m not championing the standards body that almost killed off HTML. Nor am I saying that designing a language by committee is a good idea. It’s just that you are fighting an uphill battle if you throw out the standards and start from scratch, even if it’s a better idea. The US System of Measurements is an example of design by a committee of retarded orangutangs flinging their feces at finger paintings to make their discussions — yet the Metric System was not widely adopted. Yet while Python was invented by one guy, it evolved in an open source community.

Conclusion

Can JavaScript be replaced? My guess is at worst never, and at best ten plus years. JavaScript developers are very protective of their domain, sometimes to a fault, and they don’t appear to be very welcoming of changes; they often are even averse to Harmony proposals. New technologies require a killer app in order to catch on. Flash had YouTube, Silverlight had NetFlix, and Java FX had… well, I rest my case. Since Dart has corporate giant Google behind it, a killer app is definitely not out of the question. And if so, the big brains at Google could make this happen.

The Ajax News was not recorded this time, but it was based on existing presentations from Google IO. The latest and greatest in HTML5 have landed in the Google-backed Chrome, which has surpassed the Apple-backed Safari as the browser introducing the most cutting edge features. Safari, Firefox, IE, and Opera better put it in high gear if they want to keep up.

http://html5-demos.appspot.com/static/html5-whats-new/template/index.html#1

http://www.htmlfivewow.com/slide1

NOTE: These presentations must be run in Google Chrome 12+. Also, you may need to enable some features, like audio in the about:flags.

Before getting into Declare, here is an example of the traditional prototype method:

var Play = function(options){
	this.type = "play";
	this.init(options);
	this.isPlaying = false;
	this.toggle = function(){
		// toggle between play and pause
	}
}

var Volume = function(options){
	this.type = "volume";
	this.init(options);
	this.openVolumeSlider = function(){
		// open popup
	}
}

var Base = {
	init: function(options){
		this.node = options.node;
		this.player = options.player;
		this.video = this.player.video;
	},
	update: function(p, vert){
		// do something common...
	}
};

Play.prototype = Base;
Volume.prototype = Base;

There are several problems with this. The first (minor) annoyance is that as I would add new components, I would forget to add the Component.prototype = Base; code. Next, in order to add properties and methods to the main classes (Play and Volume) they have to use this within the constructor, as opposed to my preferred style of assigning them within an object literal, as used in the Base class. There are minor technical penalties for assignments in the constructor, but mostly I don’t like having to use this before every line which makes the code less readable. But fundamentally, this is limiting. I can only combine a parent class and a child class, and that’s it. Any other combination overwrites something.

The Declare Inheritance Helper

I started with the declare system I wrote for DojoX Drawing. This system accepts functions as constructors and objects to be mixed in — or functions as classes where its methods and properties are already mixed in. This did what I wanted, but I realized that it was still on the ugly side. Jamming a function as an argument followed by an object literal followed by object names… it’s self contained but there was no flow. I decided to rework it.

I realized that I didn’t need to have a separate function and object which gets put together via a prototype — I could just pull the function out of the object! Duh! That’s what Dojo does!

So it was a simple matter of having a conventionally named method act as the constructor. First I used “init”:

var Foo = declare({
	init: function(){
		// this is my constructor
	},
	update: function(){
		// do something else!
	}
});

There was still one problem. I ran into a couple of situations where I wanted to know what class I was within. I started by just sticking a type in every class, but this was extra work, not to mention bytes. I originally wondered if I could somehow pull the name out of the assigned variable, like:

var Foo = declare({
	this.declaredClass = getInstanceVariableName(); // not a real method!
})

Well of course you can’t do that, but that thought process led to an idea. What I could do is name the constructor the same name as the class — and capitalize it — which is not only semantically correct (a class function should conventionally begin with a capital) but this can signal to my helper code which method is the constructor. And it’s not so crazy of an idea since this is the same convention used in AS3 and Java. So now my code might look something like this:

// sub classes
var Foo = {
	Foo: function(){
		// I am capitalized, therefore I am... constructor.
	},
	update: function(){
		// update something!
	}
};

var Bar = {
	Bar: function(){
		// Initialize, constructor!
	},
	draw: function(){
		// Draw something!
	}
};

var Zap = {
	Zap: function(){
		// By now you know what this is!
	},
	remove: function(){
		// remove something!
	}
};

// main, derived class
var CustomClass = declare(Foo, Bar, Zap);

// instance

var myClass = new CustomClass();

Declare Library Code Explained

The following is the declare inheritance helper. It’s simple, small, and has no dependencies:

declare = function(){
	var i, a = arguments, constructors = [];

	var Class = function(){
		for(i=0; i<=constructors.length-1 ; i++){
			constructors[i].apply(this, arguments);
		}
	}

	for(i=a.length-1;i>=0;i--){
		for(var n in a[i]){
			if(/^[A-Z]/.test(n)){ // testing for capitalized key words
				constructors.push(a[i][n]);
			}else{
				Class.prototype[n] = a[i][n];
			}
		}
	}
	return Class;
}

Declare expects one or more objects. It loops through the arguments, pulls the constructor out of each one based on a capitalized key word, then copies the properties and methods into the (temporary) Class function prototype. The array of constructors are then combined in reverse order so the last one fires first, allowing subsequent constructors to overwrite any properties the previous ones may have set. Finally, the Class function is then returned, which gives you your derived, custom class. When the custom class is fired, it loops through the child constructors and fires them all in the proper order.

Fixing instanceof

There is an issue in that instanceof doesn’t work with this pattern. But really, the only purpose for instanceof is to know what type of object you are in. For this implementation, saving the function names and testing for them works perfectly well. Remember, that’s why we are naming our constructors the same as the class names, and not using the same thing over and over, like “init”. We have a built-in ability for getting the class type, we just need to provide access to it.

Now, when the custom class is fired, it assigns the classes property:

declare = function(){
		var i, a = arguments, constructors = [], classes = [];

	var Class = function(){
		this.classes = classes;
		for(i=0; i<=constructors.length-1 ; i++){
			constructors[i].apply(this, arguments);
		}
	}

	Class.prototype = {
		isClass: function(cls){
			return this.classes[this.classes.length -1] === cls;
		},
		isSubclass: function(cls){
			for(var i=0; i < this.classes.length; i++){
				if(this.classes[i] === cls) return true;
			}
			return false
		}
	};

	for(i=a.length-1;i>=0;i--){
		for(var n in a[i]){
			if(/^[A-Z]/.test(n)){
				constructors.push(a[i][n]);
				classes.push(n);
			}else{
				Class.prototype[n] = a[i][n];
			}
		}
	}

	return Class;
}

The isClass and isSubclass methods are added for convenience, so now we can test from where the instance was derived:

var o = declare(Foo, Bar, Zap);
console.log("is Foo:", o.isClass("Foo")); //true
console.log("has Bar:", o.isSubclass("Bar")); // true

Conclusion

I’ve written inheritance helpers before, but I was always concerned about extending existing classes, assembling both functions and objects, and therefore rearranging the arguments order. After I stopped worrying about these relatively needless features, the inheritance system became downright tiny! You are free to use and download it from Google Code, or hopefully it just helped you to understand how simple inheritance in JavaScript really is.

And we also have Bob doing the Ajax News, where he focuses on an interesting blog and topic, The 11 JavaScript Mistakes You’re Making.

Yes. The Dallas Mavericks are playing game 4 of the finals that night. We looked at changing the date, but that didn’t work – the Mavericks wouldn’t cooperate and move the game to Wednesday… something about TV schedules and 20,000 ticket holders.

Hence we’ve opted for an easy-going meeting, but it should still be fun! And I will have the Mavs game queuing up on my DVR and will be racing home to see them win!

GO MAVS!!