We met when you were 1.5, and started dating when you were 2.0. We enjoyed making fun of my clueless ex, Internet Explorer. IE seemed great at the time, but you showed me the error of my ways. IE was selfish and wanted to do everything its own way. You truly believed in collaboration and gratefully accepted suggestions. When you brought Firebug to the party, I became deeply committed to our relationship. Before Firebug I had no idea how difficult my life was, or the abuse of “error on line 0 character 0″; or blank, failed, pages and the silent treatment. You were very up-front with my errors, and kept life spicy with tabs, smart bookmarks, and an Awesome Bar that was truly awesome. Sure you didn’t load pages as fast as the other browsers, but I’m not greedy and the most important thing in my life was never… “cache”. Life was never boring, and at the nearest hint that it was, you would whisper in my ear, “I have a new AddOn…” And boy oh boy, I’ll never forget the first night with that Greasemonkey.

Soon after, other browsers began vying for attention. Safari spawned Webkit, Opera was talking about an HTML5 thing, and Chrome had a hot V8 engine. I honor my commitments, and planned to spend the rest of my career with you. I know the grass is always greener, and it’s important to love the one you’re with, and many more cliches, songs and metaphors.

But relationships are a two way street.

At first, I thought the fact that you didn’t play well with Flash was funny. I mean, you and I are all about HTML5, right? You put Flash in a (sand) box, kneed it in the groin, and we laaaaaa-ughed!

However, I work with video a lot. I understood your attraction to Ogg Vorbis, I really did. But nobody else wanted to play with your hippy friend. Later, I was as excited as you when your rich Uncle Google introduced WebM to everybody. WebM was so charming and intelligent — all the developers were swooning. But WebM had skeletons in the closet and just didn’t make good on its promises. Then WebM was stood up by none other than… Flash. You know you’ve hit rock bottom when the town drunk stands you up.

I’m glad to see you are opening up to the idea of H264. Your ideals were great, but we can’t live on a commune eating tofu forever. Don’t get me wrong, no love is lost on H264, or as I call it, H666, that patent troll who comes to every party claiming someone stole its idea for chip dip. Thanks to you and your rich uncle, H264 was afraid nobody would play, and so agreed to never charge admission. It’s time to help the web move on and think about other things. H264 may be evil, but it’s not kittens in the microwave.

Firefox, I can overlook all those things. You’ve been making it tough, but that’s okay — life is tough. But something serious has come up. I noticed you had memory problems since 3.0. I thought it might get better over time, but you’re 11 now. Your memory is starting to interfere with our relationship.

Which leads to a confession I have to make. A developer has needs. I’ve been seeing your cousin Chrome on the side.

My wandering eye started with video. Choppy, stuttering, almost unwatchable video. Yes, it was in large part due it playing through that mentally challenged plugin, but you didn’t leave much option, did you? Oh sure, you use HTML5 to play WebM and Ogg beautifully… but you know what pages use WebM and Ogg? NONE OF THEM!

Recently at a party when you were chatting with your highfalutin W3C friends about whether video should have a fullscreen API, or whether images should be allowed in canvas cross domain, Chrome cornered me in the bathroom. With trembling fingers, I began opening webpages that had videos. And guess what?

I liked it.

I never meant for it to happen. It was just one of those things. I became witness to a new world where a video would play from beginning to end without a stutter. Even more exciting, I discovered that I could actually smoothly scroll pages again. Don’t pretend to be shocked Firefox, you know what I’m talking about! How you give me the cold shoulder and freeze everything while you battle your memory-management Tourette’s Syndrome as I try and scroll a page that is still loading. Which as mentioned, you take your sweet time to do.

Sorry. I didn’t mean to get angry. I tried looking the other way. I tried reading email while you were busy being busy. But it’s gotten so bad that people are starting to blame my code for being slow. I hate to say this, but Firefox, it’s not me… it’s you.

We’ve had some good times. I never thought of myself as the type who needed a trophy wife, but Firefox, I deserve better. Chrome is hot, available, and every time I look, I see her heaving that ample bosom.

But don’t worry — we’ll continue to see each other since we share 20% custody of users.

By the way, there is someone named MP3 I’d like you to talk to…

Sincerely,
Mike

Built by Rapiscan, thanks to help from from a six billion grant from the federal government, this new, simple device uses a completely unobtrusive set of electronic sensors that detects the slightest shift in brain activity and translates it into alphanumeric data.

The futuristic technology is on display in the following image which depicts a high-end developer writing code by only thinking.

Of course, this technology is brought to you by the same trusted company that builds the trusted and completely safe Backscatter X-Ray machines that are installed in every neighborhood airport. Continuing with that track record of complete safety, the new keyboard-less input device keeps you completely protected with state of the art grounding straps:

The next step for the Rapiscan keyboard-less input? To take your thoughts which may not even be thoughts and translate them into thoughts and then translate that into perfectly legible language.

There is an undocumented feature in HTML5: “IE6 mode”. After all the pain and suffering all these years, all we had to do was:

<script>
"IE6 mode"
</script>

Here is how Club AJAX looks in IE6 without the feature:

And here is how it looks when I add the simple code as shown above:

When you send a Photoshop document to another designer, pay some attention to how the layers and groups are named. It’s really hard managing the file of someone else where everything in it is named Layer 2, Layer 2 copy, Layer 2 copy 8, etc., etc. The first thing I generally do is start toggling the visibility of each to figure out which is which and naming things accordingly. But ironically, this has even burned me in the past. The sender actually had the nerve to complain that I wasn’t able to send the file back with changes because it no longer matched his “layer structure”.

And you know, I guess I also disrupted the communication as now we can’t refer to Layers in the file: “Look at Layer 13 copy 12. No, no, the other Layer 13 copy 12 in group 3 copy 6.”

I’m just saying, garbage in, garbage out. Show some professional courtesy before you send that PSD.

We will also do ajax news.

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.