We have to remember that JavaScript isn’t like most other languages. The majority of languages do as they’re told regardless of whether they’re machine languages, scripting languages, markup languages, or whatever else. When you tell Python to make an Array, we get an Array. When you tell ActionScript to create an Object, you get just that – an Object. We’re pretty safe in assuming the language we’re using isn’t lying to us. JavaScript, however, takes another approach. JavaScript has a plan – and you’re a part of it – it’s just going to take your ideas and try to do something better. Problem is.. it’s not always right.

JavaScript, along with the rest of the web platform, is not implemented by one organization. It is an implemented standard and nothing more. So, it is up to several teams to implement this standard and compete with one another (Mozilla, Apple, Microsoft, BlackBerry, Opera, and so on). But, it’s not just enough to implement the standard – it has to be fast, efficient, and… well… better than everyone else’s. Thus, each platform will try to make different assumptions and educated guesses as to what you’re trying to accomplish and find ways to make it run faster. Therefore, the more you cater to a JavaScript Engine’s ability to guess what you’re trying to do, the more you’ll see a boost in performance (and a surprisingly large one too). For example, if you have a sparse array (an array which has a lot of empty indices between ones that have values), an engine will typically manage that array as a dictionary to save resources, but it will cost you when it comes time to iterate over that array.

I could go on for an entire article about which particular optimizations to make (and I definitely will in my next post) but here I’m going to focus on how creating clean explicit code is an amazing start to make your JavaScript run faster.

OK. How do I this?

If you remember from my previous post, I wrote about all sorts of “good practices” junk but, most importantly, I touched on classes and inheritance. We all know JavaScript to be loosely-typed, polymorphic, and prototype-based. These characteristics of JavaScript can be incredibly effective and yet, if used incorrectly, you’re gonna have a bad time.

When we want to extend the functionality of DOM Elements, there’s really only so many ways to do this and the most effective being the following:

HTMLElement.prototype.someFunction = function(param1, param2) {
	// Your code here
};

Depending on the engine, this might compile someFunction into the HTMLElement class or it might create a separate “hidden class” for managing this new functionality behind the scenes. Either way, this slows down our application a great deal and needs to be kept to a minimum and only when necessary. A more common use-case is as follows:

var Point = function Point(x, y) {
	this.x = x;
	this.y = y;
};

var point3D = new Point(3, 4);
point3D.z = 6;

We have some class called Point which did a fine job of being a model for 2-dimensional coordinates. However, at some point in our application, we needed to keep track of an extra coordinate for whatever really good reason we have (don’t ask questions and just believe me) and so we decided to add the property z. To most JavaScript developers, this seems like an awesome solution. The problem is the engine that is interpreting our JavaScript code is going to have troubling guessing what we want to do and, in some cases, will keep a “hidden class” for Point and an arbitrary one for our one-time point3D variable which was created at runtime and, as a result, greatly slowed down our application. Instead we should have created another class called Point3D, or added the property z to the Point class and setting its default value to 0 like this:

var Point = function Point(x, y, z) {
	this.x = x;
	this.y = y;
	this.z = z ? z : 0;
};

This way we don’t break previous code that relied on this class and we now have a more generic point model for future 3-dimensional uses.

As our classes become increasingly complex and modifications to existing classes are required, constantly modifying our original class can turn our once easy-to-use reusable code snippet into a monster. This is easily solved with Object Inheritance. For example, perhaps we create a simple class for dispatching generic events like so:

// EventDispatcher
(function EventDispatcherStaticScope() {
	// Give functions an extra somethin' for the EventDispatcher to use.
	Function.prototype.EventDispatcher_ID = 0;	
	// A static variable for creating unique IDs
	var ID = 0;
	// The class itself (note no 'var' makes EventDispatcher global)
	EventDispatcher = function EventDispatcher() {
		// Private global variables to this class
		var _events = {};
		// more vars goes here...
		this.addEventListener = function(event, callback) {
			// Whatever goes here...
		};
		this.removeEventListener = function(event, callback) {
			// More codez
		};
		this.dispatchEvent = function(event, data) {
			// dispatching event logic
		};
	};
})();

Whatever the above class does exactly isn’t important. What is important is what we’re about to do next. Let’s say we want a Timer class for expanding the basal setInterval function JavaScript provides and giving it some event dispatching capabilities. We could do what we first did with Point and just add the necessary properties we need to an instance of EventDispatcher. Unfortunately, that code wouldn’t be reusable and, as we learned, will slow down our app while executing. We could copy and paste all of EventDispatcher‘s functionality but this wouldn’t help us keep our code DRY (Don’t Repeat Yourself) and any fixes would have to be made in two places. We can, however, have Timer be a subclass of EventDispatcher! This way, we can create a class our engine will make good guesses about while, at the same, extending functionality we might only need for now but can be easily reused later. Nice!

Here’s how you would go about it:

var Timer = function Timer(ms) {
	var __self__ = this; // Internal reference
	this.inheritFrom = EventDispatcher;
	this.inheritFrom();
	delete this.inheritFrom; // Save us a bit of memory.

	var _timer = false; // Class's global variable
	var timerDispatch = function() {
		__self__.dispatchEvent('timer');
	};
	this.start = function() {
		if (!_timer)
			_timer = setInterval(timerDispatch, ms);
	};
	this.stop = function() {
		if (!_timer)
			return;
		clearInterval(_timer);
		_timer = false;
	};
};

And, just so we’re clear, Timer has all the same functions EventDispatcher has – plus its own!

Creating classes and inheriting functionality is a sure way to keep your code running well, the JavaScript engine happy, and your code clean and easy to debug. This sure beats creating generic objects and modifying properties (deleting them and adding new ones) during runtime.

This is a lot to swallow and hence why I tried to focus only a few things for this particular post. Be sure to ask questions and I’ll be sure to answer them!

See you next time!

That’s pretty cool. And if you’re here wanting to develop mobile apps, that’s pretty cool too. We have an unparalleled HTML5 app platform which makes it very accessible for those familiar with building web apps to transition into making mobile apps. But is it ever that easy?

On the web, we’re accustomed to building page-to-page or AJAX navigation, as opposed to using templates and transitioning from view-to-view all within JavaScript; it’s a nice top-down/linear way of thinking. We start at the top with a request, scripts execute, and then the page is done. However, we want our apps to feel like apps – not like webpages.

So, we use all sorts of magical libraries and frameworks to do the legwork for us. We slap their scripts in the “head” tag, create some views, create either a server-side or client-side model, and then we have ourselves an app. But then it’s slow. Or it’s buggy. We try to fix it and the framework or library we’re using is picky, or requires more modification than what’s really worthwhile. We want to make changes (we know your boss asked for it) and suddenly we have to re-write our code. But what really happens is you hack something together that merges your codebase into one hot unmanageable mess. Next thing you know, the HTML5 app you’re building isn’t awesome. We want awesome. So let’s fix that.

Where Do We Start?

Before you can worry about writing efficient JavaScript, you need to write efficient JavaScript. Yeah, you read that right. If your codebase isn’t scalable or manageable, there’s no point in writing sneaky algorithms. In order to squeeze every bit of performance out of your app, you need to be able to see how your codebase talks to all of its different parts. If you don’t, you’re gonna have a bad time. Not only will this help you see your code more clearly, but it will help the JavaScript engine that runs your script see your code more clearly (and therefore, run your code faster). We will talk about that more in my next blog post, but for now, trust me!

You want to make each piece of code you write as modular as possible. Begin by thinking of your app as being made up of smaller programs. Just like you would group methods and properties together to make a class based on their function, group your classes together based on the tasks you need to perform. I like to call these wee programs “modules” – for the obvious reason that they keep your code modular. The only top-down/linear part of your script we want is the starting of these modules. From there, you should be able to start, stop, add, or remove them. Now you’re almost ready to write some awesome JavaScript. Below are some initial tips; we’ll get started with these, and then next time we’ll delve into other speed boosting and architecture tips.

Your code should:

1. Have a namespace/package. Organize all of your classes in a logical manner. This will enable you to have a large collection of classes without interfering with the names of other classes you have written or have included in your app.

   // EXAMPLE: Create our namespace
   	if (!window.com)
   		com = new Object();
   	if (!com.grahamzibar)
   		com.grahamzibar = new Object();
   	if (!com.grahamzibar.mouse_tracker)
   		com.grahamzibar.mouse_tracker = new Object();

2. Be able to run more than once. If your code breaks when it is called multiple times, you’re gonna have a bad time. This goes for everything: classes, methods, scripts, etc. You need to take into consideration that you’re code might run synchronously or asynchronously throughout the lifetime of your app and, as a consequence, may be invoked from two or more separate places from within your app in a very short interval of time. Below, we have a view that can be applied to any two DOM Elements and can be instantiated any number of times.

   // EXAMPLE:	
   	mouse_tracker.View = function View(renderContainer, bodyContainer) {
   		var MAX_VALUE = 255;
   		var MIN_VALUE = 225;
   
   		this.displayCoordinates = function(x, y) {
   			// Incremental string concatenation(sp?) is the bomb.  Trust.
   			var result = 'x: ';
   			result += x;
   			result += 'px - y: ';
   			result += y;
   			result += 'px';
   			renderContainer.innerHTML = result;
   		};
   
   		this.modifyBackground = function(x) {
   			var half_width = bodyContainer.offsetWidth / 2;
   			var val = Math.round((Math.abs(x - half_width) / half_width) *
   					(MIN_VALUE - MAX_VALUE) + MAX_VALUE);
   			var rgb = 'rgb(';
   			rgb += val;
   			rgb += ', ';
   			rgb += val;
   			rgb += ', ';
   			rgb += val;
   			rgb += ')';
   			bodyContainer.style.backgroundColor = rgb;
   		};
   
   		this.clear = function() {
   			renderContainer.innerHTML = '';
   		};
   	};

3. Usually be an instance of some class. If it isn’t, you’re probably breaking rule 2. Break rule 2, and you’re gonna have a bad time.

• Inherit, inherit, inherit. A view in your app should be some class (let’s call it app.pages.SettingsPage) which inherits some base view class (maybe app.pages.BasePage). This, in turn, probably inherits some event dispatcher (perhaps events.EventDispatcher) so another class can use it to display page request and load progress by adding event listeners. This is a great way to help keep your code DRY (http://en.wikipedia.org/wiki/Don’t_repeat_yourself).
• Disposable. When you create an object and it does all sorts of things like add timers and subscribes to events, always write the reverse so you can clean-up when needed. You never know when this will come in handy and will save you hours of headaches and frustration. This will help you keep on top of removing event listeners and references to objects that are no longer required to avoid memory leaks and buggy code.

  // EXAMPLE:
  	mouse_tracker.Controller = function Controller(model, view) {
  		var onChangeModel = function(e) {
  			view.displayCoordinates(e.x, e.y);
  			view.modifyBackground(e.x);
  		};
  
  		var init = function() {
  			model.onchange = onChangeModel;
  		};
  
  		this.dispose = function() {
  			model.onchange = null;
  		};
  
  		init();
  	};

Let’s use the above concepts together in a quick code sample. The only item in the above list I didn’t get the chance to use was inheritance. It’s a bit beyond the scope of the code sample this time around, but I’ll certainly touch on that next time when we talk about events.

I have a very particular way I like to write my JavaScript that tends to boggle developers from time-to-time (note the way I write classes). Therefore, feel free to ask questions in the comments below and I’ll be sure to respond as best I can.

Later, mobile devs.

Our very own @mendozamiche, @naveenan5, and myself - @grahamzibar will be in downtown Toronto for a hands-on WebWorks experience this coming Monday, January 21st starting at 6 pm  We’ll be showing you how to build your first BlackBerry 10 app using the BlackBerry WebWorks SDK.

We’ll be doing awesome things like downloading the SDKs, setting-up your environment, enjoying some beverages, and a slew of other fun stuff you’ll need to know so you can make your first super awesome BlackBerry 10 app. I think there will be chicken wings too… (Confirmed – there will be chicken wings – Ed.)

Why come you may ask?? If not for the food, beer, and awesome people, everyone else is making BlackBerry 10 apps, so you should probably give into peer pressure and do the same.

Come see us at the Toronto BlackBerry Developer Group at the Fox & Fiddle this Monday. See you all there!

p.s. If you want to get a head start, try downloading the tools and getting your signing keys before the event.