Object-Oriented JavaScript - Second Edition

4 (4 reviews total)
By Stoyan Stefanov , Kumar Chetan Sharma
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies

About this book

JavaScript is the behavior, the third pillar in today's paradigm that looks at web pages as something that consists of clearly distinguishable parts: content (HTML), presentation (CSS) and behavior (JavaScript). Using JavaScript, you can create not only web pages but also desktop widgets, browser and application extensions, and other pieces of software. It's a pretty good deal: you learn one language and then code all kinds of different applications. While there's one chapter specifically dedicated to the web browser environment including DOM, Events and AJAX tutorials, the rest is applicable to the other environments


Many web developers have tried coding or adopting some bits of JavaScript, but it is time to "man up" and learn the language properly because it is the language of the browser and is, virtually, everywhere. This book starts from zero, not assuming any prior JavaScript programming knowledge and takes you through all the in-depth and exciting futures hidden behind the facade.

Once listed in the "nice to have" sections of job postings, these days the knowledge of JavaScript is a deciding factor when it comes to hiring web developers. After reading this book you'll be prepared to ace your JavaScript job interview and even impress with some bits that the interviewer maybe didn't know. You should read this book if you want to be able to take your JavaScript skills to a new level of sophistication.

Publication date:
July 2013
Publisher
Packt
Pages
382
ISBN
9781849693127

 

Chapter 1. Object-oriented JavaScript

Ever since the early days of the Web, there has been a need for more dynamic and responsive interfaces. While it's OK to read static HTML pages of text and even better when they are beautifully presented with the help of CSS, it's much more fun to engage with applications in our browsers, such as e-mail, calendars, banking, shopping, drawing, playing games, and text editing. All that is possible thanks to JavaScript, the programming language of the Web. JavaScript started with simple one-liners embedded in HTML, but is now used in much more sophisticated ways. Developers leverage the object-oriented nature of the language to build scalable code architectures made up of reusable pieces.

If you look at the past and present buzzwords in web development—DHTML, Ajax, Web 2.0, HTML5—they all essentially mean HTML, CSS, and JavaScript. HTML for content, CSS for presentation, and JavaScript for behavior. In other words, JavaScript is the glue that makes everything work together so that we can build rich web applications.

But that's not all, JavaScript can be used for more than just the Web.

JavaScript programs run inside a host environment. The web browser is the most common environment, but it's not the only one. Using JavaScript, you can create all kinds of widgets, application extensions, and other pieces of software, as you'll see in a bit. Taking the time to learn JavaScript is a smart investment; you learn one language and can then write all kinds of different applications running on multiple platforms, including mobile and server-side applications. These days, it's safe to say that JavaScript is everywhere.

This book starts from zero, and does not assume any prior programming knowledge other than some basic understanding of HTML. Although there is one chapter dedicated to the web browser environment, the rest of the book is about JavaScript in general, so it's applicable to all environments.

Let's start with the following:

  • A brief introduction to the story behind JavaScript

  • The basic concepts you'll encounter in discussions on object-oriented programming

 

A bit of history


Initially, the Web was not much more than just a number of scientific publications in the form of static HTML documents connected together with hyperlinks. Believe it or not, there was a time when there was no way to put an image in a page. But that soon changed. As the Web grew in popularity and size, the webmasters who were creating HTML pages felt they needed something more. They wanted to create richer user interactions, mainly driven by the desire to save server roundtrips for simple tasks such as form validation. Two options came up: Java applets and LiveScript, a language conceived by Brendan Eich at Netscape in 1995 and later included in the Netscape 2.0 browser under the name of JavaScript.

The applets didn't quite catch on, but JavaScript did. The ability to use short code snippets embedded in HTML documents and alter otherwise static elements of a web page was embraced by the webmaster community. Soon, the competing browser vendor Microsoft shipped Internet Explorer (IE) 3.0 with JScript, which was a reverse engineered version of JavaScript plus some IE-specific features. Eventually, there was an effort to standardize the various implementations of the language, and this is how ECMAScript was born. ECMA (European Computer Manufacturers Association ) created the standard called ECMA-262, which describes the core parts of the JavaScript programming language without browser and web page-specific features.

You can think of JavaScript as a term that encompasses three pieces:

  • ECMAScript—the core language—variables, functions, loops, and so on. This part is independent of the browser and this language can be used in many other environments.

  • Document Object Model (DOM), which provides ways to work with HTML and XML documents. Initially, JavaScript provided limited access to what's scriptable on the page, mainly forms, links, and images. Later it was expanded to make all elements scriptable. This lead to the creation of the DOM standard by the World Wide Web Consortium (W3C) as a language-independent (no longer tied to JavaScript) way to manipulate structured documents.

  • Browser Object Model (BOM), which is a set of objects related to the browser environment and was never part of any standard until HTML5 started standardizing some of the common objects that exist across browsers.

While there is one chapter in the book dedicated to the browser, the DOM, and the BOM, most of the book describes the core language and teaches you skills you can use in any environment where JavaScript programs run.

Browser wars and renaissance

For better or for worse, JavaScript's instant popularity happened during the period of the Browser Wars I (approximately 1996 to 2001). Those were the times during the initial Internet boom when the two major browser vendors—Netscape and Microsoft—were competing for market share. Both were constantly adding more bells and whistles to their browsers and their versions of JavaScript, DOM, and BOM, which naturally led to many inconsistencies. While adding more features, the browser vendors were falling behind on providing proper development and debugging tools and adequate documentation. Often, development was a pain; you would write a script while testing in one browser, and once you're done with development, you test in the other browser, only to find that your script simply fails for no apparent reason and the best you can get is a cryptic error message like "Operation aborted".

Inconsistent implementations, missing documentation, and no appropriate tools painted JavaScript in such a light that many programmers simply refused to bother with it.

On the other hand, developers who did try to experiment with JavaScript got a little carried away adding too many special effects to their pages without much regard of how usable the end results were. Developers were eager to make use of every new possibility the browsers provided and ended up "enhancing" their web pages with things like animations in the status bar, flashing colors, blinking texts, objects stalking your mouse cursor, and many other "innovations" that actually hurt the user experience. These various ways to abuse JavaScript are now mostly gone, but they were one of the reasons why the language got some bad reputation. Many "serious" programmers dismissed JavaScript as nothing but a toy for designers to play around with, and dismissed it as a language unsuitable for serious applications. The JavaScript backlash caused some web projects to completely ban any client-side programming and trust only their predictable and tightly controlled server. And really, why would you double the time to deliver a finished product and then spend additional time debugging problems with the different browsers?

Everything changed in the years following the end of the Browser Wars I. A number of events reshaped the web development landscape in a positive way. Some of them are given as follows:

  • Microsoft won the war with the introduction of IE6, the best browser at the time, and for many years they stopped developing Internet Explorer. This allowed time for other browsers to catch up and even surpass IE's capabilities.

  • The movement for web standards was embraced by developers and browser vendors alike. Naturally, developers didn't like having to code everything two (or more) times to account for browsers' differences; therefore, they liked the idea of having agreed-upon standards that everyone would follow.

  • Developers and technologies matured and more people started caring about things like usability, progressive enhancement techniques, and accessibility. Tools such as Firebug made developers much more productive and the development less of a pain.

In this healthier environment, developers started finding out new and better ways to use the instruments that were already available. After the public release of applications such as Gmail and Google Maps, which were rich on client-side programming, it became clear that JavaScript is a mature, unique in certain ways, and powerful prototypal object-oriented language. The best example of its rediscovery was the wide adoption of the functionality provided by the XMLHttpRequest object, which was once an IE-only innovation, but was then implemented by most other browsers. XMLHttpRequest allows JavaScript to make HTTP requests and get fresh content from the server in order to update some parts of a page without a full page reload. Due to the wide use of XMLHttpRequest, a new breed of desktop-like web applications, dubbed Ajax applications, was born.

The present

An interesting thing about JavaScript is that it always runs inside a host environment. The web browser is just one of the available hosts. JavaScript can also run on the server, on the desktop, and on mobile devices. Today, you can use JavaScript to do all of the following:

  • Create rich and powerful web applications (the kind of applications that run inside the web browser). Additions to HTML5 such as application cache, client-side storage, and databases make browser programming more and more powerful for both online and offline applications.

  • Write server-side code using .NET or Node.js, as well as code that can run using Rhino (a JavaScript engine written in Java).

  • Make mobile applications; you can create apps for iPhone, Android, and other phones and tablets entirely in JavaScript using PhoneGap or Titanium. Additionally, apps for Firefox OS for mobile phones are entirely in JavaScript, HTML, and CSS.

  • Create rich media applications (Flash, Flex) using ActionScript, which is based on ECMAScript.

  • Write command-line tools and scripts that automate administrative tasks on your desktop using Windows Scripting Host or WebKit's JavaScript Core available on all Macs.

  • Write extensions and plugins for a plethora of desktop applications, such as Dreamweaver, Photoshop, and most other browsers.

  • Create cross operating system desktop applications using Mozilla's XULRunner or Adobe Air.

  • Create desktop widgets using Yahoo! widgets or Mac Dashboard widgets. Interestingly, Yahoo! widgets can also run on your TV.

This is by no means an exhaustive list. JavaScript started inside web pages, but today it's safe to say it is practically everywhere. In addition, browser vendors now use speed as a competitive advantage and are racing to create the fastest JavaScript engines, which is great for both users and developers and opens doors for even more powerful uses of JavaScript in new areas such as image, audio, and video processing, and games development.

The future

We can only speculate what the future will be, but it's quite certain that it will include JavaScript. For quite some time, JavaScript may have been underestimated and underused (or maybe overused in the wrong ways), but every day we witness new applications of the language in much more interesting and creative ways. It all started with simple one liners, often embedded in HTML tag attributes (such as onclick). Nowadays, developers ship sophisticated, well designed and architected, and extensible applications and libraries, often supporting multiple platforms with a single codebase. JavaScript is indeed taken seriously and developers are starting to rediscover and enjoy its unique features more and more.

Once listed in the "nice-to-have" sections of job postings, today, the knowledge of JavaScript is often a deciding factor when it comes to hiring web developers. Common job interview questions you can hear today include: "Is JavaScript an object-oriented language? Good. Now how do you implement inheritance in JavaScript?" After reading this book, you'll be prepared to ace your JavaScript job interview and even impress your interviewers with some bits that, maybe, they didn't know.

 

ECMAScript 5


Revision 3 of ECMAScript is the one you can take for granted to be implemented in all browsers and environments. Revision 4 was skipped and revision 5 (let's call it ES5 for short) was officially accepted in December 2009.

ES5 introduces some new objects and properties and also the so-called "strict mode". Strict mode is a subset of the language that excludes deprecated features. The strict mode is opt-in and not required, meaning that if you want your code to run in the strict mode, you declare your intention using (once per function, or once for the whole program) the following string:

"use strict";

This is just a JavaScript string, and it's OK to have strings floating around unassigned to any variable. As a result, older browsers that don't "speak" ES5 will simply ignore it, so this strict mode is backwards compatible and won't break older browsers.

In future versions, strict mode is likely to become the default or the only mode. For the time being, it's optional.

For backwards compatibility, all the examples in this book work in ES3, but at the same time, all the code in the book is written so that it will run without warnings in ES5's strict mode. Additionally, any ES5-specific parts will be clearly marked. Appendix C, Built-in Objects, lists the new additions to ES5 in detail.

 

Object-oriented programming


Before diving into JavaScript, let's take a moment to review what people mean when they say "object-oriented", and what the main features of this programming style are. Here's a list of concepts that are most often used when talking about object-oriented programming (OOP):

  • Object, method, and property

  • Class

  • Encapsulation

  • Aggregation

  • Reusability/inheritance

  • Polymorphism

Let's take a closer look into each one of these concepts. If you're new to the object-oriented programming lingo, these concepts might sound too theoretical, and you might have trouble grasping them or remembering them from one reading. Don't worry, it does take a few tries, and the subject could be a little dry at a conceptual level. But, we'll look at plenty of code examples further on in the book, and you'll see that things are much simpler in practice.

Objects

As the name object-oriented suggests, objects are important. An object is a representation of a "thing" (someone or something), and this representation is expressed with the help of a programming language. The thing can be anything—a real-life object, or a more convoluted concept. Taking a common object like a cat for example, you can see that it has certain characteristics (color, name, weight, and so on) and can perform some actions (meow, sleep, hide, escape, and so on). The characteristics of the object are called properties in OOP-speak, and the actions are called methods.

There is also an analogy with the spoken language:

  • Objects are most often named using nouns (book, person, and so on)

  • Methods are verbs (read, run, and so on)

  • Values of the properties are adjectives

Take the sentence "The black cat sleeps on the mat". "The cat" (a noun) is the object, "black" (adjective) is the value of the color property, and "sleep" (a verb) is an action, or a method in OOP. For the sake of the analogy, we can go a step further and say that "on the mat " specifies something about the action "sleep", so it's acting as a parameter passed to the sleep method.

Classes

In real life, similar objects can be grouped based on some criteria. A hummingbird and an eagle are both birds, so they can be classified as belonging to some made up Birds class. In OOP, a class is a blueprint, or a recipe for an object. Another name for "object" is "instance", so we say that the eagle is one concrete instance of the general class Birds. You can create different objects using the same class, because a class is just a template, while the objects are concrete instances based on the template.

There's a difference between JavaScript and the "classic" OO languages such as C++ and Java. You should be aware right from the start that in JavaScript, there are no classes; everything is based on objects. JavaScript has the notion of prototypes, which are also objects (we'll discuss them later in detail). In a classic OO language, you'd say something like "create me a new object called Bob, which is of class Person". In a prototypal OO language, you'd say, "I'm going to take this object called Bob's dad that I have lying around (on the couch in front of the TV?) and reuse it as a prototype for a new object that I'll call Bob".

Encapsulation

Encapsulation is another OOP-related concept, which illustrates the fact that an object contains (encapsulates) both:

  • Data (stored in properties)

  • The means to do something with the data (using methods)

One other term that goes together with encapsulation is information hiding. This is a rather broad term and can mean different things, but let's see what people usually mean when they use it in the context of OOP.

Imagine an object, say, an MP3 player. You, as the user of the object, are given some interface to work with, such as buttons, display, and so on. You use the interface in order to get the object to do something useful for you, like play a song. How exactly the device is working on the inside, you don't know, and, most often, don't care. In other words, the implementation of the interface is hidden from you. The same thing happens in OOP when your code uses an object by calling its methods. It doesn't matter if you coded the object yourself or it came from some third-party library; your code doesn't need to know how the methods work internally. In compiled languages, you can't actually read the code that makes an object work. In JavaScript, because it's an interpreted language, you can see the source code, but the concept is still the same—you work with the object's interface, without worrying about its implementation.

Another aspect of information hiding is the visibility of methods and properties. In some languages, objects can have public, private, and protected methods and properties. This categorization defines the level of access the users of the object have. For example, only the methods of the same object have access to the private methods, while anyone has access to the public ones. In JavaScript, all methods and properties are public, but we'll see that there are ways to protect the data inside an object and achieve privacy.

Aggregation

Combining several objects into a new one is known as aggregation or composition. It's a powerful way to separate a problem into smaller and more manageable parts (divide and conquer). When a problem scope is so complex that it's impossible to think about it at a detailed level in its entirety, you can separate the problem into several smaller areas, and possibly then separate each of these into even smaller chunks. This allows you to think about the problem on several levels of abstraction.

Take, for example, a personal computer. It's a complex object. You cannot think about all the things that need to happen when you start your computer. But, you can abstract the problem saying that you need to initialize all the separate objects that your Computer object consists of—the Monitor object, the Mouse object, the Keyboard object, and so on. Then, you can dive deeper into each of the sub-objects. This way, you're composing complex objects by assembling reusable parts.

To use another analogy, a Book object can contain (aggregate) one or more Author objects, a Publisher object, several Chapter objects, a TOC (table of contents), and so on.

Inheritance

Inheritance is an elegant way to reuse existing code. For example, you can have a generic object, Person, which has properties such as name and date_of_birth, and which also implements the functionality walk, talk, sleep, and eat. Then, you figure out that you need another object called Programmer. You could re-implement all the methods and properties that Person has, but it would be smarter to just say that Programmer inherits Person, and save yourself some work. The Programmer object only needs to implement more-specific functionality, such as the writeCode method, while reusing all of the Person object's functionality.

In classical OOP, classes inherit from other classes, but in JavaScript, since there are no classes, objects inherit from other objects.

When an object inherits from another object, it usually adds new methods to the inherited ones, thus extending the old object. Often, the following phrases can be used interchangeably: "B inherits from A" and "B extends A". Also, the object that inherits can pick one or more methods and redefine them, customizing them for its own needs. This way, the interface stays the same, the method name is the same, but when called on the new object, the method behaves differently. This way of redefining how an inherited method works is known as overriding.

Polymorphism

In the preceding example, a Programmer object inherited all of the methods of the parent Person object. This means that both objects provide a talk method, among others. Now imagine that somewhere in your code there's a variable called Bob, and it just so happens that you don't know if Bob is a Person object or a Programmer object. You can still call the talk method on the Bob object and the code will work. This ability to call the same method on different objects and have each of them respond in their own way is called polymorphism.

 

OOP summary


Here's a quick table summarizing the concepts discussed so far:

Feature

Illustrates concept

Bob is a man (an object).

Objects

Bob's date of birth is June 1, 1980, gender: male, and hair: black.

Properties

Bob can eat, sleep, drink, dream, talk, and calculate his own age.

Methods

Bob is an instance of the Programmer class.

Class (in classical OOP)

Bob is based on another object, called Programmer.

Prototype

(in prototypal OOP)

Bob holds data (such as birth_date) and methods that work with the data (such as calculateAge()).

Encapsulation

You don't need to know how the calculation method works internally. The object might have some private data, such as the number of days in February in a leap year. You don't know, nor do you want to know.

Information hiding

Bob is part of a WebDevTeam object, together with Jill, a Designer object, and Jack, a ProjectManager object.

Aggregation and composition

Designer, ProjectManager, and Programmer are all based on and extend a Person object.

Inheritance

You can call the methods Bob.talk(), Jill.talk(), and Jack.talk() and they'll all work fine, albeit producing different results (Bob will probably talk more about performance, Jill about beauty, and Jack about deadlines). Each object inherited the method talk from Person and customized it.

Polymorphism and method overriding

 

Setting up your training environment


This book takes a "do-it-yourself" approach when it comes to writing code, because I firmly believe that the best way to really learn a programming language is by writing code. There are no cut-and-paste-ready code downloads that you simply put in your pages. On the contrary, you're expected to type in code, see how it works, and then tweak it and play around with it. When trying out the code examples, you're encouraged to enter the code into a JavaScript console. Let's see how you go about doing this.

As a developer, you most likely already have a number of web browsers installed on your system such as Firefox, Safari, Chrome, or Internet Explorer. All modern browsers have a JavaScript console feature, which you'll use throughout the book to help you learn and experiment with the language. More specifically, this book uses WebKit's console (available in Safari and Chrome), but the examples should work in any other console.

WebKit's Web Inspector

This example shows how you can use the console to type in some code that swaps the logo on the google.com home page with an image of your choice. As you can see, you can test your JavaScript code live on any page.

In order to bring up the console in Chrome or Safari, right-click anywhere on a page and select Inspect Element. The additional window that shows up is the Web Inspector feature. Select the Console tab and you're ready to go.

You type code directly into the console, and when you press Enter, your code is executed. The return value of the code is printed in the console. The code is executed in the context of the currently loaded page, so for example, if you type location.href, it will return the URL of the current page.

The console also has an autocomplete feature. It works similar to the normal command line prompt in your operating system. If, for example, you type docu and hit the Tab key or the right arrow key, docu will be autocompleted to document. Then, if you type . (the dot operator), you can iterate through all the available properties and methods you can call on the document object.

By using the up and down arrow keys, you can go through the list of already executed commands and bring them back in the console.

The console gives you only one line to type in, but you can execute several JavaScript statements by separating them with semicolons. If you need more lines, you can press Shift + Enter to go to a new line without executing the result just yet.

JavaScriptCore on a Mac

On a Mac, you don't actually need a browser; you can explore JavaScript directly from your command line Terminal application.

If you've never used Terminal, you can simply search for it in the Spotlight search. Once you've launched it, type:

alias jsc='/System/Library/Frameworks/JavaScriptCore.framework/Versions/Current/Resources/jsc'

This command makes an alias to the little jsc application, which stands for "JavaScriptCore" and is part of the WebKit engine. JavaScriptCore is shipped together with Mac operating systems.

You can add the alias line shown previously to your ~/.profile file so that jsc is always there when you need it.

Now, in order to start the interactive shell, you simply type jsc from any directory. Then you can type JavaScript expressions, and when you hit Enter, you'll see the result of the expression.

More consoles

All modern browsers have consoles built in. You have seen the Chrome/Safari console previously. In any Firefox version, you can install the Firebug extension, which comes with a console. Additionally, in newer Firefox releases, there's a console built in and accessible via the Tools/Web Developer/Web Console menu.

Internet Explorer, since Version 8, has an F12 Developer Tools feature, which has a console in its Script tab.

It's also a good idea to familiarize yourself with Node.js, and you can start by trying out its console. Install Node.js from http://nodejs.org and try the console in your command prompt (terminal).

As you can see, you can use the Node.js console to try out quick examples. But, you can also write longer shell scripts (test.js in the screenshot) and run them with the scriptname.js node.

 

Summary


In this chapter, you learned about how JavaScript came to be and where it is today. You were also introduced to object-oriented programming concepts and have seen how JavaScript is not a class-based OO language, but a prototype-based one. Finally, you learned how to use your training environment—the JavaScript console. Now you're ready to dive into JavaScript and learn how to use its powerful OO features. But let's start from the beginning.

The next chapter will guide you through the data types in JavaScript (there are just a few), conditions, loops, and arrays. If you think you know these topics, feel free to skip the next chapter, but not before you make sure you can complete the few short exercises at the end of the chapter.

About the Authors

  • Stoyan Stefanov

    Stoyan Stefanov is a Facebook engineer, author, and speaker. He talks regularly about web development topics at conferences, and his blog, www.phpied.com. He also runs a number of other sites, including JSPatterns.com - a site dedicated to exploring JavaScript patterns. Previously at Yahoo!, Stoyan was the architect of YSlow 2.0 and creator of the image optimization tool, Smush.it.

    A "citizen of the world", Stoyan was born and raised in Bulgaria, but is also a Canadian citizen, currently residing in Los Angeles, California. In his offline moments, he enjoys playing the guitar, taking flying lessons, and spending time at the Santa Monica beaches with his family.

    Browse publications by this author
  • Kumar Chetan Sharma

    Kumar Chetan Sharma studied to be an electronics engineer and has always wanted to build an ultimate sound system. He then, by chance, got a part time job as a trainee HTML guy. From there he picked up CSS and JavaScript and there was no looking back. It was the time when JavaScript was used to validate forms or create fancy DHTML effects and IE6 was the only browser the world knew. He has been developing web applications since then, using LAMP stack. He has worked on white label social networking applications to web control panels for telecom and networked electrical charger infrastructures. He currently works as a frontend engineer for Yahoo! Search.

    Browse publications by this author

Latest Reviews

(4 reviews total)
To much of the material is a history lesson rather than content orientated
No words, just a good read and on the dot.
Excellent
Book Title
Access this book and the full library for FREE
Access now