JavaScript for OO programmers, Part 1 – Introduction

Many many blog posts have been written about JavaScript as a programming language, books have been written, in order to explain and educate about this singular programming paradigm. Why? Because it’s a ruddy confusing language sometimes, and to those who are coming from a standard OO background, it can be one of the most frustrating languages to deal with. This, then, is the first in a series of posts in which I will attempt to explain JavaScript from the perspective of an OO programmer, because I share your pain, guys and gals. I started getting interested in JavaScript about 4 years ago, and I’d like to try to help you avoid some of the mistakes which I made when I was first getting into it.

If you’re like I was about 4 years ago, you’re a budding web developer who’s getting interested in JavaScript and what it can do. The explosion of JavaScript on the Web over the last few years, and the quality of the code being written, is astonishing. The number of frameworks now available which make using JavaScript so much easier to use than in the past have led to its near-ubiquity across the domain of public-facing websites as well as corporate intranets. Why all the fuss, then? And why do object-oriented programmers fear it so? Some of my good friends, some of the best developers I know, absolutely loathe dealing with the stuff. After all, at first glance, it looks similar to C#. But beware.

Problem #1

JavaScript is not really like any standard OO language. True, it shares syntactical similarities with Java and C#, but it doesn’t behave like them, and therein lieth the rub, to paraphrase the Bard of Avon. Sparkly-eyed young developers, with dreams of Internet superstardom, see JS code and think “That looks rather like that C# code I’ve been writing! What could possibly go wrong!” More on this later.

Problem #2

Cross-browser compatibility. JS executes almost universally in the browser. True, this is not a tautology; it is not always necessarily so, but in reality the vast majority of you will be looking to do some sort of DOM manipulation. This is a problem, because a lot of browsers handle it differently. The event model, for instance, is different between the Internet Explorer and Gecko engines. Window instantiation is handled differently. The W3C DOM specification is not implemented correctly in some browsers. So you end up writing loads of boilerplate code to cater to this.

Problem #3

Performance. Badly-written JavaScript is one of the biggest site-killers on the planet. Some developers are lazy and don’t consider performance when writing their code. Others are just happy to have the damn thing working. But either way, there are a lot of things working against you. JS is interpreted, not compiled, which means that it doesn’t run natively (although the Chrome JIT engine blurs that line). Bandwidth can be a problem on slow connections, because the code can’t execute until it’s downloaded and parsed by the client. And then there’s the dreaded Internet Explorer 6; the possessor of not only the worst CSS rendering engine, but by far and away the most buggy, leaky and non-performant JS engine ever assembled by man.

There are many other problems which can hinder your enjoyment of and facility with JavaScript, but for the moment, be not afraid; with the right guidance and a little bit of hard work you can really make this little gem of a language work for you and not against you. Hey, because JS is so quirky, you might even have a little fun along the way. I certainly did.

OK, end of my first post. My Mum’s calling. On to the next post, intrepid web developer; “The Things To Watch For”.