GettingStarted

Chapter 01 - Introduction

Here we cover basics facts about strategy, tools and theory. You learn enough to get started. After reading this page, you can move on to the page on JavaScript Basics.

General Considerations

The best programmers take pride in their code. The first step on the road to creating good code is to make it readable. This means:

• Carefully choose names for your identifiers
• Format your code in accordance with popular conventions
• Architect your code properly so it is easy to understand. (Use the right algorithms and patterns, and create the right objects and modules.)

After taking the above steps, check to see if you have a performance problem. If so, use a profiler to measure performance and find the slow spots. Then review your architecture and see if there are ways to speed things up.

Introduction to JavaScript {#introductionToJavaScript}

Large parts of the web are driven by three related technologies: HTML, CSS and JavaScript. Though the differences between the roles played by these technologies can blur at times, the following assertions will help you understand the primary purpose of each component:

• HTML files contain content such as text, bitmaps or videos
• CSS let's you define how the content should appear
• JavaScript allows you to perform actions that animate that content

It is possible to completely scramble these rolls. For instance, you can put content in JavaScript files and use HTML to define the appearance of your content. It is not, however, always considered good practice to do any of these things. Some good developers follow the guidelines for apportioning roles in most, but not all cases. I prefer, however, to take a hard line, and to insist that content, and content alone be placed in HTML files, that appearance be specified only in CSS files, and that JavaScript be used only to perform actions.

At this stage, I am keeping the terms I'm using deliberately vague. I have not rigorously defined what I mean by the "appearance" of a page, or what it means to performs an action with a JavaScript file. I believe, however, that I will succeed in making making these concepts clear over time. The reader simply has to have patience, and over time you should develop a clear and well defined understanding of the roles played by each of the three components of a web page.

Style Guide

My goal is to teach people with average abilities to write code. I picture the average reader of this material as being someone most people would label as "smart" or "intelligent." What does that mean? One could find define various metrics, most of which would be useless. Perhaps it would be helpful to talk about people who tested in the top third of their classes at school, minus the very top one or two percent. In some cases, people who tested well below that level could still learn from my text, but it will probably be the exception rather than the rule.

So why do I use the word average, if I mean someone in the top third of their class? Most people who become interested in programming are fairly intelligent. People who don't have good logical skills simply never get far enough in their computer studies to ever write a line of code. Or if they do get that far, they get discouraged very quickly.

There are, however, a lot of programmers who exhibit reasonable skill as programmers, but who struggle with the most advanced concepts. It is this group of people who I try to target what I write.

Programming is a profession that attacts some of the smartest people in the world. For good reason, the future of programming is often defined by people with extraordinary skills. I've been fortunate enough to meet a number of people with that kind of intelligence, and throughout this text I will frequently refer people to their web pages or pass on advice spoken or written by these elite programmers. These super smart people are not, however, the target audience for whom I write.

Performance vs Maintainability

There are several metrics that can be used to define great code. Our primary goal is to write a program that people want to use. That means it needs to be useful, fun, or appealing in some other sense. It must also be easy enough to use that people are willing to take the time to master it. Making our code useful and easy to use is a necessity, but those are really design issues, and not fodder for a purely technical work such as the one I'm writing here. This text assumes that you have a good idea, and a plan for its design. My goal is to help you realize those goals by helping your write good code.

There are three virtues shared by all good code: it is robust, fast, and maintainability. I rank these three virtues as follows. The best code is:

1. Maintainable
2. Robust
3. Fast

This may seem like an obvious hierarchy, but it is my experience that many developers actually rank these three virtues as follows:

1. Speed
2. Robustness
3. Maintainability

If confronted, many developers would agree that it is more important for code to be robust than it is for it to be fast. Nevertheless, when they actually sit down to write code, they end up prioritizing speed over everything else. They may not even be aware that they are doing it, but they are.

If your program crashes frequently, then it is unlikely that anyone will want to use it. So that is our first priority. The problem is that some people are so determined to make their code fast, that they end up sacrificing reliability on the alter of speed. This is not a good outcome. Your code must be robust or few will want to use it.

It happens that code that is not easy to maintain is rarely robust. A developer who seeks to fix a bug must understand not only how to fix the bug, but what impact that fix will have on the rest of the program. In other words, your code must be maintainable if it is going to be robust. Seen from this perspective, our ranking needs to be as follows:

1. Maintainablity
2. Robustness
3. Speed

Our primary goal is to make our code robust, but we can't achieve that end if we don't first make our code maintainable. In many ways, the art of writing robust code is the art of learning how to write code that is maintainable, that is easy to understand. If you can create code that is both maintainable and robust, then you will be able to refactor it in ways that also make it fast.

So far, we have advanced through to layers:

1. The top layer is about design and usability
2. The next layer is about performance, robustness, and maintainability

It is turns out, however, that there is a third factor that needs to be kept in mind when you are learning how to write code. Ultimately, your ability to write good code depends upon your understanding of two things:

1. Good programming principles
2. A deep understanding of your tools and language.

By programming principles I'm talking about things like:

• Agile Design
• Program Architecture
• Team dynamics
• Testing
• Communication

Once again, those subjects, though very important, are a bit outside the scope of this work. I will try to always encourage the use of good programming principles, but I will not always take the time to define them. I will however, work hard to make it easy for you to understand how the tools and language that you are going to use work. In particular, in these pages, I will try to give good, deep explanations of how JavaScript works.

Having a deep, intuitive, understanding of JavaScript is crucial if you want to write good code. You will constantly be forced to make implementation decisions when you write code. You will not be able to make any of those decisions unless you first have an understanding of features are available in the language, and when and how to use them.

Some Caveats

Having laid out the goals and principles on which we shall be working, I think it is important to make some additional points.

Some advanced students will find points in my text where they might think: "Hey, I know a better way to do that! My way uses less code, or my way saves 10 clock cycles." All that is good and well, but is the code that you propose also both maintainable and easy to understand? Are you sacrificing maintainability on the alter of speed? In some cases, I may in fact know about that "better way," but I have chosen to stick to a simple, easier to understand syntax in order to teach people how to write robust, easy to maintain code.

In saying this, I'm not trying to create an impenetrable boundary behind which I can hide. Of course, there will be cases where there really will be a simpler and easier way to do something than the one I show. If you think you have found a better way to do something, then please write me and let me know. Before you write, however, consider whether your code is not only small and fast, but also easy to read, and easy to maintain. For me, these virtues are more important than brevity or performance. This does not mean that I don't take brevity and performance into account, but only that they are not my first priority.

I believe many of these developers are quite capable of creating good programs that would meet their own needs and the needs of most users. However, they never achieve their goals because they are too focused on performance. In short, they are aiming to high. They want to make their code impossibly fast, and end up creating programs that no one, not even themselves can maintain. As a result, they fail. My goal is to define a style of programming that can help these developers achieve their goals.

Creativity

There are various metrics by which we can define someone's talents. For instance, some people who have enormous analytic abilities and poor creative talents. Other people are very creative, but lack analytic ability.

Anyone with great analytic and logical ability is likely to succeed in the programming profession. But people with a strong creative bent often lack the analytic skills necessary to help them write good code and bring their ideas to fruition. One of my goals is to help people like this succeed.

Here is a story that might help to make this point clear. I like jazz, and I've spent a good deal of time reading interviews with Jazz musicians. One of the musicians at the top of the jazz field is Pat Metheny. To me, he is someone who seems to have it all: he is very creative and technically superb. Or at least that is how I perceive him. However, I was surprised one day when I read an interview with him in which said that he frequently encountered musicians with technical chops that far exceeded his own. If I understood him correctly, he was saying that it was his intense work ethic combined with strong creative skills that made him successful.

Pat Metheny does in fact have very strong technical chops, more than he was willing to own up to in that particular interview. Nevertheless, I think the story has a lesson that is worth remembering: it is not always purely technical skill alone that counts. Your discipline, creativity, business smarts, or good idea will never be worth anything if you can't bring your idea to fruition. My goal is to teach a manner of programming that people of "average" talent can use to help them acomplish their goals.

Be Practical

Let me try one final approach to this subject before moving on. The techniques that outline in my text are one's that I have learned from personal experience. Many times I have started writing a program, only to find myself bogged down in details that threatened to overwhelm me. Over time I began to sense that I was trying to emulate code that was brilliant, but that contained featuires not really needed in my particular case. I could achieve my goals by stripping away layers of complexity. At times that meant I had to limit the features in my program, but frequently these features were not nearly as important as they were costly. In the end, I ended up with a shorter, simpler program than the one I initially meant to write. But my program worked and my users liked it. Oddly enough, on the few occasions when I had to the chance to show my work to one of the super smart programmers discussed above, they too liked what I had done. Yes, they probably could have written a fancier program, but they were practical people. They saw that my code worked, and that I had found a way to bring a unique idea to fruition. In short, I was much better off with a robust program that worked, than with a flakey program that was cool but not reliable. And when they looked at my code, they rarely complained. It was simple but robust. It is hard to criticize code that works! Often simple code that works is better even than fancy code that works, but which is entirely unmaintainable due to its complexity. But now I am getting ahead of my subject.

To sum up the topic covered in this part of the text, I would say the following: A lot of good developers have missed their chance to create a useful or important program because they have focused too much on writing "clever" code that is fast and small, but which is also hard to debug, maintain and understand. Instead of focusing on speed and size, focus on the following concepts, and others that will be developed throughout this text. Write code that:

• is easy to read
• is easy to maintain
• Contains only absolutely necessary features
• Sacrifices features that will be used by only a small percentage of users
• is aligned with best practices, especially those outlined by the Agile school of development

Some Links

Consider using a JavaScript style guide:

• http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
• http://contribute.jquery.org/style-guide/js/
• https://github.com/rwldrn/idiomatic.js/

Hello World in the Browser {#helloWorldInTheBrowser}

JavaScript can be written as a standalone script that runs from the command prompt like a batch file or shell script. It can also be run as server side code like Python or PHP via a relatively new technology called nodejs. Most commonly, however, JavaScript is imbedded in or attached to an HTML file.

In Listing 01, for instance, you can see a very simple "Hello World" program that uses JavaScript. You can save this file as VerySimple.html.

Listing 01: Hello world in JavaScript.

<!DOCTYPE html>
<html>

<head>
 <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
 <title>Very Simple</title>
 <script type="text/javascript">
 document.writeln("<p>A very simple JavaScript Hello-World program.</p>");
 </script>
</head>

<body>
</body>
</html>

What are you supposed to do with this file? Well, you can open it in a web browser, and see the output that it produces. This is usually simply a matter of using the Windows Explorer or some similar tool to locate your file. Then you can double click on it, or right click and choose "Open with..." Because the file has an HTML extension, it should open automatically in a web browser or allow you to choose the browser in which you want to run it. Most browsers will also let you choose File | Open from the menu and browse for the file you want to open. If you are using Chrome, press Ctrl + O to open a file.

Figure 01: The VerySimple02.html file running in Chrome.

You can see the path to the file in the address bar. This is a normal Windows path with slashes rather than back-slashes. Notice also that it is prefaced with the code file:///. Later you can learn how to set up a web server to publish your code, but for now, it is fine to just browse for the file on your hard drive.

In the above example, the JavaScript is embedded in the head element. Alternatively, you can place your JavaScript smack dab in the middle of your HTML:

<!DOCTYPE html>
<html>
<head>
 <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
 <title>Very Simple</title>
</head>
<body>
        <script type="text/javascript">
               document.writeln("<p>A very simple JavaScript Hello-World program.</p>");
        </script>
</body>
</html>

I prefer, however, not to put HTML and JavaScript in the same file. Instead, I create two or more files: one for my html; one or more for my JavaScript. I then provide a link from the <head> element in the HTML to my JavaScript file or files:

Listing 03: The HTML File

<!DOCTYPE html>
<html>

<head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    <title>Very Simple</title>  
    <script src="VerySimple.js" type="text/javascript"></script>
</head>

<body>    
</body>
</html>

Listing 04: The JavaScript file: VerySimple.js.

document.writeln("<p>A very simple JavaScript Hello-World program.</p>");

Note: You can download this sample from here.

NOTE: When running the code in Listings 03 and 04, you should be sure to put both files in the same directory. For instance, you may have a folder called C:\Src where you store your source files. Put both files in that directory:

C:\Src\VerySimple.html
C:\Src\VerySimple.js

I believe it is nearly always best not to put your JavaScript code in the same file as your HTML. I believe this, despite the fact that there is nothing inherently wrong with putting JavaScript and HTML in the same file. Certainly your code will work if you follow that pattern. However, I consider it a good practice to always separate your HTML code into three files:

• Put your content in HTML files with an HTML extension: MyFile.html
• Put your presentation code in CSS files with a CSS extension: MyFile.css
• Put your JavaScript in JavaScript files with JS extension: MyFile.js

If you need to use the same CSS or JavaScript in multiple HTML files, then it is obvious that it is best to put that CSS or JavaScript in a separate file. Otherwise, you would be forced to endlessly repeat the same code in multiple HTML files. Then, if you wanted to fix a bug in your JavaScript or CSS, you would need to fix it in each HTML file that included the code. In a large web site, that might mean you would need to edit thousands of HTML files just to make one simple fix.

But suppose you CSS or JavaScript that you only wanted to use in one file? Why should you split them up into three files? Wouldn't it mean that:

• Your code ran faster because there would be one download instead of 3?
• It would be easier to make sure that code that belonged together never got separated?

The answer to both these questions is yes. And still, despite these arguments, I think you should always separate your code out into three files. I believe this for the following reasons:

• It promotes good habits
• More often than you think, there will come a time when you will want to use the CSS or JavaScript in a second HTML file. If it is not already split out into multiple files, then you will get lazy and copy it from one file to another, ending up with duplicate code.
• Ultimately, it is easier to write good clean, easy to read, and easy to maintain code if you don't mix different types of source in a single file
• And finally, there are tools that can be run over HTML files before you release them that will automatically consolidate them into a single file.

NOTE: This last point is not really as good an argument as it sounds. Ultimately, I believe you are better off with a maintainable code base that runs a bit slow, than you are with a fast code base that is impossible to understand, maintain or improve. Furthermore, most developers who try to optimize their code end up spending hours, days, or even months fussing with code in order to save milliseconds that the user never notices. The rule you want to follow is simple: unless you can see obvious, and certain, proof that you have a performance problem, you should not waste time trying to optimize your code. Instead, focus on writing clean code that is easy to maintain. One thing we know for certain: users always prefer code that works and has the right features to code that does not work and lacks key features. If you write messy, hard to maintain code, you will nearly always find it harder to add features to that code base than it is to add features to well written programs.

The Case of File Names {#theCaseOfFileNames}

I should say a word about the case of the file names I create. There are six different ways to name files, three of which are wrong, and three of which are right:

1. file01.html
2. vrysmpl.html
3. verysimple.html
4. very_simple.html
5. very-simple.html
6. VerySimple.html

The first example is wrong because the name has no meaning: it tells you nothing about the contents of the file. The second name is wrong because it contains abbreviations. Twenty years ago developers used abbreviations to save space on machines where memory or hard drive space was scarce, or where operating systems did not support names with more than 8 characters. This is no longer necessary for a variety of reasons, and now abbreviations are merely a sign that developers are too lazy to type out the whole word. (To every rule, there are exceptions, and there are occasions when the code in very short methods is easier to read when it makes use of abbreviations. But those are the exceptions to a good rule, and there is rarely a case where any good is accomplished by showing newcomers such shortcuts.) The third example is wrong because it provides no means of helping the reader to separate out the face that verysimple is a name consisting of two words.

The fourth example is correct, but is now considered a bit old fashioned. Most people prefer using a dash, rather than an underscore, because they believe it is easier to type. In either case, the basic strategy is good, because there are no abbreviations, and the words are cleanly separated. The whole issue of case is moot in this strategy, since all letters are rendered in lower case. The last example is the one I prefer, because it is most familiar to me, and I find it easier to read a long list of names rendered in this format. It uses Pascal casing, where multiword names are run together into one name, and each word in the name begins with a capital letter.

NOTE: One good argument from the folks who prefer using dashes to using Pascal casing runs as follows. Suppose you have a common acronym such as IBM. Perhaps you have method from IBM that performs fast addition. You would want to call this method IBMFastAddition. This name runs the words IBM and Fast together into one name and thereby breaks an important rule about clearly delineating the words in a name. I therefore would name this method IbmFastAddition; now we can clearly see that Ibm is meant to be treated as a discreet unit. In fact, I always treat acronyms this way: I capitalize the first letter and put the other letters in lower case. This system works, but some find it less than optimal. If you used dashes, you could write something like this instead: ibm-fast-addition. This is arguably easier to read than the Pascal casing example. But I don't find so terribly much difference, and sometimes I think Pascal casing is easier to read. For instance, I think SimpleHtmlToElvenwareConverter is easier to read than simple-html-to-elvenware-converter. But gosh, it is a silly thing to get upset about. I distrust anyone who gets overly excited about such issues. I think even great programmers, such as Douglas Crockford, do little more than display their rare blind spots when they get overly exercised over issues that so clearly are more matters of taste than of science. In fact, I have seen people foolishly ignore Crockford's many strengths because he is so obviously overly zealous in this one area. He's doing more harm to himself than good by being so narrow minded.

Ultimately, the choice you make between the last three "correct" examples is a matter of personal taste. There are only two primary caveats you need to keep in mind:

• Whatever strategy you pick: stick with it! Once you have decided on a strategy then you, and everyone who works with you, must stick to that strategy in all the code you produce.
• If you go to work for a shop that has already adopted a strategy, then you must happily conform with it. A good manager will work with you, and have patience while you come to see the error of your ways. Bad managers will simply make your life miserable until you either come to your senses or move on. In either case, there is no question that it is irrational and counter productive to create code that uses a style that does conform to the needs of the others in your group.

The case of a file name is one thing, but the case of formatting code in a source file is a different matter. Almost all languages have an agreed upon style of casing, indentation, etc. You should make a real effort to discover the strategy for the language you are using, and to follow it as best you can. In this document, I attempt to follow the standards for formatting JavaScript code. With a few minor exceptions, if you see me vary from what you consider to be the best strategy for formatting JavaScript, then please send me email and let me know. My goal is to conform to the standards set by the JavaScript community. If I want to assert my individuality, I wrote prose or poetry; when I write code, I try to conform to standards. The only case for individuality in code is the case for writing the cleanest, easiest to understand code of any developer on your team. There is no place for a quirky style of capitalization or indentation.

A Simple JavaScript Development Strategy {#aSimpleJavaScriptDevelopmentStrategy}

JavaScript run in the browser has one set of rules when run in a browser, and another set when run outside a browser. If you are using JavaScript primarily to write client side scripts meant to be run in a browser, then it is best to learn JavaScript, and develop JavaScript, under that scenario. It is true that there are legitimate and important ways to run JavaScript from outside the browser. For instance, you can run JavaScript from the command prompt, or directly from inside some IDEs. At first, however, such stratagems can lead to much confusion. As a result, I suggest that you begin by developing JavaScript inside a browser.

NOTE: I should probably qualify what I say above. The basic syntax of the language does not change when you switch from a browser to some environment. (The only exception, of course, is when a browser has a buggy implementation of JavaScript, and that still happens quite frequently.) But even when everything works correctly, certain key features of the language, such as the this keyword, have a different significance inside a browser and outside a browser. Also, key elements of the API, such as the alert function, are available in a browser and not outside a browser. These and other differences become manageable when you gain proficiency in the language, but at first, it is best to avoid such subtle pitfalls by running JavaScript in the environment in which you intend to use it. Of course, if you are intending to write mostly server side JavaScript with nodejs, then this advice is less convincing. I do not think there are serious disadvantages to learning JavaScript in a browser even if you want to use it on the server side, but you will find that there are differences. In general, I think it is easier to move from the browser to nodejs, than it is to move from nodejs to the quirky world of browsers.*

It turns out that the code you saw in the previous section provides a good framework for beginning and intermediate level JavaScript programmers who want to learn more about the langauge. Start out by opening up code similar to what you see in Listing 3 and 4. As a matter of fact, you can simply reuse VerySimple.html over and over again. As we explore the JavaScript language, all you need do is change the name of the JavaScript file that you are linking in. For instance, linking VerySimple01.js for one program, then VerySimple02.js for the next program. Better yet, follow best practices and rename each JavaScript file to reflect its contents. For instance, ExploringLoops.js would be a good name for a JavaScript file that you created when you wanted to learn about how loops are written in JavaScript.

Before leaving the subject of how to structure your code, there is one last subject to cover. A key tool developers use when debugging their code, and when they are exploring JavaScript, is a call to console.log:

console.log("This is a a debug message");

Console.Log {#console.Log}

You can use console.log to log debug information.

console.log('This line of code executed');

If you run your JavaScript in a browser, then use the Browser's debugger to view the results. For instance, in Chrome, press F12 to bring up the Developer Tools. Then turn to the Console page. If you are using a command line tool like node, then you can see the results at the command line itself.

Suppose you are a beginning level JavaScript programmer who wants to learn how to write a function that adds numbers. Now it is a good and admirable thing to want to design an HTML file that will allow the user to enter numbers, push a button, and display the result of an operation on those numbers. However, in this life there is a time for everything, and lets suppose that right now you don't want to focus on inputting or displaying numbers: you just want to write a method called addand see if it works. Here is how you can use console.log to help you reach your goal.

Begin your the same basic HTML file described above:

Listing 05: The HTML File

<!DOCTYPE html>
<html>

<head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    <title>Very Simple</title>  
    <script src="calculator.js" type="text/javascript"></script>
</head>

<body>    
</body>
</html>

As you can see, the code shown in Listing 5 is similar to the code found in Listing 3. The only difference is that the source file linked in is called Calculator.js rather than VerySimple.js. Here is the code for Calculator.js:

Listing 06: Code that uses console.log.

    function add(a, b) {
        return a + b;
    }

    window.onload = function() {  
      var sum = add(2, 3);
      console.log(sum);
    };

Launch your HTML file in Chrome. Press F12 or Ctrl-Shift+I to open the Developer Tools and turn to the console page. You should see the output from any of your console.log statements in the console window. Note also that the console window allows you to add arbitrary statements that will be run against the JavaScript on your page.

Figure 0X: The Chrome JavaScript Console window.

In the screen shot, you can see the output of the call to console.log. I have also used the Chrome console window to explicitly type in some code:

add(6,12)

After typing this code, my JavaScript method is called, and the result of the call to the add method is shown. This technique can be used to help you debug your JavaScript code without having to create an interface for your program.

Note: You can also use qUnit to write unit tests that can help you debug your code. I typically use both console.log and qUnit. However, if I were forced to choose between the two techniques, then I would choose qUnit or some other unit test framework. I am not forced to make that decision, so I use console.log and qUnit. But if I were forced to choose, I would choose unit testing over logging. Ultimately, unit testing is a more robust solution. In particular, it is easy to automate unit tests, while there is no simple way to automate checking the results of calls to console.log. You can visually confirm the results, but that is not that same as getting an automated error report such as you get from qUnit.

Learn More {#learnMore}

Here is a rendering of the hidden code that prints the first two lines found on this page:

<div>
<script type="text/javascript">
 document.writeln("<p>Hello world!</p>");
 document.writeln("<p>These lines written using JavaScript.</p>");
</script>
</div> 

This code changes the page you are viewing by inserting two lines of text when the document loads. Because the change occurs as the document is first loaded, you are not aware that an action is being performed. Nevertheless, this is a dynamic event, and not a static rendering of text as you see in standard HTML. For a more dynamic example of how JavaScript can change the appearance of a page, see the next section, called Insert Adjacent HTML.

The code shown above is embedded in this document directly below the caption that reads JavaScript Basics. Right click this document and choose View Source to see it.

NOTE: It is important to understand that the text you see above is not the actual code that gets executed. The real code is inside this HTML page, but hidden from view. Whenever you include an angle bracket: <> in your HTML, then the words inside those brackets are called a tag, and they become hidden from view when the page is rendered in a browser. In this case, all the words between the opening <script> and closing </script> tags are considered part of the script tag, and are hidden from view. To show an angle bracket to the reader of an HTML page, you write the following code: < or >. The first bit of code is an open angle bracket, and the second a close angle bracket. HTML is pretty simple and straight forward most of the time, but this is one of those places where it can be a bit hard to understand what is going on if you are a newcomer. Nothing will better help you grasp these concepts than actually getting your hands dirty and writing some code. Sometimes you can learn best by doing.

Install the JavaScript ChromeTools Debugger in Eclipse:

http://code.google.com/p/chromedevtools/wiki/HowToInstall

The Right Tools {#theRightTools}

There are some wonderful tools out there for developing big applications with HTML and JavaScript. Three that I use frequently are Eclipse/Aptana, Visual Studio and Expression Web. (You can substitute DreamWeaver for Expression web if you can afford it.)

If you are writing the kind of simple program needed to follow along with this text, however, I think it is simplest to use the following tools:

• notepad++
• chrome

The Right Books

Good books to read on JavaScript.

• The gold standard is JavaScript the Good Parts by Douglas Crockford. It is a tough read, but it is the pivotal book about JavaScript that taught everyone how to properly use the language.
• Maintainable JavaScript, by Nikalas Zakas, the author of JavaScript for Web Developers. MJ is a short book that is easier to read than JGP, but which follows much of the advice found in Crockford's book.
• Secrets of the JavaScript Ninjas by jQuery's John Resig is an excellent book. A bit heavy going in places, but full of excellent advice.
• Eloquent JavaScript: An in depth look at the language available on the internet.
• JavaScript, the Definitive Guide by David Flanagan. Considered the book on JavaScript by many.
• The Principles of Object Oriented JavaScript by Nikalas Zakas. If you wish JavaScript were C#.... Includes numerous insights into how JavaScript is structured. I couldn't put it down.

I also want to read JavaScript Patterns by Stoyan Stefanov and I am currently reading Functional JavaScript. The latter book is very good, but perhaps too advanced for most of us.

• Google IO
• Scott Hanselman
• JavaScript Blogs
• 33 Developers to follow

Hello World at the Command Prompt {#helloWorldAtTheCommandPrompt}

If you want to learn JavaScript, it can be helpful to start with a command line utility. One possible course of action is to install node, and run scripts from the command prompt:

• Node on Elvenware

Another solution is to install Rhino:

sudo apt-get install rhino
rhino-jsc

Built into Windows is a tool called cscript.exe. It is nice, but don't not always do what you want. For instance, console.log does not appear to be defined. Instead you need to use something like WScript.Print "Foo".

For Mac types, see:

• http://www.phpied.com/javascript-shell-scripting/